<

8.1.1: Seven Tag Roster

There is a set of tags defined for mandatory use for archival storage of PGN data. This is the STR (Seven Tag Roster). The interpretation of these tags is fixed as is the order in which they appear. Although the definition and use of additional tag names and semantics is permitted and encouraged when needed, the STR is the common ground that all programs should follow for public data interchange.
. . .

2) Site (the location of the event)

>

http://opensource.apple.com//source...

Kindly,
Molly Parker
Sr. Content & Community Associate>>

(b) Any form of name-calling (e.g., making up a pejorative nickname for another member) is forbidden, whether based on the screen-name or their name in real life. >

So if I call <SwitchingQuylthulg> "Switchy Quilty Thing" then I am breaking the rules?

<

What is wrong with putting the actual game's location in a comment?

Nobody, and I do mean nobody, has given me one single reason why this doesn't work for them.

>

* * * * *

One, spamming games with "annotations" reading "Played in Shackwick-on-Sea ENG" is a very ugly solution; moreover, it would create conflicts with actual annotations. You can't neatly append both "Played in Shackwick-on-Sea ENG" and the real note to the same move. Two, comments aren't editable; if the location is wrong, it can't be fixed by an editor. Three, it would mean the Site tag would be used for some unholy entry like "United States" or "NED/INA" or "Amsterdam NED / The Hague NED / Rotterdam NED / Groningen NED / Zwolle NED / Haarlem NED / Utrecht NED / Arnhem NED / Breda NED / Leiden NED" that would not only tell us absolutely nothing about where the game was played, but wouldn't even be standard PGN either.

I can't see any real benefits to doing it your way. Yes, it might make tournaments more SCID-compatible... which would help you, and very few if any other people. I don't know how many other people are using SCID and the Chessgames database the same way as you, but going by how many problems you've found with this database using SCID, it seems clear that that number is very low; otherwise, someone else would have found those problems first and got them fixed.

<[Event "F/S Return Match"]
[Site "Belgrade, Serbia JUG"]
[Date "1992.11.04"]
[Round "29"]
[White "Fischer, Robert J."]
[Black "Spassky, Boris V."]
[Result "1/2-1/2"]

1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7 11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5 Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6 23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5 hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5 35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6 Nf2 42. g4 Bd3 43. Re6 1/2-1/2>

This is an utter mis-characterization, both factually and especially by suggesting I'm only advocating for my own convenience in these matters...

* * * * *

<I can't see any real benefits to doing it your way.>

How can you say this, and then immediately contradict yourself with...

< Yes, it might make tournaments more SCID-compatible... >

And <ChessBase>-compatible, and SCID vs PC-compatible, and name any other PGN/DB viewer you care to.

We could look at them all case-by-case, but between <ChessBase> and <SCID>, I think we have ~98% (or more) of users covered. Again, the issue is not specific to SCID, tournament normalization is relevant for <ChessBase>, or any PGN DB, as well.

< which would help you, and very few if any other people.>

Listen, this statement is so wrong as to be ludicrously wrong.

I don't need this help, I have completely implemented enough <CG> work-arounds that I'm basically set for life.

The entire purpose of this effort is to benefit of others.

By conforming to the "de facto" PGN-standard, as implimented by SCID and ChessBase, one might hope that others can adopt the procedures I use to verify the correctness of PGN games on <CG>. And if not that, than to appreciate the ability to simply and automatically generate a correct crosstable.

Normalization is an important concept - correctness depends on it.

Concerning correctness, as far as I know, nobody else compares tournament games between online sources in any sort of systematic fashion. Why not?

Perhaps it's because <CG> games are so difficult to match up with other DB's games.

It shouldn't require ace programming skills to do so.

And it shouldn't require premium membership either.

Do you have a financial interest in <CG>? If so, please disclose it for purposes of discussion. And if not, why do you keep harping on it? Don't you think non-premium members should have equal opportunity?

<I don't know how many other people are using SCID and the Chessgames database the same way as you, but going by how many problems you've found with this database using SCID, it seems clear that that number is very low; otherwise, someone else would have found those problems first and got them fixed.>

