Consider the case of the artists: In some cases this refers to an
individual, sometimes to a group (which is composed of individuals). A
relational system can deal with such cases comprehensively, though it is a
lot of work up front.
Another point is that the most important artist connected with a recording
is not always the performer. I think we usually expect to find Beethoven
under Beethoven, not under the conductor or orchestra's name.
In the database that I have been developing I have found it essential to
make a distinction between abstractions and individual instances. A song,
symphony etc is a musical entity which has an identity independent of any
particular performance of it and is linked to the artist who wrote the
piece.
A track is a recorded instance of music by some particular performer.
An "album" (we are still using a term that originated to describe
collections of 78 RPM records where a single piece was spread out over
multiple disks), an album is a collection of recorded tracks. An album will
sometimes be composed of more than one compact disc. In some cases of
reissues of older music we find TWO albums on the same CD.
-larry
> -----Original Message-----
> From: owner-cdindex nospam at freeamp.org [mailto:owner-cdindex nospam at freeamp.org]On
> Behalf Of David Van Zeebroeck
> Sent: Wednesday, March 10, 1999 8:22 AM
> To: 'cdindex nospam at freeamp.org'
> Subject: RE: Proposal for fields in DB
>
>
> i think we should include for each track a performer
> on of the big problem with the current cddb is that is has no hooks for
> compilation cd's
>
> like compilation X
> track 1 performer A
> track 2 performer B
>
> we should make sure that we can have things like this
>
> > -----Original Message-----
> > From: robin nospam at acm.org [mailto:robin nospam at acm.org]
> > Sent: woensdag 10 maart 1999 02:10
> > To: cdindex nospam at freeamp.org
> > Subject: Re: Proposal for fields in DB
> >
> >
> > On Tue, 09 Mar 1999 20:08:19 +0000 Ian Clarke
> > <I.Clarke nospam at ed.ac.uk> wrote:
> > > Here is a list of fields that I think should be supported in the
> > > database at a minimum...
> > >
> > > CD ID ... Artist Name ... CD Title ... Release date ...
> > Genre ...
> > > Hyperlink ... Author ... Date ... lyrics(n) ...
> > That's a very basic list.
> >
> > Nearly all of these fields should be available per track too (and
> > per piece if we have that concept).
> >
> > I can come up with loads more fields just by looking at a few
> > sleeve notes:
> > Performer, Conductor, Composer, Librettist, Venue, Instrument,
> > Recorded date, Recording type (AAD/ADD/DDD) Recording equipment,
> > Producer, Engineer, Catalogue number, BWV number, Price, ...
> > If you think about fields mainly for personal use:
> > Favourite track, Rating, Review, Comment
> > And for administrative purposes:
> > Updates another entry Submit server, Submitted by,
> > Submitter's signature, Moderated by, Moderator's signature
> >
> > The list could go on indefinitely. Perhaps this is the problem: there
> > are just too many fields that someone might think are important for
> > some particular use, but most people will think are excess baggage.
> >
> > Can't we just allow any arbitrary tags to be attached to a simple
> > hierarchy of set, disk, piece and track objects, with some standard
> > tags defined?
> >
> > The absolute minimum to get right then is how the hierarchy
> > links up (just
> > nesting should suffice?) and a very basic tag like Title. Some idea
> > of the administrative tags is required too. These are required for
> > all submissions. Everything else is optional and infinitely
> > extensible.
> >
> > Robin.
> > --
> > R.M.O'Leary <robin nospam at acm.org> +44 7010 7070 44, PO Box 20,
> > Swansea SA2 8YB, UK
> >
>