PDN 3.0 Standard Review Request

[Rein Halbersma]

Hi Piet,

I think the Georgiev-style tie-breaks should be treated as separate games with asymmetric time controls. This is much easier to parse and does not require changes to the grammar. Asymmetric time controls may look strange, but remember that in chess they also have the asymmetric blitz tie-break with 6 minutes for white and 5 minutes for black, with a draw counting as a black win. And also in handicap games or clock simultan matches you also have weird timings.

Rein

You have not convinced me yet Rein.
The chess tie-break is still one game with a result and also the other examples are one game (at a clock simultane different persons).

The Georgiev-tiebreak is unique. The result is from more games, where tactics with your usage of the time in the different games is really important.
I would like to see a Georgiev tiebreak as one game (really subjective I know).
And in practice (with efficient usage of Electronic boards and EBS, although that is way beyond this topic) and display of the Georgiev-tiebreak in applets it is (in mine opinion) to prefer it to see it as one game then as several "loosy" games.
But I know: practice is different from a scientific approach (sorry for my bad English).

PIet.

I see your point, but a Georgiev-tiebreak is really just a match with a common time allocation. The games itself are independent from each other. If such games are added to a PDN database (e.g. TurboDambase), it is much easier to search for individual games / openings if they are kept separate. You can solve the display of the actual time lapses just as easily by extracting that information by the move-by-move comments (generated from the EBS or manually entered) from each of the games.

Rein

[TAILLE]

Hi,

Seing this discussion arround the time control and the “Lehmann-Georgiev" tie break, can somebody tell me how can we keep with the game the time used by each move? Do we have to use the "comment" form or do the grammar take into account this aspect?

[Wieger Wesselink]

Hi Ed, thanks for your comments!

*) Should we always use "" to denote an unknown value of a PDN tag? Currently there
are some exceptions defined in the standard where a "?" should be used instead.

The section on PDN tags seems to have some conflicting statements. In one sentence, "... a tag is omitted if it has no value". In another, "To denote that a tag has an unknown value, in most cases a "?" value can be used." I think the difference between an unknown value and no value is too subtle. This section should be more specific.

Also, what about mandatory tags? If a mandatory tag is unknown, does it have to be included because it is mandatory, or can it be omitted because it is unknown? What is the usefullness of writing a mandatory tag with an unknown value? In my case with kingsrow I write a few tags as place holders, even if unknown values, perhaps making it slightly easier to add values later using a text editor. I question whether this is important enough to make 7 tags mandatory even when none of them have known values.

The 'no value' and 'unknown value' rules come from PGN and from previous PDN versions. I can't give a justification for these rules, since I don't understand the need for them. I have copied the 'unknown value' rules for backward compatibility, and I have omitted the 'no value' rules, since I don't think they are used in practice. Perhaps the explanation in the draft standard is confusing. What I meant is that if a tag has no value, it should be omitted. I'll try to make the text more clear.

Personally I would like to drop the convention of specifying an unknown value with "?". But I haven't done this for backward compatibility. It seems more logical to me to use the empty string "" instead. The only place where the ?-notation makes sense is in an unknown date like [Date "2007.??.??"].

The 'mandatory tags' also come from previous standards. This name is very confusing, since these tags are not mandatory for a PDN file. I guess what they mean is that these tags should be set for tournament games. I will add a comment to explain this.

[Wieger Wesselink]

Hi Gérard, thanks for your question.

Seing this discussion arround the time control and the “Lehmann-Georgiev" tie break, can somebody tell me how can we keep with the game the time used by each move? Do we have to use the "comment" form or do the grammar take into account this aspect?

Comments can be used to store clock times after each move. Below is an example of that. The PDN standard does not define how to store the amount of time used for a move.

Code: Select all

