← Documentation home

Canonical Markdown source · Jul 6, 2026

Linked Art API Schema: Provenance Activity

linked-art/api/schema-provenance-activity.md · 114 lines · SHA-256 dd2fe5345a6a

Last refreshed: 2026-07-06

Source: Provenance Activity schema docs and provenance.json, part of Linked Art API 1.0, published under CC BY 4.0. This is a project summary; the upstream schema is authoritative.

Purpose

The Provenance Activity schema describes `crm:E7_Activity`: a broad activity during which ownership, custody, location, rights, or other relationships for one or more objects changed. In Linked Art API terms this is the schema-backed provenance wrapper shape, with detailed transfer, payment, move, encounter, and rights-change activities carried in `part[]`.

Related upstream references:

Top-Level Constraints

  • Schema type: object.
  • CRM class: `crm:E7_Activity`.
  • Additional top-level properties are not allowed.
  • `@context`: required.
  • `id`: required URI string for the entity.
  • `type`: required class string. The practical Linked Art class is `Activity`.
  • `_label`: required developer-facing human-readable label.
  • `classified_as`: required array of `Type` structures. Provenance Activity records must include the Provenance Activity classification.

Permitted Top-Level Fields

  • `identified_by`: array of `Name` or `Identifier` structures.
  • `classified_as`: required array of `Type` structures that classify this provenance activity.
  • `referred_to_by`: array of embedded statements or textual references about the activity.
  • `equivalent`: array of compact references to equivalent identities.
  • `representation`: array of embedded `VisualItem` structures linked through digital objects.
  • `member_of`: array of `Set` references.
  • `subject_of`: array of embedded `LinguisticObject` web pages or digital objects focused on this activity.
  • `attributed_by`: array of `AttributeAssignment` structures relating another entity to this activity.
  • `during`: array of `Period` references that contain this activity.
  • `after`: array of `Period`, `Event`, or `Activity` references that end before this activity begins.
  • `before`: array of `Period`, `Event`, or `Activity` references that start after this activity ends.
  • `took_place_at`: array of `Place` references where the activity occurred.
  • `timespan`: `TimeSpan` structure for the date-time range of the activity.
  • `caused_by`: array of events that caused this activity.
  • `carried_out_by`: array of `Person` or `Group` references responsible for the activity.
  • `used_specific_object`: array of object or set references used to carry out the activity.
  • `influenced_by`: array of entities that influenced the activity.
  • `technique`: array of `Type` references for techniques used.
  • `part_of`: reference to an identified `Event` or `Activity` of which this activity is part.
  • `part`: array of detailed provenance activity parts.

Embedded Structures Highlighted By The Schema

`identified_by` items can be:

  • `Name` structures, with required `type` and `content`, plus optional `_label`, nested `identified_by`, `referred_to_by`, `classified_as`, `language`, and `part`.
  • `Identifier` structures, following the shared identifier pattern.

`referred_to_by` items are embedded `LinguisticObject` statements:

  • `type`: required.
  • `content`: required.
  • `_label`, `identified_by`, `classified_as`, `referred_to_by`, `language`, and `format` are allowed.

`representation` items are embedded `VisualItem` structures:

  • `type`: required.
  • `_label`, `identified_by`, `classified_as`, `referred_to_by`, and `digitally_shown_by` are allowed.
  • Nested digital objects can carry `access_point`, `format`, and `conforms_to`.

`subject_of` items are embedded `LinguisticObject` structures:

  • `type`: required.
  • `_label`, `identified_by`, `classified_as`, `referred_to_by`, `language`, and `digitally_carried_by` are allowed.

Provenance Part Types

The `part` array can include these detailed activity shapes:

  • `Acquisition`: ownership transfer. `transferred_title_of` is required; `transferred_title_from` and `transferred_title_to` identify previous and new owners when known.
  • `RightAcquisition`: rights establishment or invalidation, using `Right` structures.
  • `TransferOfCustody`: custody transfer, with transferred object, previous custodian, and new custodian fields.
  • `Payment`: payment activity, including `paid_amount`, `paid_from`, and `paid_to` when known.
  • `Encounter`: discovery or encounter event, using `encountered` object references.
  • `Move`: location movement, using `moved`, `moved_from`, and `moved_to`.
  • `Activity`: generic provenance part for cases such as promises or other activity classifications.

Each part is also an activity-like structure and can carry names, classifications, statements, places, timespan, cause, actor responsibility, used objects, influences, techniques, and temporal ordering.

Required Part Evidence

The schema makes several part-level evidence boundaries explicit:

  • `Acquisition.transferred_title_of`: required object references for title transfer.
  • `TransferOfCustody.transferred_custody_of`: required object references for custody transfer.
  • `Encounter.encountered`: required object references for discovery or find events.
  • `Move.moved`: required object references for movement.
  • `RightAcquisition.establishes`: required rights structures for rights establishment.

Do not use an `Acquisition` when the evidence only proves an unknown transfer, loan, or custody change. Use the more specific part shape only when the claim is supported.

Meta Museum Notes

Meta Museum already preserves provenance wrappers and bundled `part[]` activities in ActivityStreams projections and record fixtures. Existing coverage includes `Acquisition`, `Payment`, `TransferOfCustody`, `Encounter`, `RightAcquisition`, `Move`, `Transfer`, promise activities, `Right` structures, ownership and custody transfers, movement origins/destinations, auction lot sets, commission/service payment details, unknown-transfer evidence, and rights establishment/invalidation.

This expanded schema adds the endpoint-level validation target for provenance exports: required identity fields, required top-level `classified_as`, no unexpected top-level properties, explicit `part[]` provenance parts, and required part-specific evidence fields.

Test Ideas

  • Validate representative provenance activity records against `provenance.json`.
  • Assert `@context`, `id`, `type`, `_label`, and `classified_as` are present.
  • Assert unknown top-level properties fail schema validation.
  • Preserve top-level `during`, `after`, `before`, `took_place_at`, `timespan`, `caused_by`, `carried_out_by`, `used_specific_object`, `influenced_by`, `technique`, and `part_of`.
  • Preserve `part[]` entries for `Acquisition`, `Payment`, `TransferOfCustody`, `Encounter`, `RightAcquisition`, `Move`, and generic classified `Activity`.
  • Assert `Acquisition.transferred_title_of`, `TransferOfCustody.transferred_custody_of`, `Encounter.encountered`, `Move.moved`, and `RightAcquisition.establishes` are present when those part types are used.