scidb-users Mailing List for Scidb

In games of manually input moves the navigation arrows give error:

invalid command name "GoRight"
invalid command name "GoRight"
    while executing
"__unknown__orig {*}$args"
    (procedure "::unknown" line 12)
    invoked from within
"GoRight"
    (in namespace inscope "::application::board" script line 1)
    invoked from within
"::namespace inscope ::application::board GoRight"
    invoked from within
".application.nb.main.top.board.__tb__board-control.__tbw__56 invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 22)
    invoked from within
"tk::ButtonUp .application.nb.main.top.board.__tb__board-control.__tbw__56"
    (command bound to event)

In the meanwhile I think I've found a solution for game copy, it
seems to be possible to do the game copy without any modification
of the game data, but it requires testing. This is the status:

1. In the copy the meaning of a dynamic link will change to a
static (textual) link automatically, but only if the destination
is another database. A game copy in the same database is preserving
the dynamic link.

2. Copying back to the original database will not change back the
meaning, only the original game (and the copies done inside this
database) will have the dynamic links.

I think that these restrictions are realistic. The game links are
an additional tool for database authors, not more. Such links may
be very useful for specialized opening databases, for example. The
author can point to other games, the user can use the link directly
instead of searching in the matching game list, and any copy of
the game to another database is preserving the characteristic
(player names, date, length, result, and possibly more) of the
referenced game.

Many years ago I've published an opening book, and due to my
experience I know that normally a reference to another game is
highly preferred instead of replicating the moves of this game.
I'm working on a second edition of this book, but this edition
will be a Scidb database; in fact this is the only function of
Scidb for myself. And that's one of the reasons why I have this
idea with game links. But I had the first encounter with this
idea in Scid's users forum some time ago, and nobody has answered
this request.

Gregor

> > 3. Links to other games requires an additional data file, and an additional
> >    attribute inside the game data.
> 
> Do you mean you are going to create a 4 file system ?

Yes, a 4 file system is required for this.

> I find it hard to see the worth of persistant game links.
> 
> 1. More effort at base compaction/sort
> 2. Dereferencing game links makes PGN viewing much more complicated.
> 3. (Selective) game copy between database loses data/game links
> if referenced games are not also copied. Even if they are - trying
> to preserve game links would be very ugly.
> 4. You need a good DB design , which can't be hurried.
> 5. Scidb' tree shows matched games anyway - at good speed

To 1) Yes, but manageable. I have already solved this problems at other places,
for example the game editor: if you open some games in a database, and you are
compacting the database, all open games will now reference the new game position
in the database (middle mouse button in game header will show you the game
number in database).

To 2) Yes, but expanding the link inside a game is only sugar. The main purpose
of a link is the possibility to reference another game, and to allow an easy
switch to this game.

To 3) That's in fact a problem, and if this is not solvable with a relatively
easy handling I have to give up the links.

To 5) Scidb is also showing matching games, but a matching game is not in any
case a related game. A related game is following the same route as the
referencee, for example, but a matching game may be quite different. A linked
game is a feature which will be managed by the author, the automatic of game
matching doesn't know such things, like the author knows.

> With a little effort, we can merge (say) next 10 moves of a referenced game
> as a variation with a comment showing the source game info.

Scidb can do this, too. But for me it's not elegant to replicate the moves of
another game in database. A link which opens the game - Scidb is supporting up
to nine open games simultaneously - is comfortable, expanding all the linked
games inside the referencee is an additional feature, which can be done with
single mouse clicks - or keyboard shortcuts - like folding/unfolding all
variations.

> This avoids all the pitfalls and complexity of permanent game
> links while still providing a good view of the relevant game.

Of course managing links is a bit sophisticated, and if the problem with game
copy is not easily solvable, then it's unrealistic. My first solution for this
problem is the following:

A game copy will replace all "hyperlinks" with textual links. Copying this game
to another database means, that the former links are now only comments in the
copy. With other words: if a game will be copied to another database, the
meaning of the link is changing, it's not a "hyperlink" anymore, it's only a
textual link - you cannot click it anymore to open the referenced game, and the
display of the link will change from a special link layout to a normal comment
(should be only a minor difference). Furthermore a hyperlink will always show
the actual game information, a textual link is static and will not reflect
changes of the linked game anymore.

This solution has two drawbacks:

1. I have to modify the copied game. This is realistic only if I can do this in
a very simple way - only appending the textual data for the textual links, not
more. I don't know yet whether this is realizable. A textual link will have a
few more bytes more than an ordinary comment.

