Prophecy Tracking Knowledge Graph Design - Source Excerpt 01 - Prophecy-Tracking Knowledge Graph Design

Back to Prophecy Tracking Knowledge Graph Design

Summary

This source excerpt begins near Prophecy-Tracking Knowledge Graph Design 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

# Prophecy-Tracking Knowledge Graph Design

## Executive Summary

A robust prophecy-tracking knowledge graph should not treat “prophecies” as a single undifferentiated object. The system works best when it separates at least five layers: the text itself, the normalized prediction claim, later interpretation claims, the sources that attest each statement, and the provenance and review metadata explaining how each graph assertion entered the system. That separation maps well to existing standards for RDF datasets, provenance, ontology modeling, validation, temporal modeling, geospatial modeling, and metadata, including RDF 1.1, OWL 2, PROV-O, PAV, SHACL, OWL-Time, GeoSPARQL, Dublin Core, JSON-LD, and Turtle. citeturn19view1turn19view4turn19view0turn19view12turn25view0turn19view6turn19view7turn19view10turn19view3turn34view2

The most defensible architecture is statement-centric. In practice, this means modeling each important claim as its own first-class object with a stable identifier, source anchoring, machine and human provenance, version history, confidence score, and review state. Contradictions should also be modeled as first-class assertions rather than as bare edges, because contradiction judgments require provenance, scorer outputs, thresholds, reviewer notes, and occasionally competing interpretations rather than binary “true/false” labels. Named RDF graphs and nanopublication-style packaging are especially useful for this because they let you isolate the assertion, its provenance, and publication metadata. citeturn19view1turn29view0turn19view0turn19view12

For extraction, the pipeline should be multimodal and archive-aware: ingest born-digital text, scanned pages, and archive manifests; preserve page, line, and bounding-box anchors; run OCR where needed; then perform entity extraction, entity linking, coreference, relation extraction, event extraction, temporal normalization, geospatial normalization, and claim normalization. Historical and multilingual corpora make archival interfaces and standards like IIIF, Internet Archive item metadata, hOCR, and language tags important, while NLP research shows that document-level relation extraction, cross-document event extraction, temporal tagging, and ambiguity handling all benefit from explicit normalization steps rather than end-to-end black boxes. citeturn35view0turn21view2turn36view0turn21view9turn21view7turn23view4turn21view8turn19view11turn21view19

Contradiction detection should be hybrid. Symbolic rules are strong at exact conflicts in date, place, negation, quantity, and entity identity; embedding retrieval is strong for candidate generation; and supervised NLI-style contradiction scoring is useful for semantic comparison across paraphrases. But recent work also shows that NLI systems remain brittle, especially on simple or document-level contradictions, so automatic contradiction labels should be treated as triage signals rather than final judgments. Thresholds must be calibrated on a domain-specific validation set, not copied from a benchmark paper. citeturn21view14turn21view11turn23view3turn32view0turn22view0

From an implementation perspective, there is no single mandatory storage stack. Property graphs are strong for analyst workflows and intuitive pattern queries through Cypher; RDF/OWL stores are stronger for standards-based interoperability, SHACL validation, Linked Data publication, and named-graph provenance; and dual-model systems such as Amazon Neptune reduce architectural friction because they support openCypher for property-graph-style querying and SPARQL for RDF. If the project’s long-term goal includes exchange with archives, data publication, and research reuse, a canonical RDF layer with optional projection into a property graph is the cleanest design. citeturn34view1turn19view2turn34view0turn19view8turn21view4

A realistic delivery plan is a staged build over roughly 30 to 46 person-weeks for a solid first production system: schema and governance first, then ingestion and normalization, then contradiction scoring and review tooling, then standards export, visualization, and evaluation. The largest technical risks are not storage or query syntax; they are ambiguity in figurative language, weak historical place normalization, and overconfidence in automatic contradiction detectors. Those risks are manageable if the graph distinguishes text from interpretation, preserves provenance at assertion granularity, and keeps a strong human review workflow. citeturn22view1turn22view2turn33search0turn32view0turn19view13

