Knowledge Graph Strategy For LLMWikis

LLMWikis.org is currently best understood as a **public handbook and operating pattern for LLM Wikis**, not as a public knowledge-graph service. Its public homepage, architecture, operations, schema, trust, and discov...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-fd514a7d/
Source reference	raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-06/Improvement/knowledge-graphs/Knowledge Graph Strategy for LLMWikis.org.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-06T14:48:17.7434007Z
Content hash	sha256:fd514a7d4c5c2c98a5399eaec9340fad4f36104b906c87a56114263cd714da9a
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-06-imp-fd514a7d4c5c.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-06-imp-fd514a7d4c5c.txt

Current File Content

Structure Preview

• Knowledge Graph Strategy for LLMWikis.org
• Executive Summary
• Current State of LLMWikis.org
• Public-state snapshot
• Assumptions used in this report
• Design Principles for a LLM Wikis Knowledge Graph
• Recommended semantic core
• Standards stack
• Provenance and versioning
• Multilingual support
• Construction Pipelines
• Deterministic extraction from existing wiki content
• Semi-structured import from external public sources
• NLP and LLM extraction from prose
• Human curation
• Extraction method trade-offs
• Integration Architectures and Tooling
• Architecture trade-offs
• Tool and platform comparison
• Recommended platform posture
• Governance, Licensing, Trust, and Evaluation
• Licensing and rights
• Trust, references, and moderation
• Privacy and abuse surfaces

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 43959
• Preview characters: 11981

# Knowledge Graph Strategy for LLMWikis.org

## Executive Summary

LLMWikis.org is currently best understood as a **public handbook and operating pattern for LLM Wikis**, not as a public knowledge-graph service. Its public homepage, architecture, operations, schema, trust, and discovery files describe a reviewed, source-aware, human-readable knowledge system built around immutable raw sources, compiled wiki pages, and agent instructions; the site explicitly says it does **not** currently claim open editing, live benchmarks, a public MCP surface, certification, or multilingual support. The practical implication is that LLMWikis should **not** begin by “turning the site into a graph database.” It should begin by building a **derived, read-only knowledge graph layer** over its existing public handbook and source traces, while preserving markdown pages and logs as the canonical editorial surface. citeturn1view0turn32view0turn32view1turn32view2turn2view0turn4view0

The strongest strategic design for LLMWikis is a **hybrid architecture**: human-readable wiki pages remain the source-facing experience; a semantic layer captures pages, claims, sources, entities, contradictions, reviews, and releases; and retrieval combines lexical search, vectors, and graph traversal. This fits both the LLM Wiki pattern described by Andrej Karpathy and LLMWikis’ own guidance that explicit indexes, logs, typed links, and staged review should remain central even if vectors or graph databases are added later. citeturn35view0turn32view0turn32view1turn2view0

For schema and ontology, the best practice is to **reuse standards where possible** rather than inventing a bespoke ontology from scratch. RDF provides the base graph model; OWL provides formal semantics; SHACL validates shape constraints; PROV-O handles provenance; SKOS helps with topic hierarchies and multilingual labels; JSON-LD is the best web-native serialization; DCAT helps publish dataset metadata; DQV helps publish quality metadata; and BCP 47 language tags support multilingual labels. For LLMWikis specifically, these standards should be mapped onto site-native concepts such as `source_trace`, `status`, `last_reviewed`, `contradictions`, `owner`, `agent_use`, `review_cycle`, and `index.md`/`log.md`. citeturn9search0turn9search1turn9search2turn9search3turn10search0turn10search1turn10search3turn10search6turn21search2turn3view0turn3view1turn33view0

For knowledge-graph construction, LLMWikis should use a **three-track ingest model**. The first track is deterministic extraction from existing wiki pages and frontmatter. The second is semi-structured import from external public sources such as Schema.org / JSON-LD, Wikidata / Wikibase, and DBpedia-like mappings. The third is NLP/LLM extraction from prose using NER, entity linking, relation extraction, and human review. The key operational rule should follow LLMWikis’ own two-step ingest guidance: analyze first, stage changes, review risky claims, then write and lint. citeturn32view2turn33view0turn14search2turn14search18turn14search0turn14search1turn12search2turn13search4turn12search1

