Loading ...
Sorry, an error occurred while loading the content.

Re: [sgf-std] New SGF property: transposition / links

Expand Messages
  • Mark Lentczner
    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
    Message 1 of 12 , Jul 30 9:18 PM
    • 0 Attachment
      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:

      1) Identity
      The node referenced is the identical position as the node with the
      link. Presumably they have the same position *after* each has applied
      any moves.

      2) Duplicate Sub-tree
      The nodes that follow the referenced node are equally applicable to
      the position at this node.

      3) Jump
      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
      different.

      Identity seems to have a number difficulties in definition and
      resiliency:
      - 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
      the tree.

      - Mark
    Your message has been successfully submitted and would be delivered to recipients shortly.