I think about it quite a bit. It's easier said than done.

The core issue here is that, to the surprise of some, we do not have fields called "first name", "last name", "middle name", "maiden name", etc. We just have two fields, "long name" and "short name". The long name is what we show on the player page, and on links to that page, and when they've become player of the day, etc. The short name is what you see in a game list.

The logic behind that design is that how things LOOK is what impresses people. If a list looks like gibberish, people think the data are a mess.

There are some chess database sites, one in particular that I truly admire, that show game titles like <Karpov, Anatoly - Kasparov, Garry>. We hold ourselves to a higher standard. We want it to read <Karpov-Kasparov> in the game lists and links. It's concise, and unambiguous.

So that's the motive: make it look good, and if it doesn't look good we can change the string until it does. It's such a dead stupid system it can't go wrong.

Your request is much more involved. Let's try to formalize it. Perhaps the schema could work like this:

<Let us store names in two fields, called $firstname and $lastname. Then when the PGN presents the player name, it can present the string "$lastname, $firstname".>

A decent start.

Of course, we know that the world isn't as simple as "last name, first name". However we have to try something, so the first name / last name approach seems sensible. To do this, we immediately have to start making conventions for handling names that aren't easily stuffed into the firstname/lastname format.

(If I haven't shared this with you in the past, it's a good read: "40 Falsehoods Programmers Believe About Names" http://www.kalzumeus.com/2010/06/17...)

An obvious starting question would be "what about middle names?" We could decree something like "The middle name, when known, should be appended to the first name after a space." Then we'd make some rule about Spanish names, how to handle Carlos Jesús Torre Repetto. And then Asian names, which present a new twist on what we call a "$lastname" — humorously, it would be the one that comes first.

Then there are a few people like "Garcia" who have no first name, and even some players like "Judy" who have no last name. And then there are computers. And people known only as "Dr. H". We can go down the list and come up with a way to stuff this data into a two-field schema, but the conventions that we have to cook up to make this thing fly will be pretty dense and at times arbitrary.

However, even having done that, we still have the display issue. I don't trust software programmed with first name, middle name, last name, maiden name, etc. to always get it right. In fact, without some special provision it would automatically call our previous world champion "GM Viswanathan". Will it know when to use the Spanish maternal surname and when it's excessive?

I'm not saying that it's a bad idea, I think it's probably a partial solution to the ideal representation. I think the near-perfect system might have representations for all sorts of names, and titles, and flags to tell it that it's an Asian name or a Myanmar name or a computer, and on top of that it should *still* have fields that are strictly for display purposes, input lovingly by hand.

The name presented outside a list could be exactly the same. In fact, outside the PGN, it could always look exactly the same.

The <display name> is very simply formed from the <collation name>.

A) No comma in <collation name>, then

<display name> = <collation name>

and you're done.

B) If

<collation name> = <part1, part2>

then

<display name> = <part2 part1>

Completely mechanical and uncomplicated. All the intelligence is done by the biographers in forming the <collation name>.

You can sort a <CG> list of players via the <collation name> and present it on the page via the <display name> if you wish.

I'm just asking <CG> to make the intelligence available via the <PGN> by propagating the <collation name> if possible.

There would be one extra step in the stack, the same uncomplicated mechanical step everywhere.

You would then exactly mirror FIDE, and all the rest.

E.g. Chinese names could be westernized or not, according to the player's implicit wishes (i.e. we assume that FIDE entered their version of the name accordingly).

Spanish names would be sorted on the patronymic as they should be.

There isn't need of additional fields in this scheme. Everything is done via the comma, and the vast majority of cases are covered.

Example 1:

Display: <Dr. J. S. Smith Garcia Jr.>

Collate: <Smith Garcia Jr., Dr. J. S.>

Example 2:

Display: <Joe Tsai Wu>

Collate: <Wu, Joe Tsai>

Example 3:

Display: <Wu Joe Tsai>

Those, being statically generated, would have to make a choice or be duplicated. So, it's relevant.>

Yes, I use the Zipfile Archive. If the PGN there starts giving names in collated-style rather than display-style, that will mess with several of my programs.

If that happened I'd probably write a whole new program to change every name in the PGN back to display-style before I did anything else... which is essentially what I'm suggesting you do, just in the other direction.

