Quoting Unicus69:

Quote:
Quoting T!M:

Quote:
FYI: I just spotted a news item about Jennifer Love Hewitt on IMDb this morning (link). It had the line: "Love Hewitt split from fiance Ross McCall in December after three years together." I wonder how everyone here parses her name? 

'Jennifer/Love/Hewitt'...how else would we?  'Love' is her middle name and, if you read her bio at IMDb, you will see that she goes by that offstage.  In fact, in her early career on Kids Incorporated, she was billed as 'Love Hewitt'.

I agree. Also, on her official site (according to Wikipedia) in her bio a paragraph starts "Hewitt received critical acclaim" - Source

Quoting m.cellophane:

Quote:
Quoting Dr Pavlov:

Quote:
James, this idea simply winds up with a complete and total MESS, it winds up with data which in some cases will be a complete and total departure from the appearance of the data On Screen.

"This idea" is to keep what we have, so it can hardly be called "a complete and total MESS". We have a pretty good system. It just needs some backup in the rules IMO. And parsing has nothing to do with "the appearance of the data On Screen." Whether one parses D/O/S or D//O S, the program still displays D O S exactly as it is on-screen, especially in the Credited As field which is a one-name field.

I think, and I could be wrong, he was refering to your suggestion that "Last Name" = "Surname and Suffixes". 

Quoting m.cellophane:

Quote:
Which is still keeping what we have or calling it what it is. IMO. 

But it isn't...at least it isn't when we talk about asian names.  If we call it 'surname', then 'Chow Yun-Fat' is entered as 'Yun-Fat Chow'.  As I said earlier, I don't think that is the best solution as every asian DVD will have to be redone.  Who's going to do all that work?  I know of one user, with a large asian collection, that has already said he will stop contribution should that happen.  Because of that,  I don't think it is a very good idea.

Quoting xradman:

Quote:
Quoting pdf256:

Quote:
Quoting Dr Pavlov:

Quote:
Quoting m.cellophane:

Quote:
Quoting Unicus69:

Quote:
Quoting Ken Cole:

Quote:
We don't intend to move to a single name field since it would reduce functionality as others have mentioned.  However, I don't see a problem with moving to a two-field name, which would reduce (although not eliminate) parsing disputes.  Thoughts?

A two name field wouldn't solve any of these issues as the problem of which name(s) belong in the last name field will still be there.

Using this name as an example, would it be 'David Ogden/Stiers' or 'David/Ogden Stiers'?

What would solve this issue is to create a base standard, in the rules, with deviation allowed with documentation.  JMHO

I agree with Unicus.

I don't like the suggestion of renaming the fields as Name 1, Name 2, Name 3. In that example, a two word name would occupy Names 1 and 2. Basically we want all of our surnames in the same field so that some people can sort on them.

Stating in the rules, for example, that "Last Name" = "Surname and Suffixes" would be helpful. But basically Unicus' last sentence is what we need, and it wouldn't require messing around with the program interface.

James, this idea simply winds up with a complete and total MESS, it winds up with data which in some cases will be a complete and total departure from the appearance of the data On Screen. As I have said many times any solution must deal with this. We are tracking MOVIE data, not family names, histories or profiles...MOVIE data. This is not IMDb nor some other completely inaccurate mess. The comments I read from several users are symtomatic of what I have said in relation to some strange form of vested interest in the data, almost as if it were a prersonal affront. I am also amused at the repeated usage of A-List actors, Helena Bonham Carter, Jean Paul Belmondo, whatever to bolster their argument, A-listers which are easily documented, but there are THOUSANDS of actors and Crew who are NOT A-Lisiters and for whom such documentation would be near impossible to support beyond an assumption or a guess, and all this does is provide a starting point while maintaining the appearance of the data matching the On Screen data.

Skip

If all we are tracking is 'Movie Credits', then a single name field is the only way to go! We would type in what we see and be done with it!

The only things that get lost are reports listed by actor/crew last name and this could be fixed with a sort name field.

pdf

Why would anyone outside of those few in this forum be interested in 'Movie Credits' over who actually starred and made those films?  I can't for the life of me figure out why someone is more interested in how Joe Blow is credited than what movies he was in.  We need to fix the linking problem and then go from there.  If you are interested in 'credits', just posting screen shots would achieve 99% of the purpose without any prejudice.  You can't really link with the current system anyways, so that shouldn't be a problem.

I agree with you, linking of cast and/or crew is the key to database usefulness!

And I think that a single name field plus a credited as field would be the way to go.

pdf

Quoting m.cellophane:

Quote:
Quoting Dr Pavlov:

