Executive Summary

Full report

On this page

This report outlines a prophecy-tracking knowledge graph design that rigorously models entities such as prophecies, prophets, sources, claims, events, locations, dates, interpretations, and reviewers. It defines attributes (e.g. ID, text, date, confidence, provenance, citations, tags) and relationship types (e.g. authored_by, cites, claims_about, predicts, contradicts, corroborates, reviewed_by, updated_to). We propose cardinalities (e.g. one Prophecy has one Prophet author; one Claim may involve many entities), required vs. optional fields, and versioning links between entity versions.

For ingestion, we recommend automated pipelines: scraping or OCR of primary texts (e.g. scanned manuscripts or news), APIs for social media, RSS feeds and academic databases. NLP tools (spaCy, Hugging Face transformers, AllenNLP) perform tokenization, coreference resolution, named-entity recognition, entity linking (e.g. to Wikidata/DBpedia), and relation/claim extraction. Temporal expressions are normalized to dates/times. Provenance metadata (source ID, timestamp, extractor version) is captured for every node.

We address contradiction and corroboration detection via multi-stage methods: rule-based checks (e.g. date conflicts), semantic similarity/embedding models, NLI classifiers, and knowledge-base cross-checks【40†L129-L137】【37†L48-L57】. For example, one pipeline uses spaCy+transformers to extract assertions, generates negations (rule-based), retrieves evidence, and uses GPT-3.5 to validate contradictions【37†L48-L57】【37†L60-L68】. We mark contradictions or corroborations with confidence scores to represent uncertainty, and set thresholds (e.g. only flag high-confidence conflicts by default).

A review workflow tracks each item’s status (e.g. unreviewed, under_review, verified, debunked, disputed). Reviewers (experts or crowdsourced) are modeled as nodes with roles, and each review action is logged (user ID, timestamp, notes) to provide a full audit trail. The UI should allow filtering by status, highlighting contradictory nodes, and showing provenance (original text and citations) to reviewers. Audit capabilities let admins see history of edits and version links for transparency.

For storage and querying, either a property-graph DB (e.g. Neo4j, JanusGraph) or RDF triplestore (e.g. GraphDB, Virtuoso) can be used. Property graphs (with Cypher queries) natively support arbitrary properties on nodes/edges; RDF/OWL allows ontology reasoning but can be verbose【49†L399-L407】【49†L420-L428】. We illustrate both: for example, a Cypher query like MATCH (p:Prophet)-[:AUTHORED_BY]->(pr:Prophecy) RETURN pr.title finds all prophecies by a given prophet, while an equivalent SPARQL triple pattern can do the same【51†L291-L300】【51†L308-L313】. The graph can be exported in JSON-LD or RDF formats for interoperability.

We discuss ethical, bias and legal issues: we must avoid defamatory or culturally insensitive claims (e.g. “prophecy X was false” about a living person can be defamatory), adhere to copyright (use public-domain or licensed texts, as ClaimsKG does with fact-checking sites【16†L38-L44】), and mitigate algorithmic bias. Cultural sensitivity is key when interpreting religious prophecies or elder traditions. We cite relevant ethics guidelines (e.g. on disinformation) to emphasize responsible design【25†L278-L284】.

Finally, we give a sample data model and example dataset with nodes and relationships (in table form) and sample queries with expected results. For instance, we show how a Prophecy node (text, date) by a Prophet node connects via a predicts edge to an Event, and how two Claim nodes can be linked by contradicts. We also list example Cypher/SPARQL queries (e.g. finding all claims about a given event) to illustrate graph analysis. Throughout, we cite tools and literature (spaCy, HuggingFace, AllenNLP, Tesseract, Neo4j) and suggest evaluation metrics: precision/recall/F1 for extraction and contradiction detection【56†L1-L4】.

【69†embed_image】 Figure: Example knowledge graph (entities and relationships). The ontology includes classes like Prophecy, Prophet, Claim, Event, etc., with attributes (ID, text, date, confidence) and relationships (e.g. a Prophecy predicts an Event, a Claim claims_about an Event). As in standard knowledge-graph design, unique IDs and provenance links are stored for each node【16†L25-L30】【20†L126-L134】.

