On 9/26/05 5:11 PM, "Charles Hartman" <[EMAIL PROTECTED]> 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 > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