Quote:
James, this idea simply winds up with a complete and total MESS, it winds up with data which in some cases will be a complete and total departure from the appearance of the data On Screen.

"This idea" is to keep what we have, so it can hardly be called "a complete and total MESS". We have a pretty good system. It just needs some backup in the rules IMO. And parsing has nothing to do with "the appearance of the data On Screen." Whether one parses D/O/S or D//O S, the program still displays D O S exactly as it is on-screen, especially in the Credited As field which is a one-name field.

Quote:
We are tracking MOVIE data, not family names, histories or profiles...MOVIE data. This is not IMDb nor some other completely inaccurate mess.

Parsing names has nothing to do with IMDb. And we DO track family names because the program offers the option to display with family name first. It is this function that Ken cites in his post about why we cannot return to one field.

Quote:
The comments I read from several users are symtomatic of what I have said in relation to some strange form of vested interest in the data, almost as if it were a prersonal affront. I am also amused at the repeated usage of A-List actors, Helena Bonham Carter, Jean Paul Belmondo, whatever to bolster their argument, A-listers which are easily documented, but there are THOUSANDS of actors and Crew who are NOT A-Lisiters and for whom such documentation would be near impossible to support beyond an assumption or a guess, and all this does is provide a starting point while maintaining the appearance of the data matching the On Screen data.

Skip

On Screen appearance is always maintained in the current system. The "vested interest" is to input the data so that it follows the functionality of the program. You may not use that functionality, but it's there for others and we need to be mindful of that.

Quoting Dr Pavlov:

Quote:
In additon to renaming the fields so that they more correctly communicate that the data looks like it does On Screen, and the addition of suffix and prefix fields. If Ken wants to allow, probably through the CLT, a system which will allow for"improper" surname usage, (improper in the sense that the data will not look like the On Screen data) then that could be done WITH documentation, not guesses or assumptions or statements "because he is Chinese" or some such.

Rule #1 we are tracking MOVIE data not Family data, What someone's Family history might be is not of any relevance, the MOVIE credits are relevant.

Your comments do not reflect the name format options of the program.

Quote:
One other addition I would consider is refinemnet of the BY data for those instances when BY data is is not available. I presume we could document an earliest known appearance on screen and that could substitute as BY data to separate multiple name instances  where no BY can be obtained.

I'm sure Ken could implement a system for the online in which a number could be assigned in place of a birth year to designate the first non-BY variant, second non-BY variant, etc. Therefore, if one was contributing a John Doe that is not the John Doe (1971) in the system, one could check a box and it would be assigned as John Doe (1) or something. That requires no documentation of what the person's first credit is. It's just first-come-first-served.

No it's not James, you may have convinced yourself of that but as soon as you entered the Surname point you deviated from the credits. Many films do not say Yun=Fat Chow, they say Chow Yun-Fat, this would tickle the Asian fans tremendously but would totally deviate from the data appearing as it does On Screen, Why don't we just go the route of IMDb, even better IMDb already exists, so if you want to go down that kind of road, Profiler is not needed. Which is just a crazy idea.

The very foundation is based upon As Credited, attack that and we will have a garbage can for a database. Now how can we continue As Credited and achieve the desired goal, there are many different forms, as I have expplained previously many times, I personally believe Ken chose the weakest method...perhaps he sees something that I haven't seen (always a possibility) but I doubt it. The BEST possible answer remains a simple association. You guys keep holding up linking as some sort of a God to worship at the feet of, linking IS important but the bottom line for linking is that it functions better at the local level, so ideally we need a system which is sharable and and verifiable(documentable), not based on some the notes that have recently been generated by some users who simply want an easy way out, they profess to want accurate data and then take every possible shortcut to avoid generating accurate data, including not even including CLT results at a bare minimum.

So the question remains the same as always. HOW do we re4tain As Credited and still give some users what they want. For me to explore this further, I want Ken's active involvement in the discussion, there are numerous ways to do this.

And we need users to understand the foundation which i am not sure they do based on some of the comments I see being posted, all they want to achieve is their particular preference, which is a local matter ONLY. We don't need to return the bad old days when we guidelines and users submitting and resubmitting data based on how any given user was trying to manipulate the Online database, it didn't make any difference that the credit said Chow Yun Fat...this week someone would enter Chow Yun-Fat, netx week someone will submit Yin-Fat Chow, and then Yun Fat Chow and everyone gets a head ache with the constant and never-ending updates. According to Ken, we had ONE title that got edited and re-edited over 2000 times as users battled over how they wanted the data to appear. That was useful and productive....NOT!!!!!!!!!

