PicaJet

Reference Glossary

JSON-LD

A JSON-based format for encoding linked data, including Schema.org vocabulary, as a self-contained script block on a page rather than mixed into visible HTML; it became a W3C Recommendation in January 2014.

Why it matters in a DAM

JSON-LD is the delivery mechanism most DAM-driven websites use to publish Schema.org ImageObject/VideoObject data — because it lives in a single block, a DAM's publishing layer can regenerate it programmatically from live asset metadata without touching the page's display templates, which is why Google recommends it over inline microdata for structured data. That separation is what makes it practical to keep license, creator, and rights data current on public pages as the underlying DAM record changes.

A worked example

@context https://schema.org
@type ImageObject
contentUrl Direct URL to the asset
license URL to current license terms

Common mistake

Generating the JSON-LD block once at publish time as static text baked into the page, so it keeps advertising an asset's original license or contentUrl even after the DAM record is updated, replaced, or the asset's rights expire.

JSON-LD (JSON for Linking Data) reached W3C Recommendation status on January 16, 2014, following work led by Manu Sporny and Dave Longley of Digital Bazaar, along with Gregg Kellogg, Markus Lanthaler of Google, and Niklas Lindström. The design goal was to make Linked Data — a concept previously expressed through denser formats like RDF/XML and Turtle — usable by ordinary web developers without requiring specialist knowledge of RDF. A revised JSON-LD 1.1 became a Recommendation in July 2020.

What makes JSON-LD distinct from older structured-data approaches like microdata (which annotates existing HTML elements with attributes) is that it’s self-contained: the entire structured-data payload sits in one script block, independent of the surrounding markup. That separation is exactly why Google’s own documentation recommends JSON-LD as the preferred format for structured data — it can be added, changed, or removed without editing the page’s visible content or risking broken HTML.

For a DAM-driven site, this means the JSON-LD block for an asset page (or a page embedding multiple assets) can be templated to read directly from the DAM’s API at render time — pulling current license status, creator credit, and contentUrl — so a rights change or license expiry recorded in the DAM propagates automatically to what search engines see, rather than requiring a manual page edit.

Frequently asked

What is JSON-LD?

A JSON-based format for encoding linked data, including Schema.org vocabulary, as a self-contained script block on a page rather than mixed into visible HTML. It became a W3C Recommendation in January 2014.

Why do DAM-driven websites favor JSON-LD for publishing structured data?

Because it lives in a single script block, a DAM's publishing layer can regenerate it programmatically from live asset metadata without touching the page's display templates — which is why Google recommends it over inline microdata for structured data.

What does that separation from display templates actually enable?

It's what makes it practical to keep license, creator, and rights data current on public pages as the underlying DAM record changes, since the markup can be regenerated independently of the page's visual layout.

What's the risk of generating a JSON-LD block only once at publish time?

If it's baked into the page as static text, it keeps advertising an asset's original license or contentUrl even after the DAM record is updated, replaced, or the asset's rights expire.

How does JSON-LD differ from inline microdata for the same purpose?

JSON-LD sits in a separate script block disconnected from the visible HTML, while microdata is mixed directly into HTML attributes — Google recommends JSON-LD specifically because it's easier to generate and update programmatically without touching page templates.

When did JSON-LD become a formal web standard?

It became a W3C Recommendation in January 2014.

Sources

  • JSON-LD 1.0 reached W3C Recommendation status on January 16, 2014. checked 2026-08-07W3C: JSON-LD is a W3C Recommendation
  • JSON-LD 1.0 was designed by Manu Sporny and Dave Longley of Digital Bazaar, Gregg Kellogg, Markus Lanthaler of Google, and Niklas Lindström. checked 2026-08-07JSON-LD — Wikipedia
  • JSON-LD 1.1 was published as a W3C Recommendation in July 2020. checked 2026-08-07JSON-LD — Wikipedia