I know that, karsten. However I also know the predatory nature of the parent Company. I would look for some other answer. Remember predatory companies such as this one are not interested in winning a lawsuit necessarily, they are interested in forcing a competitor into expending its resources on defense instead of development, ultimately resulting in the demise of the targeted company. Caution is better part of valor, I will do nothing nor make any recommendations which might have any potential to imperil the Program or Ken

Skip

Quoting DJ Doena:

Quote:
Quoting 8ballMax:

Quote:
First off, who decides what the Crew or Cast member's "real" name is? How is it to be determined? What sources would be considered valid?

Once you have an Id for an actor like 08154711 that's the master key for the actor. If you have that you can even use the same procedure as today to determine the common name, use the CLT, provide cator's homepage links, ...

And if there's a need to change the common name, it has no impact on the database itself because everywhere he played there is just noted "08154711".

It would look something like this

Actor Table
ID | Common Name
1  | Courteney Cox
2  | James Tolkan

Movie Table
ID | Name
1  | Masters of the Universe
2  | Friends: Season 10
3  | Back to the Future

Cast Table
MovieID | ActorID | Role                    | CreditedAs                    | Uncredited | ...
1          | 1          | Julie                    | Courteney Cox              | false          | ...
1          | 2          | Detective Lubic    | James Tolkan                | false          | ...
2          | 1          | Monica Geller-Bing | Courteney Cox Arquette | false          | ...
3          | 2          | Prinicpal Strickland | James Tolkan                | false          | ...

Let's say I contribute a John Smith [Johnny Smith] and you contribute a Johnny Smith. How would the db handle that?

Quoting EnryWiki:

Quote:
Let's say I contribute a John Smith [Johnny Smith] and you contribute a Johnny Smith. How would the db handle that?

First of all, you have to have the entire actor database locally. It has to be downloaded just as the basic DVD information you get every time you press "Add DVD".

It's not that big, even if we talk about ten thousand actors. Let's assume 50 bytes for the entire name, 4 byte for the ID, 2 byte for the birth year, that makes 574 kilobytes in  actor database. Let's assume that every third actor has one alias (My personal prediction is that it's less than every third, but some actors have well more than one alias). So let's say it's another 500 kilobytes. Currently when you install the program you download nearly 14 megabytes already. Then it's 15.

Now you profile DVD. When you search for an actor, it looks up the name table and the alias table and presents you the results, either by direct hit or by suggestion "person X is sometimes credited as Y".
Now you have the problem of determine if either of the listed names is actually your actor (and which one) or if you have an yet unprofiled actor. That's basically the same problem you have today when you want to determine a common name: you have to know under which names he (or she) goes, when he was born, in what other movies he starred and so on.
To help the user it could be useful to have a "lookup" button which presents him with a list of DVDs this actor is profiled in - I would do that via online query, because a crosstable would be about 100 megabytes (400,00 DVD profiles times 30 actors times 8 bytes).

If you choose the actor, the DVD profile links to the actor ID.

If you think he doesn't exist you create a new actor profile and enter his name as credited. When you contribute this the vote screen shows that you attempt to create a new actor and people can vote accordingly ("already exists as ..."). If it comes through, then there is a new actor in the database. If someone sees your mistake and re-assigns the credit to another actor, contribute and gets accepted, then the new actor has no profiles assigned to him and gets dropped from the database again.

What about concurrent updates? Let's assume two people in different localities profile the same movie where a new actor appears for the first time. The first contributes and it happens as above. The second one contributes but before he confirms the contribution he is informed that the same name was recently contributed and he must confirm whether this is the same person.

Will this always work in all cases? Nope. The less known an actor is the less likely is it that his two appearances as "Soldier #3" will link together if he is credited differently. Will it work with large parts of the cast and crew? I think so.

That's the way I'd do it and I know that it's a lot more complicated than it is currently implemented. But if you want to have a database that actually links actors and not only by accident, then there's IMHO not much of a choice. And let's face it: Have you ever tried to contribute to IMDb? Have you seen that crappy webinterface? But they have managed to get actors and movies linked - and that's the reason I'm using their data when it comes to cast lists and not the one from DVD Profiler.


But this entire discussion is academic as long as Ken doesn't announce that he actually wants to change the way it works now.

Quoting DJ Doena:

Quote:
PS: If it stays the way it is now then at least allow the entering of a birth year regardless of possible actors with the same name. Yes a birth year is "additional information" but it's also an additional identifier that helps to distinct one person from another.

If I see a John Hannibal Smith and a John Smith I assume that they are actually different persons. If it is John Hannibal Smith [1928] and John Smith [1928] I'd get suspicious whether these are really different persons.

I agree with that. It would be cool to allow to enter birthday years for all actors and crew when they are known. It's really a pain to verify each time we get a birthday year from an online profile if it is a "coorect per the rules" one. Extra work for no added value.