[Event "SWMG"]
[Site "Beijing"]
[Round "ronde7.3"]
[White "Jean-Marc Ndjofang"]
[Black "Ainur Shaibakov"]
[BoardId "1096"]
[GeneratedBy "EBS2.03"]
[Result "2-0"]
[FEN "W:W31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50:B1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20"] {[%clock W0:05:03 b0:05:03]}
  1. 32-28 {[%clock w0:05:03 B0:05:03]}
     17-21 {[%clock W0:05:03 b0:04:49]}
  2. 37-32 {[%clock w0:04:34 B0:04:51]}
     21-26 {[%clock W0:04:36 b0:04:51]}
  3. 41-37 {[%clock w0:04:39 B0:04:51]}
     16-21 {[%clock W0:04:39 b0:04:51]}
  4. 34-29 {[%clock w0:04:34 B0:04:54]}
     21-27 {[%clock W0:04:34 b0:04:54]}
  5. 31x22 {[%clock w0:04:35 B0:04:55]}
     18x27 {[%clock W0:04:37 b0:04:57]}
  6. 32x21 {[%clock w0:04:37 B0:04:57]}
     26x17 {[%clock W0:04:37 b0:04:57]}
  7. 38-32 {[%clock w0:04:39 B0:04:59]}
     20-25 {[%clock W0:04:41 b0:04:58]}
  8. 43-38 {[%clock w0:04:34 B0:04:48]}
     15-20 {[%clock W0:04:34 b0:04:48]}
  9. 49-43 {[%clock w0:04:34 B0:04:54]}
     19-24 {[%clock W0:04:29 b0:04:51]}
 10. 46-41 {[%clock w0:03:33 B0:04:55]}
     17-21 {[%clock W0:03:34 b0:04:35]}

[TAILLE]

Hi Gérard, thanks for your question.

Seing this discussion arround the time control and the “Lehmann-Georgiev" tie break, can somebody tell me how can we keep with the game the time used by each move? Do we have to use the "comment" form or do the grammar take into account this aspect?

Comments can be used to store clock times after each move. Below is an example of that. The PDN standard does not define how to store the amount of time used for a move.

Code: Select all

[Event "SWMG"]
[Site "Beijing"]
[Round "ronde7.3"]
[White "Jean-Marc Ndjofang"]
[Black "Ainur Shaibakov"]
[BoardId "1096"]
[GeneratedBy "EBS2.03"]
[Result "2-0"]
[FEN "W:W31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50:B1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20"] {[%clock W0:05:03 b0:05:03]}
  1. 32-28 {[%clock w0:05:03 B0:05:03]}
     17-21 {[%clock W0:05:03 b0:04:49]}
  2. 37-32 {[%clock w0:04:34 B0:04:51]}
     21-26 {[%clock W0:04:36 b0:04:51]}
  3. 41-37 {[%clock w0:04:39 B0:04:51]}
     16-21 {[%clock W0:04:39 b0:04:51]}
  4. 34-29 {[%clock w0:04:34 B0:04:54]}
     21-27 {[%clock W0:04:34 b0:04:54]}
  5. 31x22 {[%clock w0:04:35 B0:04:55]}
     18x27 {[%clock W0:04:37 b0:04:57]}
  6. 32x21 {[%clock w0:04:37 B0:04:57]}
     26x17 {[%clock W0:04:37 b0:04:57]}
  7. 38-32 {[%clock w0:04:39 B0:04:59]}
     20-25 {[%clock W0:04:41 b0:04:58]}
  8. 43-38 {[%clock w0:04:34 B0:04:48]}
     15-20 {[%clock W0:04:34 b0:04:48]}
  9. 49-43 {[%clock w0:04:34 B0:04:54]}
     19-24 {[%clock W0:04:29 b0:04:51]}
 10. 46-41 {[%clock w0:03:33 B0:04:55]}
     17-21 {[%clock W0:03:34 b0:04:35]}

Thank you for your answer though it sounds not very satisfactory.
For the future I guess we will see more and more the usage of Electronic boards and EBS which allow a quite easy record of the time of each move. If you imagine that this information may be interesting to keep attached to the game it will be a pity to let each programmer store this information as a comment i.e. without any standard format. Such standard would allow to display the game with a beautiful clock for each player.
Why not try to make an effort to standardize these information?

[Wieger Wesselink]

Thank you for your answer though it sounds not very satisfactory.
For the future I guess we will see more and more the usage of Electronic boards and EBS which allow a quite easy record of the time of each move. If you imagine that this information may be interesting to keep attached to the game it will be a pity to let each programmer store this information as a comment i.e. without any standard format. Such standard would allow to display the game with a beautiful clock for each player.
Why not try to make an effort to standardize these information?

Did you take a look at http://10x10.org/pdn/extensions.html#embedded-commands? If you think this way of storing clock times is not adequate, perhaps you can make a suggestion for how it can be improved?

[TAILLE]

Thank you for your answer though it sounds not very satisfactory.
For the future I guess we will see more and more the usage of Electronic boards and EBS which allow a quite easy record of the time of each move. If you imagine that this information may be interesting to keep attached to the game it will be a pity to let each programmer store this information as a comment i.e. without any standard format. Such standard would allow to display the game with a beautiful clock for each player.
Why not try to make an effort to standardize these information?

