data-design question

[Dick Kriesel]

On 9/26/05 5:11 PM, "Charles Hartman" <charles.hartman at conncoll.edu> wrote:

> Thanks for your very thought-provoking response. One little piece:
> 
> On Sep 26, 2005, at 7:04 PM, Dick Kriesel wrote:
> 
>> performance data =
>>     recording
>>     artist
>>     instrument -- examples: guitar, voice
>>     performance category -- examples: solo, lead, backup
> 
> This isn't quite right, because each of the several performers on a
> track plays a different instrument (occasionally even two!). I

I agree that snip isn't quite right.  What it omitted from my thinking is
the notion of a concatenated key in a relational database.  If there were a
table of performance data, then its concatenated key would involve all four
partial keys: recording, artist, instrument, and performance category.  With
an unlimited number of combinations of instances of the four keys, the table
is ready holds enough data to answer all the performance related queries
you've mentioned.

> mention it because it's an example of how the data involved is multi-
> layered: an album composed of tunes each of which has several players
> each of whom has at least one instrument and each of whom also
> presumably plays different roles (solo, comping, etc) at different
> times. So it's got to be "thick" metadata, not flat. But I don't know
> what I'm talking about, really, so I'll shut up.

Don't shut up.  Do keep defining and refining your perceptions of
requirements, whether you know a lot or a little about metadata.  Your list
of example questions serves not only as a basis for design but also as a
basis for testing your code, for deciding when you've finished, and for
developing marketing material for your results.

> 
> People here have convinced me not to write a whole relational
> database manager from scratch (that didn't take much). As far as I
> can tell, if I want to do this open-source (except for Dreamcard),
> that makes my choices either
>          MySQL with Dreamcard
> or
>          SQLite with Python
> because those seem to be the available combinations. Am I wrong? I'd
> rather know what the choices are before I make one and start thinking
> about plunging in and learning a new system.

Generally, the more software boundaries your data must cross, the more
resistant your system is to changing the structure of your data.  Since I
think you're likely to throw away your first attempt no matter what, I
suggest you consider starting with just Dreamcard, making a stack for each
category of metadata, except for the category I called reference data, in
which each line item can have a stack of its own.  Build a prototype, revise
your requirements, maybe throw the prototype away.  Repeat.

By the time you're satisfied with your prototype, and show it to others on
this list, you might find that some who already know the other tools are
ready to collaborate with you on the next version, saving you the time of
learning those tools yourself.

> 
> Charles
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution