Discourse Grammar Explainer

OWL Ontology Extensions

The discourse grammar is implemented as OWL class extensions to sbpi.ttl. Every node type and relation has formal domain/range constraints that SHACL validation enforces.

DiscourseNode Superclass & 7 Subclasses

All discourse elements inherit from sbpi:DiscourseNode. Signal and Prediction have dual inheritance — they exist in both the scoring and discourse layers.

# ── Discourse Grammar: Node Type Hierarchy ──

sbpi:DiscourseNode a owl:Class ;
    rdfs:label "Discourse Node" ;
    rdfs:comment "Abstract superclass for all discourse grammar nodes" .

sbpi:Claim a owl:Class ;
    rdfs:subClassOf sbpi:DiscourseNode ;
    rdfs:label "Claim" ;
    rdfs:comment "An assertion about the world, requiring evidence" .

sbpi:Evidence a owl:Class ;
    rdfs:subClassOf sbpi:DiscourseNode ;
    rdfs:label "Evidence" ;
    rdfs:comment "Data or observation that supports or opposes a claim" .

sbpi:Source a owl:Class ;
    rdfs:subClassOf sbpi:DiscourseNode ;
    rdfs:label "Source" ;
    rdfs:comment "Provenance origin for evidence" .

sbpi:Question a owl:Class ;
    rdfs:subClassOf sbpi:DiscourseNode ;
    rdfs:label "Question" ;
    rdfs:comment "Driving inquiry motivating analysis" .

sbpi:DirectiveNode a owl:Class ;
    rdfs:subClassOf sbpi:DiscourseNode ;
    rdfs:label "Directive" ;
    rdfs:comment "Actionable recommendation derived from claims" .

sbpi:Annotation a owl:Class ;
    rdfs:subClassOf sbpi:DiscourseNode ;
    rdfs:label "Annotation" ;
    rdfs:comment "Reader feedback on any discourse node" .

# ── Dual-Inheritance: Scoring + Discourse ──

sbpi:Signal a owl:Class ;
    rdfs:subClassOf sbpi:DiscourseNode ,
                     sbpi:ScoringElement ;
    rdfs:label "Signal" .

sbpi:Prediction a owl:Class ;
    rdfs:subClassOf sbpi:DiscourseNode ,
                     sbpi:ScoringElement ;
    rdfs:label "Prediction" .

9 Object Properties (Relations)

# ── Discourse Relations with Domain/Range ──

sbpi:supports a owl:ObjectProperty ;
    rdfs:domain sbpi:Evidence ;
    rdfs:range  sbpi:Claim .

sbpi:opposes a owl:ObjectProperty ;
    rdfs:domain sbpi:Evidence ;
    rdfs:range  sbpi:Claim .

sbpi:informs a owl:ObjectProperty ;
    rdfs:domain sbpi:Source ;
    rdfs:range  sbpi:Evidence .

sbpi:triggers a owl:ObjectProperty ;
    rdfs:domain sbpi:Signal ;
    rdfs:range  sbpi:Question .

sbpi:predicts a owl:ObjectProperty ;
    rdfs:domain sbpi:Claim ;
    rdfs:range  sbpi:Prediction .

sbpi:annotates a owl:ObjectProperty ;
    rdfs:domain sbpi:Annotation ;
    rdfs:range  sbpi:DiscourseNode .

sbpi:grounds a owl:ObjectProperty ;
    rdfs:domain sbpi:Question ;
    rdfs:range  sbpi:Claim .

sbpi:supersedes a owl:ObjectProperty ;
    rdfs:domain sbpi:DiscourseNode ;
    rdfs:range  sbpi:DiscourseNode .

sbpi:derivedFrom a owl:ObjectProperty ;
    rdfs:domain sbpi:DiscourseNode ;
    rdfs:range  sbpi:DiscourseNode ;
    rdfs:comment "Provenance chain: this node was derived from another" .

3 Datatype Properties

sbpi:hasConfidence a owl:DatatypeProperty ;
    rdfs:domain sbpi:Evidence ;
    rdfs:range  xsd:decimal ;
    rdfs:comment "Confidence score [0.0 - 1.0]" .

sbpi:nodeFormat a owl:DatatypeProperty ;
    rdfs:domain sbpi:DiscourseNode ;
    rdfs:range  xsd:string ;
    rdfs:comment "Output format hint: text, chart, table" .

sbpi:discourseText a owl:DatatypeProperty ;
    rdfs:domain sbpi:DiscourseNode ;
    rdfs:range  xsd:string ;
    rdfs:comment "Human-readable text content of the node" .

K-Pop Vertical Extension

The K-Pop extension demonstrates how the discourse grammar adapts to vertical-specific domains. Four new classes and ten high-value edge types capture the unique dynamics of the K-Pop industry.

# ── K-Pop Vertical Extension ──

kpop:Agency a owl:Class ;
    rdfs:subClassOf sbpi:TrackedCompany ;
    rdfs:label "K-Pop Agency" ;
    rdfs:comment "Entertainment company managing K-Pop artists (e.g., HYBE, SM, JYP)" .

kpop:ArtistGroup a owl:Class ;
    rdfs:label "K-Pop Group" ;
    rdfs:comment "Multi-member performance group (e.g., BTS, BLACKPINK, aespa)" .

kpop:Soloist a owl:Class ;
    rdfs:label "K-Pop Soloist" ;
    rdfs:comment "Individual K-Pop artist" .

kpop:Fandom a owl:Class ;
    rdfs:label "Fandom" ;
    rdfs:comment "Organized fan community with coordinated buying/streaming behavior" .

# ── K-Pop Edge Types (10 high-value relations) ──

kpop:manages a owl:ObjectProperty ;
    rdfs:domain kpop:Agency ; rdfs:range kpop:ArtistGroup .

kpop:hasFandom a owl:ObjectProperty ;
    rdfs:domain kpop:ArtistGroup ; rdfs:range kpop:Fandom .

kpop:memberOf a owl:ObjectProperty ;
    rdfs:domain kpop:Soloist ; rdfs:range kpop:ArtistGroup .

kpop:comebackEvent a owl:ObjectProperty ;
    rdfs:domain kpop:ArtistGroup ; rdfs:range sbpi:Signal .

kpop:rivalsWith a owl:ObjectProperty ;
    rdfs:domain kpop:Agency ; rdfs:range kpop:Agency .

kpop:distributedBy a owl:ObjectProperty ;
    rdfs:domain kpop:ArtistGroup ; rdfs:range sbpi:TrackedCompany .

kpop:streamingMetric a owl:DatatypeProperty ;
    rdfs:domain kpop:ArtistGroup ; rdfs:range xsd:integer .

kpop:chartsOn a owl:ObjectProperty ;
    rdfs:domain kpop:ArtistGroup ; rdfs:range sbpi:TrackedCompany .

kpop:collaboratesWith a owl:ObjectProperty ;
    rdfs:domain kpop:ArtistGroup ; rdfs:range kpop:ArtistGroup .

kpop:fandomAction a owl:ObjectProperty ;
    rdfs:domain kpop:Fandom ; rdfs:range sbpi:Signal .

SHACL Validation Shapes

SHACL shapes enforce structural rules at data ingestion time. A Claim without evidence or an Evidence node without confidence will fail validation before entering the store.

# ── SHACL: Discourse Grammar Validation ──

sbpi-sh:ClaimShape a sh:NodeShape ;
    sh:targetClass sbpi:Claim ;
    sh:property [
        sh:path sbpi:discourseText ;
        sh:minCount 1 ;
        sh:datatype xsd:string ;
        sh:message "Every Claim must have discourse text"
    ] ;
    sh:property [
        sh:path [ sh:inversePath sbpi:supports ] ;
        sh:minCount 1 ;
        sh:message "Every Claim must have at least one supporting Evidence"
    ] .

sbpi-sh:EvidenceShape a sh:NodeShape ;
    sh:targetClass sbpi:Evidence ;
    sh:property [
        sh:path sbpi:hasConfidence ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:datatype xsd:decimal ;
        sh:minInclusive 0.0 ;
        sh:maxInclusive 1.0 ;
        sh:message "Evidence must have exactly one confidence score in [0.0, 1.0]"
    ] ;
    sh:property [
        sh:path [ sh:inversePath sbpi:informs ] ;
        sh:minCount 1 ;
        sh:message "Evidence must trace to at least one Source"
    ] .

# ── SHACL: K-Pop Vertical ──

kpop-sh:ArtistGroupShape a sh:NodeShape ;
    sh:targetClass kpop:ArtistGroup ;
    sh:property [
        sh:path [ sh:inversePath kpop:manages ] ;
        sh:minCount 1 ;
        sh:class kpop:Agency ;
        sh:message "Every ArtistGroup must be managed by at least one Agency"
    ] .

