The argument, up front

Thesis

Every RDF serialization denotes the very same triples, so the choice among them changes nothing about meaning. It is a pure fit-for-purpose decision — readability, tooling, volume, channel. Keep one canonical encoding per artifact as the source of truth, and generate the rest.

A graph of triples can be written as terse Turtle, as verbose RDF/XML, as JSON-LD a web developer will recognise, or as one-triple-per-line N-Triples a loader can stream by the billion. All four carry the identical model. That is the freedom this brief is about: because the encoding is downstream of the meaning, you may pick whichever serves the task, and convert between them without loss of a single triple.

It is worth setting against a complementary principle. A transport or message encoding — the JSON or XML that crosses a wire — must never be allowed to shape your domain model. An RDF encoding is the opposite: it cannot shape your model, so you may choose it freely, and late. One is a trap to avoid; the other, a lever to use.

01 — THE DISTINCTION

The model is the meaning; the encoding is a rendering

RDF is an abstract data model: a set of triples — subject, predicate, object — built from IRIs, literals and blank nodes, optionally grouped into named graphs to form a dataset. A serialization (or concrete syntax) is just a grammar for writing that graph down as bytes. The triples are what mean something; the file is one way to spell them.

The practical consequence is liberating: round-tripping a graph through any two RDF serializations preserves every triple. Load Turtle, write N-Triples, load that, write JSON-LD — the denoted graph is identical at each step. Encodings are interconvertible by construction, which is exactly why the choice is safe to defer and cheap to change.

“Lossless” is true of the graph, not of the file

Conversion preserves the triples, but not everything around them. Comments, indentation and layout, your choice of prefixes, the order of statements, and blank-node labels (which get relabelled) are all serialization-level artifacts that a round-trip may drop or change.

Toolchains lean on this more than people expect. Editors and pipelines often stash their own metadata in comments — tool directives read on load, provenance notes, generation timestamps, header conventions. Bounce such a file through RDF/XML and back and every one of those comments is gone. That alone is often reason enough to keep a hand-authored source in a single format, rather than regenerating it from another.

So the discipline is not “pick the one true format.” It is: decide which encoding is the authored source for each artifact, and treat all others as generated renderings of it.

02 — THE CRITERIA

What actually decides the choice

Eight questions settle almost every encoding decision. Rank them for the task at hand and the format usually falls out.

Who edits it — human or machine?

Hand-authored, reviewed artifacts want a terse, readable syntax (Turtle). Machine-generated bulk wants a simple, regular one (N-Triples).

What must the tooling accept?

Editors, reasoners and loaders have required inputs. Some OWL and legacy tools still expect RDF/XML; most modern stacks prefer Turtle. Match what round-trips cleanly.

One graph, or a dataset?

Multiple named graphs (per-source, per-provenance) need a quad format — N-Quads or TriG. Triple-only formats (Turtle, N-Triples) cannot carry the graph name.

Who consumes it, over what channel?

Web and application developers want JSON-LD; command-line pipes want N-Triples; a partner tool wants whatever it ingests. Serve the consumer’s native shape.

How big, and streamed?

At scale, line-based N-Triples / N-Quads stream and parallelize without parser state; a single huge Turtle or RDF/XML document must often be held together.

Does it live in version control?

Git-tracked artifacts want stable, minimal diffs. Consistent Turtle formatting for authored files; canonical sorted N-Triples for generated data.

Any statement-level metadata?

Provenance, confidence or time about a triple points to RDF 1.2 triple terms, or to named graphs as an alternative.

Standards status & longevity?

Prefer W3C Recommendations for anything you must still read in ten years. Reserve emerging or binary formats for where their specific payoff is real.

03 — THE FORMATS

The candidates, at a glance

The families worth knowing, and the one thing each is best at. All text serializations are UTF-8.

Format	Carries	Human-readable	Best at	Status
Turtle .ttl	triples	High	Authoring, review, documentation	W3C Rec
TriG .trig	quads	High	Human-readable multi-graph datasets	W3C Rec
N-Triples .nt	triples	Low	Streaming, bulk load, canonical diff	W3C Rec
N-Quads .nq	quads	Low	Bulk datasets with per-graph provenance	W3C Rec
JSON-LD .jsonld	triples / quads	Medium	Web & app APIs, HTML embedding	W3C Rec
RDF/XML .rdf	triples	Low	Legacy & OWL tool interchange	W3C Rec
RDF 1.2 triple terms · formerly RDF-star	triples + triple terms	Med	Statement-level annotation	W3C Rec (RDF 1.2)
OWL 2 Functional / Manchester	OWL axioms	High (Manchester)	OWL-native authoring & reading of axioms	W3C Rec (OWL 2)
HDT .hdt	triples (binary, indexed)	None	Large read-only, compressed, queryable	Member submission

the readable default

Turtle

Prefixes, nesting and shorthand make it the most pleasant to read and write, and a superset of N-Triples. It is the usual authored form and the right default for anything a person edits or reviews.

the web door

JSON-LD

RDF that a JSON developer can consume without knowing it is RDF. A @context maps IRIs to plain keys; it embeds in HTML as <script type="application/ld+json">. The format of choice for APIs and web publishing.

