Linked Art API Schema: Visual Work

Last refreshed: 2026-07-06

Source: Visual Work schema docs and image.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 Visual Work schema describes `crm:E36_Visual_Item`: the visual content of a work. In Linked Art API terms this is the endpoint shape for image or visual content, separate from the physical object that shows it and the digital object that digitally shows it.

Related upstream references:

• Visual Work API endpoint
• Visual works and object aboutness model documentation

Top-Level Constraints

• Schema type: object.
• CRM class: `crm:E36_Visual_Item`.
• 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 `VisualItem`.
• `_label`: required developer-facing human-readable label.

Permitted Top-Level Fields

• `identified_by`: array of `Name` or `Identifier` structures.
• `classified_as`: array of `Type` structures that classify this visual work.
• `referred_to_by`: array of embedded statements or textual references about the visual work.
• `equivalent`: array of compact references to equivalent identities.
• `member_of`: array of `Set` references.
• `subject_of`: array of embedded `LinguisticObject` web pages or digital objects focused on this visual work.
• `attributed_by`: array of `AttributeAssignment` structures relating another entity to this visual work.
• `dimension`: array of `Dimension` structures that describe this visual work.
• `subject_to`: array of `Right` structures that apply to the visual work.
• `part_of`: array of `VisualItem` or `LinguisticObject` references of which this visual work is part.
• `conceptually_part_of`: array of `PropositionalObject` references of which this visual work is conceptually part.
• `about`: array of references to the main topics of the visual content.
• `created_by`: creation activity for the intellectual or visual content.
• `represents`: array of known entities represented in the visual content.
• `represents_instance_of_type`: array of `Type` references for kinds of entities represented when the individual entity is not identified.
• `used_for`: array of activities in which this visual work was used.

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.

`subject_to` items are `Right` structures:

• `type`: required and must be `Right`.
• `_label`, `identified_by`, `classified_as`, `referred_to_by`, `created_by`, and `possessed_by` are allowed.

`subject_of` items are embedded `LinguisticObject` structures:

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

Aboutness And Representation

The schema keeps visual subject relationships distinct:

• `about`: the main topic or topics of the visual content.
• `represents`: a known entity represented in the visual content.
• `represents_instance_of_type`: a type of entity represented when the individual entity is not identified.

Do not collapse a known represented person, object, or place into a generic type. Use `represents` for identified entities and `represents_instance_of_type` for depicted classes.

Carrier Boundaries

The schema keeps visual content separate from carriers and surrogates:

• Physical objects show visual content through object-side `shows`.
• Digital objects show visual content through digital-object-side `digitally_shows`.
• Other endpoint records can point to visual content through `representation`.
• The visual work remains a `VisualItem`; physical artworks, image files, services, and visual content should remain separate linked resources.

Activity Fields

The schema supports visual-work activity evidence:

• `created_by`: creation of the intellectual or visual content, including common activity fields such as `took_place_at`, `timespan`, `caused_by`, `carried_out_by`, `used_specific_object`, `influenced_by`, `technique`, `during`, `after`, `before`, and `part_of`.
• `used_for`: activities in which the visual work was used, such as publication, exhibition, documentation, or another described use.

Creation and use should remain structured activity evidence rather than flattened creator/date strings when the data supports it.

Meta Museum Notes

Meta Museum already preserves Visual Work semantics through object, digital object, and record fixtures. Existing coverage keeps carrier/content/surrogate boundaries explicit: physical `HumanMadeObject` records can show `VisualItem` content, `DigitalObject` records can digitally show visual content, and object records can carry `representation[]` references without treating image files, depicted content, and physical artworks as the same entity.

This expanded schema adds the endpoint-level validation target for visual exports: required identity fields, no unexpected top-level properties, structured names/classifications/statements, dimensions, rights, aboutness, representation relationships, part relationships, and visual-work creation/use activity evidence.

Test Ideas

• Validate representative `VisualItem` records against `image.json`.
• Assert `@context`, `id`, `type`, and `_label` are present.
• Assert unknown top-level properties fail schema validation.
• Preserve `about`, `represents`, and `represents_instance_of_type` as distinct relationships.
• Preserve `subject_to` as `Right` structures, not string labels.
• Preserve `dimension`, `created_by`, `used_for`, `part_of`, and `conceptually_part_of`.
• Preserve carrier boundaries: physical objects use `shows`, digital objects use `digitally_shows`, and visual content remains a distinct `VisualItem`.