Quote:
After thinking about it some more, though, I realised you could quite easily accompany this with a line in the rules that clarifies that the first word of any name goes into the "first name" field, and all the rest goes into the second field. And hey presto: then we're done. Everyone on the same page immediately, and no more questions about this ever. 

Quote:
When i first saw Ken's suggestion two field proposal my immediate preference was the opposite...last word in the last field, everything else in the first. <shrug>

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?

Though I'm at this moment a little off those forums, I think this is too important a problem not to give my opinion.
Two-fields names have no more and no less advantages than three fields : you always has to choose where you put Scott for Kristin Scott Thomas, and no rule, no automatic system will ever solve that problem for all type of names (american, european, asian cultures). What is important is to allow to decide which field is the sort field (with a check box, for instance), to resolve stage names and asian names problems.

I think that a solution as
Name Field #1
Name Field #2
Name Field #3
would be the worse. We would get things like Jean/Paul/Belmondo or Cedric/The/Entertainer or The /Dandy/Warhols, which would be even worse than present situation.

Quote:

When parsing names, enter the first name into the first field, enter the last name (surname) into the third field and enter everything else into the second field.

Clarifications and exceptions:
Titles such as Dr., Colonel, Father, etc will be entered in the first field before the first name
Suffixes and affiliations/degrees such as Jr., M.D., S.J.  will be entered in the third field after the last name (surname)
If documentation is provided to support that a person has a double-barreled last name (surname), enter it entirely in the third field
If documentation is provided to support that a person has a double-barreled first name, enter it entirely in the first field
Stage names are to be entered entirely into the first field
Articles (such as de, de la, di, von) are to be entered in the appropriate name field along with the name that they precede

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

Quote:
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.

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