Re: [ARSCLIST] More on cataloging

["Steven C. Barr" <stevenc@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Copeland, Peter" <Peter.Copeland@xxxxx>
To: <ARSCLIST@xxxxxxxxxxxx>

> Dear All,
>     And I would add that not only does the data need to be consistent, but
the file(s) need to be accompanied by a text-based document (which can then
be converted - for example, to Word for Windows). This document lists the
various procedures for entering the data, so the data becomes "consistent"
by default, while being based on ASCII text it should permanently be
readable however word-processors may evolve in future.
>     Each field in the database is given a name, and its function is
defined and its internal syntax described. Thus a performer or composer will
be entered surname-first (for sorting or indexing purposes). But I also find
I need a "Notes" field, for any unstructured extra information.
>     I don't know dBaseIII, I only use dBaseII. This software allows one to
find the name "Bloggs" whether it's a forename or a surname! And, being an
ASCII-based program, I can also write software (in dBase's own language) to
generate text-only files of any or all of the data - depending how I write
the program.
>     I feel that both the "phonorecords" feature mentioned by Steven Barr
and his "discographical" features are both incorporated. But I admit I am a
nerd, and this would not be suitable for general use by anybody. However, so
long as people can read, printouts may be made at any time for "general
use". My printout software is written so the whole thing is a practical
number of sheets of paper, with blank spaces programmed to be ignored, and
other features (such as indents) to make it instinctively readable.
===
First: what is needed (and I have been trying to promote ARSC involvement in
this) is
some sort of standardization of the data fields used in phonorecord
cataloguing, as
far as type and minimum size. Were this to be done, it would establish the
possibility of data interchange and data archival my merging different
catalog
files into an archival "uberfile!"

Second: dBASE II does offer some programability; however, subsequent
versions of dBASE offer additional capabilities (commands, etc.) and
much simpler interfaces. As well, II files are not directly compatible with
newer versions; in fact, this is true to some extent for each version. I
have III+, IV, V and V for Windows. If header data can be expunged,
what is left are essentially "random-access" data files, but with a
record-separation byte which must be allowed for.

Third: although dBASE is a relational database application, it is
not that easy to set up relational databases, and far from intuitive.
MS Access, OTOH, makes it so easy that users often can't
totally understand the details of what they are attempting!

I do agree (although I haven't taken the time to do this) that each
catalog/database should include some explanatory text covering
field details!

Finally, I use the term "phonorecord" simply because discussion
of databases and tables, made up (as they are) of data records
describing "records" can otherwise become hopelessy confusing!
For example, each C8T file contains 160-byte records, two of
which are needed to document a record...

Steven C. Barr