Qualified Piece Identifier (QPI) Specification

Version: 1.0.0
Author: Sashité
Published: January 25, 2025
License: MIT License

Overview

Qualified Piece Identifier (QPI) provides a rule-agnostic format for identifying game pieces in abstract strategy board games by combining Style Identifier Notation (SIN) and Piece Identifier Notation (PIN) primitives with a colon separator. This combination enables complete piece identification across different game styles and contexts.

QPI represents all four fundamental piece attributes:

Name → PIN component (ASCII letter with direct assignment)
Side → SIN & PIN components (letter cases)
State → PIN component (optional state modifier)
Style → SIN component (ASCII letter with direct assignment)

Unlike Extended Piece Identifier Notation (EPIN) which uses derivation markers, QPI explicitly identifies both style and piece using foundational primitives.

Terminology

For complete definitions of terms used in this document, see the Glossary.

Dependencies

QPI builds upon two foundational primitive specifications:

SIN: Foundational style identification primitives
PIN: Foundational piece identification primitives

QPI combines these primitive building blocks: SIN + PIN = QPI

Format Specification

Structure

<sin>:<pin>

Grammar (BNF)

<qpi> ::= <uppercase-qpi> | <lowercase-qpi>

<uppercase-qpi> ::= <uppercase-letter> <colon> <uppercase-pin>
<lowercase-qpi> ::= <lowercase-letter> <colon> <lowercase-pin>

<colon> ::= ":"

<uppercase-pin> ::= <uppercase-letter> | <state-modifier> <uppercase-letter>
<lowercase-pin> ::= <lowercase-letter> | <state-modifier> <lowercase-letter>

<state-modifier> ::= "+" | "-"

<uppercase-letter> ::= "A" | "B" | "C" | ... | "Z"
<lowercase-letter> ::= "a" | "b" | "c" | ... | "z"

Regular Expression

\A([A-Z]:[-+]?[A-Z]|[a-z]:[-+]?[a-z])\z

Primitive Combination

Direct Primitive Integration

QPI components are directly assigned primitive identifiers:

Style Component (SIN)

Direct assignment: SIN characters represent styles through explicit association
Context-dependent: Meaning determined by specific game system or context
Player encoding: Case indicates which player uses the style

Piece Component (PIN)

Direct assignment: PIN characters represent piece names through explicit association
Context-dependent: Meaning determined by specific game system or context
Player encoding: Case indicates which player controls the piece
State support: Optional modifiers for enhanced/diminished states

Combination Examples

SIN	PIN	QPI Result	Interpretation
`C`	`K`	`C:K`	Style C, piece K, first player
`c`	`k`	`c:k`	Style C, piece K, second player
`S`	`+P`	`S:+P`	Style S, enhanced piece P, first player
`x`	`-p`	`x:-p`	Style X, diminished piece P, second player

Piece Attribute Mapping

QPI encodes piece attributes by combining SIN and PIN information:

Piece Attribute	QPI Encoding	Examples
Name	PIN letter choice	`K` = King, `N` = Knight
Side	SIN & PIN cases	`C:K` = First player, `c:k` = Second player
State	PIN state modifier	`S:+S` = Enhanced, `C:-P` = Diminished
Style	SIN letter choice	`C` = Chess-style, `S` = Shogi-style

Important: The SIN and PIN components encode their respective attributes independently through direct assignment. The SIN component indicates which style governs the piece, while the PIN component handles name, side, and state according to PIN specification rules.

Component Relationship

Independent Primitives with Consistency Constraint

QPI treats SIN and PIN as independently assigned components connected by a colon separator:

SIN component: Direct style assignment using SIN primitive
PIN component: Direct piece assignment using PIN primitive
Separator: Colon (:) provides clear delimitation

Cross-Reference Constraint

While the components are assigned independently, there is a semantic constraint: the style identified by the SIN component must be associated with the same player as indicated by the PIN case. This ensures consistency between style assignment and piece ownership.

Valid combinations:

C:K - Style C with first player king
c:k - Style C with second player king
S:+S - Style S with first player enhanced silver
s:+s - Style S with second player enhanced silver

Invalid semantic combinations (syntactically valid but semantically inconsistent):

C:k - Style C (first player) with second player piece
c:K - Style C (second player) with first player piece

Extension Integration

Human-Readable Extensions

QPI can be enhanced through human-readable extension systems:

Extension Integration: Systems can provide descriptive names for QPI components:

Style extensions (like SNN): Provide human-readable style names
Piece extensions (like PNN): Provide human-readable piece names
Bidirectional mapping: Require maintained indexes for reliable conversion

Mapping Requirements

Important: While QPI → extension mapping requires external indexes, the compact QPI format remains self-contained:

Context dependency: Same QPI may map to different extensions in different contexts
Implementation responsibility: Systems must maintain explicit mapping tables
QPI independence: QPI functions independently of extension systems

Examples

Direct QPI usage:

C:K  # Style C, piece K
c:k  # Style C, piece K (second player)
S:+P # Style S, enhanced piece P

With extension context:

Extension system defines: CHESS → C, KING → K
QPI provides the compact representation: C:K
Full compatibility maintained between systems

Cross-Style Scenarios

Single-Style Games

Chess vs. Chess (both players use Chess):

QPI: C:K (white king), c:k (black king)
Both pieces use the same style, different players

Cross-Style Games

Chess vs. Ōgi:

First player: Style C
Second player: Style o
QPI: C:K (chess king, first player), o:k (ōgi king, second player)

With enhanced pieces:

QPI: o:+s (enhanced ōgi silver, second player)

Multiple Source Mapping

Same QPI from different extension sources:

QPI: C:K could derive from:
- (CHESS, KING) context
- (CAPABLANCA, KNIGHT) context
- (COURIER, KHAN) context

Note: From QPI C:K, you cannot determine the original extension sources without maintained mapping context.

Design Properties

Rule-agnostic: Independent of specific game mechanics
Complete identification: Explicit representation of all four piece attributes
Cross-style support: Enables multi-tradition gaming environments
Component clarity: Clear separation between style context and piece identity
Primitive foundation: Built from foundational SIN and PIN building blocks
Extension-ready: Can be enhanced by human-readable naming systems
Context-flexible: Adaptable to various identification needs

Examples

See QPI Examples for practical implementation guidance.

Reference Implementations

Ruby

QPI.rb – Reference implementation with SIN-PIN primitive combination and extension integration support.