hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
knowledge-base/wiki/concepts/llm/open-knowledge-format-okf.md
Hector-Bot db3ddc9638 ingest(blog)+wiki(concepts/llm): OKF v0.1 — Google formalisiert LLM-Wiki-Pattern 
Pit-Share in OME Topic 13 #6697 (Reddit-Post r/WebAfterAI).
OKF v0.1 ist die offizielle Spezifikation des Musters, das wir bereits umsetzen.
Neue Konzeptseite open-knowledge-format-okf.md mit Frontmatter-Schema,
Bundle-Struktur, 3 Workflows, Citations-Konvention, Versioning.
Cross-Ref in llm-knowledge-base.md + index/log Updates.
2026-06-16 13:52:24 +02:00

178 lines
10 KiB
Markdown
Raw Blame History

---
created: 2026-06-16
updated: 2026-06-16
sources:
- blog/2026-06-16_okf-google-cloud-open-knowledge-format.md
tags: [okf, google-cloud, open-knowledge-format, llm-wiki, karpathy, knowledge-base, mcp, agent-knowledge, schema, standards]
---
# Open Knowledge Format (OKF) v0.1 — Google Cloud
> **Was:** Google Cloud hat am 2026-06-12 das **Open Knowledge Format (OKF)** veröffentlicht — eine offene Spezifikation, die Karpathys LLM-Wiki-Pattern zu einem portablen, interoperablen Format formalisiert.
> **Quelle:** Pit-Share in [OME Topic 13 #6697](https://t.me/c/3839640481/13/6697) (Reddit-Post r/WebAfterAI).
> **Status:** v0.1 — Spezifikation öffentlich, Reference Implementation auf GitHub verfügbar.
## TL;DR
**OKF ist kein Runtime, kein SDK, kein Agent-Framework, kein MCP-Konkurrent.** MCP ist ein Protokoll für Agenten, um **Tools aufzurufen und Aktionen auszuführen**. OKF ist das **gegenüberliegende Ende**: eine Konvention, wie man statisches Wissen aufschreibt, damit jeder Agent es lesen kann.
**In einem Satz:** Karpathys LLM-Wiki-Pattern (raw → LLM → wiki → Q&A) wird von Google formalisiert, damit verschiedene Tools das gleiche Bundle lesen können ohne Translation-Layer.
## Bundle-Struktur
```
my_bundle/
├── index.md # optional: directory listing for progressive disclosure
├── log.md # optional: chronological history of changes
├── datasets/
│ └── sales.md
└── tables/
├── orders.md
└── customers.md
```
- Jedes `.md`-File = ein **Concept**
- Concepts verlinken sich via Standard-Markdown → **Graph von Beziehungen**
- `index.md` = plain directory listing (kein Frontmatter) für progressive disclosure
- `log.md` = chronologische Änderungshistorie (optional)
## Drei Designprinzipien
1. **Minimally opinionated.** Nur **ein** Pflichtfeld pro Concept (`type`). Alles andere (Types-Taxonomie, weitere Felder, Body-Sections) bleibt dem Producer überlassen. Die Spec definiert die **Interoperabilitäts-Oberfläche**, nicht das Content-Model.
2. **Producer/Consumer independence.** Wer schreibt und wer liest sind sauber getrennt. Bundle von Menschen hand-geschrieben → von AI-Agent konsumiert. Bundle von Metadata-Pipeline generiert → in Visualizer gebrowst. Bundle von LLM A synthetisiert → von LLM B abgefragt. **Format = Vertrag; Tooling an beiden Enden unabhängig austauschbar.**
3. **Permissive Conformance.** Consumers MÜSSEN unbekannte Types, fehlende Felder und broken Links **tolerieren** statt das Bundle abzulehnen. OKF soll nutzbar bleiben, wenn Bundles wachsen, refaktoriert oder teilweise von Agenten generiert werden.
## Conformance-Regel (SPEC §9)
Ein Bundle ist OKF v0.1 konform wenn:
- Jedes non-reserved `.md`-File hat einen parseable YAML-Frontmatter-Block
- Jeder Frontmatter-Block hat ein non-empty `type`-Feld
- `index.md` und `log.md` sind die einzigen erlaubten Frontmatter-Dateien (reserviert)
- Consumers dürfen Bundle NICHT ablehnen wegen unbekannter Types oder fehlender `index.md`
**Permissive consumption model is intentional.** — OKF wächst mit den Bundles mit.
## Frontmatter-Schema
### Pflicht
| Feld | Typ | Zweck |
|------|-----|-------|
| `type` | String (kurz) | Identifiziert Concept-Art. Consumers nutzen für Routing, Filter, Darstellung. Beispiele: `BigQuery Table`, `API Endpoint`, `Metric`, `Playbook`, `Reference`. |
**Type-Werte sind NICHT zentral registriert.** Producers wählen deskriptive Werte; Consumers behandeln unbekannte Types als generic concepts.
### Empfohlen (Prioritäts-Reihenfolge)
| Feld | Zweck |
|------|-------|
| `title` | Menschenlesbarer Titel |
| `description` | Kurzbeschreibung |
| `resource` | Verweis auf zugrundeliegende Quelle (z. B. `bigquery://project.dataset.table`) |
| `tags` | Themen-Tags für Filterung |
| `timestamp` | Letztes Update / Erstellungsdatum |
Producers können weitere Keys frei hinzufügen. Consumers MÜSSEN unbekannte Felder tolerieren.
## Citations (SPEC §8)
Wenn ein Concept-Body Claims aus externem Material macht, sollen diese unter `# Citations`-Heading am Dokumentende gelistet sein, **nummeriert**:
```markdown
# Citations
1. https://example.com/paper-x
2. https://arxiv.org/abs/2024.12345
3. references/internal-doc.md (lokale Spiegelung)
```
Citation-Links können sein:
- **Absolute URLs** zu externen Quellen
- **Bundle-relative Pfade** zu anderen Concepts
- **Pfade in `references/`-Subdirectory**, das externes Material als first-class OKF Concepts spiegelt (empfohlen für Stabilität)
## Drei Workflows zum Loslegen
### Workflow 1: Hand-author a small bundle
**Schnellster Einstieg.** Manuell 3-5 Markdown-Files für eine "messy Ecke" des Systems schreiben, Agent drauf zeigen. 10 Minuten, zeigt Wert und Limits in einem Durchgang. → **Empfohlener Startpunkt.**
### Workflow 2: Generate from existing schema
Wenn Schema zu groß zum Hand-Schreiben: Pipeline, die bestehende Strukturen (DB-Schemas, API-Specs, Notion-Wikis) als OKF-Bundle exportiert. **Achtung:** Citations-Disziplin nötig, sonst verliert Bundle an Wert.
### Workflow 3: Consume a bundle without blowing your context window
Große Bundles komplett in Context laden = teuer + noisy. OKF-Lösung: **optional `index.md`** als plain directory listing. Agent liest Index, folgt Links, zieht Concepts **on-demand**.
## Versioning (SPEC §11)
- Document spezifiziert OKF version **0.1**
- Künftige Revisionen: `<major>.<minor>`
- Bundles deklarieren Version via `okf_version: "0.1"` im **bundle-root `index.md`-Frontmatter** (einzige Stelle, wo `index.md` Frontmatter tragen darf)
- Consumers, die deklarierte Version nicht verstehen, sollen **best-effort consumption** versuchen statt das Bundle abzulehnen
## Reference Implementation + Sample Bundles
**Repo:** [github.com/GoogleCloudPlatform/knowledge-catalog](https://github.com/GoogleCloudPlatform/knowledge-catalog)
Drei ready-to-browse Sample Bundles (vom Reference Agent produziert, als lebende Beispiele committed):
- **GA4 e-commerce** — [Google Analytics BigQuery Demo Dataset](https://developers.google.com/analytics/bigquery/web-ecommerce-demo-dataset)
- **Stack Overflow** — [Pantheon Marketplace](https://pantheon.corp.google.com/marketplace/product/stack-exchange/stack-overflow)
- **Bitcoin public datasets** — [BigQuery Public Datasets](https://cloud.google.com/blog/topics/public-datasets/bitcoin-in-bigquery-blockchain-analytics-on-public-data)
Google Cloud **Knowledge Catalog** wurde aktualisiert, um OKF zu ingestieren und an Agents auszuliefern.
## OKF vs. andere Formate (SPEC §10)
| Format | Fokus | OKF-Differenz |
|--------|-------|---------------|
| **Karpathy LLM-Wiki** | Pattern, kein Standard | OKF formalisiert das Pattern |
| **Obsidian** | Wikibase für Menschen | OKF ist agent-first, permissiver |
| **Notion** | Wikibase + Block-Editor | OKF ist plain markdown, kein Tooling-Lock-in |
| **Hugo** | Static site generator | OKF ist reines Content-Format |
| **AGENTS.md** | Schema-on-Read für AI-Agents | OKF pinnt Regeln fest, AGENTS.md ist freier |
| **CLAUDE.md** | Agent-Kontext | OKF ist konzept-orientiert, CLAUDE.md ist Workflow-orientiert |
| **MCP** | Tool-Calling-Protokoll | OKF ist statisches Wissen, MCP ist Aktionen |
OKF unterscheidet sich primär durch **Spezifikation** — Interoperabilität ohne Tooling-Diktat.
## Direkte Konsequenzen für unser RamaDama-Repo
Unser Repo `knowledge-base` ist exakt nach Karpathys LLM-Wiki-Pattern aufgebaut (siehe [[../llm/llm-knowledge-base.md]]). Google macht das Pattern jetzt zum formalen Standard. Konkrete Implikationen:
### Was wir bereits OKF-konform haben
- **Frontmatter-Standards** mit `type` als Pflichtfeld in raw-Files ✅
- **`wiki/concepts/`, `wiki/teams/`, `wiki/tools/`, `wiki/architecture/`, `wiki/decisions/`** als konzept-orientierte Verzeichnisstruktur ✅
- **`wiki/log.md`** als chronologischer Append-Only Changelog ✅
- **`wiki/index.md`** als Auto-Generated Catalog (Fakten) + `wiki/ideas.md` (Subconscious Outcomes) — wir haben sogar **zwei** index-Dateien, OKF erlaubt das via optional `index.md` ✅
- **Cross-References via `[[seite.md]]`** — Markdown-Standard ✅
- **Producer/Consumer-Trennung:** Raw → Subagent-Prozessor → Wiki, Tooling unabhängig ✅
### Was wir noch ergänzen könnten (nicht zwingend)
- **`# Citations`-Section** am Ende jedes Wiki-Pages mit nummerierten externen Links (OKF-Standard, aber optional)
- **`okf_version: "0.1"`** im root-`wiki/index.md`-Frontmatter deklarieren (signalisiert Konformität für externe Reader)
- **Bundle-Root-Identifier:** Klare Konvention, dass `wiki/` als OKF-Bundle-Root gilt (oder `knowledge-base/` direkt)
### Strategische Implikation
- **Validierung:** Wir sind mit unserer Architektur-Wahl nicht alleine; Google pusht dasselbe Pattern in den Markt → potentiell mehr Tooling-Support (Lint, Visualizer, Search)
- **Migration-Risk gering:** Unsere Struktur ist bereits kompatibel, Migration wäre additiv (Citations-Section) nicht destruktiv
- **Opportunität:** Wir könnten mit minimaler Ergänzung OKF-konform sein und von zukünftigen OKF-Tools profitieren
## Externe Primärquellen
- **OKF Ankündigung (Google Cloud Blog, 2026-06-12):** https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing
- **OKF SPEC v0.1:** https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
- **OKF Reference Implementation Repo:** https://github.com/GoogleCloudPlatform/knowledge-catalog
- **Karpathy LLM-Wiki Original-Gist:** https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- **Search Engine Journal Coverage:** https://www.searchenginejournal.com/google-cloud-announces-the-open-knowledge-format/579253
- **Note.com Deep-Dive (JP/EN):** https://note.com/ai_driven/n/n8e2726b98180
- **Reddit Original-Post:** https://www.reddit.com/r/WebAfterAI/comments/1u6mge2/google_cloud_just_released_okf_think_mcp_but_for/
- **Pit-Share in OME:** [Topic 13 #6697](https://t.me/c/3839640481/13/6697)
## Verwandte Wiki-Seiten
- `[[llm-knowledge-base.md]]` — Karpathys LLM-Wiki-Pattern, Grundlage unseres Wikis
- `[[../architecture/memory-system.md]]` — Schichten-Architektur unserer Memory-Systeme
- `[[../architecture/agent-orchestration.md]]` — Orchestrator-Pattern (parallele zu OKF's Producer/Consumer-Trennung)
- `[[../decisions/2026-06-05_kein-coding-guide-in-kb.md]]` — Beispiel-Decision-Page
Reference in a new issue View git blame Copy permalink