2. The copy is not an one-to-one copy.

Does anybody know an alternative way to handle game copy? Probably the game copy
is smashing the idea with game links.

> PS - are you even going to have a permanent sort feature ?

I should implement this, so far as I see it's only an update of the index file
with the new order. All sorting features are already implemented and usable.

Gregor

> 3. Links to other games requires an additional data file, and an additional
>    attribute inside the game data.

Do you mean you are going to create a 4 file system ?

Though your DB knowledge is much greater, I find it hard to see the
worth of persistant game links.

1. More effort at base compaction/sort
2. Dereferencing game links makes PGN viewing much more complicated.
3. (Selective) game copy between database loses data/game links
if referenced games are not also copied. Even if they are - trying
to preserve game links would be very ugly.
4. You need a good DB design , which can't be hurried.
5. Scidb' tree shows matched games anyway - at good speed

The way Scid handles this seems fine to me -

With a little effort, we can merge (say) next 10 moves of a referenced game
as a variation with a comment showing the source game info.
This avoids all the pitfalls and complexity of permanent game
links whle still providing a good view of the relevant game. Tree/position
search/browse game can always be used for more information.

PS - Gregor, are you even going to have a permanent sort feature ?

regards, Steven

> Is there no permanent unique identifier for each game object
> irrespective of which collection it is currently a part of?

1. The index file would grow enormously with an additional unique
identifier.

2. Even with such an unique identifier you do not have direct
access to this game, because this identifier is not an index
(the game number is the index). Using this identifier as an
index would blow up the memory enormously.

3. Searching the game data for the linked game is too slow, this means
searching the database for an unique ID is not practicable.

4. Other database formats do not deliver such an unique ID, as
Steve has pointed out.

Momently I do need see a chance for a reference outside the database,
but probably I'm seeing ghosts here?

> Anyway - linking games within the database will surely add to Scidb's
> complexity and delivery date. Maybe this feature should be
> de-prioritized ?

I think it's the right date for this feature. The goal is to have
a stable production version (hopefully next year). One requirement
is a stable database format, which will not change (for some years).
This feature is influencing the database format.

Currently I'm already working on a next version of the database format,
because:

1. I have an issue with database management concerning the comments,
   I need an additional attribute in the game data section.

2. I have the support of children's chess in my mind (allowing invalid
   moves), this requires a small change in the game flags (index file),
   games with invalid moves have to have a special flag, such games are
   not exportable into other formats, for example.

3. Links to other games requires an additional data file, and an additional
   attribute inside the game data.

4. I'm planning to support the attachement of documents:
   - Attachement to a specific game
   - Attachement to a specific tournament, for example the tournament table
     (PDF or HTML)
   - Attachment to a database, for example a document which gives more
     information about this database.

One reason for the support of attachments is the ChessBase support.
ChessBase is attaching documents, and I'm (almost) knowing how to
export these documents (but this is not yet tested). Moreover I think
that such attachements are very useful, the author has a tool to
point out the specific attributes of a game, or even a whole database.

It's not useful to do the changes of the database format without implementing
the related features, only the practice can show whether the format is
really practicable. The effort for the implementation of the listed features is
not high, except the export of the ChessBase documents. But the latter is part
of the ChessBase support, and some users have shown great interest to switch
from ChessBase to an alternative database.

Gregor

>  Is there no permanent unique identifier for each game
> object irrespective of which collection it is currently a part of?

No - there's not. Moreover, Chessbase sort of corners the DB market,
and it's certainly not in their interests to work with other systems.

One alternative is to have a some sort of hash of the games moves used
as the identifier.. but in practice it's probably just as useful to
use the end position instead. They are fairly unique.

Anyway - linking games within the database will surely add to Scidb's
complexity and delivery date. Maybe this feature should be
de-prioritized ?

S.A.

Noob question... Is there no permanent unique identifier for each game
object irrespective of which collection it is currently a part of?




On Tue, Dec 3, 2013 at 5:32 PM, Gregor Cramer <re...@gm...> wrote:

