@context
@context — define the vocabulary
@context maps the keys in your JSON document to terms in a shared vocabulary, like schema.org. It turns ambiguous strings ("name", "author") into globally-resolvable concepts.
JSON-LD — JSON for linked data.
A W3C standard that adds meaning, identity, and classification to JSON documents — without breaking the JSON your code already speaks.
What Is JSON-LD
JSON, with the meaning baked in.
Plain JSON tells you the shape of data. JSON-LD tells you what the data means — using a shared vocabulary that any system can resolve.
A JSON-LD document is still a valid JSON document. The difference is a small set of reserved keywords — @context, @id, @type — that turn that document into a graph of typed, globally-identified entities.
That graph is RDF. JSON-LD is the most developer-friendly way to read and write it.
The Three Keywords
Master @context, @id, and @type and you have JSON-LD.
@id
@id — give every entity an identity
@id assigns an IRI (Internationalized Resource Identifier) to a node, so the same entity can be referenced and dereferenced consistently across systems and datasets.
@type
@type — classify the data
@type declares what kind of thing a node represents — a Person, an Article, a MedicalProduct — using a class from a published ontology like schema.org or your own.
Anatomy of a Document
A schema.org Article, in JSON-LD.
Same JSON you'd already write — plus three keywords that turn it into linked data any RDF-aware system can read.
Side by SidePlain JSON vs.
Plain JSON vs.
JSON-LD.
Why JSON-LD
Six reasons teams adopt JSON-LD.
Participate in the semantic web
Encode meaning the way Google, Schema.org, and the W3C standardized — making your data discoverable and machine-readable across the open web.
Power knowledge graphs
JSON-LD is the most ergonomic on-ramp to RDF. Build, transact against, and operationalize knowledge graphs without forcing developers to learn Turtle or SPARQL up front.
Link data across silos
Once two datasets share an ontology, they speak the same language. Federate queries across systems instead of writing point-to-point integrations.
Verifiable Credentials and trust
JSON-LD is the canonical encoding for the W3C Verifiable Credentials Data Model — used to issue and verify tamper-evident digital credentials.
Future-proof JSON
A JSON-LD document is still valid JSON. Your existing services, APIs, and clients keep working — and the semantic context is there when you need it.
Make data F.A.I.R.
Findable, Accessible, Interoperable, Reusable. JSON-LD ships with the metadata that makes data immediately useful to downstream analytics, AI agents, and partners.
JSON-LD in Fluree
Native, not bolted-on.
Fluree Core reads and writes JSON-LD as a first-class transaction format. No ORM, no schema translation step, no impedance mismatch between your application code and the underlying knowledge graph — write JSON-LD in, query it back out.
- Transact JSON-LD directly — no intermediary mapping layer
- Query the same graph with FQL or SPARQL
- Built on RDF and W3C standards — no semantic lock-in
- Time-travel any entity to any historical state
POST /api/ledger/transact
{
"@context": "https://schema.org/",
"@id": "ex:customer-1024",
"@type": "Person",
"name": "Ada Lovelace",
"memberOf": {
"@id": "ex:org-7",
"@type": "Organization"
}
}FAQ
JSON-LD (JSON for Linked Data) is a W3C standard that adds semantic context to JSON documents using a small set of keywords (@context, @id, @type, and a few others). It lets a JSON document carry the meaning, identity, and classification of its data — enabling interoperability with the broader linked-data ecosystem.
Functionally, yes — and that's the point. Every JSON-LD document is a valid JSON document. The @context tells consumers how to interpret the keys as RDF triples, but a non-LD-aware consumer can read the same payload as plain JSON.
RDF (Resource Description Framework) is the abstract data model — a graph of subject-predicate-object triples. JSON-LD is one of several concrete serializations of RDF. Others include Turtle, RDF/XML, and N-Triples. JSON-LD is the most accessible for developers used to JSON.
Schema.org markup for SEO is the most visible deployment — Google indexes JSON-LD on the web for rich search results. It's also the canonical encoding for W3C Verifiable Credentials, used in enterprise knowledge graphs, and is the native input/output format for Fluree.
Often, yes — without breaking existing clients. Add an @context that maps your existing keys to a published vocabulary, give your entities @ids, and you've shipped a JSON-LD-compatible response. Old clients see plain JSON; new clients see linked data.
An IRI (Internationalized Resource Identifier) is a generalization of a URI that supports the full Unicode character set. JSON-LD uses IRIs as identifiers (@id) and predicates so every term in a document resolves to a globally unique, dereferenceable concept — no naming collisions across systems.
Fluree Core natively reads and writes JSON-LD as a first-class transaction format. There's no ORM, no schema translation step, and no impedance mismatch between your application code and the underlying knowledge graph — write JSON-LD in, query it back out.
No. The @context can reference any published ontology — schema.org, FIBO, SNOMED, an industry standard, or your own internal vocabulary. JSON-LD is the carrier; the meaning lives in whatever ontology you choose.
Go Deeper
Keep learning.
See also json-ld.org — the community hub for the spec, playgrounds, and reference implementations.
Recognized by Gartner
JSON-LD, natively
Write JSON-LD. Get a knowledge graph.
Fluree Core treats JSON-LD as a first-class input — no ORM, no schema translation, no glue code. Your linked-data model is your database.