Quoting T!M:

Quote:
Quoting Kulju:

Quote:
we must get rid of BYs. In some cases they are impossible to find [...]

Make that: in most cases they are impossible to find. The amount of much-needed, but impossible to find birth years in my database literally grows every single day. The addition of the new 3.5 art crew (or even worse: custom crew) seems to make clear that just about everyone has a namesake. The scenario where we'd need birth years for four different John Doe's seems pretty horrific: in real-life, you're lucky if you can find one or two of the needed birth years.

I agree.  We won't be able to find BY for majority of cast and crew.  As I have previously outlined, we should just use a unique ID for each actor linked to their credited name in a movie linked to their online common name linked to their local common name.

Quote:
I think the easiest solution for Ken to implement would be to assign a unique actor ID to each actor.

Chow Yun Fat = Actor 10023 for example

Then you can link this to any cast entry that he appears in as

Cast102Movie23453 = Actor 10023 where Cast102Movie23453 would be how he is credited in Movie 23453.

In your local database, you can individually choose what his common name is by selecting a different username such as User10023 = Actor 10023, but the displayed user name is Yun-fat Chow.

Further improvement can be made in the program so that when you add new cast and crew, you are first required to select the actor from a pre-approved database rather than entering whatever name you want.

So in conclusion, in this system

Actor 10023 = Chow Yun Fat (or whatever Invelos chooses as a community name)
Cast102Movie23453 = Chow Yun-fat (or however he is credited in the movie 23453)
User 10023 = Yun-fat Chow (or whatever the user decides is the name he/she wants displayed for this actor in the local actor database)

I think with this system, we can satisfy pretty much all the different factions out there.  We can start out with the default of Actor10023 = Cast102Movie23453 = User 10023 and refine the names to our satisfaction from then on without ruining the online database, "as credited name", and have accurate linking.  Additional advantage is if unicode is ever added to the program, we can quickly adjust the names to reflect actual credits without destroying the existing linking.

Quoting Forget_the_Rest:

Quote:
I agree to an extent about using a unique ID but have the same query that Hal has -

Quoting hal9g:

Quote:
Quoting Kulju:

Quote:
I support the idea, but we must get rid of BYs. In some cases they are impossible to find and then we are forced to use fake ones. In my opinion Unique ID is the only way to go.

How is this unique key used when entering the person into a profile?

John Doe = Unique Key 1234
John Doe = Unique Key 1235

How do I know which one is the guy who was born in 1953 versus the one born in 1968?

If two people share the same name, how would we determine which is which solely on a unique ID?

If there are multiple matches, we need to see what titles each is in and their role or crew position.  This should give us enough information to figure out which to match to.  It would also give us enough info to know if it was a totally new person.

And, we should probably never actually see the unique id in the application.  The user interface should be designed in a way that we don't need to see or know it.

I am happy with any solution as long as I can still display the name, in Profiler, exactly as it is displayed in the film credits.

There are a pretty healthy number of people who voted that the current system is working fine.  Could any of them elaborate?

Quoting Forget_the_Rest:

Quote:
I'm not one of those but on a basic level it does work. It allows us to see who has been in which films. For some people that's enough so they would (rightly) vote that way. As those of us who dig a little deeper know though it's rather flawed largely due to the way multiple people with the same name are handled, different variants of the same name, as well as some from a non Western world.

So if you only want to see if person X from film 1 was also in TV series 2 then it's acceptable.

The other drawback with the current system is that each and every profile in the online (and subsequently in your local database) has to be updated with a "Common Name" in order to get linking to work (we won;t even talk about the fact that the "Common Name" might change later on as credits are corrected).

With the simple linking system you don't have to edit any profile, unless the person needs a BY.

Quoting hal9g:

Quote:
Quoting mdnitoil:

Quote:
There are a pretty healthy number of people who voted that the current system is working fine.  Could any of them elaborate?

I have to wonder how many of them really should have voted "I don't care about linking".

I voted to keep the existing system because I don't see the new suggestion as providing all of the features that we currently have, especially locally. If I felt confident that we wouldn't lose any current functionality, I could switch my vote. Ultimately, I think we need a unique key for each name. I think we're closer to that with the current system than we would be with the new suggestion.

My current voting option says" it's working fine", but that's not really the case of course. There are several issues that could be improved. As with many of these kinds of polls, the options aren't always a perfect fit.

I also feel that the separate contribution system, according to many of the suggestions, are trying to acheive a higher burden of proof on name-linking. I'm not convinced that's a good thing. It's popular amongst the perfectionists, but I'm not sure it will increase name-linking contributions.

Quoting hal9g:

Quote:
I think you're pretty safe, James.

Every indication in the past was that Ken was convinced that the current system is the better than a simple linking system.

I'm not really opposed to your system. I just want to be sure it addresses all of the issues first.

You asked me several pages back (this thread grew overnight! ) about how long it took me to link up my local db. I think I worked on it for a couple of sessions (few hours each) per week for 3-4 months. 

And then of course as you buy new stuff and download more profiles, it all gets mess ups. One of the things I absolutely hate about the current system is that when you have Name A (BY1) and Name A (BY2) and you download a profile with Name A (no BY), the program assigns the new profile to one of your BY names! This drives me crazy.

Also, another thing I don't like about the current system is that I can't change a common name easily. I have to edit all of the profiles for that name rather than just changing the common name. If you just change the name in your system, you can mess up profiles that were "as credited".

Let's solve the Alan Smithee problem. Also let's make sure we can do whatever we want locally, independent of what gets through the contribution gauntlet, and then we're in good shape I think.

Two things from me.

1) I agree with m.cellophane's recent post. Perhaps with some tweaking (easier end-user interaction) the current system can be greatly improved (ease of changing the common name locally could encourage changes to the online). This is especially important considering that the indications from others are that this system is likely to be retained.

2) If we do go down the unique ID route, I keep recollecting the system used on LibraryThing, whereby you're offered a name, and then the option to combine/separate works for them. I've no concept of the mechanisms behind it, or if it'd work for "us", but it keeps coming to mind for me perusing this discussion.