For LLM integration, pure vector-only RAG is not enough. Classical RAG improves factuality and updateability by introducing non-parametric memory, but GraphRAG-style systems show strong value when users ask broad, cross-document, “global” questions. A LLMWikis strategic stack should therefore support: lexical search for exact routes and terms, vector search for semantic recall, graph traversal for entity/claim neighborhood expansion, and optional hierarchical community summaries for corpus-level synthesis. citeturn15search0turn15search2turn24search2turn24search3turn24search16turn19search15turn19search3

The recommended rollout is phased. The first pilot should be a **handbook claim graph** over the current public site, with pages, sources, claims, typed links, contradictions, and review metadata. The second should add **hybrid retrieval and citation-backed answering**. The third should link out to external IDs and publish machine-readable JSON-LD/RDF releases. More ambitious work—public APIs, live benchmarks, or multilingual expansion—should wait until provenance completeness, rights handling, and moderation workflows are operational. citeturn1view0turn4view0turn32view2turn3view2

## Current State of LLMWikis.org

The public evidence reviewed on May 6, 2026 shows that LLMWikis.org presents itself as “the practical standard for building LLM Wikis,” with top-level routes for Start, Build, Template, Architecture, Operations, Governance, Agents, and Explore. The homepage describes the system as a durable, trust-labeled, citable, retrieval-ready knowledge system built from raw sources, reviewed wiki pages, and agent-readable instructions, and it prominently exposes discovery files such as `llms.txt`, `robots.txt`, `sitemap.xml`, and a starter bundle. citeturn1view0turn4view0

The site’s public content is strongest on **process and governance**. Public pages already specify metadata fields such as `owner`, `status`, `last_reviewed`, `review_cycle`, `sensitivity`, `agent_use`, and `related`; trust labels such as authoritative, working-draft, historical, deprecated, and external-reference; graph-navigation concepts such as typed links, contradiction maps, cluster maps, `index.md`, and `log.md`; and a two-step ingest process built around hashing, analysis, staging, review, write, and lint. In effect, the handbook already contains the seed of a knowledge graph, even though it is exposed chiefly as human-readable content. citeturn3view0turn3view1turn2view0turn32view2turn33view0

The public evidence also defines important **boundaries**. The homepage says the site does **not** currently claim open editing, live benchmark integrations, a public MCP server, UAIX certification, or multilingual coverage. The two-step ingest page also says the site is a runbook rather than a live ingestion product and does not currently provide automated arXiv ingestion, public MCP access, hosted file processing, or anonymous public editing. `llms.txt` enumerates route families such as reports, standards, model registry, evaluation hub, editorial standards, content-quality metrics, community, and roadmap, but the public handbook positioning remains that of a guidance and reference layer rather than an exposed graph service. citeturn1view0turn32view2turn4view0

That makes the strategic reading fairly clear: **LLMWikis.org already has graph-shaped information architecture, but not yet a publicly declared graph product**. The right next move is not to replace the handbook with a KG, but to formalize the semantic structures already implied by page metadata, source traces, logs, typed links, and contradiction records. This is an inference from the public material rather than a stated site roadmap, but it follows directly from the handbook’s own invariants and evidence boundaries. citeturn32view0turn32view1turn2view0turn33view0

### Public-state snapshot

| Public evidence | What is publicly specified | Strategic implication |
|---|---|---|
| Homepage and route map | Public handbook, starter bundle, discovery files, build/govern/agents pages. citeturn1view0turn4view0 | The site already exposes enough structured editorial metadata to derive a first graph. |
| Metadata and trust model | Owner, status, review cycle, sensitivity, agent permissions, trust labels. citeturn3view0turn3view1 | A KG should ingest these fields as first-class governance attributes, not as prose. |
| Page schema and ingest runbook | `source_trace`, contradictions, freshness, staged review, lint. citeturn32view2turn33view0 | Claim-level provenance and contradiction modeling should be part of the first pilot. |
| Graph navigation page | Hub pages, typed links, contradiction maps, cluster maps, hybrid search boundary. citeturn2view0 | Vectors should augment—not replace—page indexes, hubs, and typed edges. |
| Not-claimed features | No open editing, multilingual support, public MCP, live benchmarks, hosted ingestion. citeturn1view0turn32view2 | Initial rollout should be read-only and controlled, with internal review gates. |
| `llms.txt` route inventory | Reports, standards, model registry, evaluation hub, metrics dashboard, roadmap, community. citeturn4view0 | There is enough public topology to design graph entities and route classes now, even if content depth varies by section. |