I agree with this statement. I'm leading an effort to educate and disseminate. These techniques aren't hard, and if <CG> were more conforming, it could have been done earlier by a general user.

Get it? That's the entire point.

I had to spent countless hours with programming hacks, which would be unnecessary if <CG> would follow "best" practices.

I don't want to be the only person "x-raying" the games.

<One, spamming games with "annotations" reading "Played in Shackwick-on-Sea ENG" is a very ugly solution; moreover, it would create conflicts with actual annotations. You can't neatly append both "Played in Shackwick-on-Sea ENG" and the real note to the same move.>

First of all, the GameSite location would go before the first move, and so wouldn't conflict with any annotation for any given move.

And if a previous comment existed, one would just append the text. I would suggest...

<

[LastTag "x.x.x"]

pre-existing comment; @GameSite blahCity blahCountry

>

Now if you don't like the comment idea, just use the GameSite tag idea. Then the actual location is hidden inside the PGN, <*as it currently is on <CG> when using pgn4web*!>

It's isn't how I'll do it in Z-base, but I think it a valid solution for embedding the actual location - just don't break the Site normalization tag.

< Two, comments aren't editable; if the location is wrong, it can't be fixed by an editor. >

<CG> could fix this in a jiffy. Not really a valid argument.

<Three, it would mean the Site tag would be used for some unholy entry like "United States" or "NED/INA" or "Amsterdam NED / The Hague NED / Rotterdam NED / Groningen NED / Zwolle NED / Haarlem NED / Utrecht NED / Arnhem NED / Breda NED / Leiden NED" that would not only tell us absolutely nothing about where the game was played, but wouldn't even be standard PGN either.>

It is standard PGN, to begin with, why do you say it isn't? Just look at actual usage by <ChessBase>, <365chess>, etc., etc.

Let's be practical. If the list of actual sites become unruly, then <[Site "(Various) NED"]> is used. Or, in the case of Wijk aan Zee,

Actually, let's acknowledge that this is beyond a cut-and-dry standard. The idea is to conform and cooperate with the de-facto standards of the world community, beyond the purely <CG>-centric viewpoint.

Again, the idea is to be able to interoperate with <ChessBase>, <365chess> and other online DB's.

<CG> already "steals" wholesale from these sources.

I'm just asking for <CG> to "give back" a little.

And to enable non-programmers, non-premium members to be biographers, able to contribute to the effort with standard tools.

Technical discussions aside, the point here is that Chessgames wants to offer a product that is most valuable to its customers. This means compatibility with existing software. "Hurray!" Zanzibar cries, finally we get 100% compatibility with SCID.

But wait—it's still not so simple! Even then, exactly what we mean by "compatibility" is a point of contention.

I thought my example of the Bundesliga was spot-on. Here is an event which most people believe is best kept as one giant super-event. Meanwhile most people believe that the Grand Prix events should be kept separated. And the Steinitz-Lasker WCC that took place in three cities: surely nobody is arguing for THAT event to be broken up into three sub-tournaments.

You see my point? There is a great deal of human interpretation of what is best here. The fact we have Bundesliga and the Steinitz-Lasker WCC on single pages, while other events are broken up into the various cities, is a product of human decision making, not an algorithm. I don't think such decisions can ever be done by an algorithm.

