data-design question

[Dick Kriesel]

Charles --

I see you've already received a lot of advice about implementation tools, so
instead I'll focus on metadata.  Maybe the metadata will influence your
choice of tools.

There seem to be several categories of relevant metadata.  As I see it, here
are at least some of them:
    album data
    track data
    composition data
    recording data
    performance data
    acquisition data
    importation data
    reference data

For some details about these categories, see the following notes.

To me, the richness of the metadata suggests there may be significant value
in further collaboration, such as in the Dublin Core Metadata Initiative.
Whether you want to engage in a core metadata initiative or not, your
perceptions of your needs will probably evolve significantly as you proceed.
So I suggest an important factor in selecting tools be your ease of changing
your metadata.

-- Dick

----------------------------------------------------------------------------
In the following notes,
    {} indicates multiplicity -- example: {genre}
    = indicates decomposition -- example: group = {person}
    -- indicates a comment -- example: this comment
----------------------------------------------------------------------------
album data =
    title
    label -- examples: Capitol, RCA
    series  -- families of albums on the same label
    release date
    {genre}
    medium -- examples: vinyl, CD
    copyright
    track data
    
track data =
    album
    track number
    composition data -- a composition may appear on more than one album
    recording data -- a recording may appear on more than one album

composition data =
    title
    music by {person}
    lyrics by {person}
    composition date
    {genre}
    variations on composition
    medley of {composition}
    copyright

recording data =
    composition
    recording date
    {genre}
    studio
    recording engineer

performance data =
    recording
    artist
    instrument -- examples: guitar, voice
    performance category -- examples: solo, lead, backup

acquisition data =
    album
        -- an album may have been acquired more than once because
        -- of damage to the media
    track
        -- individual tracks from the same album may have different
        -- acquisition dates and sources
    source -- examples: iTunes, Wherehouse
    acquisition date

importation data =
    recording
    bit rate
    encoding scheme
    importing date

reference data =
    persons
    groups -- group = {person}
    genres
    instruments
    performance categories
    media
    labels
    series
    studios
    sources
    encoding schemes
    bit rates
----------------------------------------------------------------------------
On 9/24/05 11:34 AM, "Charles Hartman" <charles.hartman at conncoll.edu> wrote:

> Many years ago I wrote a jazz-record-collection database program in C
> -- so many years ago that memory problems raised by sparse arrays of
> unpredictable size led me into baroque designs involving pointers-to-
> pointers-to-pointers . . . It occurs to me that Rev would make a nice
> front-end for this both easy and pretty. But I'm wondering what the
> best approach to the data structure(s) would be.
> 
> Assume that the basic record (in the database sense) is Album -- so
> the basic design is one card per Album. Each Album includes a list of
> Tunes (besides Artist/Group and Label/Date/EtcData). Each Tune is
> associated with one or more Writers, and also with a list of Players,
> each of whom is associated with an Instrument. So we've got at least
> four fundamental types of data lists -- player, instrument, tune-
> title, writer -- and some items that combine fundamental items in
> many-to-one relation.
> 
> The program would be useful (at least to me) only if it were possible
> to search it on any of those criteria. (Show me every Album including
> a Tune by Matt Dennis on which Steve Swallow is playing bass.)
> Obviously it's necessary to be able to add to each of the fundamental
> data lists -- which suggests combox-box menus -- and it would be
> important to have a series of defaults (same players for all tunes on
> an album, for example) to encourage data-entry.
> 
> Any suggestions about the best approach to the internals of this? I'm
> not clear whether, for example, custom properties are up to the
> demands of what's essentially a relational database . . .
> 
> Thanks for any help in thinking about this.
> 
> Charles Hartman
> 
> _______________________________________________
> 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