Re-posting this here to try and gauge on a user level, how many would be interested in this -

Quote:
Hmm, I've just had a thought (always dangerous  ), would it be possible, when contributing cast/crew that include new Credited As data, for the system to automatically add, in a non-editable field, the CLT figures for the relevant entries?

That would then make everyone happy in that regard.

Just a thought, I'm not a programmer so don't know how hard that would be to do.

Edit:
Just to add that in cases where the CLT should be ignored, you'd still be free to include links to threads the same as you are now.

I do see a problem with it though.  The CLT does NOT  ignore punctuation.

so the following would all return different results, since the CLT only looks at the Credit as field.

Joe Smith Jr
Joe Smith, Jr
Joe Smith, Jr.
Joe Smith Jr.

I think the CLT needs to ignore puntuation when retrieving results...

Quoting CharlieM:

Quote:
I think the CLT needs to ignore puntuation when retrieving results...

Same for initials (J. K. Simmons vs. J.K. Simmons). I would also very much like to see something to be done with regards to season indicators for TV shows: currently each localized season indicator is counted by the CLT as a different title, multiplied by eight times if such a set has child profiles for each of the, say, eight discs. Think of that in two dozen localities, and hey presto: just one misspelled credit can easily be declared the "winner" by the CLT despite a lifetime of credits under a slightly different name variant. That's something I'd like to see addressed first (suggestion: getting the season/disc indicators out of the title field, and into a new, separate field of it's own, which doesn't get counted as a title by the CLT).

In general, I can see how some users would like this, although I personally haven't seen a single user lying about the CLT results yet, so in my personal experience, this is an area that doesn't really need improvement. I'm not missing anything now, nor would I expect to gain anything with this. But I have nothing against it either, obviously - although we should be extremely wary of taking the CLT numbers on face value. The big problem with the CLT is that it generally declares the IMDb-name the winner - and not always because it actually is the person's common name, but simply because over half of the profiles in the DVD Profiler database still contain IMDb-mined cast and crew data. As of yet the CLT is a nice starting point, but I never ever take the numbers on face value. The danger of implementing something like this might be that we suddenly are declaring the numbers on face value as the absolute truth - which will lead to propagating incorrect IMDb-mined names for years to come. That's my main concern.

I'd also like to see the CLT taking birth years into consideration. One of the mistakes I'm seeing the most, common name-wise, is users removing previously established "credited as" usages because they've found that the "credited as" value now has a larger CLT number than the comnon name. What they tend to forget is that, in those cases, there are usually different people with the same name involved - so rather then improving the situation by splitting these people out, they're linking them all back together, just because the numbers, taken on face value, say so.

All in all, it's important to realize that no matter how nicely the numbers are provided for us, it still remains a hell of a job to do it all correctly. You have to wade through IMDb-mined data, incorrectly formatted titles, missing original titles, incorrect production years, people with the same names, TV-show credits that are literally counted dozens of times due to endlessly differing and translated season and disc indicators, and so on. Automatically providing the numbers when contributing doesn't make that job any easier. Again: I'd have no problem with it. If it were up to me, though, I'd rather see Ken working on some of the issues I just named first - each improvement in those areas will improve the accuracy of the numbers, after which I'll be just a little more interested in them than I am now.

Quoting CharlieM:

Quote:
Quoting Prof. Kingsfield:

Quote:
Charlie:

Actually since punctuation is our standard, it should ignore lack of same perhaps.

Skip

What I am saying is, CLT doesn't ignore it.  So if it pulls info automatically, it will only pull the info on the 2 variants that are presented.  And punctuation is not necessarily our standard, you know that Hollywood will punctuate as they see fit.

The punctuation based names have an auto filter on them though. As a result, we the users aren't responsible for the common name.

Though i will say the BEST possible answer remains Simple Association, that will end this silliness.

This Commonly Credited name will always be problematic as long as it is based on user data entry, and with various exceptions to complicate mattersj. There is only one thing to figure out with SA and that would be a method to be able to share the associations when they are made. But beyond the sharing the data would be handled on a local basis, why should say Tim be expected to search on Robin Wright Penn, maybe he wats to search on Robin Wright....and with SA he would be able to search on ANY variant and get the same list of films

Skip

Quoting Forget_the_Rest:

Quote:
Quoting CharlieM:

Quote:
Quoting Prof. Kingsfield:

Quote:
Charlie:

Actually since punctuation is our standard, it should ignore lack of same perhaps.

Skip

What I am saying is, CLT doesn't ignore it.  So if it pulls info automatically, it will only pull the info on the 2 variants that are presented.  And punctuation is not necessarily our standard, you know that Hollywood will punctuate as they see fit.

The punctuation based names have an auto filter on them though. As a result, we the users aren't responsible for the common name.

If I understand right, the CLT doesn't care about the common name, only the name in the credited as field.  So the auto filters would not make any difference.

Tim:

Obviously for people like the Hales and others we would still ned a discriminator. This would probably best be handled via a Unique ID for each name but...I see some issues with that, and haven't figured out a resolution yet.

Anything would be btter than the system that we have right now, dependent on user data entry and users refusing to provide supporting documentation

Skip

Quoting lyonsden5:

Quote:
Quoting Prof. Kingsfield:

Quote:

Anything would be btter than the system that we have right now, dependent on user data entry and users refusing to provide supporting documentation

Without trying to start anything the way I see it ,based on the votes I've seen, most users are more than satisfied with the documentation given on most of the entries, even those that just cite the CLT and not put the results. (of course there are exceptions and of course there are those who are flat ourt wrong at times)

There are a few who demand stricter documentation, yourself being one of the most vocal about it. Ken has already stated more than once the stricter documentation is not required.

IMNSHO the system would work much better if those who request (or even demand) more documentation than Invelos requires learn to deal with it and lock down their local if they don't like it, just as they would (and do) tell others about whatever it is they don't like in the program or the rules.

Again, not trying to start something but for years I've listened to you say things like "its Ken's program" and "who are you to tell Ken what to do" yet on this issue you dig your heels in and fight with tooth and nail, even after Ken has clarified his position more than once.

To me your continued ranting about requiring more documentation even though Invelos doesn't ask for it is the same as when surfeur starts in about correcting overviews*, something you jump all over him for. The Invelos policy is clear for both issues yet for some reason you only see it as "carping" when surfeur does it for the issue he doesn't agree with. Gues what, you're both carping. 

If you want more documentation then you need to rally your troops and try to get Ken to change it. Until you successfully do that you can't expect the community to do what isn't required.

*@surfeur - I am not trying to drag you into this or say what you are doing is right or wrong, your's is just an example that I believe is quite well know in the forums and one that Dr. Professor will usually jump on immediately.

Hey if you like slop, rick, then yes I would have agree but i am not a pig, and i don'ty like living in a slop pen.<shrugs> And as i have said before such slop may get into the Onl;ine but it wiill NEVER see my database, the one thing i hate is that the slop colors good Contributions that come after it.

I am not saying that to offend or be argumentative, Rick. But I don't like undocumented data, I don't like people who say "it is because i say it is" and i will not accept any such data EVER. If you will simply provide CLT results, unless i have some question about NameA=NameB, I will more than likely vote Yes and i will be willing to accept the data. Otherwise, forget it. I won't support and I don't understand why ken is willing to allow it to happen.

Your comments are not very complimentary to the community however, Rick.

Skip