Ontology / Schema

We propose the following main entity types and their attributes (cardinalities and required/optional fields in parentheses):

• Prophet: (nodes labeled Prophet in a property graph or class :Prophet in RDF). Attributes include id (unique identifier), name, birthDate, deathDate, biography. (Name is required; dates/biography optional.) A Prophet may author many Prophecies (one-to-many).
• Prophecy: A record of a predicted event. Attributes: id, title, text (the prophecy content), date (when the prophecy was made or recorded), language, confidence (numeric estimate of authenticity), provenance (source identifier), citations (list of references), tags. Required: text, date, prophet_id. Optional: others. Each Prophecy is authored_by exactly one Prophet. A Prophecy may be linked to multiple Claims extracted from it (or vice versa). Versioning: Prophecies can have an updated_to link to a revised version node to track edits.
• Text/Media Source: (e.g. a text document, news article, social post, video transcript). Attributes: id, title, text, media_type (e.g. “news”, “tweet”, “video transcript”), date_published, url, language, license. A Source can authored_by one or more people or organizations (modeled via an Author entity or just a name property). Sources cite other sources or contain one or more Prophecies or Claims. (For example, a news article might contain an excerpt of an older prophecy.)
• Claim: A factual assertion extracted from a Source or Prophecy. Attributes: id, text, confidence (from the extractor), date (when said/published), provenance, tags. A Claim may claim_about one or more Events, Topics, or Entities. Multiple claims can be extracted from a single Source. Claims often carry a truth value or rating (e.g. from fact-checkers), so a Claim node may be linked to a Rating or have a truthValue property (drawn from e.g. ClaimReview model【20†L126-L134】).
• Event: The actual or predicted event. Attributes: id, name, description, date (may be predicted date or actual date after the fact), location_id. Dates may be normalized to ISO format; uncertainty (e.g. year only) can be encoded as a separate field. Events can connect to Locations and to Claims that reference them.
• Location: Entities for places (city, country, etc). Attributes: id, name, coordinates. A Claim or Event may claims_about or occur at a Location.
• Date/Time: Optionally model complex dates (e.g. ranges). Could be literals or nodes (e.g. Date node with date property) depending on query needs.
• Interpretation: A node capturing an expert’s interpretation of a Prophecy. Attributes: id, text, confidence, reviewer_id. It links a Prophecy to how it was interpreted (e.g. “this predicts the election result”).
• Reviewer: People or organizations evaluating claims. Attributes: id, name, affiliation, role (fact-checker, editor). A Reviewer may be reviewed_by or debunks certain Claim or Prophecy nodes. (In RDF, Reviewer can be a subclass of Schema:Person.)

Relationships:

• authored_by: (Prophecy)-[:AUTHORED_BY]->(Prophet) (each prophecy has exactly one prophet). Similarly, a Source can have authored_by links to authors (people/orgs).
• predicts: (Prophecy)-[:PREDICTS]->(Event). One prophecy can predict multiple events (e.g. “two kings will come” = two events) and an event might be predicted by multiple prophecies (many-to-many).
• claims_about: (Claim)-[:CLAIMS_ABOUT]->(Event/Location/Topic). A claim often refers to one or more target events or entities.
• cites: (Claim)-[:CITES]->(Source) or (Source)-[:CITES]->(Source) (document citations). This links claims to their source documents, or links a prophecy to earlier texts it references.
• contradicts / corroborates: Binary relations between Claim or Prophecy nodes. For example, (ClaimA)-[:CONTRADICTS]->(ClaimB) means ClaimA negates ClaimB. These should be mutual or directional as needed, and can carry a confidence or certainty property. Likewise, (ClaimA)-[:CORROBORATES]->(ClaimB) for supporting claims. Cardinality: many-to-many (a claim can contradict many others).
• reviewed_by: (Entity)-[:REVIEWED_BY]->(Reviewer) where Entity could be a Claim or Prophecy. Each review action might create a node (Review) or just a timestamped property on the relationship. Status taxonomy (below) can be a property on the entity or review edge.
• updated_to: (EntityOld)-[:UPDATED_TO]->(EntityNew) linking one version of a Claim/Prophecy to its next version. This is typically one-to-one (version chain).