kpop-sh:AgencyShape a sh:NodeShape ;
    sh:targetClass kpop:Agency ;
    sh:property [
        sh:path rdfs:label ;
        sh:minCount 1 ;
        sh:message "Every Agency must have a label"
    ] .

Evidence Trail

These are real evidence chains retrieved from the Oxigraph store. Every claim below was traced to its sources via SPARQL. The confidence scores, the sources, and the support/opposition relationships are all stored as RDF triples — not prose.

Live Data — Oxigraph Store Statistics

The knowledge graph currently holds 3,202 triples across two layers: the original SBPI scoring data and the new discourse grammar layer seeded in this session.

Instance Counts by Type

Layer Composition

Growth Trajectory

The Annotation Loop

Gordon Pask's Conversation Theory posits that understanding is demonstrated through teach-back — the ability to re-express an idea and have discrepancies surface. In the Discourse Grammar, reader annotations are the teach-back mechanism. When a reader opposes a high-confidence claim, that disagreement is a Teach-Back Delta — and it is more valuable than any automated signal.

Annotation Prefix Conventions

Readers annotate using 4 prefix symbols. Each prefix maps to a discourse relation type:

pending.yaml Format

Annotations are staged in a YAML file before processing. Each entry specifies the target node, the prefix type, the annotator, and the text content.

# pending.yaml — Staged reader annotations

annotations:
  - id: "ANN_001"
    target: "CLM_reelshort_decline"
    prefix: "~"
    annotator: "limore@shurai.com"
    timestamp: "2026-03-28T10:15:00Z"
    text: "ReelShort still dominates LATAM markets.
           Composite decline may not reflect regional strength."

  - id: "ANN_002"
    target: "CLM_disney_surge"
    prefix: "+"
    annotator: "analyst@microco.com"
    timestamp: "2026-03-28T11:30:00Z"
    text: "Disney reportedly allocating $50M for vertical
           drama originals in 2026 — confirms infrastructure
           commoditization thesis."

  - id: "ANN_003"
    target: "CLM_col_belive_shopify"
    prefix: "?"
    annotator: "analyst@microco.com"
    timestamp: "2026-03-28T12:00:00Z"
    text: "Has COL/BeLive disclosed pricing or signed
           any customers since FILMART announcement?"

Processing Pipeline

annotation_processor.py reads pending.yaml, classifies each annotation by prefix, generates a SPARQL UPDATE, and executes it against the Oxigraph store.

def classify_annotation(entry):
    """Map prefix to discourse relation and node type."""
    prefix_map = {
        "?": {"node_type": "Question",    "relation": "grounds"},
        "~": {"node_type": "Evidence",    "relation": "opposes"},
        "+": {"node_type": "Evidence",    "relation": "supports"},
        "!": {"node_type": "Signal",      "relation": "triggers"}
    }
    return prefix_map[entry["prefix"]]

SPARQL UPDATE Template

Each processed annotation generates a SPARQL UPDATE that inserts the new node and its relations into the graph:

PREFIX sbpi: <http://shurai.com/ontology/sbpi#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

INSERT DATA {
  # Create the annotation node
  sbpi:{ann_id} a sbpi:Annotation , sbpi:{node_type} ;
      sbpi:discourseText  "{text}"^^xsd:string ;
      sbpi:hasConfidence  "{confidence}"^^xsd:decimal ;
      sbpi:annotatedBy    "{annotator}"^^xsd:string ;
      sbpi:annotatedAt    "{timestamp}"^^xsd:dateTime .

  # Link annotation to target
  sbpi:{ann_id} sbpi:annotates sbpi:{target_id} .

  # Create the discourse relation
  sbpi:{ann_id} sbpi:{relation} sbpi:{target_id} .
}

Sample Annotations — Processing Preview

Here is what happens when the 3 pending annotations are processed:

System Architecture

Three layers, six components, one feedback loop. The architecture is designed for incremental growth — each report cycle adds triples, each annotation sharpens the graph, and each query returns richer provenance chains over time.

Three-Layer Stack

Component Registry

Data Flow

The feedback loop closes when reader annotations from cycle N improve the provenance chains in cycle N+1.

Full Architecture Diagram

Phase 1 to Phase 2