### Assumptions used in this report

The roadmap and resource estimates below are **assumption-based**, because public pages reviewed here do not state corpus volume, budget, staffing, update frequency, or a public machine-readable data release plan.

| Assumption | Working value used in this report |
|---|---|
| Scope | Public-information KG for LLMWikis.org only, with later optional federation to UAIX and allied sites |
| Corpus size for pilot | Roughly 2,500–10,000 pages/chunks and low millions of derived triples/edges |
| Budget posture | Moderate; able to fund a focused 6–9 month pilot |
| Governance posture | Review-first, no anonymous public writes, source-cited outputs only |
| User promise | Public answers should expose citations, freshness, and trust status |

## Design Principles for a LLM Wikis Knowledge Graph

A rigorous LLM Wikis KG should begin with **competency questions** rather than tables and triples. Ontology engineering guidance has long argued that developers should first determine domain, scope, intended uses, and the kinds of questions the ontology must answer. For LLMWikis, those questions are concrete: *What does this page claim? What source supports it? What contradicts it? When was it last reviewed? Which route owns current truth on this topic? Which entities, protocols, models, tools, or benchmark pages are linked to this claim?* citeturn38search0turn32view0turn32view1turn33view0

The defining architectural rule should be **canonical editorial surface, derived semantic layer**. LLMWikis’ own architecture says raw sources should remain immutable, the wiki layer should change, and the schema should control how the agent changes it. The graph-navigation guidance explicitly warns that vector search can help a large wiki but should not replace the human-readable index, log, hubs, and typed links. Therefore, the KG should be treated as a **projection** of reviewed sources and pages, not as the only source of truth. citeturn32view0turn2view0turn35view0

A practical model for LLMWikis is a **four-layer stack**. The first three layers already exist in public form: `raw/`, `wiki/`, and the schema file. The fourth layer should be a derived semantic layer containing entities, claims, sources, contradictions, review events, and release snapshots. That layer can then be serialized to JSON-LD/RDF for public interchange and projected into a property graph for application queries. This adds machine actionability without breaking the human-first operating model. citeturn32view0turn35view0turn10search1turn9search0

### Recommended semantic core

At minimum, LLMWikis should model the following as first-class graph objects:

| Core object | Why it matters for LLMWikis |
|---|---|
| **Page** | Public editorial unit with title, route, type, status, owner, audience, sensitivity, and review metadata |
| **Section** | Granular anchor for claim extraction and citations |
| **Source** | Raw or external evidence object with URL/path, hash, date, license, and provenance |
| **Claim** | Atomic statement that can be supported, contradicted, superseded, or marked source-needed |
| **Entity** | Person, organization, project, model, protocol, tool, standard, benchmark, or concept |
| **Review event** | Human or automated review action with reviewer, date, decision, and notes |
| **Contradiction record** | First-class record of unresolved disagreement rather than prose-only caveat |

Why This File Exists

This is a memory-system evidence file from llmwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Knowledge Graph Strategy for LLMWikis.org; Executive Summary; Current State of LLMWikis.org; Public-state snapshot; Assumptions used in this report; Design Principles for a LLM Wikis Knowledge Graph; Recommended semantic core; Standards stack. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-1230 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Knowledge Graph Strategy For LLMWikis",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-fd514a7d/",
    "source_reference":  "raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-06/Improvement/knowledge-graphs/Knowledge Graph Strategy for LLMWikis.org.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:fd514a7d4c5c2c98a5399eaec9340fad4f36104b906c87a56114263cd714da9a",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-06T14:48:17.7434007Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-1230",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}