I agree. Anything to improve the mess we're now stuck with - and have been for years.

Oh - did we ever rule out the single name field? What a blessing that would be for all this...  And now I'm out.

Quoting Forget_the_Rest:

Quote:
I can see what you're saying but you're picking 1/2/3 due to culture. Although we may have plenty of people here who would be 1/2/3, we'll also have plenty who are 1//2 3. I don't see that providing info to "prove" either way shouldn't be an option. Yes it may involve some more work, but it's fairer overall. But by "forcing" people to use 1/2/3 if they can't find documentation to prove it should be 1/2 3 (or to support 1/2/3 for that matter) it'll be like the US naming standard is being imposed on all.

While it might be culture for me to pick 1/2/3 as a standard, you surely don't want each and every 3-part name to have to be documented in the contribution notes do you? I'd be willing to bet that the entire database has near 80% or more of the 3-part names parsed 1/2/3 correctly. Why on earth would we want to have to document those when the minority of 1 2//3 or 1//2 3 names can still be entered correctly with some documentation?

No rules are about fairness. The rules of baseball (or any other sport of your choice) are only to try to insure fairness as to the officiating of the game, and don't prevent one team from beating the other 100 to 0. What's fair about a team of 7 foot tall basket ball players against a team of 5 footers? The only fair thing to do would be a single name field, with as credited data only. Then no arguments about correct parsing, common names, breaking linking or anything else, it either matches the film credits or it doesn't. That would be fair, but severely cripple the functionality of the program as it stands today.

A "1/2/3" parsing rule would be an attempt to keep everyone on the same page and establish a standard, so we don't have 2 or 3 variants of a 3-part name. The biggest problem is when 1 user correctly documents and enters a 1//2 3 name but other users profiling the same film but different UPC/EAN don't. Still 2 forms for the same person. I'm not sure that is something that will ever be completely eliminated, no matter what any rule might say, since each profile stands on its own. The only way to eliminate multi-variants for any name is for there to be a central db of names and I'm not sure how that could be implemented.

The current system, that allows basically any parsing a person wants to contribute works how ever well or bad we believe, and we probably don't need a parsing rule even though I would support one. Most of the time, most names are probably entered the correct way, but there are a lot of profiles that haven't been looked at for a very long time. My limited experience in looking at name variants has shown me that there are a huge number of profiles with IMDB scraped data that aren't getting many updates. Those "inactive" profiles are the ones that keep the CLT from giving good results, and though parsing is not something the CLT cares about, if a user starts to enter a person's name and their local has the incorrect version, that's the one that will be used most of the time, whether it's the parsing or the IMDB name.

I'm trying to figure out if two fields would make things better or worse for those with three words in their names.

People have suggested another solution is to rename the three fields from:

First Name
Middle Name
Last Name

to something like:

Name Field #1
Name Field #2
Name Field #3

to hopefully remove some cultural bias.  Maybe that's a better direction to go.

P.S. A small program improvement that may or may not help but is related would be for the program to parse a little smarter when new names are entered.  Example: I enter John C. McGinley for the first time.  When i click Add Cast Member it currently parses it:

First Name: John
Last Name: C. McGinley

instead of looking at the spaces and splitting it among the three fields.

Whatever is decided the programs default parsing should reflect the decision.

Ken, I'd be more inclined to renaming the existing 3 fields and go to simple word counting, if the goal is to eliminate multiple entries that are based on parsing. Having only 2 name fields would result in the same situation we have now, where user A would enter John/Q. Public and user B would enter John Q./Pubic. All of the arguments about double-barrel last names would still exist.

In fact, even with Field 1, Field 2, Field 3, and simple counting, we will have the potential for problems, because of someone like HBC sometimes being credited with a hyphenated last name HB-C. The linking for her would not work unless a rule was set for hyphenated names to use a non-hyphenated word count common name and Credited as for the hyphenated version.

IMO, what we have now seems to work MOST of the time. As has been pointed out, there still exist today, parsing variations for even some of the double-barrel last named people who are more famous like HBC. I think a standard method spelled out in the rules, with variation allowed with some form of proof that is accumulated in a dedicated thread much like the BY thread, would go a long way to solving this issue.

