Re: [ARSCLIST] Clarification (was Re: A wiki-discopedia?)

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

Again, see end...
----- Original Message ----- 
From: "Jon Noring" <jon@xxxxxxxxxxx>
> Based on a private reply, I need to clarify what I meant by a
> "wiki-like" system for our centralized 78 discography system:
> *****
> We have to remember that discographical data is "data", not "text",
> and it is important that it be normalized, properly structured, etc.
> 
> If we make our discography strictly text-based (like what Brian Rust
> did), that's worse than no data at all, even if we try to normalize
> the text structure.
> 
> We also have to properly deal with "exceptions" to the dominant model
> of how 78 discographical data is "structured."
> 
> For example, we have the Benny Goodman recording of "Popcorn Man"
> for RCA Victor, which was issued as a side on a 78. It was quickly
> withdrawn (only a few of the records made it to the public), and a
> new 78 with the same record number was issued but with a different
> side. So a discographical database model has to handle certain
> exceptions that deviate from the well-known basic model.
> 
> (Another exception is how to handle the Fats Waller record, Vic
> V-38050, where the labels for "The Minor Drag" and "Harlem Fuss" were
> reversed on all discs. If one is to tie the discographical data to a
> song/composition database, how does one handle this? Fortunately the
> vast majority of 78s follow the basic model...)
> 
> Anyway, "wiki" itself, which is text-based, is not the approach, but
> the wiki *principle* does suggest an open database structure allowing
> entry and correction of data by those we allow, and to keep a running
> history of changes so bad changes can be trivially reversed.
> 
> We also need to consider how to export the data in a standardized and
> open form, and I recommend we develop an XML schema for this purpose.
> 
> This would take some design effort, and that's why getting a few
> database "gurus" who are also familiar with 78 discography to get
> involved. I actually have ideas for the XML schema which needs to
> codify the "ontology" we decide upon (and I have ideas for the
> ontology underlying this all -- basically a two-part structure, one
> focused on the metadata associated with a recording session, and the
> other on each "recorded artifact" the session produces)
> 
> Anyway, learning about wiki is a good thing, if for no other reason to
> understand the principles of what wiki enables.
> 
1) Define (if you would) the difference(s) between "data" and "text?!"

2) Virtually all "exceptions" can be covered if an additional "remarks"
data field is included in each data record...or, anyway, that has
always been my approach...

3) The only items that ARE NOT (nor can they be) "text" are (a) label
images and (b) sound files of the phonorecord's sonic content. When one
considers that even a "limited to 78's" database would have to include
about three million phonorecords...or SIX million side-oriented data
records...one quickly realizes that the necessary funds to purchase
the amount of computers and/or storage devices would be well over
the practical limits...even without the above two rather large
files included in the data records...!

4) The "Abrams Files" include text-based data records...one per
phonorecord side...of 160-byte length (this necessitates cutting
of a very few long entries). As well, these files were never
conceived for inclusion of classical recordings...which might
require different and/or additional data fields.

5) My personal 78-catalog database (which is sadly VERY incomplete)
uses a three-level relational structure. The first table is labeled
RECORDS (phono, NOT data!)...and includes the data which apply to
BOTH sides of a phonorecord. The second is labeled SIDES...and
includes the data which is specific to the side of a phonorecord
(i.e. condition, usw.) The third table is labeled TRACKS...and 
includes the data which applies to a track on a side (i.e. artist,
title, usw.). Note that most phonorecords have only ONE track per
side. Of course, improvements in hard drives mean that relational
tables are no longer as necessary as they once were...?!

6) I'm not totally conversant...nor experienced...in XML. I'd be
interested in seeing anything you've "roughed out" along with an
idea how you intend for it to work...!

Remember my one ultimate goal is to live to see the final, ultimate
78rpm record database completed (or as nearly such as possible...?!)!

Steven C. Barr