Quote:
I don't think we will get any meaningful linking, unless we get away from a thinking about it in names.



We need to think of it more in How we associate.  We really don't care if this is the same name as these other 10 variants.  The only thing we care about is "Are these 2 people the same".

This is a 1 to 1, not 1 to many relationship

I am not a very good diagramer, but here goes (very simplified)


                                          KEY1
      J. Doe --  John Doe -- J. R. Doe --  John R Doe -- John Robert Doe

                                          KEY2
      J. Doe --  John Doe -- J. R. Doe --  John R Doe -- John Randall Doe

Here we have 2 distinct people, represented by Key1 and Key2.  The names below them are WYSIWYT.  What name you enter is irrelevant.  No need for BY, or correct names, or common names,  the only thing that matters is the relationship between he name you entered and the key to associate it with.  In this scenario, common name would automatically be determined by the relationship of the number of entries to the key.

When you enter a name into a profile you are auditing, the system would use a soundex or some other filtering subroutine to determine possibilities, and present them into a list.  So if you type in:

John Doe as Role 1

A list would pop up and give you an option of like

1  J. Doe --  John Doe -- J. R. Doe --  John R Doe -- John Robert Doe
2  J. Doe --  John Doe -- J. R. Doe --  John R Doe -- John Randall Doe

Of course the more info you have, the closer the list becomes.  So typing in John R. Doe, would of course limit the list.  At this point, you would be able to click on a select the appropriate one.  If you did not know the right one, you would be able to look at the credits associated with each one, and then make your selection.  the entry in the DB would be John Doe (key?).  Now you have an association.

It would require work, but when fully implemented, cast and crew would be linked properly.  It would not care if you accented or not.

Now, I do not know how to implement this.  I can picture the structure, but not knowing how kens DB is designed, it may very well be a massive overhaul.

well MHO

Charlie

Quote:
Quoting paulb_99:

Quote:

Completely agree with this, of course this would only work if the actors DB wasn't local only. If i don't have a movie with John Doe i would still have to be offered the possible John Doe's.

Also, i'd like to say again, just as Staid S Barr said, i'd really prefer if there was a movieDB where everybody owning a movie, not a DVD could vote on. Regional/version differences can than be applied where needed and voted on. First movie based, if than it turns out that more people have the original credit it is than dclined, and you could submit for your UPC only.

Paul

Once started, only partially.  The master key would have to be centrally processed.  But once you had the proper information, then you could work locally, until you came across a name that was not in your local.  Then it could search online for the proper connection.

There is a downside to this system.  The management of it would become large.  Just think if you were to add a new name for a new key.  Who and how would this be handled.  Then the other issue, Heaven for bid if an association was wrong, and you tried to submit a correction.  The way our voting system works, I don't think it could be managed.

Charlie

Quote:
You know that i agree with you 100% Martian. Mika seems to be describing simple association. But each title is unique unto itself in terms of its data. That is the point from which we start creating a linking system. We do not create a link system which results in fictional cast/Crew and company data.