Choosing a knowledge format is choosing what the knowledge layer can do

What a format decides

A format decides who can read the knowledge, what a tool can do with it without guessing, and how much effort each correction costs.

Every format sits somewhere between two audiences. Written only for people, it is comfortable to author and expensive to query. Written only for machines, it is precise and queryable and almost nobody will volunteer to maintain it. The formats worth using hold both — readable enough that a domain expert will correct a mistake, structured enough that an agent engine can retrieve and traverse without a human in the loop.

So the honest framing is not which format is best, but which format lets this corpus do what it needs to do at the cost we are prepared to pay.

Four families of knowledge format

Prose markdown

Markdown is plain text with light structure, and it is the cheapest format to author and review. It diffs line by line, needs no runtime, and is readable by every model and tool in common use. With conventions on top — a type per file, links that state their kind in prose — it becomes traversable structure as well as readable text, which is the idea behind a knowledge bundle. Its limit is expressiveness: markdown carries no semantics of its own, so anything a machine needs beyond the words has to come from convention.

Structured data in JSON-LD

JSON-LD expresses knowledge as subject–predicate–object statements inside ordinary JSON, which makes it directly consumable by web tooling without a special graph database. It is the practical route to publishing knowledge as linked data, and it is what search engines and many agents already read. The cost is authoring and review: a statement graph is harder for a domain expert to read than a paragraph, so it usually works best as a derived form rather than the place people write first.

Graph serialisations in Turtle

Turtle is a compact, human-readable syntax for RDF. It keeps the full expressiveness of a statement graph while staying legible: prefixes shorten identifiers and the notation reads close to English. Where the knowledge genuinely is a graph — relationships between entities rather than documents about them — Turtle is the clearest way to write it down. The cost is tooling and skills: it assumes an RDF stack on both ends, and it tends to be maintained by a smaller group than the one that reads it.

Compact and compressed forms in HDT

HDT is a binary format for RDF that compresses a graph for storage and query without decompressing it into triples first. It is built for scale — large graphs that must be shipped, loaded, and queried efficiently. It is not an authoring format: nobody writes knowledge in HDT, and the tooling around it assumes the graph already exists in a normal RDF form. It is the last step in a pipeline, not the first.

What each format costs

The costs move in opposite directions, which is what makes the choice a trade rather than a ranking.

• Authoring effort. Lowest in prose markdown, highest in Turtle and statement graphs, where every relationship has to be named explicitly as a predicate.
• Tooling. Markdown needs a text editor. JSON-LD needs a consumer that understands context. Turtle needs a parser and usually a store. HDT needs the conversion pipeline that produces it and a reader for the compressed form.
• Expressiveness. Markdown carries no semantics by itself; JSON-LD and Turtle carry full statement-level meaning; HDT carries whatever RDF it was built from.
• Reviewability. Highest in markdown, where a domain expert can read a diff and object. Lower in any statement graph, where a correction requires the reviewer to understand the structure as well as the content.

How to choose

Start from the audience that has to keep the knowledge correct, then add structure only where something downstream genuinely needs it.

If the corpus is documents that people read and agents retrieve, prose markdown with conventions is usually the right starting point, because the corrections happen and the graph is recoverable. If a downstream system has to query relationships rather than fetch passages, the corpus needs an explicit statement form, and JSON-LD or Turtle becomes worth the authoring cost. If the graph is large enough that storage and load time dominate, a compressed form like HDT belongs at the end of the pipeline rather than the start.

Most working corpora end up with more than one of these at once: markdown where people write, a generated statement form where machines query, and a compact form where the graph is shipped. That layering only holds together if the underlying concepts keep the same meaning across the forms — which is a convention problem, not a format problem.