data-design question

[david bovill]

On 27 Sep 2005, at 03:06, Dick Kriesel wrote:

> On 9/26/05 5:11 PM, "Charles Hartman"  
> <charles.hartman at conncoll.edu> 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.

As far as i understand the issue here Dick - more than one instrument  
= problem for schema proposed schema / database?

This is not I think a problem for the Dublin core type schema as you  
can have as amny repeated entries as you need... so instruments as  
many times as you want for any XML entry / chunk.

I don't know where the example records came from - ITunes (they are  
not Dublin Core):
Title
Creator
Subject
Description (summary or keywords) > must be entered in german?
Publisher
Contributor
Date
Type (genre)
Format
Identifier (uri)
Source
Language
Relation
Coverage
Rights
If you want to look at metadata specifically for audio - there are a  
few projects that i know of that have spent years on this sort of  
stuff - some links here:

     http://www.ccProducer.org/ctv/wiki/VideoMetaData

While it is focussing on video - it is largely an extension of audio  
metadata for radio shows and music - the one I know most about is:

     http://www.ccproducer.org/ctv/wiki/SharedOnlineMediaArchive


>> 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.

Totally.