Date:         Wed, 4 May 2005 21:52:41 -0400
Reply-To:     Association for Recorded Sound Discussion List
              <[log in to unmask]>
Sender:       Association for Recorded Sound Discussion List
              <[log in to unmask]>
From:         "Steven C. Barr" <[log in to unmask]>
Subject:      Re: Cataloging sound recordings
Comments: To: Association for Recorded Sound Discussion List <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

----- Original Message -----
From: "Matt Snyder" <[log in to unmask]>
> Another underlying issue, which to me seems to be the elephant in the
> room, is that nobody is making the rather important distinction between
> cataloging and discography. I wouldn't 't expect a MARC catalog record to
> tell me who was conducting a particular recording of a Beethoven piano
> concerto, but that is exactly the sort of information that I would expect
> out of a good discography. No matter what anybody here says, MARC
> cataloging as we have known it is here to stay for quite a long time, if
> only because it is an international standard and such things have their
> own substantial momentum.  We CAN, however, definitely work on improving
> the accuracy and production methods of discographies. See
> www.jazzdiscography.com for further expounding on this topic, at least on
> the jazz end of things.
Having been interested in discography since 1973...digital databases since
first encountering dBASE III+ in 1989...and spent many years trying to
create "the best of both worlds"...yes, there is a definite difference!

Cataloguing databases refer to actual, physical entities...these being
the phonorecords that are held by a particular individual or institution.
As such, they include fields only applicable to these specific phonorecords:
items like Condition, Damage, Price Paid, Acquisition Date and similar, as
well as information on where they specific item is stored. From a strictly
technical standpoint, these databases do not need to include detailed
discographic information; presumably, the catalog user can obtain that data
from the phonorecord itself, after establishing the collection includes
a copy and accessing it.

Discographic databases, on the other hand, contain data on a theoretical
entity rather than an actual once. Thus, they do not need the fields which
apply to actual copies of the phonorecord...only the phonorecord as a
representative of a class of objects (i.e. all copies of Victor 21375).
Therefore, they need all (or as many as practical) the fields containing
discographic data (Catalog #, Matrix #, Issued takes, Dates of recording/
release, etc.)

These two separate entities cross paths in at leat two situations:

1) When the owner and cataloguer of the collection is a dedicated
discographer (as in my case). In this situation, the owner includes
all, or as many as practical, of the fields containing discographic
data...and all (or, etc.) the fields applying to the specific
instance of the record being catalogued. Some collectors or
institutions will want this, while others think of it as too much
effort.

2) When catalog databases are made available on-line, users will be
either trying to establish where a copy of a specific phonorecord
can be accessed...or looking for discographic data (for any number
of reasons, including cataloguing their own copy).

Since I am both a collector and discographer, my personal database
file (sadly, less than 1% complete) includes both cataloguing and
discographic data (and the requisite fields therefor). This
basically becomes a decision of the cataloguing party as to what
is to be included. A further complication is that most libraries
already catalog books, using specific software designed for that
purpose...and logically want all the items in their holdings to
be included in the same database.

That said...does MARC function like XML, in the sense that fields
specific to the needs of the cataloguer can be created and filled?
Or does it come with a specific set of fields which must be used
"as is?" I used to have a small sample MARC file someone sent more
for analysis, just to see how the program worked; dunno if I still
have it or not.

Steven C. Barr