> From: "Paolo Casaschi"
> -------------------------------------------------------
> It's an interesting feature, worth exploring.
>
> I would consider both links to games in the same DB or
> to games from another DB.
>
> I did some work around the PGN standard, it's probably worth
> considering how to save those games references into the PGN
> export of the game/database and defining a "standard" method
> for coding those references into PGN files. There's a proposed
> extension to the PGN standard that allows for custom tags to
> be defined within game comments, in the format
>
> 1. e4 e6 { [%proprietaryTag value of proprietary tag] } 2. d4 d5
>
> A general syntax for your tag could be
>
> [%gamelink plyNumber, gameNumber, fileName]
>
> with fileName being an optional parameter defaulting to the same
> database and gameNumber and plyNumber are self explanatory.
>
> Your example in PGN could for example be:
>
> 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 (4...Bc5 { [%gameLink 8, 23, ] } )
> 5.exd5 b5
>
> --
> Paolo
> -------------------------------------------------------
>
> Thanks, Paolo, for your suggestions. Defining a generic PGN tag for
> the links is very useful, I will do this.
>
> A bit problematic is the idea to have links into games of other
> databases. The following cases can occur with links:
>
> 1. The referenced game will be deleted physically.
>
> 2. The referenced game will change, so that the referenced position
> is no longer existing.
>
> If the referencee and the referenced game are in the same database,
> it's no problem to handle these cases appropriately, but what should
> I do if the referencee is in another database (and this database is
> currently not accessible)?
>
> 1. Do no allow deleting the referenced game, and do not allow changes
> so that the referenced position will be gone.
>
> 2. Do allow these operations, but in this case the link will become
> invalid.
>
> Both solutions are not nice.
>
> Gregor
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Scidb-users mailing list
> Sci...@li...
> https://lists.sourceforge.net/lists/listinfo/scidb-users
>

From: "Paolo Casaschi"
-------------------------------------------------------
It's an interesting feature, worth exploring.
 
I would consider both links to games in the same DB or
to games from another DB.
 
I did some work around the PGN standard, it's probably worth
considering how to save those games references into the PGN
export of the game/database and defining a "standard" method
for coding those references into PGN files. There's a proposed
extension to the PGN standard that allows for custom tags to
be defined within game comments, in the format
 
1. e4 e6 { [%proprietaryTag value of proprietary tag] } 2. d4 d5
 
A general syntax for your tag could be
 
[%gamelink plyNumber, gameNumber, fileName]
 
with fileName being an optional parameter defaulting to the same
database and gameNumber and plyNumber are self explanatory.
 
Your example in PGN could for example be:
 
1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 (4...Bc5 { [%gameLink 8, 23, ] } )
5.exd5 b5
 
--
Paolo 
-------------------------------------------------------

Thanks, Paolo, for your suggestions. Defining a generic PGN tag for
the links is very useful, I will do this.

A bit problematic is the idea to have links into games of other
databases. The following cases can occur with links:

1. The referenced game will be deleted physically.

2. The referenced game will change, so that the referenced position
is no longer existing.

If the referencee and the referenced game are in the same database,
it's no problem to handle these cases appropriately, but what should
I do if the referencee is in another database (and this database is
currently not accessible)?

1. Do no allow deleting the referenced game, and do not allow changes
so that the referenced position will be gone.

2. Do allow these operations, but in this case the link will become
invalid.

Both solutions are not nice.

Gregor

I'm thinking about a special feature: links to other
games in same database. These links will be created/
deleted in game editor. One example: the game editor
has the following content:

1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5
   ( 4...Bc5 [+]<Reinisch-Traxler,17,0-1> )
5.exd5 b5
   ( 5...Nd4 "The more solid Fritz variation, see
   <Lange-Humbold,34,0-1>" )
6.Bxb5 Qxd5

In this example we have two types of links:

1. The link <Lange-Humbold,34,0-1> is embedded inside
a comment, a mouse click on this link will open the
corresponding game. But this link type is possibly
superfluous, because creating this link in the comment
editor seems to be a bit complicated.

2. The link [+]<Reinisch-Traxler,17,0-1> is a solitary
link, not embedded inside a comment. A click on the link
<...> will open the corresponding game, a click on the
leading [+] will expand to the moves of the mainline in
the linked game (without comments):

1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5
   ( 4...Bc5 [-]<Reinisch-Traxler,17,0-1> 5.Nxf7 Bxf2+
   6.Ke2? Nd4+ 7.Kd3? b5! {...} 17.Kb4 c5# )
5.exd5 b5

A click on [-] will fold the link. The stored game will
only contain the link, not the moves of the corresponding
game. This means, if a game will be removed (compacting
the database), all links to this game will also be deleted.

Any further ideas or suggestions to this feature?

Cheers,
Gregor