Schema considerations: The ontology may reuse Schema.org classes (e.g. ClaimReview, Claim, Rating) as in fact-checking datasets【20†L126-L134】. For instance, one can model a Claim as schema:Claim with author, datePublished, and link it to a ClaimReview. We should define which fields are required (e.g. every Claim must have text and a source, every Prophecy must have a prophet and date) and which are optional. Versioning can be handled by adding version numbers or by the updated_to edges. In RDF/OWL, we would declare classes (Prophecy, Claim, etc.) and properties (e.g. ex:predicts, ex:contradicts), with cardinality constraints. In a property graph (Neo4j), we enforce constraints through application logic or database schema (unique constraints on IDs, etc.).

Data Ingestion and Extraction

Data sources include primary prophetic texts (e.g. scriptures, books, recordings), media reports (news articles, transcripts, blog posts), social media content (tweets, videos), and academic papers. Ingestion methods: web scraping (RSS feeds, news APIs), crawling archives, social media APIs, and document processing (PDF/text ingestion). For physical or image-only documents, apply OCR (e.g. Tesseract) to extract text【54†L300-L309】.

Once text is obtained, an NLP pipeline extracts structured data:

• Preprocessing: Clean and normalize text (lowercasing, removing boilerplate).
• Coreference Resolution: Link pronouns to entities (using AllenNLP or spaCy coref models) so that references (“he”, “this”) correctly map to prophets or subjects【64†L279-L286】【58†L53-L62】.
• Named Entity Recognition (NER): Identify names of prophets, places, events, dates with spaCy or a transformer model. E.g. “Nostradamus” → Prophet, “Paris” → Location.
• Entity Linking: Map entities to knowledge bases (Wikidata/DBpedia) for disambiguation and external context (as in ClaimsKG linking to DBpedia)【16†L25-L30】.
• Temporal normalization: Convert relative date phrases (“next month”, “Year of the Dragon”) to absolute dates. Use libraries (HeidelTime, SUTime) or custom rules.
• Claim/Relation Extraction: Identify factual assertions. Tools like Hugging Face BERT models or spaCy rule-based extractors can isolate candidate claims【37†L48-L57】【58†L53-L62】. The “Claim Extraction” benchmark (FEVERFact dataset) uses generation or NER approaches to produce atomic claims【58†L53-L62】. Each extracted claim is turned into a Claim node with properties (text, date, source link) and connected to relevant entities.
• Interpretation tagging: If human analysts are involved, they may add Interpretation notes to Prophecy nodes, stored as text with confidence scores.
• Provenance capture: For every ingested item, record source metadata (source ID, fetch date, extractor version). This is stored as properties on the node or via a provenance edge to a Source node【16†L25-L30】【54†L300-L309】.

Finally, the extracted entities/claims are upserted into the graph: existing nodes are merged by unique ID or name, new nodes/edges created accordingly. This pipeline can be automated and scheduled (e.g. daily news ingestion), and retrained as new data arrives.

【66†embed_image】 Figure: Example information extraction pipeline. Text input goes through coreference resolution, entity linking, and relation extraction steps to populate the knowledge graph【64†L279-L286】【37†L48-L57】. In practice, we may use spaCy for NER, Hugging Face transformers for claim extraction, and Tesseract for OCR【37†L39-L45】【54†L300-L309】.

Contradiction and Corroboration Detection

Detecting contradictions among claims is crucial. We define a contradiction as one claim logically negating another. Algorithms include:

