On 27 Sep 2005, at 03:06, Dick Kriesel wrote:
On 9/26/05 5:11 PM, "Charles Hartman"
<[EMAIL PROTECTED]> 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.
_______________________________________________
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
