Actually, I think you may be right, and you certainly won't be
castigated ("shot") for speaking your mind.  Remember, though,
what is important here - the museum personnel reading this may
not themselves be programmers, and their institutions may not
even have programming resources on site, but these personnel
and institutions DO understand the material they are
cataloguing, and the requisite information that must be
managed.  These functional definitions dictate, in my mind, the
direction any technological solution will take.

Take as an example the situation that got this whole thread
going.  The knowledge of how dates must be handled in relation
to the items being catalogued is the key (IMHO) to what
solution makes the most sense.  If a certain degree of dating
accuracy is necessary, or if queries on the data involve a
certain range of dates with a certain amount of variance -
these functional needs will determine whether an simple integer
field can handle the requirements, or a different approach is
required (i.e. a .DLL with formatting, verification and parsing
capabilities).  The cataloguers themselves probably won't
create 100% of most tools, but they must understand 100% of
what it does.

I certainly didn't mean to get carried away with the mechanics
of the particular example we were discussing - the important
thing is that there are always more solutions to a problem than
one thinks.  Thanks for your comments.

Charlie Karukstis
[log in to unmask]