• Rule-based checks: Compare structured facts (dates, numbers). E.g., if Claim A predicts “2025” and Claim B says “2025 will not occur”, flag a contradiction.
• Embedding/NLI: Use sentence embeddings or Natural Language Inference models (e.g. a fine-tuned BERT) to classify claim pairs as contradictory, neutral, or entailment. For instance, models like “all-MiniLM-L6-v2-nli” on HuggingFace can score semantic contradiction【38†L0-L4】.
• Negation generation: As in one case study, generate explicit negations of assertions (rule-based or via prompting) and check if any actual statement matches it【37†L48-L57】.
• Evidence lookup: Retrieve external evidence (other claims or factual knowledge bases). If two claims conflict with authoritative data (e.g. timeline facts), mark as contradiction. This hybrid approach is advised by practitioners【40†L149-L157】【37†L60-L68】.
• Temporal consistency: Ensure that events referenced by multiple claims have coherent timelines (e.g. not a prophecy predicting an event before the prophecy was made).

Thresholds and uncertainty: Because these methods can err, we assign each contradicts or corroborates edge a confidence score. The system uses a high threshold for auto-flagging contradictions (favoring precision) and routes ambiguous pairs for human review【40†L147-L155】. For example, a contradiction classifier might have high precision but lower recall (so flagged contradictions are reliable but some conflicts may be missed)【56†L1-L4】. We explicitly record that uncertainty (e.g. an edge property confidence=0.92). Corroboration (supporting evidence) is similarly tracked.

Graph representation: Contradiction/corroboration edges link two Claim (or Prophecy) nodes. We might also log which pieces of text led to the conflict, as metadata or via separate “Explanation” nodes, to make the graph explainable. As RedBuffer’s pipeline noted, structuring negations and linking evidence provides an audit trail for reviewers【37†L48-L57】【37†L60-L68】.

Review Workflow and Status

Each claim or prophecy node carries a review status property. Proposed statuses:

• unreviewed (newly ingested),
• under_review (assigned to a reviewer),
• verified (confirmed true or likely true),
• debunked (determined false),
• disputed (conflicting evaluations exist).

A Review action is modeled by linking the entity to a Reviewer node: (Claim)-[:REVIEWED_BY {date, status}]->(Reviewer). The Reviewer (a Person) node has role = “fact-checker” or similar. All status changes are timestamped. This audit trail ensures transparency: we know who reviewed what and when.

Reviewer roles can be tiered (e.g. volunteer, editor, expert). Workflows should support delegation: an under_review claim may be picked up by any qualified reviewer. UI considerations: interfaces should allow searching/filtering by status, displaying provenance text and any contradictory edges, and capturing reviewer notes. We should offer explainable views (highlighting terms that triggered contradictions) and history logs. High-severity items (e.g. possibly defamatory claims) could be auto-flagged for senior review.

This mirrors fact-check systems where each claim has a “claim review” entry (e.g. Schema.org ClaimReview with a reviewRating【20†L126-L134】). We adapt that idea to our internal workflow taxonomy, ensuring consistency and traceability at every step.

Storage and Query

Graph database choice: A property graph (Neo4j, JanusGraph) is intuitive and performant for many-to-many relations【49†L399-L407】【49†L420-L428】. Neo4j, for example, can enforce uniqueness on node IDs and offers Cypher for queries. Alternative: an RDF triplestore (Virtuoso, GraphDB) with an OWL ontology for reasoning. RDF enables standard exports (RDF/XML, Turtle, JSON-LD) and SPARQL querying but can be verbose (e.g. reifying multi-valued edges). Neo4j now also supports GQL/ISO standard queries【49†L399-L407】.

Schema example (property graph): We might define labels/properties like:

• (p:Prophet {id, name, birthDate}), (prop:Prophecy {id, text, date, language}), (e:Event {id, name, date}) etc.
• Edges: (prop)-[:AUTHORED_BY]->(p), (prop)-[:PREDICTS]->(e), (c:Claim)-[:CLAIMS_ABOUT]->(e), (c1)-[:CONTRADICTS {confidence}]->(c2), (c)-[:REVIEWED_BY {status}]->(r:Reviewer).

Sample Cypher queries:

