Quote:
Quoting Dr Pavlov:

Quote:
It's been explained repeatedly for years, Tim. But its not what you want to hear, nor from whom you want to hear it from, but that does not invalidate the answer. nor that one has been provided and explained.

Please point me to that answer in the rules. It just isn't there. I know you don't have a problem - neither have I. The result, however, is a mess in the database, and ignoring the problem doesn't make it go away. Again, and as I said above as well: I perfectly understand why this is such a disaster, and you may understand it as well, but you and I understanding the problem doesn't equal a solution. Your stance on this hasn't changed for years, mine hasn't either. We both understood the problem then, and we both understand it now. Over those past few years, though, things haven't improved, and the database still contains pointless dual entries for every three-piece name out there.

You can try and turn this into another dig at me, but the fact of the matter is that it's not. As I said: we desperately need to come up with something that causes ALL users, throughout the various regions and localities, and burdened with different cultural backgrounds - and including those that don't regularly visit these forums, to automatically do it the exact same way. That's what we need.

Quote:
Think about that comparison for a minute: just as it doesn't really matter which common name we pick, as long as we all pick the same one, it really doesn't matter which way of parsing we apply to the common name, as long we all pick the same way. There's the key.

Quote:
Quoting surfeur51:

Quote:
Once again, two or three fields is exactly the same. We have to decide where to put the "middle" name if it exists, and no rule will ever be able to solve that problem.

No, the problem would be solved if there was a rule that said to put all given names in the first field and all family names in the last. The only problem we could have is if the middle parts are only initials and we don't know if they represent a given or family name, but we could tackle that with a rule that said to always put those initials in the first field.

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

Quote:
Quoting Dr Pavlov:

Quote:
But I really don't comprehend the relevance of parsing, except as it relates to linking.

So you do understand the relevance? Because that's it. Parsing doesn't just "relate" to linking: the free-for-all approach to it mostly serves to BREAK linking. As pointed out time and time again: the database still contains dual entries for essentially EVERY three-piece name out there, and there's been no sign of improvement over the past few years. It's nice that you personally don't have a problem. I don't either. Basically, we all do as we please - isn't that what you're saying? I understand how that works wonders for every individual user, yes. But the database as a whole is still a mess, though, and while you're apparently not terribly concerned about that, I am.