Did you take a look at http://10x10.org/pdn/extensions.html#embedded-commands? If you think this way of storing clock times is not adequate, perhaps you can make a suggestion for how it can be improved?

Thank you Wieger, now it as clearer. I believed that the information inside a comment were not standardized but I just discover it is not the case. It is fine for me. Sorry for my misunderstanding.

[jkrabbenbos]

Thank you for your answer though it sounds not very satisfactory.
For the future I guess we will see more and more the usage of Electronic boards and EBS which allow a quite easy record of the time of each move. If you imagine that this information may be interesting to keep attached to the game it will be a pity to let each programmer store this information as a comment i.e. without any standard format. Such standard would allow to display the game with a beautiful clock for each player.
Why not try to make an effort to standardize these information?

Did you take a look at http://10x10.org/pdn/extensions.html#embedded-commands? If you think this way of storing clock times is not adequate, perhaps you can make a suggestion for how it can be improved?

Thank you Wieger, now it as clearer. I believed that the information inside a comment were not standardized but I just discover it is not the case. It is fine for me. Sorry for my misunderstanding.

For your information, as I could not find it in Wieger's link: In the extended PGN standard there are more possibilities mentioned than the clk command. There are also commands for "elapsed game time: {[%egt 1:25:42}]" and "elapsed move time: {[%emt 0:05:42]}". Theoretically you can use the elapsed move time to add in a game played on an electronic board. Practically with an electronic board this is an indication of the time being the measurement between the start and end of the clock running. Several things can extend the player thinking e.g. not being at the board when your opponent pressed the clock or forgetting to press the clock after a move. For programs this can be used with more precision.

I have currently not a direct link available to the extended PGN document, but I have the document itself. I can make it available on the net if wanted.

Jan Krabbenbos

[jkrabbenbos]

On the questions made earlier this week by Rein I have the following remarks and answers (mainly based on my experience with PGN):

Review Questions

• Results: As Ed Gilbert says, take it as cargo. The only thing is that you might prescribe a format (1.01-0.99 or 1-1 or 1/2-1/2), but not the possible values itself.
• For mandatory tags with an unknown value I would suggest "?". And if an optional tag is added with an unknown value this should be the same for consistency.
• Character set: it would be nice to know which character set it used. Especially for the tags. Which reminds me that I have seen for example Go games in SGF (Simple Game Format) with Chinese or Japanese characters. I'm not sure if this is prescribed in SGF.
• Long notation for unambigious moves: yes, makes it more human readable. For a computer program it does not matter much.
• Move separator in alphanumeric moves: keep them for human readability.

Common Questions

• I have read the PDN 3.0 documentation, but not intensively. One of my co-workers at DGT did read it more intensively.
• We have one request for an addition: line comments as available in PGN (starting with a %). This gives the possibility to add some comments to a file. And we have some use for it in our electronic board software (e.g. RabbitQueen which can read the electronic board internal memory for played games).
• I have not tested it with a parser generator yet. Nor did I test with legacy PDN files.
• Should the FMJD call this an official standard? They should advise it at least. But in the future there may be better alternatives for exchanging games between computers.

Jan Krabbenbos

[Wieger Wesselink]

For your information, as I could not find it in Wieger's link: In the extended PGN standard there are more possibilities mentioned than the clk command. There are also commands for "elapsed game time: {[%egt 1:25:42}]" and "elapsed move time: {[%emt 0:05:42]}". Theoretically you can use the elapsed move time to add in a game played on an electronic board. Practically with an electronic board this is an indication of the time being the measurement between the start and end of the clock running. Several things can extend the player thinking e.g. not being at the board when your opponent pressed the clock or forgetting to press the clock after a move. For programs this can be used with more precision.

I have currently not a direct link available to the extended PGN document, but I have the document itself. I can make it available on the net if wanted.

Jan Krabbenbos

Hello Jan, thanks for your comments! The link to the DGT clock time extension document can be found in the reference section: http://10x10.org/pdn/introduction.html#references. I read somewhere that this proposal was rejected for PGN, and so I did not make it part of the PDN 3.0 draft. I only copied the syntax of embedded commands.

[Wieger Wesselink]

On the questions made earlier this week by Rein I have the following remarks and answers (mainly based on my experience with PGN):

Review Questions