// Find all prophecies by a given prophet
MATCH (p:Prophet {name:"Nostradamus"})<-[:AUTHORED_BY]-(pr:Prophecy)
RETURN pr.title, pr.date;

// Find claims about event "World War III"
MATCH (c:Claim)-[:CLAIMS_ABOUT]->(e:Event {name:"World War III"})
RETURN c.text, c.date;

// List contradictions involving a specific claim
MATCH (c:Claim {id: "C1"})-[r:CONTRADICTS]-(other:Claim)
RETURN other.id AS conflictingClaim, r.confidence;

Sample SPARQL queries (RDF):

PREFIX ex: <http://example.org/>
SELECT ?prophecyText WHERE {
  ?prophecy a ex:Prophecy;
            ex:authoredBy ex:Nostradamus;
            ex:text ?prophecyText.
}

PREFIX ex: <http://example.org/>
SELECT ?claim ?rating WHERE {
  ?claim a ex:Claim;
         ex:claimsAbout ?event;
         ex:text ?claim.
  ?event ex:name "Apollo Moon Landing".
  ?claim ex:truthValue ?rating.
}

Query results can be returned in tabular form or as JSON. We can export subgraphs in JSON-LD (with a @context mapping our classes/props to IRIs) or RDF (Turtle, RDF/XML). Neo4j supports exporting to JSON/CSV; triplestores natively output RDF.

【51†L291-L300】【51†L308-L313】 demonstrate how a Cypher pattern has an equivalent SPARQL triple pattern, emphasizing flexibility: property graphs use pattern-matching (Cypher), while RDF allows more logical reasoning through SPARQL. For our use, Cypher’s straightforward graph traversals may suffice, but RDF/OWL could allow adding inference rules (e.g. transitive closure of “predicts” over events). Either way, standards like JSON-LD ensure interoperability.

Ethics, Bias, and Legal Considerations

We must handle content responsibly. Defamation: Labeling a real person’s prophecy as false could be defamatory. We must clearly mark unverified or disputed claims and possibly restrict sensitive claims (e.g. “Prophet X said negative things about Living Person Y”). Legal advice suggests caution: evidence and provenance must be cited for any negative verdict to avoid libel【25†L278-L284】. We can implement notice-and-takedown or allow individuals to contest misrepresented claims.

Copyright: Many sources (news articles, books) are under copyright. Our ingestion must respect licenses: use open data when possible, request permission, or use minimal quotes under fair use. The ClaimsKG project notes they “ensure data alignment with copyright restrictions” of fact-check sites【16†L38-L44】. We should similarly record source licenses and only store extracts quoted under fair use. Non-text media (images, videos) likewise require caution.

Cultural sensitivity: Prophecies often involve religious/cultural contexts. We must avoid bias or misinterpretation that offends. For example, labeling an interpretation as “false prophecy” could upset communities. The system should allow context (e.g. “according to critics” vs. factual assertion). Cultural sensitivity guidelines (e.g. avoiding unfounded claims about a cultural figure) should be encoded as review criteria.

Algorithmic bias: NLP models may misrecognize names or events in non-Western languages. We should use multilingual models (spaCy supports many languages, Tesseract has 100+ languages【54†L307-L314】) and include diverse training data. Audit outputs for demographic or ideological bias. Also, mention from AI ethics guidance: do not spread disinformation and safeguard sensitive info【25†L278-L284】. We should enable user feedback/corrections to mitigate errors.

Overall, we adhere to ethical AI principles: transparency (citing sources), accountability (audit trail), privacy (no sensitive personal data beyond public figures), and fairness (review by diverse panel).

Sample Data Model and Example Queries

Sample graph data (nodes and relationships): The table below illustrates a toy dataset.

In words: Prophet P1 authored prophecy PR1 predicting event E1. Claim C1 (from a source) contradicts Claim C2. Reviewer R1 has marked C1 as “debunked”.

Sample queries and results:

Cypher:

• Query: Find all prophecies by “John of Ararat”:

  MATCH (p:Prophet {name:"John of Ararat"})<-[:AUTHORED_BY]-(pr:Prophecy)
  RETURN pr.id AS prophecyID, pr.title, pr.date;

Expected Result: (prophecyID:"PR1", title:"Dark Eclipse", date:"0925-08-21").

Cypher:

• Query: List claims about the Solar Eclipse of 925:

  MATCH (c:Claim)-[:CLAIMS_ABOUT]->(e:Event {name:"Solar Eclipse of 925"})
  RETURN c.id AS claimID, c.text, c.confidence;

Expected:

  (claimID:"C1", text:"Eclipse will span three days", confidence:0.8)
  (claimID:"C2", text:"It will last only hours", confidence:0.7)

Cypher:

• Query: Find contradictions for Claim C1:

  MATCH (c:Claim {id:"C1"})-[r:CONTRADICTS]-(other:Claim)
  RETURN other.id AS conflictID, r.confidence;

Expected: (conflictID:"C2", confidence:0.9).

• Query: Which reviewer debunked C1?

  MATCH (c:Claim {id:"C1"})-[r:REVIEWED_BY]->(rev:Reviewer)
  RETURN rev.name AS reviewer, r.status, r.date;

Expected: (reviewer:"Dr. A. Scholar", status:"debunked", date:"0925-09-16").

The equivalent SPARQL for the first query (in RDF) is:

SELECT ?prophecyID ?title WHERE {
  ?p ex:name "John of Ararat" .
  ?pr a ex:Prophecy; ex:authoredBy ?p; ex:title ?title; ex:id ?prophecyID.
}

These examples illustrate node/edge types and typical graph queries. They show how the schema and relationships work together.

Tools and Evaluation

Representative tools and libraries can implement this system. For NLP extraction, we can use spaCy (industrial-strength NLP: tokenization, NER, dependency parsing【37†L48-L57】), Hugging Face Transformers (fine-tuned models for claim extraction【58†L53-L62】 and contradiction classification【37†L48-L57】), and AllenNLP (for coreference and SRL). For OCR of scanned text/images, Tesseract (via pytesseract) reliably extracts multi-language text【54†L300-L309】. Entity linking can use open-source tools (e.g. DBpedia Spotlight, spaCy Linker).

Graph storage examples: Neo4j is a popular choice (ACID, Cypher)【49†L399-L407】【49†L420-L428】; JanusGraph or Amazon Neptune are scalable alternatives. For RDF/OWL, Apache Jena or GraphDB could be used (with SPARQL queries).

Evaluation metrics:

• For information extraction (entities, claims), standard metrics are Precision, Recall, F1 against a gold standard. Ullrich et al. propose specialized metrics for claim extraction: Atomicity, Fluency, Faithfulness, etc., to ensure extracted claims are factual and self-contained【58†L53-L62】. We should evaluate both the correctness of extracted triples and the quality of claim text.
• For contradiction detection, we use classification metrics (accuracy, precision, recall, F1) on labeled contradiction pairs【56†L1-L4】. Because false positives are costly (mislabeling true claims as false), emphasis may be on high precision. Human-in-the-loop evaluation will further ensure reliability. Metrics like area under ROC or confusion matrices can help tune thresholds.

In sum, our design combines proven knowledge-graph modeling with modern NLP fact-checking techniques. By rigorously tracking provenance and review status, and by providing clear schema and queries, we enable reliable analysis of prophecies and their real-world outcomes.

Sources: Authoritative proposals like the Schema.org ClaimReview model inform our schema【20†L126-L134】, and recent fact-checking KGs (e.g. ClaimsKG【16†L25-L30】) inspire extraction pipelines. The Neo4j and research literature guide best practices in graph storage and contradiction detection【49†L399-L407】【37†L48-L57】【40†L129-L137】. Tools like spaCy, Transformers, AllenNLP, Tesseract and Neo4j are explicitly cited as representative components, while key evaluation literature provides recommended metrics【58†L53-L62】【56†L1-L4】. This report integrates those insights into a comprehensive blueprint for a prophecy-tracking knowledge graph.