A candid, evidence-based view of how Meta Museum conforms to the Linked Art 1.0 API — at the protocol layer, the model layer, and per provider. For the full standards ledger see LinkedArtModel1.0-Reference.md(LinkedArtModel1.0-Reference.md).
\nThe Linked Art Protocol page defines three MUSTs (first three rows); the `HEAD` and HTTP/2 SHOULDs are also met. All are verified against the live deploy on the canonical entity endpoints (`/api/objects/[id]`, `/api/artworks/[id]`, `/api/works/[id]`, …):
\n| Requirement | Status | Evidence |
\n|---|---|---|
\n| Content-Type `application/ld+json;profile="https://linked.art/ns/v1/linked-art.json"` when requested via `Accept` | ✅ | Echoed exactly under content negotiation (`src/utils/protocol.ts`). |
\n| `Access-Control-Allow-Origin: *` on every response | ✅ | `createPublicCorsHeaders()`. |
\n| `GET` + `OPTIONS` supported | ✅ | `optionsResponse()` on every public route; auto-implemented `OPTIONS` plus explicit allow-methods. |
\n| `HEAD` supported (SHOULD) | ✅ | Canonical entity/collection routes export `HEAD` (same headers as GET, no body, mirrors 200/404); `Allow-Methods` advertises `GET,HEAD,OPTIONS`. `tests/api/head-methods.test.ts`. |
\n| HTTP/2 on the live deploy (SHOULD) | ✅ | Vercel edge negotiates HTTP/2 — verified `HTTP/2.0 200` on `www.metamuseum.org`. |
\nTested by the B8 protocol-conformance suite across ~14 representative routes (media-type negotiation, CORS, URI opacity, array cardinality, HAL `_links` separation).
\nApplied uniformly in `src/utils/linked-art.ts` (`normalizeIncomingRecord`) and `src/utils/artwork-builder.ts`:
\n| Aspect | Status |
\n|---|---|
\n| `@context` (`linked-art.json`) always present | ✅ |
\n| `id` / `type` / `_label` required | ✅ |
\n| `identified_by` (Name/Identifier), `classified_as`, `referred_to_by` | ✅ |
\n| `produced_by` as a `Production` activity (maker via `carried_out_by`, date via `timespan`, place via `took_place_at`) | ✅ |
\n| Event-centric provenance (`Activity`-wrapped acquisition/transfer; ownership vs. custody distinct) — B9 guardrails | ✅ |
\n| Multi-valued properties kept as arrays (cardinality-safe) | ✅ |
\n| Carrier / content / surrogate distinct (HumanMadeObject ≠ VisualItem ≠ DigitalObject) | ✅ |
\n| HAL `_links` separated from semantic assertions; `describedby` signposting | ✅ |
\n| `subject_to` (Right entities with classification) | ✅ Every object record: Getty's preserved; others synthesized from rights signals, classified by CC0 / rightsstatements.org URIs (`src/utils/linked-art-rights.ts`) |
\nEvery production provider has committed pass + fail fixtures (`provider-fixture-manifest.json`(../../tests/fixtures/validation/provider-fixture-manifest.json)), asserted in CI by `validation-architecture-depth.test.ts`(../../tests/quality/validation-architecture-depth.test.ts): the pass fixture must conform and the fail fixture must be rejected, each mapped to explicit Linked Art reference rounds. Each pass fixture is also validated against the Linked Art SHACL shapes by a dedicated pyshacl CI job (`shacl-conformance.yml`(../../.github/workflows/shacl-conformance.yml)) — proving the JSON-LD expands to valid CIDOC-CRM RDF. Rights are modeled uniformly as `subject_to` `Right` entities for every provider (Getty's preserved; the rest synthesized — see the rights row in the core-model table). The table below is generated from those fixtures and the capability registry, so it cannot drift from what the tests verify.
\n<!-- GENERATED:provider-matrix:start -->
\n_Generated by `pnpm conformance:matrix` from `provider-fixture-manifest.json`(../../tests/fixtures/validation/provider-fixture-manifest.json) and the provider capability registry. Each ✓ is computed live by running `inspectLinkedArtRecord` over the committed pass/fail fixtures — 13/13 providers pass both directions (pass conforms, fail rejected). Do not edit by hand._
\n| Provider | Import | Search | Pass fixture conforms | Fail fixture rejected | Linked Art rounds |
\n|---|:--:|:--:|:--:|:--:|---|
\n| Art Institute of Chicago API | ✅ | ✅ | ✅ | ✅ | R2, R3, R11 |
\n| Cleveland Museum of Art Open Access API | ✅ | ✅ | ✅ | ✅ | R2, R3, R11 |
\n| Europeana | ✅ | ✅ | ✅ | ✅ | R2, R3, R11, R65 |
\n| Getty Museum Collection | ✅ | ❌ | ✅ | ✅ | R2, R3, R11, R14 |
\n| Harvard Art Museums | ✅ | ✅ | ✅ | ✅ | R2, R3, R11, R68 |
\n| Louvre Collections | ✅ | ✅ | ✅ | ✅ | R2, R3, R11, R14 |
\n| National Gallery of Art Open Data Program | ✅ | ✅ | ✅ | ✅ | R2, R3, R11, R14 |
\n| Princeton University Art Museum | ✅ | ✅ | ✅ | ✅ | R2, R3, R11 |
\n| Rijksmuseum Data Services | ✅ | ✅ | ✅ | ✅ | R2, R3, R65 |
\n| RKD Knowledge Graph | ✅ | ✅ | ✅ | ✅ | R2, R3, R11, R65 |
\n| Smithsonian Open Access | ✅ | ✅ | ✅ | ✅ | R2, R3, R11, R65 |
\n| The Metropolitan Museum of Art | ✅ | ✅ | ✅ | ✅ | R2, R3, R11 |
\n| Victoria and Albert Museum Collections API | ✅ | ✅ | ✅ | ✅ | R2, R3, R65 |
\n<!-- GENERATED:provider-matrix:end -->
\nCounts come from the provider capability registry (`src/gateway/readiness.ts`), also surfaced at `/api/providers/capabilities`: 13 production providers · 12 searchable · 13 importable. Access: most providers are open; RKD uses a Triply token, Harvard and Smithsonian need an API key.
\nThe spec's MUST-level HTTP requirements and the hard part — the event-centric model — are genuinely conformant and test-backed. The remaining gaps are breadth (precise per-provider license categories, Solr-scale search, richer SHACL shapes), not correctness.
","updatedAt":"2018-10-20T01:46:40.000Z","checksum":"53ff87000bf4beee3e6c40e0d7719f5e79f6382f671c467d61868d0758c80300","checksumPrefix":"53ff87000bf4","anchorCount":5,"lineCount":70,"rawUrl":"/api/docs/content?path=linked-art%2Fconformance-matrix.md","htmlUrl":"/docs?doc=linked-art%2Fconformance-matrix.md","apiUrl":"/api/docs/content?path=linked-art%2Fconformance-matrix.md"}