Quoting RHo:

Quote:
Quoting hal9g:

Quote:
Then we'll have another big battle over which version should be the "common name".  It will be one way one day depending on which method was used most often, but could change the next day if the other method overtakes in the CLT.

The credit lookup tool is not sensitive to parsing. A/B/C and A//B C is the same for the CLT.

OK...then which one gets used as the Common Name?

The CLT is rendered useless! 

Quoting T!M:

Quote:
Quoting kdh1949:

Quote:
Here's my suggestion.  The first time a name is contributed (cast or crew) the contributor gets a pass on how he parses it.  He can do it A/B/C, AB//C, A//BC, whatever -- and needn't document how he did it.

If someone thinks the original submission is wrong and wants to change it, then he has to document why it should be changed.

That's not just a suggestion - that's an EXACT description of what we have right now.

Actually, I do like this suggestion very much. It is what we have today minus the constant campaigning for word counting. And the results in my experience are really good. Most middle names are entered as middle names at the first shot without any problem.

Quoting skipnet50:

Quote:
Quoting T!M:

Quote:
Quoting kdh1949:

Quote:
Here's my suggestion.  The first time a name is contributed (cast or crew) the contributor gets a pass on how he parses it.  He can do it A/B/C, AB//C, A//BC, whatever -- and needn't document how he did it.

If someone thinks the original submission is wrong and wants to change it, then he has to document why it should be changed.

That's not just a suggestion - that's an EXACT description of what we have right now.

But that is NOT a single page starting point, Tim. We need a singl;e starting point and ANY deviation at any point requires documentation. A/B/C is simply the easiest page to start from. NJote this does preclude deviation , it just means if you do document it. Else we have a mess, with users operating from whichever page they want and errors will multiply exponentially.

Skip

I know what it's not, and I'm certainly aware of the problems that come with it, but it is what we currently have. I have already said that I do feel we need to lay out a few ground rules to be able to cut down on all those pointless double entries for all affected people in the database, but in the end, this is the system that we have right now, and only Invelos can change it.

As an aside: I'm getting a bit tired of the "documentation" argument, since documentation on "correct" parsing basically doesn't exist. I'd say that documentation on this is available in about 1% of all affected names. While it all sounds very sensible and reasonable to say "any deviation requires documentation", there usually just isn't any. It does seem a bit strange to base the way you handle something on a bit of documentation that simply doesn't exist 99% of the times you need it. I must say I still see some merit in the single name field solution...

Quoting EnryWiki:

Quote:
As guidance, I would say:

if you don't have a clue, use A/B/C as a general starting point, unless documented otherwise, as follows:

Documentation: since there is not much documentation on name parsing, and a definitive proof is often impossible to find either way, documentation which shows the most likely parsing will suffice;

Foreign Cast & Crew: if it's a foreign (non-US) production, or there are foreign Cast & Crew members anyway, you are allowed to use local parsing rules according to their origin/nationality;

I hope that these guide lines would make everybody happy.

I can live with that.

Quoting T!M:

Quote:
I must say I still see some merit in the single name field solution...

Me too!

Quoting RHo:

Quote:
Quoting T!M:

Quote:
As an aside: I'm getting a bit tired of the "documentation" argument, (...)

Me too, but for different reasons. As an example I have to get the Bonham Carter case again out of the pocket.

no we don't have to get her out of the pocket!

For some reason you just want to.

Can we all move on now from this pointless discussion which has left a number of dead horses lying in the road and all the following cars are crashing into them.

There is blood everywhere.. bits or limbs / legs etc



Who wants to talk about the new panasonic Plasma TV I'm thinking of buying instead?

Quoting RHo:

Quote:
In my collection I have 5 profiles featuring Helena Bonham Carter. All of them are parsing the name as H//B C. And only one single profile has any kind of documentation about her name in the contribution notes. Guess who is the author of that contribution.

Tim Burton?

Quoting hal9g:

Quote:
Quoting T!M:

Quote:

As an aside: I'm getting a bit tired of the "documentation" argument, since documentation on "correct" parsing basically doesn't exist. I'd say that documentation on this is available in about 1% of all affected names. While it all sounds very sensible and reasonable to say "any deviation requires documentation", there usually just isn't any. It does seem a bit strange to base the way you handle something on a bit of documentation that simply doesn't exist 99% of the times you need it. I must say I still see some merit in the single name field solution...

This is precisely why we need a "standard" when there is a lack of documentation; not a "let me "guess" for my profiles, and let someone else "guess" (very possibly differently) for their profiles".

That approach will only lead to a perpetual problem with data consistency and an inability to link actors to all of their profiles.

I'm really struggling to understand why this logic does not resonate other than people just wanting to do it their own personal way.

I absolutely agree, Hal. We are not going to be able doument beyond A/b/C in the majority of the cases. That's fine. RHO brings up a well-known actress H/B/C who is incredibly easy to document, he should try picking a name that nobody knows and try the same argument. Then his argument is reduced to its lowest level, and it is because he is applying HIS cultural standards and he says it is so, which is completely unacceptale, justr as the comment "it is more likely" is unacceptable. The claim is that they want acuurate data, if they can't document it then it is NOT accurate, it is their GUESS based on whatever.

Nor do I buy the concept that an initial contribution gets a pass. That is utter nonsense, IF you deviate from the data standard, you document it PERIOD. I don't buy the prenise presented that if you use your cultural or lazy choice, instaed of the data standard and don't document it. If the data gets acdcepted then it becomes impossible to fix unless it is documented. If you cqan't document a deviation from data standard then don't do it, don't make an assumption. I have news for you if you deviate from data standard and don't document it, then when someone changes it to data standard I will absolutely support the change.

Any data standard will cause "data inaccuracy" which cannot be documented, even the cultural data standards mentioned. But the cultural standards are not based on anything within the program, they are based on culture (or laziness). The A/B/C data standard which could be argued is American culture based, it is NOT, it simply deals with the data as it is displayed ON SCREEN without regard to any culture. It treats all data in the SAME way no matter where it originates or anything else, unlike the cultural standards it is also very easy for ALL users to  enter EVERY TIME to START with...except for those users who desperately desire to create controversy where no controversy should exist; of which we have a number of those.

Skip