Quoting m.cellophane:

Quote:
Quoting DarklyNoon:

Quote:
2. Only one cast and Crew list for a Film, no more DVD based lists. The very few exceptions that we will need to live with are outweighed by the amazing simplicity we would gain.

I think this is a good idea. Also, we wouldn't need to necessarily lose the alternate data, if it exists. If a film has different credits in different regions or different formats, we could have alternate cast and crew lists available.

While I agree if possible this would be a good thing (especially if alternate lists can be done). Going by his request in the original post I think it may be beyond what he is willing to do at this point. If this is the case I hope Ken will say so. This way we can concentrate more on what he is actually planning instead of concentrating on something that isn't going to happen yet.

Not sure I understand what is gotten from this? I mean how does it help matters at all? I mean parsing still would have to be done for the original 3 name fields.

Quoting VirusPil:

Quote:

...
It should be always possible to enter a new person and mark it as local only. Local only persons will be never uploaded.
...

I am not sure I understand the purpose of what I quoted. If they are in the credits then they should be uploaded. If you mean for uncredited actors... we already have this by just not checking the box when uploading. I don't see that changing anyway... not sure why it would.

One of us must be confused... as the way I understood it with the id's you wouldn't have to worry about name changes any longer. From what I thought they were saying You use the ID for the person... an ID that always stays the same and for each ID you get a list of names that person uses. So they all link. So when a new name comes up you add to that list.

But what that wouldn't solve is when 2 people use the same name in their list. I believe you would still need something similar to birth years for when more then 1 person uses the same name.

I've picked up a couple things reading this thread.

Quoting GSyren:

Quote:
I know a single name field would break current functionality, but personally that's something that I would happily sacrifice. If we can't decide proper parsing (e g Kristin Scott / Thomas vs Kristin / Scott Thomas), then sorting by last name is crippled anyway. But that's just me...

Why do we need to decide proper parsing?  If both variations are linked together, you've just pleased 99% of the users.  The other 1% are always free to cleanup the bad name if it bugs them.

I've also been following the discussion (mainly from Pete) about how he just wants to type what he sees on the screen and perhaps link a few of the bigger names.  I like this as well and suggest that perhaps these actors have a field to indicate if they've been linked or not.  Those who care could then easily identify which cast / crew need some additional research and which have already been taken care of.

Ok, I know that I am repeating both myself as well as others, but it's easier for me to just say it all at once rather than tailor my post against what was said.


1) Cast/Crew Unique IDs sounds great, but it is no more helpful than the current system if there isn't a way on the fly to identify individuals against the current ID.

Pick a name that is common -- John Doe for instance -- and look through the online database at how often that names shows up. Ok, first we will have to drift away from the old system into the new one. So I resubmit the data found in my local DB from a single movie that I own where all cast had already been stored in the online DB (same as any other update in the current system). How then would that initial link between the actor and a unique ID be established? If it's done automatically, then there is no linking. You can't assume every John Doe is the same; you can't assume that a new one added is the same as one already in the system. So, before John Doe (not to mention every other person) can be entered into the system as connected to an DVD, the unique ID already needs to be established in the system for the name to have something to latch onto otherwise it is given a unique ID, the next submission of the same actor (particularly if the submissions are going simultaneously) will get a different unique ID, and so on.... and next thing you know we have a linking system that is no better (and probably even worse) than what has been complained about for years.


2) Film Unique IDs creation for me is even more important than changing the cast/crew system because it can be a major work-load reducer. Currently, a film's data was entered and then copied to several UPCs including those in other languages. If a change is made, to be helpful people then have to go through every copy in every language to make that same change. This type of system has flaws of its own in it's most basic form, but it also has practical applications.


3) ID Merging would be another necessity. Looking at this from a cast ID system only (no Film IDs), I am entering a brand new film not yet in the database. Assume for the moment every other cast entry and UPC/Disc ID entry in the database has been fully cleaned up and integrated; the cast system is currently as perfect as it could get. From a local-versus-online DB standpoint, there are still three types of cast groups: a) Cast members in my local DB that were pulled from the online DB because I own and updated the films. These are bridged between local and online DBs by the Unique ID just like we wanted; b) Cast that I am adding which are new to my local DB (no other film was ever added or updated from online DB) but exist in the online DB. Locally these have no IDs (or at least none that are yet synced to the online DB); c) Brand new actors that I am adding that are not yet in the online database either.

Even if there is a way to check online what ID a cast member uses prior to submission, you will still have many cast members added as "new" to the online BD (with brand new IDs) because in the current system, all that is required is entering a name, although parsing in order to find the best name which in turn allows for adding as "Credited As" adds to the 'correctness' of the online DB. In the new system you'll just have members accepting that "this John Doe is different from the others" whether by lack or research or though slip-ups.

There will need ot be a way to later say "OK, this guy in this film, under this DVD/Disc ID with this cast ember ID is the same as this other guy with the same name but has a different ID; someone simply messed up; now we need ot merge to fix the problem."



If #1 and #3 options are taken as the forefront of the new system, would it really think that this will be an improvement over the system that we currently have? It sounds to me like the exact same problem as we are dealing with now, just done in a different way as well as some possible additional problems.

Quoting Addicted2DVD:

Quote:
Quoting VirusPil:

Quote:
Quoting Addicted2DVD:

Quote:
Quoting VirusPil:

Quote:

...
It should be always possible to enter a new person and mark it as local only. Local only persons will be never uploaded.
...

I am not sure I understand the purpose of what I quoted. If they are in the credits then they should be uploaded. If you mean for uncredited actors... we already have this by just not checking the box when uploading. I don't see that changing anyway... not sure why it would.

Simple answer: for those users tracking something completely different. ("Wineprofiler")

Still not sure if that is needed... as in those cases you wouldn't be submitting it anyway.  But there may be something there I am just not understanding... wouldn't be the first time. 

Would be needed just at my first idea (1.)), because to have a new person in the database it has to be added online. So you would lose the possibility to track also for example Laser Disc, VHS, ... which have actors in it which are not in the database.
Of course on the next idea which add the person at submitting it wouldn't be needed.

Quoting Addicted2DVD:

Quote:
One of us must be confused... as the way I understood it with the id's you wouldn't have to worry about name changes any longer. From what I thought they were saying You use the ID for the person... an ID that always stays the same and for each ID you get a list of names that person uses. So they all link. So when a new name comes up you add to that list.

But what that wouldn't solve is when 2 people use the same name in their list. I believe you would still need something similar to birth years for when more then 1 person uses the same name.

Wouldn't it be like that: you will always have the possibility to add a new one. For example:
In database: John Doe (ID 123456789) [aka John A. Doe]
If you add a new one, the second will be: John Doe (ID 987654321)
The ID instead the BY as separator and as collector for the variants.