Data Schema - Harivulagam Knowledge Base

Data Schema — Harivulagam Knowledge Base

1. Purpose

This schema defines how every piece of content on Harivulagam is structured, stored, and linked. It ensures that:

• The wiki can store neutral knowledge entries
• The concept map can visualize entries and connections
• The main site can link to entries and display connection articles
• Search and filtering work consistently across all views
• Data can be exported for backup or migration

The schema is designed to be simple enough to implement in a wiki (MediaWiki with Semantic MediaWiki, or Wiki.js with a database) and flexible enough to grow.

---

2. Core Entities

The system has four core entities:

Entity	What it represents	Where it lives
Entry	A single knowledge item, connection article, or witness record	Wiki, main site
Connection	A labeled link between two entries	Stored as data, rendered on map
Pillar	One of the six top-level categories	Fixed taxonomy
Tag	A flexible label for filtering and discovery	Attached to entries

---

3. Entry Schema

Every entry — whether a knowledge item, a connection article, or a witness record — shares the same core fields.

3.1 Core Fields

Field	Type	Required	Description
id	string	Yes	Unique identifier (e.g., lokayata, my-story-mystery)
title	string	Yes	Display title
type	enum	Yes	knowledge, connection, witness, framework
pillar	enum	Yes	One of the six pillars (see Section 5)
summary	text	Yes	One or two sentences for map and search results
body	text	Yes	Full content (wiki markup or HTML)
sources	array	No	List of references (see Section 3.4)
created	date	Yes	Date the entry was created
updated	date	Yes	Date of last edit
status	enum	Yes	stub, draft, complete, disputed
language	string	Yes	Primary language (e.g., en, ta, hi)
tags	array	No	Free-form tags for filtering
connections	array	No	IDs of connected entries (see Section 4)
ai_assisted	boolean	Yes	Whether AI was used in drafting (default: false)
ai_note	text	No	Description of AI involvement, if any

3.2 Type-Specific Fields

For knowledge entries:

Field	Type	Description
period	string	Historical period (e.g., "Gupta Empire, 4th–6th century CE")
region	string	Geographic region (e.g., "South India", "Global")
primary_sources	array	Primary texts or documents referenced

For connection entries (main site articles):

Field	Type	Description
connection_summary	text	One sentence describing what the article connects
linked_entries	array	IDs of knowledge entries the article connects
connection_types	array	Which types of connection are made (see Section 4)
author	string	Author name (default: site owner)

For witness entries (dream insights):

Field	Type	Description
received_date	date	When the insight was received
received_context	text	Circumstances of reception (e.g., "during sleep", "in meditation")
original_text	text	The insight as received, unedited
interpretation	text	Later interpretation, clearly separated
witness_id	string	Persistent pseudonym for the receiver

For framework entries (synthesis):

Field	Type	Description
framework_type	string	e.g., "Three Worlds", "Three Bodies", "Connection Types"
used_by	array	IDs of entries that reference this framework

3.3 Status Values

Status	Meaning
stub	Short entry, needs expansion
draft	In progress, not yet reviewed
complete	Reviewed and considered finished
disputed	Content is contested; see talk page or dispute section

3.4 Source Schema

Each source in the sources array has this structure:

Field	Type	Description
citation	string	Full citation (author, title, year, publisher)
url	string	Link to source, if available
type	enum	primary, secondary, tertiary, oral
accessed	date	Date accessed (for online sources)

---

4. Connection Schema

Connections are the heart of the system. They are stored separately from entries, so they can be queried, visualized, and filtered.

4.1 Connection Fields

Field	Type	Required	Description
id	string	Yes	Unique identifier
from_entry	string	Yes	ID of the source entry
to_entry	string	Yes	ID of the target entry
type	enum	Yes	historical, structural, intuitive
label	string	No	Short description of the connection
evidence	text	No	Explanation or evidence for the connection
sources	array	No	References supporting the connection
created	date	Yes	Date the connection was added
created_by	string	Yes	Contributor who added it
status	enum	Yes	proposed, accepted, disputed

