Prophecy Tracking Knowledge Graph Design - Source Excerpt 02 - Identifiers, provenance, and versioning

Back to Prophecy Tracking Knowledge Graph Design

Summary

This source excerpt begins near Identifiers, provenance, and versioning and preserves the surrounding evidence from Antichrist.net/agent-file-handoff/Archive/2026-05-12-content-reports/Prophecy-Tracking Knowledge Graph Design.md.

**Source path:** Antichrist.net/agent-file-handoff/Archive/2026-05-12-content-reports/Prophecy-Tracking Knowledge Graph Design.md

For edges, the essential predicates are: `HAS_EXPRESSION`, `HAS_PASSAGE`, `MENTIONS`, `ABOUT`, `PREDICTS`, `INTERPRETS`, `REFERS_TO`, `CITES`, `DERIVED_FROM`, `SUPPORTED_BY`, `CONTRADICTS`, `COMPETES_WITH`, `SUPERSEDES`, `SAME_AS`, `LOCATED_IN`, `OCCURS_DURING`, `OCCURS_AT`, `REVIEWED_BY`, and `GENERATED_BY`. In an RDF implementation, many of these can be ordinary predicates, while contradiction judgments, reviewer actions, and machine extraction results are usually better reified as resources or placed into named graphs. In a property graph, ordinary semantic links can be direct relationships, but contradiction and review results still benefit from reification whenever you need per-assertion provenance, scores, or audit history. citeturn19view1turn29view0turn19view0

### Identifiers, provenance, and versioning

Use **two identifier layers**. The first is a **stable conceptual ID** for the thing itself, such as a person, place, text work, or canonical claim. The second is a **versioned record ID** for mutable graph records. In RDF form, the stable ID is an IRI; versions can be related through PAV and Dublin Core versioning terms. In a property graph, store both `kg_id` and `version_id` on the node and never overwrite version history destructively. citeturn19view1turn19view12turn19view10

Every machine-created assertion should carry enough provenance to be replayed or challenged later. The minimum high-value fields are: `source_id`, `passage_id`, `source_locator`, `source_checksum`, `pipeline_version`, `model_name`, `model_version`, `prompt_hash` if prompting is used, `run_timestamp`, `extractor_confidence`, and `wasDerivedFrom`. That recommendation follows directly from the role PROV-O and PAV play in provenance interchange and version traceability. citeturn19view0turn19view12

A practical versioning rule is: **stable sources and passages are immutable; claims, alignments, contradictions, and review decisions are append-only**. If a reviewer changes an interpretation or contradiction ruling, create a new version and link it with `SUPERSEDES` and a provenance edge rather than rewriting the old one. Nanopublication practice is especially useful here because it explicitly separates assertion, assertion provenance, and publication information in distinct graphs. citeturn29view0turn19view1turn19view0

### Example schema diagram

The diagram below shows a recommended logical model. It is illustrative rather than exhaustive.

' ' ' mermaid
classDiagram
    class TextWork {
      kg_id
      canonical_title
      tradition
      tags
    }

    class TextExpression {
      kg_id
      language
      edition
      translator
      publication_date
    }

    class Passage {
      kg_id
      locator
      quoted_text
      token_offsets
      ocr_confidence
    }

    class SourceDocument {
      kg_id
      source_type
      author_or_attributor
      date
      reliability_score
      rights
    }

    class ProphecyStatement {
      kg_id
      statement_text
      literalness_score
      hedge_score
      confidence
    }

    class PredictionClaim {
      kg_id
      canonical_form
      predicate
      polarity
      modality
      confidence
    }

    class InterpretationClaim {
      kg_id
      interpretation_text
      school
      confidence
    }

    class Entity {
      kg_id
      type
      canonical_label
      external_ids
    }

    class Event {
      kg_id
      label
      start_time
      end_time
      place_id
    }

    class ContradictionAssertion {
      kg_id
      relation_type
      contradiction_score
      aligned_facets
      threshold_version
    }

    class ReviewDecision {
      kg_id
      status
      reviewer_role
      reviewed_at
      rationale
    }

    class ExtractionRun {
      kg_id
      pipeline_version
      model_name
      model_version
      prompt_hash
      run_at
    }

    TextWork "1" --> "*" TextExpression : HAS_EXPRESSION
    TextExpression "1" --> "*" Passage : HAS_PASSAGE
    Passage "1" --> "1" SourceDocument : ANCHORED_IN
    Passage "1" --> "*" ProphecyStatement : EVIDENCES
    ProphecyStatement "1" --> "*" PredictionClaim : NORMALIZES_TO
    ProphecyStatement "1" --> "*" InterpretationClaim : INTERPRETED_AS
    PredictionClaim "*" --> "*" Entity : ABOUT
    PredictionClaim "*" --> "*" Event : PREDICTS
    InterpretationClaim "*" --> "*" Entity : REFERS_TO
    InterpretationClaim "*" --> "*" Event : REFERS_TO
    ContradictionAssertion "*" --> "1" PredictionClaim : CLAIM_A
    ContradictionAssertion "*" --> "1" PredictionClaim : CLAIM_B
    ContradictionAssertion "*" --> "*" ReviewDecision : REVIEWED_BY
    PredictionClaim "*" --> "*" ExtractionRun : GENERATED_BY
    InterpretationClaim "*" --> "*" ExtractionRun : GENERATED_BY