Maybe it's just me, but if it's as simple as you guys are saying it is, why hasn't Ken done it already?  I mean, it's been what, 9 years now? 

Quoting DJ Doena:

Quote:
Quoting Unicus69:

Quote:
Maybe it's just me, but if it's as simple as you guys are saying it is, why hasn't Ken done it already?  I mean, it's been what, 9 years now? 

I never said it's simple, I just think it's a better solution.

And I don't mean to be offensive or insulting, but maybe this entire thing started out as hobby project of a hobby programmer and now it has grown so much that a modification is beyond his skills?

My understanding is this was not a 'hobby' project by a 'hobby' programmer.  Intervocative was a company formed by a few programmers to market and sell their products.  Ken was the only programmer to produce a marketable product.

We have invelos be cause Ken go tired, and rightly so, of other people making money off the sweat of his brow.

As to the rest, I don't know and honestly don't care.  I spent $20 on this program nine or ten years ago.  That pittance wouldn't cover the band width I have used in that time.  If the program never improved from this day forward, I have more than gotten my money's worth.

That is another reason I don't understand people who complain that the program doesn't do this, or doesn't do that.

Quoting madacid:

Quote:
to keep his scheme:

"MovieID","ActorID[John SMith]","his Role","Johnny Smith", "false"

simplest DB structure. even when his common name becomes "Derka Mohamed", this relation still is correct.

How do you know that a contribution for a  "Johnny Smith" (just that) is for John Smith? Just because John Smith is also sometimes credited Johnny Smith?

My question is:
Let's say I contribute a John Smith [Johnny Smith] and you contribute a Johnny Smith...
The first one would be easy: id:1 = John Smith [Johnny Smith]
But the second one? How does the database know they are the same person, if the contribution is just for "Johnny Smith".

Quoting DJ Doena:

Quote:
Quoting EnryWiki:

Quote:
Let's say I contribute a John Smith [Johnny Smith] and you contribute a Johnny Smith. How would the db handle that?

First of all, you have to have the entire actor database locally. It has to be downloaded just as the basic DVD information you get every time you press "Add DVD".

It's not that big, even if we talk about ten thousand actors. Let's assume 50 bytes for the entire name, 4 byte for the ID, 2 byte for the birth year, that makes 574 kilobytes in  actor database. Let's assume that every third actor has one alias (My personal prediction is that it's less than every third, but some actors have well more than one alias). So let's say it's another 500 kilobytes. Currently when you install the program you download nearly 14 megabytes already. Then it's 15.

Now you profile DVD. When you search for an actor, it looks up the name table and the alias table and presents you the results, either by direct hit or by suggestion "person X is sometimes credited as Y".
Now you have the problem of determine if either of the listed names is actually your actor (and which one) or if you have an yet unprofiled actor. That's basically the same problem you have today when you want to determine a common name: you have to know under which names he (or she) goes, when he was born, in what other movies he starred and so on.
To help the user it could be useful to have a "lookup" button which presents him with a list of DVDs this actor is profiled in - I would do that via online query, because a crosstable would be about 100 megabytes (400,00 DVD profiles times 30 actors times 8 bytes).

If you choose the actor, the DVD profile links to the actor ID.

If you think he doesn't exist you create a new actor profile and enter his name as credited. When you contribute this the vote screen shows that you attempt to create a new actor and people can vote accordingly ("already exists as ..."). If it comes through, then there is a new actor in the database. If someone sees your mistake and re-assigns the credit to another actor, contribute and gets accepted, then the new actor has no profiles assigned to him and gets dropped from the database again.

What about concurrent updates? Let's assume two people in different localities profile the same movie where a new actor appears for the first time. The first contributes and it happens as above. The second one contributes but before he confirms the contribution he is informed that the same name was recently contributed and he must confirm whether this is the same person.

Will this always work in all cases? Nope. The less known an actor is the less likely is it that his two appearances as "Soldier #3" will link together if he is credited differently. Will it work with large parts of the cast and crew? I think so.

That's the way I'd do it and I know that it's a lot more complicated than it is currently implemented. But if you want to have a database that actually links actors and not only by accident, then there's IMHO not much of a choice. And let's face it: Have you ever tried to contribute to IMDb? Have you seen that crappy webinterface? But they have managed to get actors and movies linked - and that's the reason I'm using their data when it comes to cast lists and not the one from DVD Profiler.


But this entire discussion is academic as long as Ken doesn't announce that he actually wants to change the way it works now.

If I understand correctly what you explained, that means that we couldn't just contribute credits any more without determining the person (unique identifier) they actually  belong to. That's what IMDb does.  They don't just list credits, they also link each and every credit to a person. That would be very good for the db, I agree, but it would require that each and every user does the job properly, for instance providing documentation for each actor. For instance, they should have to know if a "Johnny Smith" in the credits is actually actor 1, 2 or 3, before entering his name in the db. Hmmm...  Most DVDP users just read the credits on screen and write them down.  That's our weakness, but also our strength.