JGN: A PGN Replacement

[dkl]

Since there is a parallel thread about creating a chess database format in SQL, I thought it's a good time for this.

So I was really fed up with PGN. I am not going into details here, probably anyone who implemented a PGN parser can relate. PGN has so many ambiguities and oddities...

Tord Romstad summarized this on reddit [Red2016] some time ago as "PGN is designed to be somewhat humanly readable, at the expense of making it harder for computer software to parse and produce."

Together with a few other chess programming enthusiasts (not sure if they want to come out publicly... I hope they are ok with posting this here...) we sat together last year and sketched out a replacement format. There were several design principles, amongst them

- create a replacement for PGN i.e. a text-based format
- ability to use standard/existing parsers instead of rolling your own
- ease of implementation, avoid need to implement full chess logic to parse SAN
- fix typical limitation with PGN

We worked enthusiastically for some month, but then "life hit". Currently I am very busy with job, life and stuff and cannot pursue this actively. Thus I am posting this here for open discussion...

(this is actually markdown)


----------------------
JSON Game Notation (JGN)
========================

Version 1.00

Foreword
========

Portable Game Notation is the de-facto inter-operable standard to save and exchange chess games. It comes with disadvantages though, of which some are listed here:

- No support for non-western character sets. This hinders usage in upcoming and existing chess power houses such as China, India and Russia.
- It uses short algebraic notation. This requires a program that parses chess games stored in PGN to implement full chess-logic, including move generation, and slows parsing.
- Several ambiguities in the standard make it hard to define what a formally correct PGN file is. Indeed, numerous chess programs produce and read ‘incorrect’ PGN files to a certain degree.
- It uses a special-purpose surface format, rather than extending a widely used format for structured data, requiring program authors to implement custom parsers.

This standard tackles these issues and provides a simpler-to-parse, yet more expressive solution.


Introduction
============

This standard defines a text-based file format to store and exchange chess games. It supports standard chess as well as Chess960. Other variants are currently out of scope.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

MIME-Type
=========

The MIME type of a JGN file is `application/x-chess-jgn`.

Definition
==========

JGN is a text based format. One or more games are stored in a text file. The file ending of JGN is ‘.jgn’ in lower-case letters. The text file MUST be encoded in UTF-8 [RFC3629] WITHOUT Byte Order Mark (BOM).

JGN files contain a sequence of JSON [RFC8259] objects.
Two JSON objects MUST be separated by a single newline character (‘\n’).
A newline character MUST NOT occur in any JSON OBJECT.
In other words, the contents are valid Newline Delimited JSON [Ndj2014].

Note that RFC 8259 specifies that trailing whitespace after a JSON object, including a carriage return character (‘\r’), is ignored.

JSON data types (NULL, BOOLEAN, NUMBER, STRING, ARRAY, OBJECT) in this document are written in UPPERCASE.

A JGN file consists of an (optional) Meta-OBJECT and zero or more Game-OBJECTs. Therefore, an empty file is a valid JGN file.
A JGN file MUST contain at most one Meta-OBJECT. If so, the Meta-OBJECT MUST be the first JSON-OBJECT in the file.

The format is designed to be extended by future versions of this standard or proprietary additions. Unknown OBJECTs and fields MUST be ignored.

Meta OBJECT
-----------

Meta is a JSON OBJECT with the following REQUIRED fields.

- "type" of STRING. The value MUST be "JGN".
- "version" of NUMBER. The value MUST be 100 and denotes the current version of this standard.

Game OBJECT
-----------

Game is a JSON OBJECT with the following REQUIRED fields.

- "type" of STRING. This string MUST be "Game".
- "info" of ARRAY
- "moves" of ARRAY

The next field MUST be present if the encoded game is a Chess960 game. For standard chess games, the field SHOULD be omitted.
- "variant" of STRING. "Chess960" for a Chess960 game. If this field is included and the game is a standard chess game, the string MUST be "Chess".

"info" OBJECT
------------

The OBJECT "info" MAY include the following fields:

- "white" of STRING: The name of the white player. If this is a real name (and not e.g. an pseudonym for online play), the name MUST be formatted as "Lastname, FirstName", i.e. with a comma and a space separating the last and the firstname. In case of multiple first names, these MUST be separated by a space each. Abbreviations of the first name SHOULD NOT be used (e.g. "Karpov, A.").
- "black" of STRING: The name of the black player.
- "whiteTrans": If the name in "white" contains non-Latin characters, a transliteration of "white" into Latin characters SHOULD be present here. Lastname and Firstname should be separated by a comma and a space as for "white"; and in case of multiple first names these MUST be separated by a space each. As an example consider "white" : "Каспа́ров, Га́рри Ки́мович" and "whiteTrans" : "Kasparov, Garry Kimovich".
- "blackTrans": The transliteration of "black" into Latin characters
- "whiteTeam" of STRING: The name of the team that the white player belongs to (in case of a team event)
- "blackTeam" of STRING: The name of the team that the black player belongs to (in case of a team event)
- "date" of STRING: The STRING date MUST be formatted as many segments of an [RFC3339] timestamp
as are known according to the following rules. One of the following options
MUST be chosen:

1. date-fullyear
2. date-fullyear "-" date-month
3. date-fullyear "-" date-month "-" date-mday
4. full-date "T" full-time

with date-fullyear, date-month, date-mday and full-time as defined in [RFC3339]. Missing information MUST NOT be replaced by "?". It is RECOMMENDED to store time-stamps in UTC time without any offset (i.e. "Z").

Examples:

Valid:
- 1996-12-19T16:39:57Z
- 1996-12-19T16:39:57-08:00
- 1996-12-19T16:39-08:00
- 1996-12-19
- 1996-12
- 1996

Invalid:
- 1996-12-19T16:39:57
- 1996-12-??
- 1996-?2
-19?6
- "event" of STRING: The name of the event where this game was played.
- "site" of STRING: The site of the event where this game was played.
- "result" of STRING. Valid values are "1-0" if white won the game, "0-1" if black won the game, "1/2-1/2" if the game was drawn, and "*" if the result is unknown.
- "end" of STRING. Valid values are - decisive games only: "Resign", "Mate", "Forfeit"; Draws only: "Agree", "Stalemate", "Repetition", "Count", "Insufficient"; Any type of result: "Bye", "Unplayed", "Unknown", "Time". In this "Forfeit" means the game did not end normally, but the controlling authority declared one player the winner. "Count" means the game was drawn since no capture was made and no pawn was moved for a number of moves that reached a threshold. Insufficient" means the game was drawn because mate was no longer possible. "Time" means lost on time in a decisive game, or drawn due to the opponent having insufficient mating material in a drawn game. Other values are self-explanatory.
- "uuid" of STRING: A UUID in textual representation according to [RFC4122]
- "whiteFideId" of STRING: The textual representation of the FIDE-ID of the white player
- "blackFideId" of STRING: The textual representation of the FIDE-ID of the black player
- "url" of STRING: A URL linking to the game in an online database.
- whiteRating of NUMBER: The rating point of the white player
- blackRating of NUMBER: The rating of the black player
- ratingSystem of STRING. The rating system used for the player, i.e. "Elo", "Glicko", "Glicko2", "INGO", "USCF", "DWZ" or other rating systems. If "ratingSystem" is omitted, but whiteRating and/or blackRating are present, then Elo should be assumed as the rating system.
- whiteRatingDiff of NUMBER: The rating increase/decrease of the white player w.r.t. the current game
- blackRatingDiff of NUMBER: The rating increase/decrease of the black player w.r.t. the current game
- annotator of STRING: The name of the person/entity that annotated the game. In case of real names, they SHOULD be formatted "Lastname, Firstname". Multiple persons SHOULD be separated by the word "and". An example is "Doe, John Peter and Smith, Joe".
- round of NUMBER. In case of a tournament, this denotes in which round the game occurred.
- boardNr of NUMBER: In case of a tournament or league game, this denotes the board number of the game.
- comment of STRING: Any other information that are deemed informative for the game.
- timeControl of STRING. The time controls used in the game encoded as a string. The string s MUST be encoded as follows:

s := "TC_1;TC_2;TC_3; ... ;TC_N"

where N >= 1 and

