Linked Art API: JSON-LD Considerations

Last refreshed: 2026-07-06

Source: JSON-LD Considerations, part of Linked Art API 1.0, published under CC BY 4.0. This is a project summary; the upstream page is authoritative.

Purpose

Linked Art API records use JSON-LD so publishers can expose Linked Open Data while keeping responses usable as predictable JSON for ordinary backend and browser clients. The context maps compact JSON keys to RDF predicates and classes, letting implementers work with stable JSON object shapes without requiring RDF tooling for basic consumption.

The canonical Linked Art context is:

https://linked.art/ns/v1/linked-art.json

Standalone Linked Art API records should carry this context in `@context`. Embedded structures inherit the containing record's context unless they are shared separately as Linked Art JSON-LD.

Media Type

The Linked Art JSON-LD media type profile is:

application/ld+json;profile="https://linked.art/ns/v1/linked-art.json"

Publishers should use it as the `Content-Type` for Linked Art JSON-LD responses. Consumers can send it in `Accept` when a server supports content negotiation. Other serializations may exist, but the Linked Art API does not require consumers to assume Turtle, RDF/XML, or any other graph serialization is available.

Core JSON-LD Rules

• Terms are case sensitive. `Type` and `type` are different keys with different meanings.
• Properties cannot be repeated within a JSON object. Multi-valued Linked Art properties stay arrays, even when only one value is present.
• Linked Art uses serialization order for ordered values where needed; it does not require RDF ordered lists for normal API records.
• `id` and `type` are JSON-LD-friendly aliases for `@id` and `@type`.
• `_label` is a developer-facing label and should not be treated as the canonical public display name when structured names are available.
• Consumers should preserve unknown but valid extension data where their own contracts allow it, but schema-bound endpoint checks can still reject unexpected top-level fields when validating strict API shapes.

Context Design

The Linked Art context is designed to make the JSON ergonomic without losing CIDOC-CRM semantics:

• Class names use upper CamelCase, such as `HumanMadeObject`.
• Property names use lower snake_case, such as `identified_by`.
• Namespace prefixes and CRM numeric prefixes are hidden behind the context.
• Dashes are removed from class names so keys remain easy to use in common programming languages.
• Inconsistent or colliding ontology predicates are normalized to practical API keys.
• Common partitioning relationships are presented as `part` and `part_of` where scoped contexts can preserve the precise underlying RDF predicate.
• The context includes common ontology and vocabulary prefixes, including RDF, SKOS, schema.org, AAT, TGN, and GeoNames patterns.

The important implementation consequence is simple: JSON keys should be treated as Linked Art API terms, not as raw CIDOC-CRM property names. If a transformation needs graph precision, expand through the context rather than inventing local key mappings.

Plain JSON Usability

Linked Art deliberately makes records usable by JSON clients:

• Client code can read `id`, `type`, `identified_by`, `classified_as`, `equivalent`, `part`, `part_of`, and other fields directly.
• Basic API consumers should not need JSON-LD expansion or SPARQL to display or traverse records.
• RDF-aware consumers can still expand the same JSON-LD into graph data for validation, reasoning, or triplestore loading.

This is the bridge we care about in Meta Museum: human-facing product code can use predictable JSON structures, while conformance checks can still prove the records expand to linked data.

Meta Museum Notes

Meta Museum already relies on these rules: Linked Art JSON-LD is canonical at record boundaries, HAL `_links` stay outside semantic graph assertions, multi-valued properties remain arrays, URI handling stays opaque, and SHACL/schema checks validate the linked-data shape instead of relying on display-only DTOs.

This note should be used whenever code touches API serialization, dataset exports, ActivityStreams embedded `linkedArt` projections, record fixtures, or docs examples. In practice, check that records keep the canonical `@context`, preserve `id` and `type`, avoid repeated JSON properties, keep array-valued fields as arrays, and remain usable as predictable JSON without sacrificing RDF compatibility.

Test Ideas

• Assert public records and exports include `@context: "https://linked.art/ns/v1/linked-art.json"` where they are standalone Linked Art JSON-LD.
• Keep `id` and `type` aliases stable instead of leaking `@id`/`@type` into project-authored API records.
• Preserve array-valued fields such as `identified_by`, `classified_as`, `equivalent`, `part`, and `part_of` at cardinality 1.
• Reject accidental case drift such as `Type` where `type` is required, or `type` where a `Type` class reference is required.
• Verify JSON-LD fixtures remain usable by ordinary JSON consumers and expandable by RDF/SHACL validation tooling.