I also agree it would be nice for prefix and suffix fields if you were so inclined to add them.

Quoting Unicus69:

Quote:
Quoting Ken Cole:

Quote:
We don't intend to move to a single name field since it would reduce functionality as others have mentioned.  However, I don't see a problem with moving to a two-field name, which would reduce (although not eliminate) parsing disputes.  Thoughts?

A two name field wouldn't solve any of these issues as the problem of which name(s) belong in the last name field will still be there.

Using this name as an example, would it be 'David Ogden/Stiers' or 'David/Ogden Stiers'?

What would solve this issue is to create a base standard, in the rules, with deviation allowed with documentation.  JMHO

Agreed, but by also using the Name Field Concept. I have no problem with deviation as long as there is documentation to support it, ANY kind of deviation, not just someone's assumption or guess. Assumptions and guesses will one day cause big trouble and then we will have to unwind and disentangle them, which will prove very problematic.

Skip

Skip

Quoting Unicus69:

Quote:
Quoting Ken Cole:

Quote:
We don't intend to move to a single name field since it would reduce functionality as others have mentioned.  However, I don't see a problem with moving to a two-field name, which would reduce (although not eliminate) parsing disputes.  Thoughts?

A two name field wouldn't solve any of these issues as the problem of which name(s) belong in the last name field will still be there.

Using this name as an example, would it be 'David Ogden/Stiers' or 'David/Ogden Stiers'?

What would solve this issue is to create a base standard, in the rules, with deviation allowed with documentation.  JMHO

I agree... I don't see how going to a 2 name field would help anything at all.  You still have to know where to put the middle word(s) of a 3 (or more) part name. I still think the best bet would be a single name field... that would take care of the parsing problems. But since that is out there needs to be some sort of standard on how to parse the names.

Quoting m.cellophane:

Quote:
Stating in the rules, for example, that "Last Name" = "Surname and Suffixes" would be helpful.

The problem is that such words cause problems. People in different places in the world might have completely different understandings of what something like "surname" means. It doesn't necessarily mean the same thing to you as it does to me, and so we'll be stuck with the exact same problems. Those that automatically, instinctively recognize, for instance, "Ogden Stiers" as the guy's surname, will still be tempted to put it into the appropriate field, if that's what you tell them to do.

I'm also not a big fan of "documentation". Sure, it all sounds very reasonable, until you realise it hardly ever exists. The fact that we haven't managed to come up with so much as five examples where a double last name should be listed in the "last name" field, doesn't exactly make me think this is something that we desperately need to keep at all costs (all costs being: perpetual parsing disputes for all eternity). If the number of examples we might actually reach an agreement on is really that low, I'd rather give it up altogether and just have a no-exceptions-at-all standard that gets everyone on the same page immediately.

The key here is not whose preference to choose, but to get everyone on the same page. Using field names that will be interpreted in different ways throughout the world means the problem will remain. As with common names, it's important to realise that it really doesn't matter whether we use variant X or Y - the important thing is that we all use the same one. That's why Ken moved away from using documentable "real" or "correct" names: documenting it just doesn't work, which is why he chose for a starting point that can (relatively) easily be established right here at Invelos.com by everyone. Given that there's even less available documentation on "correct" parsing then there is on "correct" names, it's decidedly not a good idea to re-introduce external documentation here. Sure it sounds nice, but it just doesn't work. It really doesn't matter so much how we do this, as long as we can be sure that EVERYONE, throughout the various regions and localities, automatically does it the same way.

Quoting Ken Cole:

Quote:
I don't see a problem with moving to a two-field name, which would reduce (although not eliminate) parsing disputes.  Thoughts?

I'd certainly like it better over what we have now. At first, I agreed that it would't eliminate the problems entirely, but like Martin, I felt that that most users - including the vast majority that hardly ever comes the forums and doesn't provide input here - would be able to work with that a lot better.

After thinking about it some more, though, I realised you could quite easily accompany this with a line in the rules that clarifies that the first word of any name goes into the "first name" field, and all the rest goes into the second field. And hey presto: then we're done. Everyone on the same page immediately, and no more questions about this ever.