← Documentation home

Canonical Markdown source · Jul 6, 2026

Linked Art API: JSON Schemas

linked-art/api/json-schemas.md · 164 lines · SHA-256 57ed7e27b78b

Last refreshed: 2026-07-06

Source: JSON Schema documentation, part of Linked Art API 1.0, published under CC BY 4.0. This is a project summary; the upstream page and schema files are authoritative.

Purpose

Linked Art publishes JSON Schema definitions for the API endpoint response shapes, along with generated HTML documentation for those schemas. These schemas are useful for fixture validation, importer/exporter checks, and evaluator-facing proof that Meta Museum's JSON-LD records are not only model-aligned but also API-shape aligned.

The schemas define endpoint-level objects and generally reject unexpected fields through no-additional-properties constraints.

Schema Catalog

Abstract Work Schema Snapshot

The Abstract Work schema describes a `crm:E89_Propositional_Object`: a purely conceptual work, such as the idea behind an exhibition.

Related upstream references:

Required fields:

  • `@context`
  • `id`
  • `type`
  • `_label`

Permitted fields in the provided schema snapshot:

  • `identified_by`
  • `classified_as`
  • `referred_to_by`
  • `equivalent`
  • `representation`
  • `member_of`
  • `subject_of`
  • `attributed_by`
  • `dimension`
  • `subject_to`
  • `about`
  • `conceptually_part_of`
  • `created_by`

Important constraint: the schema is an object schema with no additional properties.

Expanded local checklist: Abstract Work schema(schema-abstract-work.md).

Concept Schema Snapshot

The Concept schema describes `crm:E55_Type`: concepts, subjects, and other categorizations. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows concept classification, names and identifiers, statements, equivalents, visual representation, set membership, subject web pages, attribution evidence, creation activity, and broader concept hierarchy via `broader`.

Expanded local checklist: Concept schema(schema-concept.md).

Digital Object Schema Snapshot

The Digital Object schema describes `dig:D1_Digital_Object`: a digital resource such as a web page, image, or other retrievable digital carrier. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows identifiers, statements, equivalents, visual representation, set membership, subject pages, attribution evidence, dimensions, `part_of`, media `format`, `conforms_to`, `access_point`, `digitally_available_via`, `digitally_carries`, `digitally_shows`, `used_for`, and `created_by`.

Expanded local checklist: Digital Object schema(schema-digital-object.md).

Event Schema Snapshot

The Event schema describes `crm:E4_Period`, `crm:E6_Event`, and `crm:E7_Activity`: temporal entities ranging from periods to events to actor-driven activities. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows names and identifiers, statements, equivalents, visual representation, set membership, subject pages, attribution evidence, places, timespan, period containment, relative `after`/`before` ordering, causation, responsible actors, participants, used objects, influences, techniques, and `part_of` event/activity references.

Expanded local checklist: Event schema(schema-event.md).

Group Schema Snapshot

The Group schema describes `crm:E74_Group`: a group of people and/or other groups. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows names and identifiers, statements, equivalents, visual representation, group `member_of`, subject pages, attribution evidence, `carried_out`, `participated_in`, structured `contact_point`, `residence`, `formed_by`, and `dissolved_by`.

Expanded local checklist: Group schema(schema-group.md).

Person Schema Snapshot

The Person schema describes `crm:E21_Person`: a human. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows names and identifiers, statements, equivalents, visual representation, group `member_of`, subject pages, attribution evidence, `carried_out`, `participated_in`, structured `contact_point`, `residence`, `born`, and `died`.

Expanded local checklist: Person schema(schema-person.md).

Physical Object Schema Snapshot

The Physical Object schema describes `crm:E22_Human-Made_Object`: a human-made object, part, or culturally valued natural object. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows names and identifiers, statements, equivalents, visual representation, set membership, attribution evidence, dimensions, materials, part relationships, ownership, custody, location, containment/support, shown/carried content, production, destruction, part removal, encounter, modification, use, and ownership-transfer activities.

Expanded local checklist: Physical Object schema(schema-physical-object.md).

Place Schema Snapshot

