> For the complete documentation index, see [llms.txt](https://docs.origintrail.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.origintrail.io/operate/large-content.md).

# Large Content

The DKG replicates RDF graphs across many independently operated nodes running different triple-store backends. To keep every node able to store every graph, **a single RDF literal (one text value in one triple) must stay at or below 60,000 Java modified-UTF-8 bytes** for the serialized RDF literal term, including its quotes, escaping, and datatype or language suffix. This is not the same as UTF-8 length: a supplementary character such as an emoji uses six bytes, and a NUL code unit uses two bytes. Leave room for serialization when choosing a chunk size.

Why this limit exists:

* One supported backend (Blazegraph) has a hard \~64 KB per-string storage limit. A literal above it can never be stored by those nodes, so a graph containing one would permanently diverge across the network.
* Very large literals are also a replication-health problem: every subscribed node downloads and re-serves them on sync, so one oversized value multiplies into network-wide bandwidth and storage cost.

## What happens if you exceed it

Writes containing an oversized literal are rejected with a structured `OVERSIZED_RDF_LITERAL` error (HTTP 400 on the API routes). The error names the subject, predicate, and byte size so you can locate the offending value. API responses include `code`, `error`, `limitBytes`, and `actualBytes`, plus `subject`, `predicate`, and `graph` when available. This applies to publishes, updates, imports, shared-memory writes, and context-graph registration metadata (names, descriptions).

## How to publish large content today

Two supported patterns:

1. **Chunk it.** Split the text into ordered parts, each below the limit, as separate triples/resources (e.g. `part 1..N` with an order index and a total count). Choose a stable document id and an integer part index so a reader can fetch every part and restore the original order. Measure the serialized literal rather than splitting by character count.
2. **Externalize it.** Store the body outside the graph (your own storage, an artifact store, IPFS, …) and publish a compact pointer instead: the content **URI**, its **SHA-256 hash**, **byte size**, media type, and a short **summary or excerpt** for discoverability. The hash in the triple keeps the external content verifiable — anyone can fetch the body and check it against the published hash, and for Knowledge Assets the hash is covered by the on-chain commitment.

As a rule of thumb: triples carry *structured knowledge and pointers*; bulk text and binary bodies belong outside the triple store, bound by hash.

## Roadmap: first-class external content storage

A future extension could make pattern 2 a built-in feature: publish large content in one call, with the node storing the body in a content-addressed blob store and emitting the pointer triples (URI + hash + size + excerpt) for you — SPARQL-queryable metadata, verifiable integrity, without hand-rolling the externalization. This is a roadmap direction, not a currently available API. Until then, the two patterns above are the supported paths.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.origintrail.io/operate/large-content.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.