Quoting m.cellophane:

Quote:

If the program could ignore parsing differences, I think we'd be on a good path to eliminating many of the issues.

Unfortunately, linking problems do not come only from parsing. As I already wrote in another thread, linking problems are due to different factors. Seeing my collection and problems I had to solve, the reasons are :

1/  different credits for the same actor, with a contributor not using Common name from CLT
2/  bad transcription of capitalized letters, omitting accents
3/  typos by contributor when copying credits
4/  asian names that are sometimes in asian order, sometimes in western order (Gong Li/Li Gong, Zhang Ziyi/Ziyi Zhang)
5/  different actors with same name, without birth year

Those reasons are more than 80% of linking problems. Ignoring parsing will solve nothing for those.

6/  incorrect evident parsing by contributors ignoring rules on titles and articles...  About 15% of linking problems, that could probably be solved by automatic filters
7/ difficult parsing : about 5%

I'm not against a ignoring parsing solution. But in fact it will solve a very little percentage of linking problems.

Quoting lyonsden5:

Quote:
The only thing that would (IMO) is an amendment to the rules to give direction.

True, but I thought we had that at one point, or at least a widely followed agreement (though vociferously objected to my some of course!), that we put first name in first field, last name in last field and anything else in the middle field and we totally ignored whether the person in question thought of (say) their last two names as a surnmae or not.

However, the idea that the program could automatically ignore parsing for linking purposes would solve a huge portion of the problem and i think it's an excellent idea.

Quoting Voltaire53:

Quote:

True, but I thought we had that at one point, or at least a widely followed agreement (though vociferously objected to my some of course!), that we put first name in first field, last name in last field and anything else in the middle field and we totally ignored whether the person in question thought of (say) their last two names as a surnmae or not.

No, this word counting has been developed in an external forum of an unofficial self-appointed rules committee and never made it to the official Invelos rules nor has it ever been a general consensus in this forum.

Quoting Voltaire53:

Quote:
Quoting lyonsden5:

Quote:
The only thing that would (IMO) is an amendment to the rules to give direction.

True, but I thought we had that at one point, or at least a widely followed agreement (though vociferously objected to my some of course!), that we put first name in first field, last name in last field and anything else in the middle field and we totally ignored whether the person in question thought of (say) their last two names as a surnmae or not.

However, the idea that the program could automatically ignore parsing for linking purposes would solve a huge portion of the problem and i think it's an excellent idea.

Quite right, Voltaire, I think that most of us have been following this. But unfortunately most isn't good enough, all it takes is ONE user (Rho) who decides he doesn't want to do it , but wants to do it his way instead to make a complete hash out of everything.

Skip

Quoting SpaceFreakMicha:

Quote:
Ok, ontopic:
I don't understand why we need a "standard" for parsing. If you start with 1/2/3 or 1/2 3 and then document a change to the opposite doesn't make a difference. Unless any data is somehow verified it could be wrong. So there is no use of saying 1/2/3 has to be a standard or 1/2 3 has to be a standard, because both could be wrong without further verification.

The database won't be any more correct by using 1/2/3 as a start, as it would be by using 1/2 3 as a start.

IMHO this whole discussion is much ado about nothing. So why lose so many time for endless debates, this time could be used to actual verifiy or change the parsing of a few actors, where it is neccessary. 

The reason it is an issue is linking.  Let me try and explain using Robin Wright Penn.

Let's say you enter her in a profile, as Robin/ /Wright Penn and Skip enters her in a different profile as Robin/Wright/Penn.  When I download those two profiles, I will have two different actor entries.  If I double click on one, the profile...or profiles...with the other will not come up.  For them to link, I would have to change one of the names.  For a lot of people, this is unacceptable.

Quoting eaglejd:

Quote:
....
How is this parsed?

List/ of/ Accepted/ Parsed/ Names/ with/ Documentation?

List of Accepted Parsed//Names with Documentation?

List of Accepted/ Parsed Names/ with Documentation?

Serious? Of course it's a stage name so it is

List of Accepted Parsed Names with Documentation//

Quoting SpaceFreakMicha:

Quote:
Quoting TheMadMartian:

Quote:
The reason it is an issue is linking.  Let me try and explain using Robin Wright Penn.

Let's say you enter her in a profile, as Robin/ /Wright Penn and Skip enters her in a different profile as Robin/Wright/Penn.  When I download those two profiles, I will have two different actor entries.  If I double click on one, the profile...or profiles...with the other will not come up.  For them to link, I would have to change one of the names.  For a lot of people, this is unacceptable.

I see the problem, but I can't see why 1/2/3 is any better as a starting point as 1/2 3.

I have explained this many time, Space.

Skip

Quoting gardibolt:

Quote:
The linking should ignore capitalization too, just like the contribution system and the CLT do.

Good point, except locally, I think you can only have one version of capitalization, and linking happens in your local db.