The Place schema describes `crm:E53_Place`: geographic locations where activities occur. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows names and identifiers, statements, equivalents, visual representation, set membership, subject pages, attribution evidence, `defined_by` WKT/GeoJSON geometry, and `part_of` spatial hierarchy.

Expanded local checklist: Place schema(schema-place.md).

Provenance Activity Schema Snapshot

The Provenance Activity schema describes `crm:E7_Activity`: a broad activity during which ownership, custody, location, rights, or other relationships for objects changed. Required fields are `@context`, `id`, `type`, `_label`, and `classified_as`, with no additional top-level properties allowed.

The expanded schema allows common activity fields, temporal ordering, places, actor responsibility, used objects, influence and technique evidence, broader `part_of` event/activity references, and detailed `part[]` entries for acquisition, custody transfer, payment, encounter, movement, rights acquisition, and generic classified provenance activities.

Expanded local checklist: Provenance Activity schema(schema-provenance-activity.md).

Set Schema Snapshot

The Set schema describes `la:Set`: a collection of other resources, such as a set of objects or places. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows names and identifiers, statements, equivalents, visual representation, parent set membership, subject pages, attribution evidence, dimensions, topics, physical member containers, exemplar member templates, `used_for` activities, and `created_by` activity evidence.

Expanded local checklist: Set schema(schema-set.md).

Textual Work Schema Snapshot

The Textual Work schema describes `crm:E33_Linguistic_Object`: textual content expressed in one or more human languages. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows names and identifiers, statements, equivalents, visual representation, set membership, subject pages, attribution evidence, dimensions, rights, language, content format, aboutness, creation and use activity evidence, part relationships, and literal text content.

Expanded local checklist: Textual Work schema(schema-textual-work.md).

Visual Work Schema Snapshot

The Visual Work schema describes `crm:E36_Visual_Item`: the visual content of a work. Required fields are `@context`, `id`, `type`, and `_label`, with no additional top-level properties allowed.

The expanded schema allows names and identifiers, statements, equivalents, set membership, subject pages, attribution evidence, dimensions, rights, part relationships, conceptual parent links, aboutness, creation and use activity evidence, known represented entities, and represented entity types.

Expanded local checklist: Visual Work schema(schema-visual-work.md).

Meta Museum Notes

Meta Museum already has endpoint notes for all twelve core entity families named in the schema catalog. The local `validateLinkedArtSchemaProfile` harness enforces endpoint-family type checks and top-level no-additional-properties allowlists for the implemented endpoint families while still allowing documented local response metadata such as `_links`, `schemaVersion`, and `_source`. Beside that local profile, `validateOfficialLinkedArtEndpointSchema` executes the vendored official Linked Art API 1.0 schema JSON files from the cloned `linked.art/docs/api/1.0/schema` mirror for required fields, allowed fields, and `type` const/enum rules. Fixture coverage proves Physical Object, Digital Object, Person, Group, Place, Concept subclasses (`Type`, `Material`, `Language`, `Currency`, `MeasurementUnit`), Event/Activity, Provenance Activity, Set, Textual Work, Visual Work, and Abstract Work pass fixtures conform and `legacyFoo`-style unexpected top-level fields fail.

The official-schema executor also recurses through endpoint-local embedded definitions and the official shared `core.json` definitions. Fixture coverage proves nested Acquisition parts reject unexpected `legacyPartFoo` fields and require `transferred_title_of`, so the provenance specialization is checked against the same documented distinctions used by Linked Art for acquisition, custody, transfer, movement, and rights-oriented activity parts. Shared-structure fixture coverage also proves `identified_by -> Name` follows `core.json`: embedded Names reject unexpected `legacyNameFoo` fields and require `content`.

The Abstract Work snapshot reinforces existing project boundaries: conceptual works should remain `PropositionalObject` records with `created_by`, `about`, `conceptually_part_of`, rights, dimensions, references, and attribution evidence preserved as Linked Art JSON-LD fields.

Test Ideas

  • Validate representative `/api/records/{id}` route responses against the matching official schema after stripping documented local response metadata.
  • Carry source/version/checksum metadata for the vendored schema mirror into the validation report.