' ' ' 

The modeling choice to keep `Passage`, `Claim`, and `ContradictionAssertion` separate is strongly supported by provenance and named-graph standards, and it aligns with nanopublication practice for granular, citable assertions. citeturn19view1turn19view0turn29view0

### Illustrative sample records

The table below is **synthetic** and only illustrates how records can fit together.

| Record ID | Type | Canonical text or label | Key links | Source | Confidence | Contradiction state | Review status |
|---|---|---|---|---|---:|---|---|
| `txt:oracle-scroll-a` | `TextWork` | Oracle Scroll A | `HAS_EXPRESSION -> expr:osa-en-1987` | `src:archive-item-001` | 1.00 | — | verified |
| `ps:osa-3-14` | `ProphecyStatement` | “Within three moons, the northern ruler will fall.” | `EVIDENCES <- passage:osa-p3-l14` | `src:archive-item-001` | 0.97 | — | verified |
| `pc:northern-ruler-falls` | `PredictionClaim` | `RulerOf(North) FALLS WITHIN [T0,T0+3 months]` | `NORMALIZES_TO <- ps:osa-3-14` | `src:archive-item-001` | 0.83 | candidate conflict with `pc:northern-ruler-victorious` | under_review |
| `ic:commentary-b-1` | `InterpretationClaim` | “The statement refers to the Siege of City X.” | `INTERPRETED_AS <- ps:osa-3-14`, `REFERS_TO -> evt:siege-city-x` | `src:commentary-b-1987` | 0.71 | competing interpretation with `ic:commentary-c-2` | disputed |
| `ca:conflict-009` | `ContradictionAssertion` | `pc:northern-ruler-falls` contradicts `pc:northern-ruler-victorious` | aligned on entity/time; conflict on outcome | derived from multiple sources | 0.78 | partial contradiction | under_review |
| `rv:review-2241` | `ReviewDecision` | reviewer notes + evidence | `target -> ca:conflict-009` | internal review | — | conflict retained | verified |

## Extraction Pipeline

### Ingestion from web, OCR, and archives

A prophecy-tracking KG needs an ingestion layer that can handle born-digital documents, scanned manuscripts, archive facsimiles, and derivative PDFs without discarding layout evidence. IIIF Presentation API manifests are useful for interoperable access to compound digital objects and their navigable structure, while the Internet Archive Metadata API and OCR pipeline expose item metadata, OCR artifacts, hOCR files, searchable text, and page-level indexes. Tesseract and TrOCR are both relevant OCR options: Tesseract is widely used and can emit hOCR, TSV, ALTO, PAGE, and searchable PDF output, and TrOCR is a modern transformer-based OCR approach for end-to-end text recognition. citeturn35view0turn21view2turn36view0turn31search1turn31search3turn21view9

For scanned or archival texts, the system should store four parallel artifacts for every ingestible document whenever feasible: the source image or PDF, the extracted text, the page/line or bounding-box anchor, and the ingest/OCR metadata. Internet Archive’s hOCR design is a good model here because it explicitly preserves text, word-level bounding boxes, per-word confidence, page indexing, and searchable derivatives. In a prophecy-tracking workflow, those anchors are important because later reviewers often need to inspect an exact page, line, or image crop to judge transcription quality or interpretive ambiguity. citeturn36view0

### NLP pipeline for entities, claims, relations, and events

A practical NLP stack should be staged rather than monolithic. The first pass performs language identification, sentence and passage segmentation, quote detection, and canonicalization. The second pass does entity mention detection, entity linking, and coreference. The third pass performs relation extraction and event extraction. The fourth pass converts raw passages into normalized propositions suitable for graph insertion. Research on document-level relation extraction and cross-document event extraction is important here because many prophecy interpretations depend on information dispersed across multiple sentences or sources, not on one sentence alone. citeturn19view11turn21view7turn23view4turn21view19