Rick, hit_ny I think we're getting caught up in terminology and nomenclature again... And, I don't think what you guys are suggesting is very different at all functionally - the confusion is all tied up in what we each understand of the nomenclature. It's definitely clear to me that what I thought was relational may not, in fact, be relational in the strict sense. So, as one or two others have suggested... let's throw around some illustrative examples - it's clear there are a few ways all of this might be done developmentally, but in the end it's the user functionality we're interested in. If we can agree on a functional model, then and only then maybe J River could offer much in the way of feasibility
Also, I would suggest that any implementation should require as little work for the user as possible (ie be as transparent as possible). Both Rick and hit_ny have suggested that new "entities" be created manually. Does this need to be the case? What if simply entering a value for an existing field (let's say [Artist]) worked as creating an entity as we've defined above. This "Artist" entity could then be tagged with fields assigned specifically to the [Artist] parent field.
Here are three examples of what I'd like to see. One each for Audio, Video and Images (Oh My!)
I'm going to use "Parent Field" and "Child Field" terminology (because that's what makes sense you me) but you could easily substitute "entity" for "Parent Field" I think. Note that some of the fields I mention below are custom fields. My proposal for assigning Child Fields to Parent Fields (something which need only be done once) can be seen here:
http://yabb.jriver.com/interact/index.php?topic=51456.msg351225#msg3512251. ArtistsThe Parent Field is [Artist]
Child fields might include [Nationality] [Bio] [Formed] [Disbanded] [Discography] [Primary Genre] [Primary Styles] [Primary Moods] etc
So, once child fields have been assigned to the Parent Field as described above...
1. I import a file for tagging.
2. "Queen" could be added to the [Artist] field just as it is in the current version. Doing so would automatically create "Queen" as a taggable entity. It is an "Artist" which now exists in the database, just as a file does now.
3. Child fields [Nationality] etc could be filled in for "Queen" as per below
4. If I import a new file and tag [Artist] as "Queen", the file will inherit all of the Child Field values assigned above. Perhaps this could be accompanied by a "Would you like to assign this file to the Artist "Queen" and inherit all associated metadata?"
5. If I select a file already assigned to Queen with the artist metadata already filled out, and change the value of of a child field - [Nationality] for example - the user might receive the message: "Are you sure you which to change the Artist "Queen"? Note this change will affect all files assigned to the Artist "Queen"
This is the interface the user might see in the Tagging AW
> Artist: Queen
Bio: … (extended field)
Nationality: UK
Primary Genre: Pop/Rock
Primary Styles: Glam-Rock; Hard-Rock; Album-Rock etc
Members (a list field): Bon Scott; Malcolm Young
Formed: 1971 in London, England
Disbanded: 1995
> Album: A Night at the Opera
Album Genre: Pop/Rock
Album Year: 1975
Album Styles: Prog-Rock/ Art Rock etc
Album Moods: Witty; Theatrical; Elaborate etc
Label: Elektra
> Rest of the fields etc etc
Note that all of the fields listed above exist/can be created in the current MC - the key is that the child fields (tabbed) are all common to and inherited based on a singular Parent Field. I know some people get iffy about affecting files which aren't currently selected - but we're talking about a shift here from "changing the files" to "changing the artist to which the files belong" - ie any fields you assign as child fields of "Artist"
should have the same values for all files belonging to that artist.
2. MoviesThe Parent Field is [Movie] <- I use this as a custom field for the movie name
Child fields might include [Country] [Director] [Actors] .. pretty much all the new video metadata fields which have been added recently.
Movies as a media concept will generally have fewer files, but the idea might be useful when we're also including associated media like posters, trailers, special features etc. Having a "Movie" existing as its own entity in the database can act as a mechanism to tie together all media related to that movie. This seems much tidier and intuitive than having a whole bunch of disparate media files which exist separately in the database - MC has no real way of knowing they share a common element. Remember - we're talking here about building a movie database and then assigning files to that movie...
> Movie: The Crow
Year: 1994
Director: Alex Proyas
Country: USA
Actors: Brandon Lee; ...
Genre: Action; Fantasy
Subgenre: Action Thriller, Superhero Film, Tech Noir
Studio: Miramax
MPAA: Rated R for a great amount of strong violence and language, and for drug use and some sexuality.
Synopsis: Based on the graphic novel by James O'Barr... (ext. field)
Review: (ext. field)
Themes: Righting the Wronged, Reincarnation, Dangerous Friends, Supernatural Romance
Tones: Goth, Stylized, Gritty, Menacing, Bittersweet, Elegiac, Dreamlike
Flags: Graphic Violence, Sexual Situations, Nudity, Adult Language
Keywords: revenge, crow [bird], murder, martial-arts, reincarnation, family-member, multiple-murder
> Rest of the fields etc etc
3. PeopleJust a simple one here to illustrate how this might be useful in photos
The Parent Field is [People]
Child fields might include [Association] [Birthday]
I'll define association as their loose relation to the user - ie values might include: Friends, Family, Colleagues, Friends of Friends
So, once child fields have been assigned to the Parent Field as described above...
1. I import a photo for tagging.
2. "John Smith" and "Anna Claire" could be added to the [People] field, along with any other people who may be in the photo, just as it is in the current version. Doing so would automatically create "John Smith" and "Anna Claire" as taggable people entities. They are "People" who exist in the database and may be tagged just as files are now. I'm going to say that John Smith is my brother (family) and Anna Claire is a friend.
3. Child fields eg. [Association] could be filled in for "John Smith" and "Anna Claire" as per below
4. If I import a new file and tag [People] as "John Smith", MC will know that John Smith is family - I need not enter that value again. Once again this could be accompanied by a "Would you like to assign this file to the Person "John Smith" and inherit all associated metadata?" This prompt could perhaps be optional.
Once again, the interface the user might see in the Tagging AW
> Album: Melbourne Trip
> People: John Smith
Association: Family
Birthday: 4/5/1982
> Rest of the fields etc etc
-------------
I think the advantage of these approaches are as follows:
1. Less repetitive work for the user - adding files to an existing entry in the database is much easier than re-entering the same values for the same fields each time I add new files.
2. Logical grouping of common concepts - in effect, we can easily group fields as they relate to common entities like [Artist] or [Movie]. Adding a file to a [Movie] immediately tells MC (and the user) a lot about the file.
3. Less ambiguity about some fields - using this approach, the user can easily tell the difference between tagging the year of a file, or the year an album was released.
4. Intuitive and useful artist/album/movie summaries might be easily created based on this info.
5. The entire concept is completely optional to the user... if they never assign child fields to parent fields - nothing changes and they continue to use MC as they have been.
The other question i have is assuming the system is in place how much work would be required to make use of it?
It depends on whether you're talking about the user or the developer here. In relation (excuse the pun) to the user, hopefully I've come close to answering some of that above. From a development standpoint - while those of us around here with programming & database knowledge around here (ie
not me - and I will emphasise that!) might be able to offer some ideas, in the end only J River can answer that one. Matt/Jim... do any of the suggestions made so far seem feasible?
I think the aim of this thread is to state what individual users would like to see in terms of functionality, establish whether there is a wider interest for proposals made... and then based on that establish dialogue about whether J River thinks this model might work.
It took me a while to write this - sorry I haven't posted for a while....