Topic: Relational Fields (Read 6240 times)

joh · « **on:** January 21, 2011, 10:48:00 pm »

Relational fields' should be a great improvement in order to maintain consistent data in the library. I played around a bit with it (16.0.15):
- I defined [country] as being a relational field to [artist]
- I noted that if I changed Artist from A to B that country would follow nicely
- I noted that if I changed the value of country on one track, all other tracks w/ same artists were also changed
- if however the country field had different values at the time of defining it as a relational field, 'consistency is not enforced

- it would be good to have a tool checking for relational inconsistencies in the library as we move into a relational model

This will be a BIG change as users today, (in absence of relational fields) will have implemented different conceptual models using the same standard fields (one that comes to mind is how people use [genre]: some use it as an attribute of [artist], others maybe as an attribute of [album] an others (like myself) as an attribute of the individual track. I believe you should think through the model carefully, defining the relationships between fields and then implement it 'all at once' when releasing the v16 to a broader audience. I would recommend not allow users to change field attributes on standard fields. I suggest also providign tools to support migration that caters to that people have used fields differently.

Did you have in mind later on also allowing users to define relations between user defined fields?

Exciting! /OLle

Matt · « **Reply #1 on:** January 21, 2011, 11:42:13 pm »

Quote from: joh on January 21, 2011, 10:48:00 pm

- if however the country field had different values at the time of defining it as a relational field, 'consistency is not enforced

I'm not even sure we should allow changing the relational type once a field is created. It's kind of messy to handle a change and do the expected thing.

We are imagining primarily new fields being created that are relational.

Quote

This will be a BIG change as users today, (in absence of relational fields) will have implemented different conceptual models using the same standard fields (one that comes to mind is how people use [genre]: some use it as an attribute of [artist], others maybe as an attribute of [album] an others (like myself) as an attribute of the individual track. I believe you should think through the model carefully, defining the relationships between fields and then implement it 'all at once' when releasing the v16 to a broader audience. I would recommend not allow users to change field attributes on standard fields. I suggest also providign tools to support migration that caters to that people have used fields differently.

The default database will not have many relational fields. We may add 'Artist Biography', 'Album Review', and a few others. Basic fields like Artist, Album, Genre, etc. will remain unchanged.

Quote

Did you have in mind later on also allowing users to define relations between user defined fields?

Maybe at a later date.

First we need to make sure the new system is working well (and acceptably fast for huge libraries) with the available relations.

ThoBar · « **Reply #2 on:** January 24, 2011, 02:24:56 am »

Quote from: Matt on January 21, 2011, 11:42:13 pm

Maybe at a later date.

First we need to make sure the new system is working well (and acceptably fast for huge libraries) with the available relations.

I'd just like to add this would be a HUGE bonus for Composer, Opus, Band (or Orchestra) and other fields.

I'm sure you'll get to it, just reiterating the potential uses beyond the basic Artist etc.

MrHaugen · « **Reply #3 on:** January 24, 2011, 04:45:25 pm »

This is FANTASTIC news! Finally we can have a similar Theater View experience to other competing MC's. At least I hope so. Have not had the time testing it out yet :-) Really looking forward to it.

Remember to think about adding "Series/Show Summary" and "Season Summary" as defaults as well. I guess that is something most series freaks want to use. Other than that, the most pressing field is Artist Bios I think.

leezer3 · « **Reply #4 on:** January 24, 2011, 05:29:23 pm »

First, a quick observation-
It'd probably be a good idea to add a warning when editing relational fields, like the current one for multiple files. Someone will inevitably get it wrong and come back out for blood!
Related to this, a long term suggestion I'd make would be to consider allowing 'calving' of fields. Thus, when editing a relational field the user gets a prompt as to whether to split this file off into having separate tags from those of the relational ones.

Just to add what could turn out to be a nastily complex little suggestion:
It'd be nice to be able to add somone as both a Director and Actor with the same biography etc. As I understand the current relational model, this isn't going to work, as everything would be defined as either belonging to the Director field or the Actor field

-Leezer-

darichman · « **Reply #5 on:** January 26, 2011, 08:35:51 pm »

Darichman is in Vietnam for another two weeks without MC or his media library. He would very much like to express his excitement about this feature, and about artist images, and can't wait to try them out. Thanks again J River and team.

How does the relational system work with list fields? I'd like to use it with 'people' for example which often contains a few values.

Anyway, love that the idea is even being given a trial

Posted from a little wifi cafe in Hoi An market district

JimH · « **Reply #6 on:** January 27, 2011, 06:34:18 am »

Darichman,
Thanks for the nice postcard.

Jim

Matt · « **Reply #7 on:** January 27, 2011, 11:22:40 am »

Quote from: darichman on January 26, 2011, 08:35:51 pm

How does the relational system work with list fields? I'd like to use it with 'people' for example which often contains a few values.

Sorry, but it's not possible to use relational fields with list-style fields.

tunetyme · « **Reply #8 on:** February 01, 2011, 01:25:30 pm »

I think that your implementation plan will work well. If Genre is fixed then it could be used correctly and list major categories like Rock, Jazz etc. If style is established as a relational field then all the various styles that a song may fit into can be included. The question is does it link to the song, album or the artist? I haven't looked at it yet so I can do it right from the beginning. I would like to set up Style, Chart Data, Key (the key of the song) and Mood linked to the individual song. What is the process or is there a Wiki on this already?

Tunetyme

rick.ca · « **Reply #9 on:** February 01, 2011, 03:09:17 pm »

Quote

If Genre is fixed...

Existing fields that people are already using like Genre and Style can't be arbitrarily turned into relational fields. Even if everyone agreed such a field should be relational, there would not be agreement on whether a field should be related to Artist or Album. But you're free to replace these fields in your library with custom relational fields.

Quote

I would like to set up Style, Chart Data, Key (the key of the song) and Mood linked to the individual song.

Just create custom fields. Fields are, by definition, associated with a file (i.e., an individual song). Related fields are associated with Album or Artist.

tunetyme · « **Reply #10 on:** February 02, 2011, 08:51:29 am »

Style would be a primary relational field. I can certainly create a new one. Is there a limitation to the number of relational fields that we can create?

mark_h · « **Reply #11 on:** February 02, 2011, 09:59:22 am »

Wow. It normally takes a new version of MC to get to about build .80 or so before there is any functionality I want to pay for, but relational fields means I'll be upgrading to MC16 just as soon as I can.

mark_h · « **Reply #12 on:** February 02, 2011, 11:13:49 am »

Playing with this now.

Need to be able to define the field to use as the relation so that we can use calculated fields

I rarely use the default fields in my setup, preferring to use my own fields, many of which are calculated expressions that provide advanced functionality. Would be fantastic to be able to set relations against calculated fields...

mark_h · « **Reply #13 on:** February 02, 2011, 11:33:21 am »

An indeed have already hit a problem where Artists from different countries use the same name...

However, the relational database has allowed me to knock together a very quick test for country mismatches in data and I can very quickly fill in/correct missing data in the default fields, improving my data, which is great. But it looks like we'll need to be very careful with relational fields due to issues like this...

mark_h · « **Reply #14 on:** February 13, 2011, 05:51:18 am »

Could we get relational fields for tracks using [artist][name] as the connection? My workflows are immensely improved by using relational fields but I'm stumbling on the tracks and having to duplicate a lot of work that could be taken care of by relational fields...

MrHaugen · « **Reply #15 on:** February 14, 2011, 05:56:06 am »

Quote from: mark_h on February 13, 2011, 05:51:18 am

Could we get relational fields for tracks using [artist][name] as the connection? My workflows are immensely improved by using relational fields but I'm stumbling on the tracks and having to duplicate a lot of work that could be taken care of by relational fields...

This would also be needed if you take Series/TV Shows as an example. Series info regarding whole Series and Seasons, like Series/Season overview. Series overview would not be problematic, as you can set it up directly to Series. It would be a lot more work to add it to individual Seasons though. Season info should be matched on both Series and Season.

tunetyme · « **Reply #16 on:** February 14, 2011, 11:21:53 am »

Quote from: mark_h on February 02, 2011, 11:13:49 am

Playing with this now.

Need to be able to define the field to use as the relation so that we can use calculated fields

I rarely use the default fields in my setup, preferring to use my own fields, many of which are calculated expressions that provide advanced functionality. Would be fantastic to be able to set relations against calculated fields...

I am very interested in data integrity. I spend an enormous amount of time ensuring data integrity the hard way. I would be very interested in how you are setting up your user defined fields.

Tunetyme

mark_h · « **Reply #17 on:** February 15, 2011, 04:29:51 am »

An example in my workflow would be my user field called 'Country:My' that is set as a relational field against Artist. And a smartlist that shows all mismatches between Country:My and Country. This enables me to apply a country globally using my Country:My field, but still override it with the Country field. All I do is copy and paste data between the fields.

The relational field means that when I import new tracks the mismatch smartlist in my workflow will hightlight the tracks and hint at the correct country. In this way I can correctly tag my data without the relational field automatically applying data and causing problems...

tunetyme · « **Reply #18 on:** February 15, 2011, 03:31:27 pm »

That is an interesting method. I do not track country at this time. I am thinking about creating styles for songs and possibly albums. I will most likely start out using the styles in AMG. The problem is that they have so many different styles and some don't really tell you anything about the song itself. For example singer songwriter could mean just about anything.

The next challenge is to set up chart data. Currently I use 2 different charts, Whitburns top 40 that only covers singles and McLeer's top 20 that identifies those songs that have been in the top 20 for at least 30 days. I am thinking about adding the hot 100. The challenge will be on how to encode rank, date, peak date and weeks in the top 40. I am not sure exactly how I am going to accomplish this. I am open to suggestions how how to structure these fields.

Finally, I would like to track albums/songs that I want to acquire. Since they do not have an existing file I am not sure how I will be able to do this within MC. I am sure others have looked at this as well. If anyone has some suggestions I would love to hear it. Right now I use several different music programs and documents to track all the info I want. It would be sweet to be able to accomplish everything within one program.

Tunetyme

JimH · « **Reply #19 on:** February 15, 2011, 03:49:22 pm »

Quote from: tunetyme on February 15, 2011, 03:31:27 pm

Finally, I would like to track albums/songs that I want to acquire. Since they do not have an existing file I am not sure how I will be able to do this within MC. I am sure others have looked at this as well. If anyone has some suggestions I would love to hear it. Right now I use several different music programs and documents to track all the info I want. It would be sweet to be able to accomplish everything within one program.

You could try the Notes feature. You have to enable it under Options/General/Features.

mark_h · « **Reply #20 on:** February 16, 2011, 09:03:01 am »

Quote from: tunetyme on February 15, 2011, 03:31:27 pm

The next challenge is to set up chart data. Currently I use 2 different charts, Whitburns top 40 that only covers singles and McLeer's top 20 that identifies those songs that have been in the top 20 for at least 30 days. I am thinking about adding the hot 100. The challenge will be on how to encode rank, date, peak date and weeks in the top 40. I am not sure exactly how I am going to accomplish this. I am open to suggestions how how to structure these fields.

Two discussions on chart data:

http://yabb.jriver.com/interact/index.php?topic=60906.0

http://yabb.jriver.com/interact/index.php?topic=60993.msg411265#msg411265

Enjoy!

tunetyme · « **Reply #21 on:** February 19, 2011, 05:57:13 pm »

Thanks! I'm going to wade in and try out all your recommendations.

221bBS · « **Reply #22 on:** May 11, 2011, 02:16:51 pm »

Quote from: mark_h on February 02, 2011, 11:13:49 am

Playing with this now.

Need to be able to define the field to use as the relation so that we can use calculated fields Cheesy

I rarely use the default fields in my setup, preferring to use my own fields, many of which are calculated expressions that provide advanced functionality. Would be fantastic to be able to set relations against calculated fields...

I'm the same, I've stopped using a lot of the default field and mostly use custom fields. I would love to use this but without the ability to define my own relations it's no use to me.

Quote from: Matt on January 21, 2011, 11:42:13 pm

Quote
Did you have in mind later on also allowing users to define relations between user defined fields?

Maybe at a later date.

First we need to make sure the new system is working well (and acceptably fast for huge libraries) with the available relations.

Hopefully the system is working well and you guys are working to allow custom/expression fields.

mark_h · « **Reply #23 on:** May 12, 2011, 02:33:33 am »

I think more relational functionality is my biggest WANT right now.

rick.ca · « **Reply #24 on:** May 12, 2011, 05:09:21 am »

Quote

I think more relational functionality is my biggest WANT right now.

You've been spending too much time on that dating site...

mark_h · « **Reply #25 on:** May 12, 2011, 05:24:49 am »

221bBS · « **Reply #26 on:** May 12, 2011, 09:51:00 am »

Quote from: mark_h on May 12, 2011, 02:33:33 am

I think more relational functionality is my biggest WANT right now.

YES! I'm crossing my fingers.

Matt · « **Reply #27 on:** May 12, 2011, 10:01:34 am »

Please post specific suggestions if there is something you want here.

Sorry, but custom relationships or relationships to individual items in a list-type field will not be added to v16. Both of these have complicated performance and technical hurdles.

Thanks.

221bBS · « **Reply #28 on:** May 12, 2011, 10:18:40 am »

Quote from: Matt on May 12, 2011, 10:01:34 am

Sorry, but custom relationships or relationships to individual items in a list-type field will not be added to v16. Both of these have complicated performance and technical hurdles.

That's what I really wanted

, maybe in v17, crossing fingers

wig · « **Reply #29 on:** June 24, 2011, 07:54:47 am »

Quote from: Matt on May 12, 2011, 10:01:34 am

Please post specific suggestions if there is something you want here.

Sorry, but custom relationships or relationships to individual items in a list-type field will not be added to v16. Both of these have complicated performance and technical hurdles.

Thanks.

I'm a bit confused by this statement. I want to create a Relational Field (Favorite Albums) and set the data type to List (semicolon delimited). Can I safely do this?

Matt · « **Reply #30 on:** June 24, 2011, 08:02:40 am »

Quote from: wig on June 24, 2011, 07:54:47 am

I'm a bit confused by this statement. I want to create a Relational Field (Favorite Albums) and set the data type to List (semicolon delimited). Can I safely do this?

Yes. The data can be a list.

I was saying that you can't relate the data to individual values in a list. For example, it's not possible to have an "Actor Biography" linked to a list-field of "Actors" that stores a biography for each actor in the movie. This would be neat, and is on the maybe someday list.

wig · « **Reply #31 on:** June 24, 2011, 08:14:30 am »

Thanks, I thought I was ok but just wanted to make sure before my latest tagging odyssey.

Lasse_Lus · « **Reply #32 on:** July 24, 2011, 05:45:56 am »

Relational Fields is truly a killer feature, the more i use it the more i want custom fields

but i understand that it is difficult

Quote from: Matt on May 12, 2011, 10:01:34 am

custom relationships or relationships to individual items in a list-type field will not be added to v16. Both of these have complicated performance and technical hurdles.

my simple suggestion would be to add a couple of custom fields named [customrel1],[customrel2],[customrel3] ......

then they could be hardcoded in MC just like [Artist] [Album] & [Series] Fields..with possible relation attribute

but the user could use the fields for their own purposes, and "name" them yourself by changing the the Display name

thoughts ?

INTERACT FORUM

Author Topic: Relational Fields (Read 6240 times)