TCI_i := PLAYERTIME \[ ms \] \[+INCTIME\[ms\] OR ~DELAY\[ms\]\] \[#MOVECOUNT\]

where \[ \] denotes optional components.

The following meaning applies:

- a time unit (PLAYERTIME, INCTIME, DELAY) is always considered in seconds,
except when "ms" is appended to it.
- PLAYERTIME denotes the time a player has available.
- if #MOVECOUNT exists, PLAYERTIME is the time that is available to do the next
MOVECOUNT moves, started after passing the last time control (or from the start).
- if +INCTIME exists, INCTIME is the amount of increment a player receives
with each move
- if ~DELAY exists, DELAY denotes the Bronstein delay that is applied to each
move.
- if TC_N does not contain #MOVECOUNT, it denotes the remaining time that a
player has for the rest of the game. If #MOVECOUNT is present, it means that
after passing MOVECOUNT, TC_N is applied ad infinite.

Examples:
- "timeControl" : "60+0" is bullet game with 60s/side.
- "timeControl" : "60" also is a 60 + 0 bullet game (semantically the same)
- "timeControl" : "7200#40;3600#20;300+2"
- 7200secs = 120 min for the first 40 moves
- 3600secs = 60 min for the next 20 moves,
- 300secs = 5 min for the rest of the game with 2 secs increment / move
- "timeControl" : "120~10#20;300+2#10;60"
- 120 secs = 2 minutes for the first 20 moves with a Bronstein delay of 10 secs / move
- 300 secs = 5 minutes for the next 10 moves, with 2 secs increment / move
- 60 seconds for the rest of the game
- "timeControl" : "1500ms#1". 1500ms = 1.5 seconds for one move for the whole game (e.g. an engine match).

It is RECOMMENDED to provide all information that are applicable and known.

"moves" ARRAY
-------------

For standard chess, the first element of the "moves" ARRAY MAY be a Fen OBJECT. Otherwise, the initial chess position is assumed as the starting position.

For Chess960 the first element of the "moves" ARRAY MUST be a SFen OBJECT. SFen OBJECTs MUST NOT be present in standard chess games and vice-versa.

Aside from Fen/SFen as the first element, the "moves" ARRAY contains the following elements that either

- Change the current game position:
- a legal move of STRING encoded (both for standard chess and Chess960) according to [UCI2000]
- a null move of STRING "0000", i.e. four zeros. This does not change the position of the pieces but only switches the side to move
- an offset of NUMBER. This is possible only in variations, before any moves, and indicates that the variation starts at an offset from the current point in the parent variation. A Positive offset indicates the number of ply (i.e. half moves) to advance before the moves that follow. A negative offset similarly indicates the number of ply to rewind before the moves that follow. If not present the offset is -1, indicating that conventionally variations start as an alternative to the most recent move, so the position should be rewound by one move. The offset element makes it possible to refer to events either earlier or later in the game without requiring a Fen OBJECT.

- Characterize the current game position:
- Comment OBJECT
- Clock OBJECT
- Circles OBJECT
- Arrows OBJECT
- Attachment OBJECT
- Diagram OBJECT
- Evaluation OBJECT
- PositionAnnotation OBJECT

- Characterize the previous move. These elements MUST NOT occur at the start of a "moves" array before the first
move string:
- a MoveAnnotation OBJECT
- an EGT OBJECT
- an EMT OBJECT

- Create a variation. One or more peer "moves" ARRAY(s) can be introduced after any move. Such an array is encapsulated in an object { "moves" : ARRAY }. The variations start from the position before the move by default, but can be optionally offset forward or backward. Variations can be nested in the conventional manner, by introducing variations within "moves" ARRAY(s) that are themselves variations'.

Fen OBJECT
----------

A Fen OBJECT has the single field "fen" of STRING. The value is a valid FEN (Forsyth-Edwards-Notation) string.

SFen OBJECT
-----------

A SFen OBJECT has the single field "sfen" of STRING. The value is a valid Shredder-FEN (Forsyth-Edwards-Notation extended to Chess960) string.

Remark: Note that Shredder-FEN differs from X-FEN in that castling rights are encoded by denoting the files on which the rooks are placed initially. For example HAha is written instead of Kqkq if rooks are placed on the A-file and H-file initially.

Comment OBJECT
--------------

A comment OBJECT has the single field "comment" of STRING. The string contains a comment about the current position.

Clock OBJECT
------------

A Clock OBJECT has the single field "clock" of NUMBER. The number denotes the time in milliseconds left by the player whose current turn it is.

Circle OBJECT
--------------

A Circle OBJECT MUST have the single field "circle" of OBJECT. This object MUST have two fields of type string:
- a field "square" of type STRING. This string MUST be exactly two characters long, denoting the square in algebraic notation (e.g. "e4").
- a field "color" of type STRING. This string MUST have the form "#RRGGBB" where RR, GG, and BB are hex numbers denoting the RGB color values.

A GUI should highlight the square with a circle or with a different color.

Arrows OBJECT
-------------

An Arrows OBJECT MUST have the single field "arrow" of OBJECT. This object MUST have three fields of type string:
- a field "from" of type STRING. This string MUST be exactly two characters long, denoting the square in algebraic notation (e.g. "e4") where the arrow originates.
- a field "to" of type STRING. This string MUST be exactly two characters long, denoting the square in algebraic notation (e.g. "e4") where the arrow ends.
- a field "color" of type STRING. This string MUST have the form "#RRGGBB" where RR, GG, and BB are hex numbers denoting the RGB color values.

Attachment OBJECT
------------

An Attachment OBJECT has the single field "attachment". This object has two fields:

- "url" of STRING: A URL (resp. file location) indicating the storage of a media object (e.g. audio or video file or image, or even another .jgn file itself) that should be displayed at this position
- "mediaType": A string denoting the media type (MIME type) of the media object

Examples:

Suppose there is a tutorial video, and time point 1 minute plus 30 seconds from the start of the video gives an explanation of the current position:

````
{
"attachment": {
"url": "file://home/user/scandinavian/mainline.mp4#t=1m30s",
"mediaType": "video/mp4"
}
}
````

Suppose there is another file other.jgn which contains a game with 550e8400-e29b-11d4-a716-446655440000a. This might be references as

````
{
"attachment": {
"url": "file://home/user/other.jgn?uuid=\"550e8400-e29b-11d4-a716-446655440000a\"
"mediaType": "application/x-chess-jgn"
}
}
````



Diagram OBJECT
------------

A diagram OBJECT has the single field "diagram" of type OBJECT. It indicates that a diagram should appear for this position at this point in a traditional non-dynamic rendering of the game, for example a textual representation in a magazine or book.
The OBJECT MAY be empty or contain any combination of the following members:
- Circles OBJECT (cf. definition above). The circles specified here refer to the rendered diagram
- Arrows OBJECT (cf. definition above). The arrows specified here refer to the rendered diagram
- "label" of STRING. This specifies a textual description of the diagram that is intended to be rendered above or below the diagram.

Evaluation OBJECT
-----------------

An Evaluation OBJECT MUST have EITHER the field "cp" of type NUMBER or "mate" of type NUMBER.

- "cp" : NUMBER encodes an evaluation of an engine in centipawns,
from the point of view of the player with the current turn.
- "mate" : NUMBER This MUST be a number encoded as follows:
If the number is negative, the opponent has a forced mate. Otherwise the player
with the current turn has a forced mate.
The absolute value indicates the number of moves (not plies) of the forced mate.

It MAY additionally have the following fields:

- "engine" : STRING indicates the engine that produced the result.
- "depth" : NUMBER search depth, as reported by the engine.

PositionAnnotation OBJECT
--------------------------

A PositionAnnotation OBJECT has the single field "positionAnnotations" of type ARRAY.
The ARRAY MUST contain strings only. Each string contains a position annotation. The following conventions SHOULD be used:

- ⩲ : White is slightly better
- ⩱ : Black is slightly better
- ± : White is better
- ∓ : Black is better
- +− : White is winning
- −+ : Black is winning
- ∞ : unclear position
- =∞ : with compensation
- ↑ : Initiative
- → : Attack
- ⇄ : with counterplay
- ⊕ : Time trouble
- ⊙ : Zugzwang

MoveAnnotation OBJECT
----------------------

A MoveAnnotation OBJECT has the single field "moveAnnotations" of type ARRAY. The ARRAY MUST contain only strings. Each string contains a move annotation.

The following encoding conventions MAY be used:

- ?? : blunder
- ? : mistake
- ?! : dubious move
- !? : interesting move
- ! : good move
- !! : brilliant move
- □ : only (reasonable) move
- Δ : with the idea
- N : novelty move

EMT OBJECT
--------------

An EMT OBJECT has the single field "emt" of NUMBER. The number denotes the elapsed time that a player used for the last move.

EGT OBJECT
--------------

An EGT OBJECT has the single field "egt" of NUMBER. The number denotes the elapsed time that a player has used for all moves in the game up to that point.


Examples
========

Below whitespace and newlines are added for readability. Note that in a real JGN file, one game MUST be stored in exactly one line without any newline character [Ndj2014].

```
{
"type" : "Game",
"info" :
{
"white" : "Johner, Paul",
"black" : "Nimzowitsch, Aron",
"date" : "1926.04.05",
"event" : "Dresden 1926",
"site" : "Dresden GER",
"round" : 2,
"result" : "0-1",
"url" : "https://www.chessgames.com/perl/chessgame?gid=1007465"
},
"moves" :
[
{ "comment" : "Excerpted and adapted from 'Learn from the Grandmasters', edited by Raymond Keene, Batsford 1975, chapter 3 by Bent Larsen.\nTo choose one game among all the masterpieces played during the last hundred years is very difficult. I thought of the famous game Rotlewi-Rubinstein, I remember how this game looked like magic to me when I was thirteen....." },
{ "moves" :
[
{ "offset" : 80 },
{ "comment" : "The final position after 40...Re8! bears comparison with the famous Saemisch-Nimzowitsch immortal Zugzwang game" },
{ "diagram" : {} },
]
},
"d2d4",
"g8f6",
"c2c4",
"e7e6",
"b1c3",
"f8b4",
{ "comment" : "Though this opening was played in a few tournament games in the 1880's, it only became popular during the 'Hypermodern' wave of the 1920's, so our game is from a time when this opening was very new. The most common variations were" },
{ "moves" :
[
{ "offset" : 0 },
"d1c2",
]
},
{ "moves" :
[
{ "offset" : 0 },
{ "comment" : "and" },
"d1b3",
{ "comment" : "but Johner plays what is now called the Rubinstein (or the Normal or the Modern) line." },
]
},
"e2e3",
{ "moves" :
[
"d1c2", { "comment" : "This is the conventional way of presenting a variation with the default offset of -1. Larsen often prefers the preemptive approach above, introducing the variation before the main line move the variation varies from. Larsen's writing style is not supported directly by PGN (Larsen was untroubled since he was writing this in 1975 before computing revolutionized so much of chess), but as we have seen JGN's offset capability does allow direct and natural support for Larsen's approach." },
]
},
"e8g8", { "comment" : "The offset = -7 variation below starts with an alternative to this Black move" },
"f1d3",
"c7c5",
"g1f3",
"b8c6",
"e1g1",
"b4c3",
{ "moveAnnotations" : ["!?"] },
{ "comment": "Of course. Nimzowitsch was far ahead of almost all other masters of his day in his understanding of these positions with a doubled c-pawn. It was because of this, and a few other Nimzowitsch games, that at a very young age I played many games with this idea." },
{ "moves" :
[
{ "offset" : -7 },
{ "comment" : "Often I played" },
"c7c5",
"f1d3",
"b8c6",
"g1f3",
"b4c3",
{ "comment" : "Now, many years later Huebner has made this idea popular." },
]
},
"b2c3"
]
}

```

Test Cases
==========

This section contains test-cases. Each test case presents a JGN file, and describes its parsing output (valid file, or not a valid file with the specified error).

#todo

References
==========

[Red2016]( Romstadt, T: Towards a replacement for the PGN format

[RFC2119](https://tools.ietf.org/html/rfc2119): Bradner, S: Key words for use in RFCs to Indicate Requirement Levels

[RFC3629](https://tools.ietf.org/html/rfc3629): Yergeau, F.: UTF-8, a transformation format of ISO 10646

[RFC8259](https://tools.ietf.org/html/rfc8259): Bray, T.: The JavaScript Object Notation (JSON) Data Interchange Format

[UCI2000](https://www.shredderchess.com/de/schach ... rface.html): Huber, R. & Meyer-Kahlen, S.: Universal Chess Interface

[Ndj2014](http://ndjson.org/): Hoeger, T.: Newline delimited JSON

---------------------------------

[phhnguyen]

Thanks for the work!

As a chess GUI developer and a JSON fan (I used JSON as many as I can for my apps), I am interested in chess standards, especially JSON ones. I may support it when it adapts what I need.

I have been working intensively with PGN for a while, understood its advantages as well as drawbacks. Below is just a few suggestions and requests:

1. Store a player as an object:

Code: Select all

“white” : {
   “name”: “John son”,
   “elo”: 2020,
   “ratingDiff” : 0,
   “team” : “USyd”, 
   “fideId”: “123” 
},

It may be better to group all information of a player together, reduce the number of keywords and simplify for picking values. The “flat” way you are using (use whiteName, whiteRank…) is good for someone who is familiar with PGN but that may be not the "right" JSON way and doesn’t encourage people to store more info (with players) since the name fields are not simple/straightforward and needed as a pair (with prefix white and black). For example, someone may want to store a version of an engine in a different field rather than in the name.

You may consider events and sites too since they may have some extra information (e.g., event's date, address).

2. From my experience, for any standard, if you don’t mention a thing, people may apply their understanding, different implementations and quickly make it becomes widely nonstandard later. Users may not care, but that may become a nightmare for other developers, weakening the standard. The most annoying to me when working with PGN is that it does mention storing computing information nor their details. Developers use some different ways and I did not satisfy with them in general and I have been looking for a while to find a better solution. Nowadays there are many of them needed to store, including depth, selective depth, nodes, time, pv, tbhits, win-draw-loss,… Thus you should focus on this issue and mention as many items as possible. I far as I know, TCEC is the one stored the most number of them (https://github.com/TCEC-Chess/tceccutec ... ssgame.cpp)

3. Request: can you give me an example of moves with computing info (depth, score, nodes, time, pv…)?

[hgm]

I am not sure which problem this is supposed to solve. PGN is designed for human readability, hence the use of SAN. If that is not a factor, then any text-based format is wasteful, and binary formats are superior. So I see no use case for this new format.

[Fulvio]

So I was really fed up with PGN. I am not going into details here, probably anyone who implemented a PGN parser can relate. PGN has so many ambiguities and oddities...

If understood, the PGN format is very simple, certainly simpler than JSON or XML.
My lexer is just over 100 lines:
https://sourceforge.net/p/scid/code/ci/ ... xer.h#l158

However, I too think that using SAN notation is a mistake.
Just, extending the PGN format to support moves in "long algebraic notation" would be a big step forward.

[Steve Maughan]

I love JSON and use it wherever possible but I'm not convinced by this use case. I realize PGN has its vagaries but most GUIs parse PGN text well. There doesn't seem to me to be a compelling reason to create a new format that isn't as human readable as PGN.

Steve

[Sopel]

While PGN has its issues I think most people stick to the minimum spec and ignore all the oddities. It's well established and both human and computer readable without bigger issues. I will not put myself behind any new text-based format, particularly this one which is not human readable and is much more bloated than PGN.

[flok]

I am not sure which problem this is supposed to solve. PGN is designed for human readability, hence the use of SAN. If that is not a factor, then any text-based format is wasteful, and binary formats are superior. So I see no use case for this new format.

"binary formats are superior" is spoken as a non-developer

Yes they may be faster to parse but in this day and age it is more important that it is relatively easy to implement a processor and debug that code. Not fast enough? Buy a faster computer!

[Sopel]

I am not sure which problem this is supposed to solve. PGN is designed for human readability, hence the use of SAN. If that is not a factor, then any text-based format is wasteful, and binary formats are superior. So I see no use case for this new format.

"binary formats are superior" is spoken as a non-developer

Yes they may be faster to parse but in this day and age it is more important that it is relatively easy to implement a processor and debug that code. Not fast enough? Buy a faster computer!

Will you pay for it?

[hgm]

"binary formats are superior" is spoken as a non-developer

Yes they may be faster to parse but in this day and age it is more important that it is relatively easy to implement a processor and debug that code. Not fast enough? Buy a faster computer!

Why do you think speed is an issue here? Binary formats are superior in all ways. Most important is of course that they are easier to process.

[Harald]

Is this a good comparison and summary?

PGN (text format)
unclear specification
easy to read for humans
hard to read for computers (SAN algorithm)
slow to read for computers (time)
needs lots of storage space (just zip it)
an import into computer memory will probably use an own binary format
slow to work with on the computer unless restructured in memory
you can use any decent text editor to see and search something, special programs are better

JGN (structured text format)
strict specification
hard to read for humans
easy to read for computers (algorithm)
fast enough to read for computers (time)
needs lots of storage space (just zip it)
an import into computer memory will probably use an own binary format
slow to work with on the computer unless restructured in memory
you can use any decent text editor to see and search something, special programs are required

Binary Format
no specification yet, should be very strict and clear
impossible to read for humans
very easy to read for computers (algorithm)
very fast to read for computers (time)
needs little storage space (may also be zipped)
an import into computer memory will probably just use the given format
fast to work with on the computer
a special program is needed to see and search something

SQL Database
no specification yet, should be very strict and clear
hard to read for humans (with viewer tools and own queries)
very easy to read for computers (algorithm)
very fast to read for computers (time)
needs medium storage space (may also be zipped)
an import into computer memory will use the SQL library
fast to work with on the computer
a special program is needed to see and search something

SQL Database with binary blobs
no specification yet, should be very strict and clear
nearly impossible to read for humans (cannot look into blobs)
very easy to read for computers (algorithm)
very fast to read for computers (time)
needs little storage space (may also be zipped)
an import into computer memory will use the SQL library
very fast to work with on the computer
a special program is needed to see and search something