## Data Model and Schema

### Recommended modeling approach

The core schema should distinguish between **works and passages**, **claims**, **interpretations**, **entities**, **events**, **sources**, **contradiction assertions**, and **review decisions**. This follows the general pattern encouraged by RDF, OWL, PROV-O, Dublin Core, and nanopublication practice: represent the thing itself, the assertion about the thing, and the provenance of that assertion as separate but linked resources. citeturn19view1turn19view4turn19view0turn19view10turn29view0

A good default is to make the **atomic normalized claim** the centerpiece of the graph. The original passage remains immutable evidence. A prophecy statement node can preserve the wording from a passage, while a prediction claim node represents the normalized proposition extracted from that wording. An interpretation claim then connects a prophecy statement or prediction claim to a proposed referent, event, person, place, or period. This distinction matters because theological, symbolic, and historical interpretive traditions often disagree without necessarily contradicting the original passage text itself. That difference is precisely where provenance and review metadata become most important. This is an architectural inference from the provenance and named-graph standards plus the known difficulty of machine contradiction detection in document-scale settings. citeturn19view0turn19view1turn29view0turn22view0turn32view0

### Node types, edge types, and attributes

The following schema is a practical minimum.

| Type | Purpose | Required attributes | Recommended attributes |
|---|---|---|---|
| `Person`, `Group`, `Place`, `Event`, `TextWork` | Canonical real-world or textual entities | `kg_id`, `canonical_label` | aliases, external IDs, description, temporal span, geometry, tradition/context tags |
| `TextExpression` | A specific edition, manuscript witness, translation, or version of a text | `kg_id`, `work_id`, `language`, `source_id` | edition, translator, publication date, manuscript shelfmark, canonical citation |
| `Passage` | A page/folio/verse/line/span anchored inside a text expression or source | `kg_id`, `source_id`, `locator`, `quoted_text` | token offsets, OCR bbox, OCR confidence, image URI, checksum |
| `ProphecyStatement` | Passage-level statement preserving wording | `kg_id`, `passage_id`, `statement_text` | directness, modality, literalness score, hedge score, extraction method |
| `PredictionClaim` | Normalized atomic proposition derived from a statement | `kg_id`, `canonical_form`, `predicate`, `modality` | subject/object IDs, time interval, place ID, quantity, polarity, confidence |
| `InterpretationClaim` | Claim mapping a prophecy statement or prediction claim to a meaning or referent | `kg_id`, `interprets_id`, `interpretation_text` | target event/entity, tradition/school, confidence, reviewer rationale |
| `SourceDocument` | Primary or secondary source artifact | `kg_id`, `title`, `source_type`, `date`, `author_or_attributor` | reliability score, rights, publisher, archive ID, URL/URI, language |
| `ContradictionAssertion` | Reified contradiction or competing-interpretation judgment | `kg_id`, `claim_a`, `claim_b`, `relation_type` | contradiction score, aligned facets, method, threshold version, reviewer status |
| `ReviewDecision` | Human review outcome | `kg_id`, `target_id`, `status`, `reviewed_by`, `reviewed_at` | notes, evidence dossier, dispute ID, supersedes ID |
| `ExtractionRun` | Machine provenance record | `kg_id`, `pipeline_version`, `run_at` | model name, model version, prompt hash, parameters, calibration version |

This attribute set is consistent with widely used metadata and provenance vocabularies: Dublin Core terms supply resource-level metadata such as creator, date, source, language, spatial and temporal coverage; BCP 47 language tags provide standardized language encoding; OWL-Time supports instants, intervals, and durations; GeoSPARQL supports geospatial representation and querying; and PROV-O plus PAV cover derivation, attribution, authorship, curation, and versioning. citeturn19view10turn19view11turn19view6turn19view7turn19view0turn19view12