How many of you recall that users used to manipulate even the sort title Online to suit themselves, so that sometimes if were looking for Thunderball you might have to try James Bond 04, Jame Bond004 or even James Bond IV, everything BUT the title and it changed regularly. Ken finally PUBLICLY said that Sort Title+TITLE, that changed nothing, because there were some users, some still active here, who simply wanted the ONLINE their way...it ain't Burger King. So, finally Ken was forced to make it strictly a local decision for sorting and the Online would be sorted based on HIS parameters.


Skip<shakes head>

Quoting Dr Pavlov:

Quote:
No it's not James, you may have convinced yourself of that but as soon as you entered the Surname point you deviated from the credits.

The surname is required for the functionality of the program.

Quote:
Why don't we just go the route of IMDb, even better IMDb already exists, so if you want to go down that kind of road, Profiler is not needed. Which is just a crazy idea.

We've had 3 name fields for years and years. DVD Profiler has functionality for sorting by surname. There's nothing about this that has anything to do with IMDb.

Quote:
The very foundation is based upon As Credited, attack that and we will have a garbage can for a database.

We had 3 name fields and the ability to sort by last name before we went as-credited. We have the ability in the program to do both.

Quote:
So the question remains the same as always. HOW do we re4tain As Credited and still give some users what they want. For me to explore this further, I want Ken's active involvement in the discussion, there are numerous ways to do this.

We have 3 name fields and a Credited As field. It seems that we already retain as-credited.

Quote:
And we need users to understand the foundation which i am not sure they do based on some of the comments I see being posted, all they want to achieve is their particular preference, which is a local matter ONLY. We don't need to return the bad old days when we guidelines and users submitting and resubmitting data based on how any given user was trying to manipulate the Online database, it didn't make any difference that the credit said Chow Yun Fat...this week someone would enter Chow Yun-Fat, netx week someone will submit Yin-Fat Chow, and then Yun Fat Chow and everyone gets a head ache with the constant and never-ending updates. According to Ken, we had ONE title that got edited and re-edited over 2000 times as users battled over how they wanted the data to appear. That was useful and productive....NOT!!!!!!!!!

I'm advocating rule clarifications to solve some of our current issues. How exactly will that result in weekly changes of how to parse Chow Yun Fat?

Quote:
How many of you recall that users used to manipulate even the sort title Online to suit themselves, so that sometimes if were looking for Thunderball you might have to try James Bond 04, Jame Bond004 or even James Bond IV, everything BUT the title and it changed regularly. Ken finally PUBLICLY said that Sort Title+TITLE, that changed nothing, because there were some users, some still active here, who simply wanted the ONLINE their way...it ain't Burger King. So, finally Ken was forced to make it strictly a local decision for sorting and the Online would be sorted based on HIS parameters.


Skip<shakes head>

Our current name issues are not nearly the issue that sort titles used to be. And rule clarifications won't cause ping pongs. Quite the contrary.

Quote:
we have a few users who balk at providing documentation to other users, preferring instead to hide behind comment of ken or gerri which can be interpreted in different ways itself. I will ALWAYS, should I decide to Contribute again or something, provide detailed notes not so much for Ken and gerri as for every other present and future. This is a never-ending process for me as I will go back and look at notes I typed maybe a year ago and wonder what I was trying to say, which tells me i am not being clear enough.

The CLT documentation issue is not related to name parsing. Invelos has provided a resource for name linking. Not so with name parsing. It would be nice if they could provide some further guidance for how they'd like names entered into the fields. That's all I'm asking for.

How's this for an idea.  Invelos maintains the common name database and users link to that with "as credited" name.  User when making new profiles, enter only a single field "as credited" name and link it to a master common name database.  User may request a name be added or changed to the common name database much like how we contribute DVD profiles, but it would be up to the screeners to accept a new name or make changes.  We have our linking and "as credited" credits.

Quoting Dr Pavlov:

Quote:

The surname is NOT require for the finctionality of the program, James, where did you get that from. All that we need to know is that Chow Yun-Fat=Yun-Fat Chow, that's it, I need to be able to document the association,(which is easy in this case) but it is not of ANY relevance to this program what the surname is or is not. It would be very relevant if this were FamilyProfiler, but it is not and all we need to do is establish that two variants are the same person. If Mr. Chow is NOT credited as Yun-Fat Chow, then even that is not relevant I would argue, though for the sake of our Asian fans I am willing to try to seek a way to deal with this for them. But don't pretend that Surname has some relevance which it does not in this Program.

Skip

Surname matters for sorting purposes.  This can be easily solved with a check box in cast/crew name database to indicate which name to sort by.