(And yes, that gives SCID a boost, since it's freely available to all, no matter what their budget may allow)>

What percentage of <cg.com>'s posters do you reckon are actually aware that SCID exists, let alone what it does?

The proper basic datum for Portable <Game> Notation is the game, not the event. Clearly the standard was botched during development despite numerous examples of multi-site events in the historical record. AVRO (1938) held 10 of its 14 rounds in different cities and Game Collection: Marshall -- Ed. Lasker 1923 match had 18 games played in 9 different cities, just to name two of the more extreme examples. Two-location events are common enough that the problem should have been recognized. The Procrustean "solutions" proposed to adhere to the letter of a flawed standard might make Inspector Javert proud, but not me.

For most events, the event name and year are sufficient to properly group games by event. Dec-Jan events, especially annual ones like Hastings, would need more specificity in the event name.

<And what proportion of tournaments are held at multiple locations?>

Using <SCID>'s Header search with "/" in the Site tag gives a rough indication after a 8-second search through <MillBase>:

< 11715 games / 1605722 total games >

or, about 0.7%, clearly a very small number.

Using <SCID>'s Tournament Finder, we can actually be a little more informative.

Consider tournaments since 2000, there are 26 multi-site tournaments in <MillBase> from year 2000 (inclusive).

(I won't bother determining the total count here, because the Tournament Finder saturates at 1000 tournaments. I'd have to slice up the years to intervals with occupancy of less than 1000 tournaments, and sum up. That's a bit of work, and the previous ~1% figure is already a working estimate.)

Widening the search for previous years is more problematic, as many Corr tournaments show up.

<What percentage of <cg.com>'s posters do you reckon are actually aware that SCID exists, let alone what it does?>

Of course, another good question, and one which I really don't even have a good guess for.

If you go to sourceforge you'll see that it has 735 downloads this week:

https://sourceforge.net/projects/sc...

Plus a max'ed out 5-star rating.

* * * * *

Realize that <MissS>'s question about SCID is incomplete, with regards to the discussion at hand. We must also include <ChessBase> users, as users of both DB's are affected by exactly the same issues.

So, how many <CG> users use <ChessBase>, or are even aware of its existence?

I agree with both sentiments.

<CG> can do better - and has the potential to be the best.

But, as I like to say,

<Before it can be better, it has to be as good.>

You can put a Ferrari engine in a car, but without a proper set of high-performance tires, you're not getting the full benefit. In fact, you might get yourself in a little bit of trouble, overestimating your performance.

I'll come back to this again.

* * * *

<crawfb5>'s post opens a couple of other issues, specifically about PGN failings. This deserves another post of its own as well.

But I think we differ on what we mean by "Compatibility". This needs elaboration.

The main idea, and the essential design goal, is to be able to download <CG> PGN and get a valid xtab for any given tournament.

Without any post-processing of the PGN.

The importance of seeing that a xtab is valid, with correct results and without (additional) missing games, is integral to ensuring correctness of the data - at the most coarse level. Experience has shown its importance time and time again.

It's from this point one can then probe down to try for epsilon-squared integrity of the actual game movelists by comparing <CG> games against other DB's.

* * * * *

It seems that <MissS> and <crawfb5> are suggesting techniques to hunt out tournament games with variants of a <Header Search>.

<Switch> suggested another technique - given <CG> new <TournamentID> tag.

The trouble is, both <SCID> and <ChessBase>, already have well-established internal algorithms to group tournament games together.

And those algorithms dictate the constraints we should use.

Why?

Because of the power and virtue of utilizing the tools available inside both SCID and Chessbase.

You can denormalize a tournament, and use the suggested techniques to generate a Game List of the tournament games. But neither SCID nor Chessbase will respect this grouping if you ask them to generate a xtab from any of the games.

And that's the point. We want to work cooperatively.

Denormalizing the Site tag wrecks the tournament. And if it's only 1% of the tournaments it becomes insidious.

Why? Because something that works for 99% of the bulk of the tournaments leads the unaware user to lend a level of confidence that it works 100% of the time.

And when betrayed, will leave them scratching their heads wondering why?

Without any obvious indication of what's wrong.

Those are the users this proposed change would help.

Compare that to the number of users who will benefit if this waste of everybody's time stops, and admins and editors can concentrate on doing actually useful things. As it is, nobody's addressed <sonia91>'s extremely valid requests for more tournament pages (for the Rapport-Navara match, the Russia-China match, the Capablanca Memorial etc. etc.), people are complaining submitted games aren't being processed, the Source tag still hasn't been introduced to my knowledge, editors and other site helpers are distracted, the Chessgames Member Support Forum has become a battlezone...

Just so. On the other hand, there's nothing quite like a trip down <SCID Row>.>

<crawfb5> - <The proper basic datum for Portable <Game> Notation is the game, not the event.>