MUSEUM-L Archives

Museum discussion list

MUSEUM-L@HOME.EASE.LSOFT.COM

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:
Leonard Will <[log in to unmask]>
Reply To:
Museum discussion list <[log in to unmask]>
Date:
Tue, 5 Apr 1994 09:53:50 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
I have been interested to read many of the postings on MUSEUM-L which
give good advice on data organisation and design. I am at present working
with a consortium of UK museums in a project to develop a comprehensive
collections management system (called LASSI - LArge Scale Systems Initiative -
in case you hear it referred to elsewhere).
 
I am ex-staff of the Science Museum, London, and am working with the
museum team to help interpret museum needs to the consultants who have been
engaged to design the system.
 
There are two points on which I would be very interested to have views:
 
1. Data models. Jim Croft mentioned work done by ASC (Association of
Systematics Collections and the Smithsonian, and Stan Blum's interest. I
shall follow these up. (Could Stan Blum get in touch with me please if he
is monitoring this list?) Do other readers know of other models which are
worth looking at? I know of the work done by CIDOC (the International
Committee for Documentation of the International Council of Museums). What
do you use yourselves? Do you know of any system which has really been
brought to fruition based on a rigorous data model, or are most of the
systems using this approach still at the planning stage (which seems to
run and run ...)
 
2. Relational databases. I fully agree with the recommendations that a
relational (or object oriented) database is the likely system for the
future, but I wonder about the point which Jim Croft picked up that such
systems are not good at handling chunks of text. This is my main concern.
I saw a demo of a large and much-hyped relational data base a year or so
ago in which the salesman had to admit that there was no way of editing
a few lines of text in an input screen, and that it had to be exported
to a word processing package such as Word Perfect to make a few changes.
 
Most RDBMS packages seem to have a "memo" field, though perhaps only one
such field per table, and this seems a potentially serious constraint on
what curators can write. A "free-text" package may be "bolted on" to
process such fields and make their contents searchable, but they do not
seem to be fully integrated with the rest of the system. You are either
searching "text" or "structured fields" and have to switch systems to
change from one to the other rather than being able to mix them freely
in a search query.
 
Is there no system which gives the economy and convenience of splitting
data into relational tables but without the restriction of fixed-length
fields? Am I worrying about this unnecessarily? Can almost all object
records be chopped into chunks of 256 characters or less, to fit into
limited-length fields?
 
Database systems such as Pick have true variable-length fields
throughout, but though you can have "joins" they don't conform to the
strict "relational" definition, and thus seem to be going out of favour.
Are relational systems now efficient enough that we can have the elegance
of using them fully and forgetting about "subfields" or "multi-valued"
fields, or are these concepts still necessary for performance purposes?
 
 
Leonard Will
 
--
Leonard Will                                Tel: +44 81 366 7386
Information Management Consultant           Fax: +44 81 366 0916
27 Calshot Way, ENFIELD, Middlesex          Email: [log in to unmask]
EN2 7BQ, United Kingdom

ATOM RSS1 RSS2