Re: [sgf-std] New SGF property: transposition / links
- The big issue I see to resolve is the semantic of the link. I see
several possibilities discussed in the thread, and I'm going to try to
restate the concisely:
The node referenced is the identical position as the node with the
link. Presumably they have the same position *after* each has applied
2) Duplicate Sub-tree
The nodes that follow the referenced node are equally applicable to
the position at this node.
The referenced node should be offered to the user as a possible follow
on to this node. The position at the referenced node could be wholly
Identity seems to have a number difficulties in definition and
- just how "identical" do the positions have to be?
- i.e.: same number of prisoners? or just same delta? passes?
- same comments? markup?
- what about differing in only a tenuki move?
Duplicate Sub-tree has the downside that now each node can no longer
be transformed into a single game position, since the state of the
game will depend on if you took a jump to get there.
Jump gets around these difficulties, but at the expense of being a
different kind of navigation that the existing options.
One way to approach the choice is to look at the use cases and see
which admits the most flexibility. The use cases I see are:
A) Joseki dictionary desire to not replicate whole sub-trees when a
position can be arrived at via two different move sequences. This use
case could be broadened to include color and spacial transposition, or
differing in tenuki.
B) Tsumego. Like joseki, a desire to not replicate whole sub-trees.
Here the game state identity requirement might be more rigorous.
GoProblems.com already does this automatically by identifying
identical positions in the tree: If one has follow on nodes and the
other doesn't -- they are "spliced".
C) General annotation need to have variant lines or main lines
reference other lines within the tree.
It seems to me that the Jump semantic supports all of these. If there
is a need for identical position at both ends, it is easy enough for
the creation tool to enforce that.
The only thing that then needs to be addressed is the intended user
navigation: Is it displayed as an option? Is it followed
automatically? One could support both by this rule: If the LI/TP
property appears as the only property in a node, then the link should
be immediately followed, replacing the game state with the state at
the target node. On the other hand, if there are any other
properties, including just a comment (even an empty comment!), then
the user is offered link as a sort of 'remote variation', and can
choose, as they would choose a variant, to continue in that part of