Note that I'm not opposed to creating a new <collated-style> field for every name, if somebody's prepared to put in the effort; though I'm not sure who that somebody would be, unless it's you. Collating every name accurately would involve humongous amounts of work (if you just copy from FIDE or other databases, you'll copy a lot of errors... and many names are not in any other database). And since <display-style> is what people see, very few users would ever notice that humongous effort, and even fewer would benefit from it in any way.

I am opposed to giving collated names in the PGN, though, even if somebody does put in all that work. With a good index of collated names - which would be a necessity - changing display-style to collated-style would be every bit as easy for you as doing the opposite, especially if <cg> adds pids in the PGN.

<zanzibar: <Abdel> I think everybody gets a vote, btw.

You just have to <"care"> enough to pipe up.

Of course, I'm well aware that there are different weights attached to each vote. No doubt <Switch> is in the heavy-weight bracket, given his long-term commitment and contributions round these parts.>

Julius Caesar Act 4, scene 3, 218–224>

I mean, besides <CG>?

And even then, if I were to ask you how many players have had there name changed, say from August 2014 to today, could anybody tell me?

Or how many players have been deleted?

Or how many mergers?

<Switch> do you have an idea of the scale of these changes?

* * * * *

If we don't keep the collated-name in the central location, then all the satellite mirrors will be constantly having to chase their tails.

Time after time. There is a definitive issue of stability in this scheme. And everybody who wishes to use collation-style must repeat the work - which isn't simple or mechanical.

But... if <CG> disseminates the collation names, we do the work centrally, and everybody benefits (if they wish to).

Those who don't care about sorting, or correlating with other databases for integrity checks, only need to add a simple mechanical transform step to their code. A step that is almost trivial.

Switch over, and you can almost directly compare a PGN from <CG> with those from <TWIC>, <FIDE>, <MillBase>, <ChessBase>, etc, etc.

Why is <CG> different?

Specifically, comparing Aug 23, 2014 to May 15, 2015 - about 3/4 of a year.

I've noticed many players who name has changed but no longer have a gender assignment.

<Q- Is this gender depletion a new <CG> policy, or an oversight?>

<I've noticed many players who name has changed but no longer have a gender assignment. <Q- Is this gender depletion a new <CG> policy, or an oversight?>>

https://zanchess.wordpress.com/2015...

It's far from finished, but the list at the bottom (pre-format python output) can be immediately consulted.

There's a bit of a free-for-all involved with the name changing for married women, which is done far from consistently.

And I'm not exactly sure who decides which pid gets preserved during a merge.

Also there seems to be termites here as well, happily munching various biographical information that seem to disappear in the merges.

Does anybody care to discuss the post?

There should be a <gender> (M/F) just before the <rating/#games> at the end of each line.

Doublets are listed with the old snapshot above the newer one.

I took an early lunch, and will be off-line till the end of the day most likely.

When you wrote "see my post" I assume you mostly mean the link you provided. I'm looking now.

Just to pick one example:

<old> 127442 / $ 14507323 Kristina Solic (1986.12.19) HR -- Y F 2237 / 77

<new> 133694 / $ 14507323 Kristina Saric (1986.12.19) HR -- Y 2261 / 94

This is surely one of the players that Sargon merged recently during the maiden-name cleanup. So the "F" in the first line indicates that the player is female, and the lack of an "F" indicates "no gender assigned".

But I'm confused, because if I go to the page of the new record #133694 Kristina Saric it has her marked as female. I know you can't see that as an editor, but you have access to http://www.chessgames.com/playerlis... where you can see her "F" flag set.

I did another spot-check on Rena Graf (nee Mamedova) and the same thing. You claim that she doesn't have he gender flag set, but I see otherwise.

So either your software has a bug or these records have been changed between May 15 and today. I'm hoping for the sake of the database that your software has a bug.

Yes, it's the obvious first step, and a very easy cheap way to introduce a lot of new errors into the database. FIDE's handling of non-Western names is all over the place, and contains many inconsistencies and outright mistakes.

And if you <did> copy all their data (and all their errors), you'd still have to come up with collated-style names for the ~33000 players without a known FIDE card.

<But... if <CG> disseminates the collation names, we do the work centrally, and everybody benefits (if they wish to).>

Like I said, I'm not opposed to <CG> disseminating the collated-style names; just to <CG> using them in PGN files. But acquiring the collated-style names in the first place (or at least, acquiring reasonably accurate collated-style names in the first place) is a lot harder than you seem to appreciate; so hard I don't remotely like the cost-benefit ratio.

<Those who don't care about sorting, or correlating with other databases for integrity checks, only need to add a simple mechanical transform step to their code. A step that is almost trivial.>

Nobody thinks that it's a bad thing to offer collated names, but there is an effort-to-reward ratio that we have to take into account today. We've promised to get the Sandbox up and running, at least in beta, we want to expand editor abilities to involve changing events and sites and maybe even players, we want a more rigorous and transparent logging system, and meanwhile we are scrambling to make a mobile-friendly version of our homepage.

1. mobile-friendly version of Guess-the-Move

2. improvements to the Kibitzing Search

I am aware of that, and did not mean the word "vote" literally.

All I'm suggesting is that standardization offers benefits that may not be immediately obvious, but may become so in future. Things progress, sites change, sites are even sold or merged; in case of any such eventuality, I think you may find using standard list-order will *eventually* turn out to be enormously helpful.

They might include making it possible to search for kibitzes in a specific forum.

Psst! Rumor has it Daniel is trying to neuter us all. It begins with a little inconspicuous gender depletion, and next thing you know, no one *has* a gender anymore.

Pass it on, but don't let the admins find out we're on to their skulduggery!

I'm feeling bad already, and apologize in advance - I certainly don't want to waste anyone's time chasing red herrings.

Let me redo, double-check and repost.

(I normally didn't print out the gender in my CG class __str__ function. But seeing all the deleted records I recognized many were due to merging maiden and married name records together. So a change on that day could easily messed me up. One version using the old class function... etc.

http://img.informer.com/screenshots...

Other than a few Males who became Females (not that way, they were females all along - <CG> just had to catch up) there is no problem with the gender.

But that does detract from the main point - that there is plenty to talk about in the post - and lots of issues that should be explored.

I'd like to hear <chessgames> points about M0 and M1.

I'm on the road now, and will update my blog post and then come back here with some specifics.

The systematic approach is in the blog, the case-by-case approach is just to serve as examples, and as a sanity check on the diagnostics.

First of all, the condition of the database is improving, and while I can lay any claim to the credit of implementing the changes, I'd like to think I was part of the team.

Biographer Bistro

That was about the time of my last snapshot.

A more careful analysis of the <CG> playerlist snapshot I had from then reveals 52 FIDE id's used by multiple <CG> "players".

A great many of these were women who got married, so that <CG> had two entries for them - under their maiden name, and under their married name.

A scan of the most recent <CG> snapshot that I've looked at shows that there are no duplicate (or triplicate) FIDE id's in the date.

Congratulations - this is good progress.