I think it would be better to describe what we want at a functional level. We don't know enough about the inner working of MC to dictate the implementation of new features.
Here we go
1. Setting Up fields to be relational
2. Databse handling of relational fields
3. Implementation into current Tag AW
4. Implementation into view schemes
5. Implementing online submission and lookup
Here are some ideas I had.
1. Setting up relational fieldsWe need a way to tell MC that we want one field to be subordinate or relational to another. Eg. We want [Nationality] as a field to describe [Artist]. Or we want [Association] as a field to describe [People].
Option 1: In the create new field / edit field dialogue, have a tick box for “Make Child Field of…” and then select the field you wish to link it to. Eg. Create a field called [Nationality] and make it a child field of [Artist]. Each child field should only be linked to one parent field.
Option 2: In the create new field / edit field dialogue, have a button saying “Add Child Fields”. Eg. Click on edit field for [Artist] and add a child field called [Nationality]. This is essentially the reverse of option 1. Ideally we could do it either way and the end result would be the same. We’d need the ability to add more than one child field.
2. Database handling of relational fields.Relational fields should be available as per regular fields in view schemes, panes, columns, the tagging window etc, with a few minor differences as described below.
Editing child fields will be reflected in any files belonging to the parent field.3. Implementation Into Tagging AWParent fields should display as per the current implementation, but subordinate fields need to appear under the parent field. They can be viewed or hidden with a drop down to the left of the parent field (just like tree entries). We should be able to treat child fields as regular fields in terms of selecting which ones to show in the Tag AW and in terms of editing them. The only difference is how they are viewed in the Tag AW (as subordinates of parent fields, to denote the fact they are describing another field, as opposed to the file itself.
Here is an example of what the Tag AW might look like
> Artist: AC/DC
Bio: … (extended field)
Nationality: Australian
Members (a list field): Bon Scott; Malcolm Young
Year Formed: 1973
> Album: Stiff Upper Lip
Album Genre: Pop/Rock
Album Year: 2000
Record:
> Rest of the fields etc etc
4. Implementation Into View SchemesChild fields should be available to use as panes in view schemes, filters etc just like any other field. For example, I could create a scheme [Nationality] -> [Artist] to navigate. If we are viewing “artists” in a view scheme, it might be nice to see a summary of any child fields pop up if I hover over it. Double clicking on an artist will drill down into the next pane in the view scheme. Right clicking might bring up options like “Play all files” , “Show albums by this artist”, “Show artist info” etc etc. Tagging would bring up the Tagging AW as described above. If I try to retag a child field (eg using column view) it might be wise to bring up a popup “Are you sure you wish to change the Artist: AC/DC” or something similar, so that the user knows they are changing all references to AC/DC, and not just the file in question.
It would also be really great to right click on an artist (or whatever field we’re talking about) and say “add coverart”. This artist coverart could replace the moving slideshow of album images when in artist mode. I would personally find this really useful for tagging different [People] with portraits… these could then be used as a visual way of navigating through people by their faces, not a random slideshow of photos they appear in.
5. Implementing online submission and lookupThis is probably something that would come much later, but wouldn’t it be great if we could submit artists, or movies, or TV shows or books etc as we currently do albums? An online MC database like this with lookup and submission would be incredibly powerful and would be a major selling point of MC (at least in my humble opinion). We’d be submitting child fields for each of the major categories described above.
I rip a dvd (which I own!!!) and convert the movie to divx or something. I enter fields like [Director], [Composer], [Studio], [Actors] etc (which I’ve set up as child fields of [Movie]) and upload them. Then if another user has the same movie… he need only match it by title and can download the above info!
A database like this could grow really quickly… and doesn’t rely on recognising the exact same DVD or audio album. We just need to compare a field like [Artist] or [Movie] and the information is accessible. A “closest match” option might be useful!