Last refreshed: 2026-07-06
\nSource: Protocol, part of Linked Art API 1.0, published under CC BY 4.0. This is a project summary; the upstream page is authoritative.
\nThe Linked Art API protocol defines how consuming applications retrieve Linked Art records from publishing systems over the web. Linked Art favors a resource-centric REST style over service-oriented operations, using HTTP as the transport and keeping network interaction minimal, familiar, cacheable, and easy for independent implementers to support.
\nThe protocol is intentionally retrieval-focused. Version 1.0 describes how to get representations from endpoints; it does not define create, update, or delete operations for Linked Art API resources.
\nPublishers should use HTTPS for endpoint URIs whenever possible. HTTPS protects user privacy even for open data and leaves room for deployments that require authentication or access control. A typical endpoint URI is a normal web URI, such as:
\n\nhttps://linked.art/example/object/1\nServers must support HTTP/1.1 and should support HTTP/2 or newer so clients can make concurrent requests efficiently.
\nLinked Art API 1.0 is read-only at the protocol layer:
\nThis retrieval-only rule is separate from project-specific operational APIs. For Meta Museum, mutation or workflow routes must not be described as Linked Art API 1.0 protocol operations unless they are clearly outside the public Linked Art record API.
\nConsumers request Linked Art JSON-LD with the `Accept` header:
\n\nAccept: application/ld+json;profile="https://linked.art/ns/v1/linked-art.json"\nPublishers respond with the matching `Content-Type`:
\n\nContent-Type: application/ld+json;profile="https://linked.art/ns/v1/linked-art.json"\nServers may support other serializations at the same URI, but Linked Art does not require those formats and does not define a discovery mechanism for every alternative representation. Future major Linked Art versions are expected to use different profile URIs, letting clients request a specific API/model version through content negotiation.
\nBrowser access is part of the protocol expectation. Publishers must send:
\n\nAccess-Control-Allow-Origin: *\nThat header must appear on normal responses and on `OPTIONS` preflight responses, allowing browser-based clients from other origins to retrieve Linked Art API data.
\nLinked Art does not require one URI structure. Existing institutional URIs can be reused, and consumers must not infer behavior or semantics from path segments.
\nWhen there are no stronger local constraints, the preferred practical shape is:
\n\nscheme://hostname/prefix/endpoint/identifier\nUseful conventions:
\nPreferred endpoint names include `concept`, `digital`, `event`, `group`, `object`, `person`, `place`, `provenance`, `set`, `text`, and `visual`.
\nPersistence matters more than readability. Avoid technology names, volatile departments, or implementation-specific identifiers in public record URIs when those parts may change.
\nMeta Museum already follows most of this protocol surface: public Linked Art records use web-native `GET`, docs and datasets are reachable through normal HTTP, CORS behavior is tested on public routes that need browser access, JSON-LD responses use the Linked Art profile media type where applicable, and URI handling remains opaque in both docs and tests.
\nThe main guardrail from this page is language discipline: ActivityStreams callbacks, dataset exports, partner verification POSTs, and operator workflows can exist alongside Linked Art, but they are not Linked Art API 1.0 record-mutation operations. Linked Art API conformance should be evaluated against retrieval, content negotiation, CORS, and stable dereferenceable URI behavior.
\n