the bulk pipe

N-Triples / N-Quads

One statement per line, fully expanded, no parser state. Ugly to read, unbeatable to stream, split, parallelize and diff. N-Quads adds the fourth slot for the graph name.

the compatibility export

RDF/XML

Verbose and awkward, but it is the one OWL 2 syntax every conformant tool must accept. Keep it as a generated export for interchange — not as a source you hand-edit.

04 — BY ARTIFACT TYPE

A default for each of the three

The three artifacts in the question — ontologies, vocabularies, instances — have different editors, consumers and volumes, so each earns a different canonical encoding.

Ontologies · the T-Box (schema)

Author in Turtle; export other syntaxes on demand

Ontologies are hand-authored, peer-reviewed and reasoned over. Turtle gives readable axioms, clean line-by-line diffs in review, comment-preserved round-trips through common editors, and support in every reasoner — which is what makes it the usual choice for the authored form.

Use Manchester syntax as a reading lens when a class expression gets deeply nested; generate RDF/XML only when a downstream OWL tool demands it. The Turtle stays the single source of truth.

Vocabularies · SKOS concept schemes & code lists

Author in Turtle; publish to consumers in JSON-LD

Lines of business, cause-of-loss and territory codes are controlled vocabularies. Author them in Turtle alongside the ontology, then publish to applications as JSON-LD with a context, so a developer reads familiar JSON while skos:notation and skos:exactMatch still resolve source codes to shared concepts.

Instances · the A-Box (data)

It depends on scale and channel — and often it is never serialized at all

Small, curated example datasets kept beside the schema stay in Turtle for readability. Bulk materialization and triplestore loading use N-Triples / N-Quads; multi-source datasets with provenance use N-Quads / TriG; API responses use JSON-LD; statement-level confidence uses RDF 1.2 triple terms.

And in a virtualized or Ontology-Based Data Access (OBDA) architecture, much instance data is never stored as RDF at all: it is computed on demand and returned in whatever encoding the client negotiates. There, instance “encoding” is largely a serving-format choice per consumer, not a storage decision — and only deliberately materialized subsets (a resolved-identity graph, say) ever get a persisted encoding.

05 — SCENARIOS

Situation → encoding → why

The criteria in practice. Each row is a concrete task and the encoding that fits it.

Scenario	Encoding	Why
Hand-authoring & reviewing the core ontology in git	Turtle	Terse and readable; clean line diffs in review; round-trips through common ontology editors; comments preserved.
Reading a deeply nested DL class expression	Manchester	Reads like structured English; far clearer than Turtle for nested restrictions and intersections.
Publishing a cause-of-loss SKOS code list to an app API	JSON-LD	JSON-native for app developers; @context hides the IRIs; embeddable directly in a web page.
Materializing hundreds of millions of instance triples into the store	N-Triples / N-Quads	One triple per line → stream, split and parallel-load with no parser state; gzips well.
Version-controlling generated reference data with reviewable diffs	canonical N-Triples	Sorted, one-per-line output makes diffs minimal and stable across regenerations.
A dataset with one named graph per source system + provenance	N-Quads / TriG	The fourth component carries the graph/source; TriG when humans read it, N-Quads when machines load it.
Annotating an entity-resolution link with match confidence & method	RDF 1.2	Triple terms attach metadata to a statement without the boilerplate of classic reification.
Handing the ontology to a partner tool that only ingests RDF/XML	RDF/XML (exported)	The one OWL 2 syntax every tool must accept; generated on export while Turtle stays the source.
Embedding machine-readable metadata in a web page	JSON-LD	A <script type="application/ld+json"> block is read by search engines and crawlers as structured data.
One SPARQL/REST endpoint serving many kinds of client	content negotiation	Let the Accept header choose: Turtle to tools, JSON-LD to apps, N-Triples to pipes — one graph, no stored copies.

06 — THE RULE TO KEEP

One canonical source; generate the rest

Because encodings are interconvertible, maintaining the same graph by hand in two formats is pure risk — two files that will drift. The governing habit is a single canonical source per artifact, with every other format produced by the build or the serving layer.

Pick the canonical by who edits it. Hand-authored artifacts → Turtle. Machine-generated bulk → N-Triples/N-Quads. That one file is the source of truth; the rest are outputs.
Content-negotiate at serving time. Don’t store five copies of a graph — serve the format the client asks for from the one you hold.
Never hand-maintain a second serialization. If a tool needs RDF/XML or an app needs JSON-LD, generate it in the pipeline. Regenerate, don’t re-edit.
Mind what conversion drops. Comments, layout, prefixes and blank-node labels don’t survive a round-trip — another reason the human-authored source lives in exactly one format.
Compare graphs, not bytes. To hash, sign or dedupe, use RDF Dataset Canonicalization (RDFC-1.0), which is defined over the graph — not a byte-for-byte diff of one serialization.

The one habit to keep

The graph is the asset; the file is a rendering. Author each artifact in the one encoding that fits the people or machines who edit it, let a single source generate every other form, and choose the encoding late — at the boundary where it is written or served, never in the model itself.