4.2 Connection Types

Type	Tag	Meaning	Line style on map
historical	#Historical Influence	Documented transmission — A influenced B	Solid, dark blue
structural	#Structural Resonance	Similar pattern, no proven contact	Dashed, teal
intuitive	#Intuitive Connection	Personal insight	Dotted, amber

4.3 Connection Rules

• A connection must link two existing entries.
• The type must be one of the three defined values.
• If type is historical, at least one source must support it.
• If type is intuitive, the created_by field must identify the person whose intuition it is.
• Connections are never deleted. If a connection is found to be invalid, its status is changed to disputed and the reason is recorded.

---

5. Pillar Taxonomy

The six pillars are a fixed taxonomy. Entries must belong to one primary pillar, and may be cross-referenced to others.

Pillar ID	Display Name	Color
epics	Epics & Scriptures	Deep saffron
science	Science & Quantum	Indigo
siddhas	Siddhas & Lineages	Forest green
dreams	Dream Insights	Soft violet
history	Historical Events	Warm brown
synthesis	Synthesis	Teal

---

6. Tag Schema

Tags are free-form but should follow these conventions:

Tag type	Format	Example
Pillar tag	pillar:<id>	pillar:science
Connection tag	conn:<type>	conn:structural
Status tag	status:<value>	status:stub
Topic tag	Free-form, lowercase, hyphenated	quantum-entanglement, tamil-literature
Era tag	era:<period>	era:gupta, era:modern

Tags are used for filtering in search and on the concept map.

---

7. Relationship to Wiki and Main Site

Platform	What it stores	How it uses the schema
Wiki	knowledge and framework entries	Full body text, sources, connections
Main site	connection articles, witness records	Full article text, linked entries, connection types
Concept map	Read-only view of all entries and connections	Uses summary, pillar, connections, type

The schema is the source of truth. The wiki and main site are two views of the same data. The concept map is a third view.

---

8. Export and Interoperability

To avoid lock-in and enable future migration:

• All entries and connections can be exported as JSON or CSV.
• The schema is documented and versioned.
• Wiki content can be exported as MediaWiki XML for portability.
• Connection data can be exported as JSON-LD or RDF for semantic web use.

This ensures that the knowledge base can outlive any single platform or tool.

---

9. Example Entry (JSON)

json

{
  "id": "lokayata",
  "title": "Lokāyata (Cārvāka)",
  "type": "knowledge",
  "pillar": "history",
  "summary": "An ancient Indian materialist school that rejected Vedic authority, the afterlife, and the soul. Its original texts are largely lost, known only through citations by its opponents.",
  "body": "...",
  "sources": [
    {
      "citation": "Bhattacharya, Ramkrishna. Studies on the Cārvāka/Lokāyata. 2011.",
      "type": "secondary"
    }
  ],
  "created": "2026-09-28",
  "updated": "2026-09-28",
  "status": "complete",
  "language": "en",
  "tags": ["pillar:history", "era:ancient", "materialism"],
  "connections": ["gupta-empire", "sanskrit-history", "apaurusheyatva"],
  "ai_assisted": false
}

10. Example Connection (JSON)

json

{
  "id": "conn-001",
  "from_entry": "lokayata",
  "to_entry": "quantum-mechanics",
  "type": "structural",
  "label": "Both challenge the assumption of a fixed, observer-independent reality",
  "evidence": "Lokāyata holds that only perception is reliable; quantum mechanics shows that measurement affects outcome. The parallel is structural, not historical.",
  "sources": [],
  "created": "2026-09-28",
  "created_by": "site-owner",
  "status": "proposed"
}

---

11. Implementation Notes

• If using MediaWiki: Install Semantic MediaWiki and define the schema as semantic properties. This gives you query, export, and map integration.
• If using Wiki.js: Use the built-in database and define the schema with custom fields or a linked database.
• If using a custom solution: Store the schema in a relational database (PostgreSQL or SQLite) with tables for entries, connections, pillars, and tags.

The schema is designed to work with any of these approaches.