Building A Prophecy Tracking Knowledge Graph Entities, Claims, Sources, Contradictions, And Review Status 2 - Source Excerpt 01 - Executive Summary
Summary
This source excerpt begins near Executive Summary and preserves the surrounding evidence from Antichrist.net/agent-file-handoff/Archive/2026-05-12-content-reports/Building a prophecy tracking knowledge graph entities, claims, sources, contradictions, and review status 2.md.
**Source path:** Antichrist.net/agent-file-handoff/Archive/2026-05-12-content-reports/Building a prophecy tracking knowledge graph entities, claims, sources, contradictions, and review status 2.md
# Executive Summary
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**: