Prophecy Tracking Knowledge Graph Design - Source Excerpt 03 - Temporal and geospatial normalization

Back to Prophecy Tracking Knowledge Graph Design

Summary

This source excerpt begins near Temporal and geospatial normalization 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 general linguistic preprocessing, toolkits such as Stanford CoreNLP remain useful because they bundle tokenization, sentence splitting, parsing, named entities, and coreference into a consistent processing framework. For relation extraction, DocRED is still a relevant benchmark because it explicitly addresses multi-sentence relations in plain text. For cross-document event assembly, recent work on CDEE pipelines is especially relevant to the prophecy domain because it decomposes the task into event extraction, coreference resolution, entity normalization, role normalization, and entity-role resolution across many documents. citeturn21view6turn21view7turn23view4

Claim normalization should convert each extracted proposition into a slot-based representation such as:

`subject | predicate | object | polarity | modality | time interval | place | quantity | source anchor`

That form makes downstream contradiction checks tractable and separates **wording variance** from **semantic variance**. A passage like “the city shall fall” can remain as a `ProphecyStatement`, while its normalized `PredictionClaim` becomes something like `CityX FALL polarity=positive time=uncertain`. This normal form is an implementation recommendation derived from the strengths and limitations of relation extraction, event extraction, and contradiction detection research. citeturn21view7turn23view4turn22view0turn32view0

### Temporal and geospatial normalization

Temporal normalization should use explicit intervals, not only single dates. OWL-Time provides a vocabulary for instants, intervals, durations, and ordering relations, while HeidelTime and TempEval remain practical references for extracting and normalizing temporal expressions. For prophecy corpora, many references will be partial or uncertain, so the model should support `not_before`, `not_after`, `earliest_possible`, `latest_possible`, and calendar/source qualifiers rather than coercing everything into ISO dates. citeturn19view6turn21view8turn21view18

Place normalization should similarly separate mention strings from canonical places. GeoSPARQL supports geospatial RDF representation and query, GeoNames provides a practical modern gazetteer API, and historical or sacred corpora often require ancient-place resources such as Pleiades. This means a prophecy claim should typically store both the raw place mention and the resolved gazetteer ID, with uncertainty when matching is weak. citeturn19view7turn21view3turn33search0

### Handling ambiguity, metaphor, and translation

Figurative or ambiguous language should not be flattened into literal event claims too early. Metaphor detection research shows that contextual word meaning often diverges from basic meaning, and hedge detection research shows that uncertainty cues remain lexically important and domain-sensitive. In system terms, when a passage is metaphor-heavy, hedged, or strongly interpretive, the graph should create an `InterpretationClaim` or `AmbiguousClaim` and route it to review instead of auto-promoting it to a high-confidence `PredictionClaim`. citeturn22view1turn22view2

Translation should also be modeled explicitly. Each translation or edition should be a `TextExpression` linked to a `TextWork`, with its own `language`, translator metadata, and provenance. Use BCP 47 language tags for normalized storage even if the ingest source originally uses ISO or MARC codes. Preserving the expression layer matters because contradictions can arise from translation choices rather than from the source text itself. citeturn19view11turn19view10

## Contradiction Detection

### Formal definitions

The graph should distinguish at least three different conflict types.

A **strict contradiction** exists when two normalized claims refer to the same subject and predicate, are aligned in relevant qualifiers such as time and place, and assert mutually exclusive values or polarities. In NLI terms, this is the case where the hypothesis cannot be true if the premise is true. citeturn23view3

A **qualified contradiction** exists when the claims overlap only partially: for example, they align on subject and event frame but conflict on a date range, quantity, or location. These are common in prophecy interpretation because one commentator may identify an event correctly but disagree on chronology or geography. SHACL-style validation and slot comparison are effective for surfacing those structured inconsistencies. citeturn25view0turn25view1

A **competing reinterpretation** exists when two claims map the same prophecy statement to different referents but are not formally contradictory at the proposition level. This distinction is necessary because the dataset should respect the difference between “these cannot both be true” and “these are rival interpretive traditions.” The need for this distinction is reinforced by the documented difficulty of holistic contradiction detection in long documents and by the brittleness of general NLI systems. citeturn22view0turn32view0

### Algorithmic approach

The best-performing design in this domain is a **three-stage contradiction pipeline**.

The first stage is **candidate generation**. Use lexical filters, shared entity IDs, overlapping time spans, shared prophecy statement anchors, and sentence embeddings such as SBERT to find potentially related claim pairs. Embedding retrieval greatly reduces the search space in large corpora where exhaustive pairwise comparison is infeasible. citeturn21view11

The second stage is **symbolic and structural checking**. This layer uses normalized claim slots to detect negation conflicts, quantity mismatches, incompatible dates, non-overlapping temporal windows, and location exclusivity. In RDF stacks, these checks can be implemented with SHACL shapes, SPARQL constraints, or rule layers; in property graphs, they map well to Cypher pattern matching plus post-processing. SHACL is particularly useful because it formalizes validation against shapes graphs and returns validation reports with result objects, focus nodes, and conformance state. citeturn25view0turn25view1turn19view2turn34view1

The third stage is **semantic contradiction scoring**. Here, a supervised NLI-style model scores whether two claim texts or canonical forms stand in entailment, contradiction, or neutral relation. Use NLI only after candidate generation and structural alignment, not as a standalone oracle. The reason is empirical: NLI datasets such as SNLI, MultiNLI, and FEVER are valuable training resources, but research also shows that strong benchmark performance can mask brittle reasoning and shallow heuristics. Document-level contradiction work likewise shows that contradiction detection in long contexts remains difficult. citeturn21view12turn21view13turn21view10turn37view0turn22view0

A practical scoring formula is:

`contradiction_score = w1*structural_conflict + w2*nli_contradiction + w3*entity_alignment + w4*temporal_overlap + w5*source_reliability_adjustment`

That formula is a recommended implementation pattern rather than a published standard. Its chief virtue is transparency: reviewers can see whether a contradiction was driven by logic, semantics, or metadata alignment.

### Thresholds, partial matches, and reinterpretations

There is no defensible universal contradiction threshold. Calibration research shows that modern neural models are often poorly calibrated, and temperature scaling remains a strong general-purpose calibration method. For that reason, thresholds should be tuned on an internal gold set and tracked by version. citeturn32view0

A sensible operational policy is to use **banded thresholds** rather than one hard cutoff:

| Score band | Recommended action |
|---|---|
| `< 0.35` | treat as non-contradictory unless reviewer flags |
| `0.35 – 0.65` | mark as possible conflict; queue if claim is high-impact |
| `0.65 – 0.85` | mark as probable contradiction; require one reviewer |
| `> 0.85` | mark as strong contradiction only if structural alignment also passes |

Those bands are implementation guidance, not literature-derived constants. Their purpose is to reduce unreviewed hard claims from brittle NLI outputs.

For **partial matches**, compare facets independently: entity alignment, predicate alignment, time overlap, place overlap, quantity compatibility, and modality compatibility. If the semantic core aligns but a single facet conflicts, store that as a partial contradiction with explicit facet labels such as `time_conflict` or `quantity_conflict`. If the referent shifts entirely, use `COMPETES_WITH` or `REINTERPRETS` rather than `CONTRADICTS`. That design reduces reviewer confusion and better reflects the semantic structure of prophetic interpretation. This recommendation is supported by the difficulty of long-document contradiction detection and by cross-document event normalization research. citeturn22view0turn23view4