• Results: As Ed Gilbert says, take it as cargo. The only thing is that you might prescribe a format (1.01-0.99 or 1-1 or 1/2-1/2), but not the possible values itself.
• For mandatory tags with an unknown value I would suggest "?". And if an optional tag is added with an unknown value this should be the same for consistency.
• Character set: it would be nice to know which character set it used. Especially for the tags. Which reminds me that I have seen for example Go games in SGF (Simple Game Format) with Chinese or Japanese characters. I'm not sure if this is prescribed in SGF.
• Long notation for unambigious moves: yes, makes it more human readable. For a computer program it does not matter much.
• Move separator in alphanumeric moves: keep them for human readability.

Perhaps the PDN standard should make a recommendation for the character set (like use UTF-8 whenever possible). I know little about this subject, so I'm a bit hesitant to make this mandatory.

For the moment it is probably best to put very little restrictions on results. However, this will make it difficult for programs to interpret them. So in the end I think it is better to define an additional tag that describes the result type that was used. For example [ResultType = "PlusDraw"] would indicate that 2-0, 1+ - 1-, 1-1, 1- - 1+ and 0-2 are valid results. This information needs to be recorded anyhow, since it explains why people continue to play in positions that are completely drawn. I'm thinking about including a section about this topic and give some recommendations.

A PDN reader should always accept the long notation. A PDN writer is in the current proposal only allowed to use the long notation for ambiguous moves, but this can be relaxed if needed.

Common Questions

• I have read the PDN 3.0 documentation, but not intensively. One of my co-workers at DGT did read it more intensively.
• We have one request for an addition: line comments as available in PGN (starting with a %). This gives the possibility to add some comments to a file. And we have some use for it in our electronic board software (e.g. RabbitQueen which can read the electronic board internal memory for played games).
• I have not tested it with a parser generator yet. Nor did I test with legacy PDN files.
• Should the FMJD call this an official standard? They should advise it at least. But in the future there may be better alternatives for exchanging games between computers.

Jan Krabbenbos

I was not aware of line comments in PGN, but this seems like a very useful addition to me. BTW, do you have any examples of PGN files produced by electronic board software?

If the review leads to a positive result, the FMJD will probably make it an official standard.

[Ed Gilbert]

I was not aware of line comments in PGN, but this seems like a very useful addition to me.

Why not allow curly brace comments within the game header section (but not inside [] tags of course)?

-- Ed

[sancoder]

As to character encodings.
We have several options to choose: ASCII, UTF-8, any other 1-byte per character codepages (cp1252, for Europe I guess), UTF-16, other N-byte per character codepages (UCS-2 but it seems to be deprecated almost everywhere).

If ASCII would go to the standard - the checkers developers world would be treated as dinosaurs - come on, it's 21st century. There is absolutely NO reason to use such encoding.
Any other character encoding without full Unicode coverage (cp1252, cp1251 for Cyrillic world, etc) would cause problems from the beginning - the PDN file should have an external attribute, i.e. encoding. The end user would have to choose what encoding particular PDN file has - I think this is not very good. For developers any encoding is the pain - nobody understands all details from the start.
There are several encodings with full Unicode coverage. UTF-8 is the superset of the ASCII, for this reason I would recommend this to become a standard. UTF-16 has some options (big endian, little endian), but the main problem is that every character (even ASCII one) would have 2 bytes. So, UTF-16 (and UCS-2 as its parent) would break all compatibility.

For UTF-8 to be standardized, the only change to the grammar is necessary: to treat characters from 0x80 to 0xFF as normal characters, i.e. to allow them.

There is still a question about BOM marker at the beginning of the file (BOM specifies that file is in UTF-8 or UTF-16 encoding).
The reader should allow this marker. The writer ... I'm not sure, but I think it should not write this marker to the file (for compatibility reasons).


As to dash in alphanumeric moves.
It should be optional. Disallowing the 'a1b2' is very unfriendly.

[Rein Halbersma]

As to dash in alphanumeric moves.
It should be optional. Disallowing the 'a1b2' is very unfriendly.

Hi Sancoder,

What is your opinion on allowing different separators? E.g. in Russian draughts, I often see '-' for moves and ':' for captures, and in Thai draughts they use '-' for moves and captures. The proposal only allows ':' in the reading grammar, not in the writing grammar. Is this OK as far as the Russian programmers currently do and expect?

Rein

[sancoder]

What is your opinion on allowing different separators? E.g. in Russian draughts, I often see '-' for moves and ':' for captures, and in Thai draughts they use '-' for moves and captures. The proposal only allows ':' in the reading grammar, not in the writing grammar. Is this OK as far as the Russian programmers currently do and expect?

Russian programmers use ':' as attack separator very often. I would say that this is the most used variant.
The other separator I've seen is 'x' but it is very rare.
I think this is not OK to disallow ':' in the writing grammar.