Linked Art Model 1.0 Reference (Round 1)

Status: Working reference for Meta Museum engineering and TDD alignment

Source: <https://linked.art/>

Source document basis: Linked Art Model 1.0 (`1.0.0`)

License note from source: Linked Art Data Model is published under CC BY 4.0

Captured for this reference on: May 30, 2026

---

Purpose

This file turns official Linked Art model guidance into project-ready engineering notes for Meta Museum.

It is designed to support:

• implementation decisions in adapters, contracts, routes, and UI
• roadmap updates across Era B and Era C
• test-driven development (TDD) with explicit behavior checks

This is a living reference. Future rounds append additional official sections and examples.

---

Canonical Model Summary

Linked Art 1.0 is an application profile for describing cultural heritage resources, especially artworks and museum-oriented activities.

Core characteristics:

• event-centric modeling grounded in CIDOC-CRM
• streamlined subset of CIDOC-CRM 7.1.3 for practical interoperability
• JSON-LD 1.1 as core serialization format
• vocabulary and term discipline to keep data interoperable across institutions

The model is finalized at version `1.0.0`, with future evolution expected through community process.

---

Model Coverage Areas (from official structure)

The model documentation includes guidance for:

• basic patterns used throughout
• artworks and other physical objects
• digital content about/depicting objects
• sets and collections
• provenance
• exhibitions
• conservation
• related people, organizations, places, concepts, events
• cultural context
• textual documents
• archival hierarchies
• specific assertions

Implementation note for Meta Museum:

• these areas should map to explicit contract and validation coverage, not implicit adapter behavior

---

Design Principles To Preserve

Linked Art model development emphasizes:

• iterative improvement
• responsive change from feedback
• responsible complexity management
• collaborative evolution

For this codebase, this means:

• prioritize clear contract boundaries over one-off transforms
• prefer additive schema/version migration over breaking storage changes
• keep provider-specific logic isolated in adapters

---

Scope Boundaries (Important)

From the official scope limitations:

• goal is interoperability across systems, not perfect modeling of every local institutional detail
• complete bibliographic/archival description is intentionally out of scope for Linked Art alone
• detailed provenance of the data-recording process itself is out of scope at this stage
• quantification of uncertainty/belief is valuable but intentionally deferred due to complexity

Engineering implication:

• avoid over-modeling unsupported certainty/provenance semantics until explicitly scoped in roadmap
• keep import outputs interoperable-first and standards-aligned

---

Meta Museum Implementation Mapping (Round 1)

Use this as a standards checklist when adding/changing features:

1. Canonical layer

• Stored records remain Linked Art JSON-LD centric (`SourceRecord` + `_source.raw` preservation).

1. Event-centric modeling

• Do not flatten event semantics (production/acquisition/exhibition/conservation) into untyped strings when structured activity is available.

1. Serialization discipline

• APIs and adapters should preserve JSON-LD compatibility and context handling.

1. Vocabulary discipline

• Keep required/recommended/optional term usage explicit where feasible in contracts and validation.

1. Interoperability over local convenience

• Route and UI DTOs can simplify for UX, but source-level structures must stay standards-safe.

---

TDD Guidance Derived From Linked Art 1.0

When implementing any new provider, route, or transform, test first against these minimum behaviors.

Contract-level tests

• rejects malformed Linked Art top-level shape
• preserves core identity fields (`id`, `type`, `_label` when present)
• preserves structured event/activity nodes
• preserves controlled-term links/classifications when present

Adapter-level tests

• transforms provider payloads into Linked Art-compatible structures
• does not discard important relationships (people/place/concept/event)
• keeps source provenance fields for citation and audit surfaces
• handles sparse data conservatively (warnings instead of silent loss)

Route-level tests

• inspect/resolve/import routes validate request boundaries
• import routes return standards-safe normalized output and stable error shapes
• provider routes do not leak provider-specific quirks into shared contracts

Regression tests

• adding a provider does not break existing provider adapters
• DTO simplification never mutates canonical stored source data

---

Roadmap Hooks (What this reference should drive)

This reference directly supports:

• Era B1/B2: schema mirrors + formal validation alignment
• Era B5: provider expansion with consistent Linked Art boundary behavior
• Era B6: authority strategy and controlled vocabulary consistency
• Era C: richer model coverage (documents, archival hierarchies, assertions) without breaking core interoperability

Recommended follow-up after each documentation round:

• update `docs/roadmap.md` acceptance language where needed
• add or tighten failing tests before feature code
• record gaps between source docs and current contracts in a tracked checklist

---

Round 2 Addendum — Objects (Physical Object Modeling)

Source section basis:

• Linked Art Model 1.0: Objects
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• `HumanMadeObject` is the core class for art objects and other physical objects with social/cultural value.
• Even minimally altered natural objects (for example, a shell) are still modeled as `HumanMadeObject` when value is socially conferred.
• This simplifies interoperability and avoids ambiguous thresholds for "how modified is modified enough".
• Shared/basic patterns and digital integration patterns still apply to object records.
• Object-specific documentation focus areas:
• production and destruction
• physical characteristics
• aboutness
• ownership
• rights information (non-ownership rights)
• digital representation linkage
• immovable objects handled through place-oriented modeling

Implementation Mapping — Objects

Apply these requirements to adapters, normalization, and stored source records:

1. Object typing

• Default culturally valued physical works to `HumanMadeObject` unless there is explicit evidence for a different canonical class.

1. Event modeling

• Production and destruction must remain activity/event-shaped when present; do not flatten into untyped date/label strings only.

1. Physical characteristics

• Preserve structured dimensions/materials/parts where provided; avoid collapsing to display-only text.

1. Aboutness and descriptive statements

• Keep descriptive content in structured statement fields; do not discard language-tagged or classified descriptions.

1. Ownership and location

• Keep ownership/location assertions distinct from general rights statements.

1. Rights split

• Distinguish ownership from usage/reproduction rights in normalization and UI summaries.

1. Digital linkage

• Keep physical object and digital surrogates distinct, linked through representation/documentation patterns.

1. Immovable handling

• For immovable works, prefer place-connected modeling patterns instead of forcing moveable-object assumptions.

TDD Additions — Objects

Add failing-first tests for object workflows:

Contract-level:

• accepts `HumanMadeObject` as canonical object class for valued physical objects
• preserves event structures for production/destruction when present
• preserves dimensions/materials/parts structures without forced flattening

Adapter-level:

• normalizes provider object payloads into `HumanMadeObject`-compatible output
• keeps ownership/location and rights information separated in normalized output
• preserves links to digital surrogates without collapsing physical and digital identities

Route-level:

• inspect/import paths retain object event + physical-characteristics structure after normalization
• responses include stable rights/ownership-safe summaries without mutating canonical source fields

Regression:

• immovable/place-centric records remain standards-safe and are not coerced into moveable-only assumptions

---

Round 3 Addendum — Digital Content

Source section basis:

• Linked Art Model 1.0: Digital Content
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• `DigitalObject` is a carrier of information, not the information itself.
• Information/content should remain modeled as `LinguisticObject` or `VisualItem`, with digital/physical carriers linked to that same content.
• Digital object core properties include:
• `access_point` for file/resource URLs
• `format` for media type (MIME)
• `conforms_to` for standards/specifications
• `dimension` for digital characteristics (for example, file size, pixels)
• `created_by` using `Creation` activity pattern
• Digital erasure/deletion is not yet modeled in Linked Art 1.0 and should not be invented ad hoc.
• Digital surrogates should be distinguished from generic depictions:
• physical object `shows` a `VisualItem`
• digital surrogate `digitally_shows` the same `VisualItem`
• Embedded representation pattern is valid when the digital image is auxiliary to the main entity.
• Web pages about entities should be linked via `subject_of` with intermediary `LinguisticObject`, then `digitally_carried_by` a `DigitalObject` classified as web page.
• IIIF Presentation manifests:
• treat as `DigitalObject` in `subject_of` pattern
• include `conforms_to` = `http://iiif.io/api/presentation/`
• use presentation media type in `format`
• IIIF Image API:
• model service as `DigitalService` under `digitally_available_via`
• service (not the image file itself) carries `conforms_to` = `http://iiif.io/api/image/`
• service `format` refers to `info.json` media type profile

Implementation Mapping — Digital Content

Apply these requirements to adapters, normalization, and route outputs:

1. Carrier/content separation

• Never collapse `DigitalObject` and information content into a single semantic layer.

1. URL and media handling

• Preserve canonical access URLs in `access_point`; preserve MIME/media-type detail in `format`.

1. Standards linkage

• Use `conforms_to` for protocol/spec alignment (IIIF, HTML spec, etc.), not broad topical classification.

1. Creation semantics

• Use `Creation` for digital-object creation events, not `Production`.

1. Surrogate clarity

• Preserve shared `VisualItem` linkage between physical `shows` and digital `digitally_shows` when surrogate semantics are present.

1. Embedded digital references

• Allow embedded digital representation objects in records where that improves interoperability and UI usability.

1. IIIF compatibility

• Preserve both direct image access points and service endpoints when both are available.

1. Deletion semantics guardrail

• Do not synthesize unsupported digital deletion/erasure events in 1.0 workflows.

TDD Additions — Digital Content

Add failing-first tests for digital-content workflows:

Contract-level:

• preserves `DigitalObject` records with `access_point`, `format`, and optional `conforms_to`
• preserves `Creation` event shape on digital objects where present
• rejects or flags malformed digital access points/media shapes

Adapter-level:

• keeps content-carrier separation (`DigitalObject` vs `LinguisticObject`/`VisualItem`)
• preserves surrogate linkage where physical and digital records point at the same `VisualItem`
• preserves `subject_of` → `LinguisticObject` → `digitally_carried_by` web-page pattern
• preserves IIIF manifest and IIIF image service structures (`digitally_available_via` with `DigitalService`)

Route-level:

• inspect/import outputs preserve digital fields without flattening to plain strings only
• resolve/import routes keep IIIF `conforms_to` and `format` metadata when present
• API DTO simplification does not mutate canonical `_source.raw` digital structure

Regression:

• existing physical-object workflows remain stable when digital enrichment is added
• adapter updates do not regress rights/provenance fields while adding digital metadata

Fixture Anchors — Digital Content Examples

Use these official-example patterns as fixture seeds for contract and route tests:

1. Web publication as first-class `DigitalObject`

• `type: DigitalObject`
• `classified_as` includes web page (`aat:300264578`) when applicable
• `access_point` contains the direct human/web resource URL
• `format` preserves media type such as `text/html`
• `conforms_to` can point to relevant standards (for example, HTML)
• `created_by.type` is `Creation`
• `digitally_carries` links the content entity (`LinguisticObject`)

1. Digital surrogate parity pattern

• Physical object `shows` a `VisualItem`
• Digital surrogate `digitally_shows` the same `VisualItem` identifier
• Tests should verify shared visual-content identity across carriers

1. Embedded representation image pattern

• Entity `representation[]` includes `VisualItem`
• `digitally_shown_by[]` contains a `DigitalObject`
• digital image keeps `format` and image `access_point`

1. Web page about an object pattern

• Object `subject_of[]` contains `LinguisticObject`
• `digitally_carried_by[]` contains a `DigitalObject`
• web page classification and `text/html` format remain intact

1. IIIF Presentation manifest pattern

• linked through `subject_of -> LinguisticObject -> digitally_carried_by`
• `conforms_to` includes `http://iiif.io/api/presentation/`
• `format` preserves profile media type (Presentation 3 context)

1. IIIF Image API service pattern

• digital image may include both `access_point` and `digitally_available_via`
• `digitally_available_via[].type` is `DigitalService`
• service `conforms_to` includes `http://iiif.io/api/image/`
• service `format` preserves profile media type (Image 3 context / `info.json`)

---

Round 4 Addendum — Collections and Sets

Source section basis:

• Linked Art Model 1.0: Collections
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Use `Set` for conceptual groupings across many use cases (collections, exhibition sets, auction lots, archival sets, conceptual/person sets).
• `Set` is a Linked Art class introduced outside base CIDOC-CRM to support consistent multi-type grouping semantics.
• Sets are conceptual, not physical aggregations:
• created via `Creation`, not `Production`
• cannot be destroyed in this model
• may have zero members and still exist
• Membership is asserted on the member entity via `member_of` pointing to the set.
• Linked Art API expectations focus membership on core record-capable entities.
• Ordered sets use sort value identifiers (for example, AAT sort value typing) on members, optionally contextualized with `AttributeAssignment` influenced by a specific `Set`.
• Prototypical member description uses `members_exemplified_by` embedded in the `Set`.
• Collection membership should not be conflated with ownership or custody; objects can be members of multiple sets simultaneously.
• Nested collection structures are valid (departmental set `member_of` institutional set), and collection management context can be modeled via set-level activities (for example, curating).

Implementation Mapping — Collections/Sets

Apply these requirements to adapters, normalization, contracts, and route outputs:

1. Set identity and lifecycle

• Preserve `Set` as first-class record type with stable `id`, `type`, names, statements, and optional classification.
• Model set creation with `created_by.type = Creation` where known.

1. Membership directionality

• Preserve `member_of` on member entities; do not require inverse `member` materialization on sets in API responses.

1. Collection-context separation

• Keep collection membership separate from ownership/custody semantics.

1. Ordering semantics

• Preserve sort-value identifiers and contextual assignment patterns when present; do not flatten away set-specific ordering signals.

1. Prototypical member semantics

• Preserve `members_exemplified_by` as descriptive prototype, not as highlighted members or strict universal constraints.

1. Nested set structures

• Preserve set-to-set `member_of` relations for institutional and departmental collection hierarchies.

1. Group compatibility

• Where `Group` records use set-like features (for example, `members_exemplified_by`), preserve semantics without assuming CIDOC-CRM native superclass behavior outside Linked Art context.

TDD Additions — Collections/Sets

Add failing-first tests for set and collection workflows:

Contract-level:

• accepts `Set` with core identity fields and optional statements/classifications
• preserves `created_by` creation semantics for sets
• rejects malformed `member_of` and `members_exemplified_by` structures

Adapter-level:

• preserves `member_of` links on imported member entities
• does not collapse membership into inferred ownership/custody
• preserves set ordering metadata (`Identifier` sort value + optional assignment context)
• preserves `members_exemplified_by` without converting it into concrete membership

Route-level:

• inspect/import outputs preserve set structures and membership links
• collection and entity endpoints return memberships without mutating `_source.raw`
• set-related DTO projections remain additive and do not erase canonical set semantics

Regression:

• object and digital-content workflows remain stable when set membership metadata is introduced
• multi-set membership for a single entity remains supported

Fixture Anchors — Collections/Sets Examples

Use these official-example patterns as fixture seeds:

1. Exhibition object set

• `Set` with primary name, description statement, and `created_by` `Creation`.

1. Member entity linkage

• `HumanMadeObject` with `member_of` pointing to exhibition set.

1. Ordered membership context

• member `Identifier` classified as sort value with optional `AttributeAssignment` influenced by the target set.

1. Prototypical member pattern

• `Set.members_exemplified_by` embedding a prototype entity and typical characteristics.

1. Institutional + departmental collections

• institutional collection `Set`
• departmental collection `Set` as `member_of` institutional set
• departmental curation context modeled via `used_for` activity.

1. Member in curated set

• object with `member_of` departmental collection.

---

Round 5 Addendum — Object Provenance

Source section basis:

• Linked Art Model 1.0: Object Provenance
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Provenance is modeled as a chain of activities across an object's lifecycle.
• A provenance entry is often a wrapper `Activity` ("Provenance Event") that groups multiple granular parts.
• Typical `part` activities can include:
• `Acquisition` (ownership transfer)
• `Payment` (monetary exchange)
• other legal/physical/contextual activities as needed
• Production and destruction are lifecycle boundaries but are modeled using object lifecycle patterns, not the same pattern as wrapper provenance events.
• Provenance event classification is important (for example, provenance activity, gift, purchase-like variants).
• Unknown/approximate chronology can be represented with relative ordering:
• `after`: current event starts after referenced event ends
• `before`: current event ends before referenced event starts
• Provenance can include events beyond ownership transfer:
• custody transfer
• encountering/rediscovery
• rights acquisition
• promises/auction commitments
• movement
• unknown transfer type when evidence is incomplete

Implementation Mapping — Provenance

Apply these requirements to adapters, normalization, and route outputs:

1. Wrapper-event pattern

• Preserve provenance entries as top-level `Activity` wrappers with classifications and optional timespans.

1. Part decomposition

• Preserve granular `part` activities (`Acquisition`, `Payment`, etc.) rather than flattening to narrative strings.

1. Actor/object role integrity

• Preserve explicit transfer/payment roles (`transferred_title_from`, `transferred_title_to`, `paid_from`, `paid_to`, `transferred_title_of`).

1. Monetary structure integrity

• Preserve `MonetaryAmount` + `currency` structures for payment parts when present.

1. Relative-time support

• Preserve `after`/`before` references for events with uncertain absolute dating.

1. Classification precision

• Preserve both broad provenance classification and specific transaction-type classifications.

1. Uncertain transfer handling

• Do not force uncertain evidence into overly specific ownership/custody/movement types; preserve uncertainty safely.

TDD Additions — Provenance

Add failing-first tests for provenance workflows:

Contract-level:

• accepts wrapper provenance `Activity` with `classified_as` and optional `timespan`
• preserves valid `part` arrays with `Acquisition`/`Payment` structures
• rejects malformed transfer-role structures and malformed monetary/currency payloads

Adapter-level:

• normalizes provider provenance entries into wrapper activity + granular part structure
• preserves transfer and payment roles without role collapse
• preserves specific provenance classification terms (for example, gift)
• preserves `after`/`before` relations when explicit dates are absent

Route-level:

• inspect/import outputs preserve provenance wrapper + part structures
• provenance-rich records remain queryable without losing role-specific fields
• DTO simplification does not mutate canonical provenance structure in `_source.raw`

Regression:

• object lifecycle activity fields (production/destruction) are not overwritten by provenance-wrapper logic
• uncertain/unknown transfer records remain represented as uncertain, not force-cast to a specific event type

Fixture Anchors — Provenance Examples

Use these official-example patterns as fixture seeds:

1. Purchase provenance event with payment

• wrapper `Activity` classified as provenance activity
• `part[]` includes:
• `Acquisition` with title transfer roles and object
• `Payment` with `MonetaryAmount` and currency

1. Gift provenance event

• wrapper `Activity` classified as provenance activity + gift
• `part[]` includes `Acquisition` transfer from donor to receiving group/institution

1. Relative-time-only provenance event

• wrapper `Activity` with `after` and/or `before` references
• no requirement for explicit absolute timespan

1. Unknown transfer scenarios

• fixtures where textual evidence is ambiguous; tests assert preservation of uncertainty and non-overstatement of event type.

---

Round 6 Addendum — Acquisitions and Loans

Source section basis:

• Linked Art Model 1.0: Acquisitions and Loans
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Most provenance events involve ownership transfer and are modeled via `Acquisition` parts inside a wrapper provenance `Activity`.
• "Seller" and "buyer" are role labels for transfer clarity, not strictly cash-sale semantics.
• `Acquisition` encodes title transfer:
• `transferred_title_of` (object)
• `transferred_title_from` (relinquishing owner)
• `transferred_title_to` (gaining owner)
• Unknown seller or buyer can be omitted when evidence is incomplete.
• A single provenance event can contain multiple `Acquisition` parts (for example, multiple objects in one transaction).
• Simultaneous co-ownership can be represented by multiple `transferred_title_to` (or `transferred_title_from`) entries when split details are unknown/even.
• If legal ownership is held by a consortium, model consortium as `Group` and use that group as owner.
• Agents can be modeled via `carried_out_by` on acquisition activity; model does not distinguish seller-agent vs buyer-agent semantics.
• Exchanges can be represented by multiple acquisitions with inverse transfer directions.
• Purchases include `Payment` parts with:
• `paid_from`
• `paid_to`
• `paid_amount` (`MonetaryAmount` with `value` + `currency`)
• Separate monetary flows (seller price, commissions, service payments) should be separate `Payment` instances.
• Monetary amounts are face-value constructs; diachronic comparison requires time context of referencing events.
• Loan/custody-centric transfer scenarios are related but documented in custody-specific patterns; do not force custody into ownership transfer semantics.

Implementation Mapping — Acquisitions/Payments

Apply these requirements to adapters, normalization, and route outputs:

1. Ownership transfer fidelity

• Preserve acquisition role edges explicitly; do not collapse into a generic "changed owner" string.

1. Multi-object and multi-party support

• Support arrays in transfer fields to preserve multi-object transactions and co-owner/co-seller patterns.

1. Agent representation

• Preserve acquisition-level `carried_out_by` agents when present.

1. Exchange modeling

• Preserve multi-acquisition exchange structures rather than flattening to one ambiguous transfer.

1. Payment decomposition

• Preserve each payment as a distinct part activity, especially where commissions/services are known.

1. Monetary structure preservation

• Preserve `MonetaryAmount` + `currency` (+ optional notation/classification) without type degradation.

1. Uncertainty discipline

• Where seller/buyer detail is unknown, preserve partial role assertions without speculative completion.

1. Ownership vs custody guardrail

• Do not encode loans/custody movements as title transfers unless evidence explicitly indicates ownership transfer.

TDD Additions — Acquisitions/Payments

Add failing-first tests for acquisition and payment workflows:

Contract-level:

• validates `Acquisition` role structure with object/from/to fields when provided
• allows omitted transfer-role fields for uncertain historical evidence
• validates `Payment` structure with `paid_from`, `paid_to`, and `MonetaryAmount` currency/value

Adapter-level:

• preserves multi-acquisition provenance events for bundled transactions
• preserves multi-party ownership transfer arrays without collapsing to a single actor
• preserves `carried_out_by` agents on acquisition parts
• preserves multiple payment parts (object price + commission/service) as separate events

Route-level:

• inspect/import outputs preserve acquisition/payment part granularity and actor roles
• routes do not synthesize missing seller/buyer values when source evidence is incomplete
• DTO projections preserve canonical `_source.raw` transaction structure

Regression:

• exchange-of-objects scenarios continue to round-trip without role inversion bugs
• commission/service payments do not overwrite or merge with primary seller payment

Fixture Anchors — Acquisitions/Payments Examples

Use these official-example patterns as fixture seeds:

1. Simple acquisition

• wrapper provenance `Activity` with one `Acquisition` transferring one object from seller to buyer.

1. Joint acquisition / multiple owners

• acquisition with multiple `transferred_title_to` entries for co-ownership.

1. Agent-mediated acquisition

• acquisition with `carried_out_by` agent plus explicit seller and buyer.

1. Exchange transaction

• wrapper event with multiple `Acquisition` parts modeling reciprocal transfers.

1. Purchase + payment

• acquisition part plus separate payment part with `MonetaryAmount`.

1. Service/commission payments

• multiple payment parts distinguishing seller payment from commission payment.

---

Round 7 Addendum — Auctions

Source section basis:

• Linked Art Model 1.0: Auctions
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Auction modeling separates several entities/activities:
• overall auction event (`Activity`, auction-event classification)
• auction of a single lot (`Activity`, auction-of-lot classification)
• lot itself as a `Set` of objects
• resulting provenance purchase activity (if sale completes)
• Key vocabulary anchors include:
• Auction Activity (`aat:300054751`)
• Auction of Lot Activity (`aat:300420001`)
• Auction House Organization (`aat:300417515`)
• Auction House Premises (`aat:300005234`)
• Auction Lot (`aat:300411307`)
• Lot Number (`aat:300404628`)
• Auction Catalog (`aat:300026068`)
• Auction event (`Activity`):
• `carried_out_by` auction house `Group`
• `took_place_at` auction house premises `Place`
• timespan/name/classification as regular activity metadata
• Auction of lot (`Activity`):
• `part_of` overall auction event
• references lot set via `used_specific_object`
• may cause provenance purchase event if reserve conditions are met
• Lot modeled as `Set`:
• classified as auction lot
• includes lot number identifier
• membership expressed on member objects via `member_of`
• Pre-set prices (starting/reserve/estimated) are modeled on lot set as monetary dimensions, independent of sale completion.
• Purchase of lot:
• provenance event references set via `used_specific_object`
• has per-object `Acquisition` parts and payment part(s)
• may include agent via `carried_out_by`
• can link back to auction-of-lot via `part_of`
• Auction catalogs are `LinguisticObject` records classified as auction catalogs and can reference auction event via `about`.
• Non-sale outcomes must be represented explicitly without over-asserting ownership transfers:
• lot withdrawn (catalog + lot set, but no auction-of-lot activity)
• object withdrawn from multi-object lot
• reserve not met / bought in
• owner buys own lot
• winner unable to pay

Implementation Mapping — Auctions

Apply these requirements to adapters, normalization, and route outputs:

1. Layer separation

• Preserve distinction between auction event, lot-auction activity, lot set, and resulting provenance purchase.

1. Lot membership directionality

• Preserve lot membership on objects (`member_of`) rather than synthesizing set-owned member lists in canonical data.

1. Event linkage integrity

• Preserve `part_of` links (lot-auction -> auction event, purchase provenance -> lot-auction when known).

1. Price semantics

• Preserve pre-set lot prices as lot-level monetary dimensions, separate from realized payment amounts.

1. Auction-house context

• Preserve place and organization context for auction event (`took_place_at`, `carried_out_by`) with classifications when present.

1. Catalog evidence

• Preserve auction-catalog documents as evidence entities linked through `about`.

1. Outcome discipline

• Do not infer ownership transfer when outcomes indicate no completed sale.
• Preserve custody/commission/bid context separately when available.

1. Multi-object lots

• Preserve per-object acquisition granularity even when one payment covers the lot.

TDD Additions — Auctions

Add failing-first tests for auction workflows:

Contract-level:

• validates auction event and auction-of-lot activity shapes with correct linkage fields
• validates lot set structures with lot number and classification
• validates pre-set price monetary dimensions on lot sets

Adapter-level:

• preserves auction-event vs lot-auction vs purchase-provenance boundaries
• preserves lot membership on member objects via `member_of`
• preserves lot-level estimated/reserve/starting price metadata without merging into sale price
• preserves auction catalog modeling as `LinguisticObject` evidence

Route-level:

• inspect/import outputs preserve auction chain linkage (`part_of`, `used_specific_object`) when present
• purchase-provenance imports preserve per-object acquisition + payment decomposition for lot sales
• non-sale scenarios do not fabricate transfer-of-title events

Regression:

• adding auction metadata does not overwrite existing provenance transfer roles
• multi-lot and multi-object scenarios preserve object-level membership and acquisition details

Fixture Anchors — Auctions Examples

Use these official-example patterns as fixture seeds:

1. Auction event

• auction `Activity` with timespan, auction-house place, and auction-house organization.

1. Auction of lot

• lot-auction `Activity` with auction-of-lot classification, `used_specific_object` set, and `part_of` auction event.

1. Lot set + member object

• lot `Set` with lot-number identifier and object `member_of` link.

1. Pre-set estimated price

• lot `Set` with `dimension` `MonetaryAmount` classified as estimated price.

1. Purchase of lot

• provenance `Activity` referencing lot set, with acquisition part(s) plus payment and `part_of` lot-auction.

1. Auction catalog

• catalog `LinguisticObject` classified as auction catalog and `about` auction event.

1. No-sale outcomes

• fixtures for withdrawn lot, reserve not met, owner buy-back, and winner unable to pay that preserve uncertainty and avoid false ownership-transfer assertions.

---

Round 8 Addendum — Changes of Custody

Source section basis:

• Linked Art Model 1.0: Changes of Custody
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Custody transfer is distinct from ownership transfer.
• Temporary possession changes (loan, return, theft, loss, recovery) are modeled as custody changes, not title changes.
• Custody uses `TransferOfCustody` (not `Acquisition`) with equivalent role fields:
• `transferred_custody_of`
• `transferred_custody_from`
• `transferred_custody_to`
• Loan lifecycle is typically modeled as paired custody transfers (outbound + return), potentially open-ended for active long-term loans.
• Institutional ownership can co-exist with departmental custody:
• institution as owner
• department as current keeper/custodian
• Theft/looting are illegal custody transfers; ownership remains unchanged.
• Lost-object scenarios can omit recipient custodian where unknown.
• Sale of stolen goods should be modeled as custody transfer + payment, not ownership acquisition.

Implementation Mapping — Custody

Apply these requirements to adapters, normalization, and route outputs:

1. Ownership/custody separation

• Do not translate `TransferOfCustody` into `Acquisition` unless evidence explicitly indicates title transfer.

1. Custody role fidelity

• Preserve custody role edges and allow partial role assertions for unknown recipients.

1. Loan pairing semantics

• Preserve paired transfer patterns when present without forcing synthetic return events.

1. Departmental custody

• Preserve departmental custodian context without altering institutional ownership assertions.

1. Theft/loss semantics

• Preserve theft/loss classifications as custody events and avoid ownership mutations.

1. Stolen-sale handling

• Preserve custody-transfer + payment decomposition in stolen-sale scenarios.

TDD Additions — Custody

Add failing-first tests for custody workflows:

Contract-level:

• validates `TransferOfCustody` structures with custody role fields
• allows omitted `transferred_custody_to` in loss/unknown-recipient scenarios
• preserves classification for loan/return/theft/sale-of-stolen-goods cases

Adapter-level:

• preserves distinction between `Acquisition` and `TransferOfCustody`
• preserves departmental custody part in mixed acquisition+custody provenance events
• preserves stolen-sale pattern as custody transfer plus payment

Route-level:

• inspect/import outputs preserve custody part structures and role edges
• routes do not fabricate ownership transfer events from custody-only evidence
• canonical `_source.raw` retains original custody semantics

Regression:

• ownership summaries remain stable when custody events are added
• exhibition-related custody chains do not regress into ownership chains

Fixture Anchors — Custody Examples

Use these official-example patterns as fixture seeds:

1. Loan out

• provenance `Activity` with `TransferOfCustody` classified as loan.

1. Return of loan

• subsequent `TransferOfCustody` reversing from/to custodians.

1. Mixed acquisition and departmental custody

• single provenance event with both `Acquisition` and `TransferOfCustody` parts.

1. Theft event

• `TransferOfCustody` classified as theft.

1. Sale of stolen goods

• custody transfer classified as stolen-goods sale plus payment part.

---

Round 9 Addendum — Exhibitions

Source section basis:

• Linked Art Model 1.0: Exhibitions
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Exhibition modeling separates:
• exhibition activity (`Activity`) at place/time with organizers
• exhibition concept (`PropositionalObject`) representing the abstract idea/theme
• Exhibition activity:
• classify as exhibiting (`aat:300054766`)
• include `timespan`, `took_place_at`, `carried_out_by`
• link exhibited-object set via `used_specific_object`
• link conceptual work via `influenced_by`
• Exhibition concept:
• `PropositionalObject` classified as exhibition (`aat:300417531`)
• can include `about` subjects and `created_by` creators
• can model known artist influence when specific exhibited objects are unknown
• Multi-venue exhibitions:
• each venue is its own exhibition activity
• venue activities may be `part_of` a broader travelling exhibition activity (`aat:300054773`)
• top-level travelling activity should not duplicate venue-specific place/org details
• Exhibition object membership:
• represented through exhibition `Set` and object `member_of`
• venue-specific sets should be used where object lists differ materially
• Provenance integration:
• exhibition-linked custody transfers can be `part_of` exhibition activity
• if owning institution exhibits its own object, movement may apply instead of custody transfer

Implementation Mapping — Exhibitions

Apply these requirements to adapters, normalization, and route outputs:

1. Activity/concept split

• Preserve separate records/structures for exhibition activity and exhibition concept.

1. Venue fidelity

• Preserve per-venue exhibition activities and avoid collapsing multi-venue runs into one venue-level event.

1. Concept linkage

• Preserve `influenced_by` linkage from exhibition activities to concept records.

1. Object-set linkage

• Preserve `used_specific_object` set references and object-side `member_of` membership.

1. Artist-known/object-unknown scenario

• Preserve artist relation on exhibition concept (`about` or concept-creation influence) rather than forcing fake object assertions.

1. Travel hierarchy

• Preserve `part_of` links to travelling exhibition umbrella activities.

1. Provenance integration

• Preserve exhibition-related custody provenance and avoid over-converting to ownership change.

TDD Additions — Exhibitions

Add failing-first tests for exhibition workflows:

Contract-level:

• validates exhibition activity and exhibition concept as distinct entity types
• validates `used_specific_object` linkage to set and object `member_of` membership pattern
• validates travelling exhibition classification and `part_of` structure

Adapter-level:

• preserves venue-specific activity details (time/place/organizer) and concept linkage
• preserves concept-side subject/influence assertions for artist-known/object-unknown data
• preserves venue-specific object sets when input indicates different object lists by venue

Route-level:

• inspect/import outputs keep exhibition activity/concept separation intact
• entity and artwork projections preserve exhibition membership without mutating canonical source
• provenance endpoints/surfaces preserve exhibition custody links where present

Regression:

• exhibitions do not collapse into generic events without exhibition classification
• multi-venue hierarchies remain navigable after import/normalization

Fixture Anchors — Exhibitions Examples

Use these official-example patterns as fixture seeds:

1. Single-venue exhibition activity

• exhibiting `Activity` with timespan/place/organizer, used object set, and concept influence.

1. Exhibition concept

• `PropositionalObject` classified as exhibition with `about` and `created_by`.

1. Artist-known/object-unknown concept variant

• concept creation influenced by artist without asserting specific exhibited object list.

1. Multi-venue exhibition

• venue activity with `part_of` broader travelling exhibition activity.

1. Travelling exhibition umbrella

• top-level multi-location activity with broader timespan and concept influence.

1. Exhibition object set + member object

• exhibition `Set` plus `HumanMadeObject` with `member_of`.

1. Exhibition custody provenance linkage

• custody transfer provenance entries linked `part_of` exhibition activity when applicable.

---

Round 10 Addendum — Encounters with Objects

Source section basis:

• Linked Art Model 1.0: Encounters with Objects
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Encounter events model rediscovery/find scenarios in provenance chains, especially where objects re-enter documented knowledge long after production.
• An object may have multiple encounters over time (encountered, lost, rediscovered).
• Encounter is modeled as `Encounter` activity part within a provenance wrapper `Activity`.
• `Encounter` has dedicated object linkage via `encountered` to distinguish found object(s) from other objects used in related activities.
• Encounter actors are linked via `carried_out_by` on the encounter activity.
• Ownership/custody consequences are not implicit:
• ownership transfer should be modeled explicitly (for example, adjacent `Acquisition` part)
• custody-only outcomes should remain custody semantics
• Encounter can be modeled directly in object descriptions in simpler scenarios, even without full ownership transfer logic.

Implementation Mapping — Encounters

Apply these requirements to adapters, normalization, and route outputs:

1. Encounter activity preservation

• Preserve `Encounter` as an explicit activity type; do not flatten into narrative notes.

1. Dedicated encountered linkage

• Preserve `encountered` object relations distinctly from `used_specific_object` or transfer-role fields.

1. Actor/event integrity

• Preserve encounter actors in `carried_out_by` and keep encounter-specific metadata on the encounter part.

1. Ownership/custody explicitness

• Do not infer title transfer from encounter alone.
• Preserve explicit ownership (`Acquisition`) or custody (`TransferOfCustody`) parts when present in the same provenance event.

1. Multi-encounter support

• Support repeated encounters in chains without overwriting prior encounter history.

1. Archaeological uncertainty guardrail

• Preserve partial/uncertain encounter context without inventing missing chronology or legal outcomes.

TDD Additions — Encounters

Add failing-first tests for encounter workflows:

Contract-level:

• validates `Encounter` parts with `encountered` linkage and optional `carried_out_by`
• rejects malformed encounter object references
• permits encounter events with or without adjacent acquisition/custody parts

Adapter-level:

• preserves encounter parts in normalized provenance chains
• preserves combined encounter + acquisition pattern when source indicates ownership transfer on discovery
• preserves encounter-only cases without fabricating ownership changes

Route-level:

• inspect/import outputs preserve encounter activity structure and object references
• route responses maintain explicit distinction between encounter, acquisition, and custody parts
• canonical `_source.raw` encounter content remains unmutated

Regression:

• existing acquisition/custody logic remains stable when encounter parts are introduced
• multi-encounter histories do not collapse into a single event

Fixture Anchors — Encounters Examples

Use these official-example patterns as fixture seeds:

1. Encounter with ownership transfer

• wrapper provenance `Activity` containing:
• `Encounter` part (`carried_out_by` + `encountered`)
• `Acquisition` part transferring title to discoverer entity.

1. Encounter without explicit ownership transfer

• encounter part present, no acquisition part; tests assert no inferred title transfer.

1. Encounter chain continuity

• multiple encounter events across time with distinct IDs and preserved ordering/links.

---

Round 11 Addendum — Location and Movement

Source section basis:

• Linked Art Model 1.0: Location and Movement
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Object location is, in principle, derivable from movement history; many CH systems only track selected movement events.
• Movement tracking is especially useful for:
• display/storage transitions
• exhibition display where ownership/custody might not change
• moves between facilities (storage, conservation, galleries)
• scenarios coupled with departmental custody transfer
• Movement is modeled with `Move` activity parts within provenance/event wrappers.
• `Move` captures:
• `moved` (object)
• `moved_from` (origin place)
• `moved_to` (destination place)
• Movement is semantically separate from ownership (`Acquisition`) and custody (`TransferOfCustody`), though they may co-occur in the same broader event chain.

Implementation Mapping — Movement

Apply these requirements to adapters, normalization, and route outputs:

1. Movement activity preservation

• Preserve `Move` as explicit activity structure; do not collapse to plain location strings.

1. Origin/destination integrity

• Preserve both `moved_from` and `moved_to` place nodes when known.

1. Movement/object linkage

• Preserve `moved` object references distinctly from ownership/custody role edges.

1. Co-occurring event separation

• When movement and custody changes co-occur, preserve each as separate parts in the same wrapper activity/event chain.

1. Display/exhibition movement support

• Preserve movement-only exhibition/display scenarios without forcing ownership or custody transfer.

1. Current-location inference guardrail

• Do not overwrite canonical history with inferred present location; keep derived views separate from source event history.

TDD Additions — Movement

Add failing-first tests for movement workflows:

Contract-level:

• validates `Move` parts with `moved`, `moved_from`, and `moved_to` structures
• rejects malformed place/object references in movement parts
• allows movement events without acquisition/custody parts

Adapter-level:

• preserves movement events as structured `Move` parts during normalization
• preserves co-occurring movement + custody structures without semantic merging
• preserves movement-only exhibition/internal-transfer scenarios

Route-level:

• inspect/import outputs retain movement part structure and place references
• routes do not synthesize ownership changes from movement-only evidence
• canonical `_source.raw` movement history remains unmutated

Regression:

• existing ownership/custody summaries remain stable when movement events are added
• derived location views do not erase historical movement events

Fixture Anchors — Movement Examples

Use these official-example patterns as fixture seeds:

1. Routine move between two galleries

• wrapper provenance `Activity` with one `Move` part:
• `moved` object
• `moved_from` place
• `moved_to` place

1. Movement with departmental handoff

• event chain where movement and custody transfer are both present as separate parts.

1. Exhibition-owned-object move

• movement event for institution-owned object used in exhibition context without custody transfer.

---

Round 12 Addendum — Promised Activities

Source section basis:

• Linked Art Model 1.0: Promised Activities
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Promises model planned future actions (gift, sale, exchange, commission-related obligations) that may precede final ownership transfer.
• Promise uses activity classification with the required vocabulary term:
• Promise (`aat:300435599`)
• Current model does not fully model the future planned event object directly; promise context is expressed via:
• `participant` (promised party/counterparty)
• `used_specific_object` (promised object when known)
• descriptive note (`referred_to_by`) for contract/terms details
• Promised gift pattern:
• promise activity carried out by promisor
• participant references intended recipient
• object referenced via `used_specific_object`
• Commissioning pattern can include paired promises:
• commissioner promise to pay
• artist promise to produce
• Later production, title transfer, and payment settlement remain separate lifecycle/provenance events using their standard patterns.

Implementation Mapping — Promises

Apply these requirements to adapters, normalization, and route outputs:

1. Promise classification integrity

• Preserve promise activities as `Activity` parts classified as `Promise` (`aat:300435599`).

1. Obligation context preservation

• Preserve promisor (`carried_out_by`), participant/counterparty, and promised object links where present.

1. Contract/terms evidence

• Preserve descriptive statements on promise activities for legal/contractual context.

1. Future-event separation

• Do not collapse promises into completed acquisitions/payments/productions.
• Keep promise events separate from eventual fulfillment events.

1. Commission pair modeling

• Preserve dual-obligation structures in commission scenarios when both sides are known.

1. Unfulfilled/open promise support

• Preserve open promise state without fabricating completion events.

TDD Additions — Promised Activities

Add failing-first tests for promised-activity workflows:

Contract-level:

• validates promise activity parts with required promise classification
• validates optional `participant`, `used_specific_object`, and descriptive note structures
• rejects malformed promise activity payloads and role/link fields

Adapter-level:

• preserves promised-gift pattern (promisor + object + recipient) without converting to acquisition
• preserves commissioning paired promises (pay obligation + produce obligation) as separate parts
• preserves commission/provenance classifications when present

Route-level:

• inspect/import outputs retain promise activity parts and contract-note descriptions
• routes do not synthesize title transfer or payment completion from promise-only evidence
• canonical `_source.raw` promise structures remain unmutated

Regression:

• existing acquisition/payment/production chains remain stable when promise events are introduced
• later fulfillment events can co-exist without overwriting original promise records

Fixture Anchors — Promised Activities Examples

Use these official-example patterns as fixture seeds:

1. Promised gift

• wrapper provenance `Activity` containing promise-classified part with:
• promisor (`carried_out_by`)
• promised object (`used_specific_object`)
• recipient (`participant`)
• descriptive note for promise context

1. Commissioning pair

• wrapper provenance `Activity` classified as commissioning with two promise parts:
• obligation to pay artist
• obligation to produce artwork

1. Promise without fulfillment

• promise record with no immediate acquisition/payment/production part; tests assert no inferred completion.

---

Round 13 Addendum — Transfer of Rights

Source section basis:

• Linked Art Model 1.0: Transfer of Rights
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Some provenance scenarios require explicit modeling of rights rather than only title-transfer shorthand.
• `Acquisition` is concise for standard ownership transfer, but explicit `Right` modeling is needed for complex right states (partial shares, IP rights, etc.).
• Rights are conceptual entities with key properties:
• `possessed_by` (holder)
• `applies_to` (thing the right concerns)
• Rights transitions are modeled with `RightAcquisition` activity parts using:
• `establishes` (newly established right instances)
• `invalidates` (rights superseded/terminated by the change)
• It is valid (but often redundant) to include both `Acquisition` and `RightAcquisition` in the same provenance entry.
• Shared ownership with uneven stakes:
• partition ownership right into component rights (`part`)
• represent proportions using `Dimension` with percent unit
• Subsequent share transfers should model the new resulting state directly (establish new rights, invalidate prior rights).
• Intellectual property and other non-physical rights can be modeled with the same `RightAcquisition` pattern.

Implementation Mapping — Rights

Apply these requirements to adapters, normalization, and route outputs:

1. Right model activation

• Use explicit `Right` + `RightAcquisition` when acquisition shorthand would lose legal/state detail.

1. Right-holder/object linkage

• Preserve `possessed_by` and `applies_to` links for every explicit right record.

1. State-transition integrity

• Preserve `establishes`/`invalidates` pairs as explicit state transitions, not implicit deltas.

1. Share partitioning

• Preserve ownership-share partitions as child rights with quantitative dimensions.

1. Result-state modeling

• For share trades, represent the post-transaction right state explicitly; do not rely on inferred arithmetic-only deltas.

1. Acquisition coexistence

• Where both acquisition and right transitions are present, preserve both without forcing deduplication.

1. IP-right support

• Preserve copyright/performance/right-type classifications independent of physical carrier transfers.

TDD Additions — Rights

Add failing-first tests for rights workflows:

Contract-level:

• validates `Right` structures with `possessed_by` and `applies_to`
• validates `RightAcquisition` with `establishes` and optional `invalidates`
• validates share dimensions and measurement units for partitioned ownership rights

Adapter-level:

• preserves explicit rights transitions when source includes complex ownership/legal data
• preserves partitioned ownership rights and per-holder percentages
• preserves invalidation of superseded rights in share-transfer scenarios
• preserves IP-right acquisitions without conflating with physical ownership transfer

Route-level:

• inspect/import outputs retain `RightAcquisition` transitions and right partitions
• routes do not collapse explicit rights models into flat acquisition-only summaries
• canonical `_source.raw` rights structures remain unchanged by DTO projections

Regression:

• simple acquisition paths remain stable and concise where explicit rights are unnecessary
• mixed records (acquisition + rights + payments) maintain cross-part consistency

Fixture Anchors — Rights Examples

Use these official-example patterns as fixture seeds:

1. Basic right establishment alongside acquisition

• provenance wrapper with `Acquisition` plus `RightAcquisition.establishes` ownership right.

1. Uneven shared ownership

• total ownership right partitioned into component rights with percent dimensions per holder.

1. Share transfer between existing owners

• rights transition where new shares are established and prior shares invalidated.

1. Intellectual property right acquisition

• `RightAcquisition` establishing copyright-like right held by organization and applied to artwork.

---

Round 14 Addendum — Unknown Transfers

Source section basis:

• Linked Art Model 1.0: Unknown Transfers
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Historical evidence can be insufficient to determine whether a transfer was ownership, custody, loan, or another mechanism.
• To avoid false precision, model ambiguous exchanges with `Transfer` rather than forcing `Acquisition`, `TransferOfCustody`, or right-transfer semantics.
• `Transfer` has dedicated role properties:
• `transferred` (object(s))
• `transferred_from` (source actor(s))
• `transferred_to` (destination actor(s))
• This mirrors other transfer-like activity parts while preserving indeterminacy.

Implementation Mapping — Unknown Transfers

Apply these requirements to adapters, normalization, and route outputs:

1. Uncertainty-first modeling

• Use `Transfer` when source evidence is ambiguous about legal/physical semantics.

1. No forced disambiguation

• Do not auto-convert ambiguous transfers to acquisition, custody, move, or rights transfer.

1. Role fidelity

• Preserve `transferred`, `transferred_from`, and `transferred_to` structures as provided.

1. Future refinement safety

• Allow later evidence to supersede/augment ambiguous transfer entries without destructive rewrites.

1. Provenance-chain continuity

• Keep unknown transfers in chronology so event ordering remains intact even when semantics are partial.

TDD Additions — Unknown Transfers

Add failing-first tests for unknown-transfer workflows:

Contract-level:

• validates `Transfer` parts with `transferred`, `transferred_from`, `transferred_to`
• rejects malformed transfer role structures
• supports transfer entries with sparse contextual metadata when evidence is limited

Adapter-level:

• preserves ambiguous source records as `Transfer` instead of over-classifying
• preserves actor/object role edges without semantic coercion

Route-level:

• inspect/import outputs retain `Transfer` part type and fields unchanged
• routes do not fabricate ownership/custody outcomes from ambiguous transfer records
• canonical `_source.raw` uncertainty semantics remain unmutated

Regression:

• known acquisition/custody/move workflows remain unaffected when `Transfer` parts are introduced
• future enrichment paths can add precise events without deleting prior uncertain records

Fixture Anchors — Unknown Transfers Examples

Use these official-example patterns as fixture seeds:

1. Ambiguous person-to-person transfer

• wrapper provenance `Activity` with one `Transfer` part:
• `transferred` object
• `transferred_from` person/group
• `transferred_to` person/group
• no assertion of ownership, custody, or permanence.

---

Round 15 Addendum — Conservation

Source section basis:

• Linked Art Model 1.0: Conservation
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Conservation modeling includes:
• condition assessment (state/damage identification)
• conservation intervention activities (physical modifications)
• conservation projects as wrapper activities
• Condition assessment pattern:
• represented via `AttributeAssignment` on the object (`attributed_by`)
• uses `assigned_property` (for example `classified_as`) and `assigned` condition types
• can include description, timespan, actor, and `part_of` project linkage
• Conservation intervention pattern:
• represented via `Modification` on object (`modified_by`)
• can include technique, description, timespan, actor, and `part_of` project linkage
• Conservation project pattern:
• top-level wrapper `Activity` with conservation classification
• regular activity metadata (name, description, timespan, actors) describing overall context
• Conservation links to other model areas:
• statements for object state and conservation context
• sampling/production-by-removal patterns in object production sections

Implementation Mapping — Conservation

Apply these requirements to adapters, normalization, and route outputs:

1. Assessment/intervention separation

• Preserve condition assessments (`AttributeAssignment`) separately from intervention work (`Modification`).

1. Assignment semantics

• Preserve `assigned_property` and `assigned` condition types without collapsing into plain narrative text.

1. Intervention detail preservation

• Preserve `technique`, actor, timespan, and descriptions on modification activities.

1. Project wrapper integrity

• Preserve conservation project wrapper `Activity` and `part_of` links from assessments/modifications.

1. Multi-object project support

• Allow one project to contextualize many object-level assessments/modifications without duplicating project metadata per object.

1. No provenance-role coercion

• Do not coerce conservation activities into ownership/custody transfer semantics.

TDD Additions — Conservation

Add failing-first tests for conservation workflows:

Contract-level:

• validates object-level `attributed_by` condition-assessment structures
• validates object-level `modified_by` conservation-modification structures
• validates project-level conservation activity structures and classification

Adapter-level:

• preserves condition assignment structure (`assigned_property`, `assigned`) during normalization
• preserves modification technique + temporal/actor metadata
• preserves `part_of` links tying granular events to conservation project wrapper

Route-level:

• inspect/import outputs retain conservation assessment and modification structures without flattening
• routes preserve project wrappers and links across object and event views
• canonical `_source.raw` conservation data remains unmutated

Regression:

• conservation metadata does not overwrite core classification/title fields
• adding project context does not remove object-level condition/intervention details

Fixture Anchors — Conservation Examples

Use these official-example patterns as fixture seeds:

1. Condition assessment on object

• `HumanMadeObject` with `attributed_by` `AttributeAssignment`:
• condition assignment via `assigned_property` + `assigned`
• description/timespan/actor
• `part_of` conservation project

1. Conservation intervention on object

• `HumanMadeObject` with `modified_by` `Modification`:
• conservation description
• technique classification
• timespan/actor
• `part_of` conservation project

1. Conservation project wrapper

• conservation `Activity` with name/description/timespan and multiple actors.

---

Round 16 Addendum — People and Organizations

Source section basis:

• Linked Art Model 1.0: People and Organizations
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Actors in Linked Art are modeled as:
• `Person` (human individual)
• `Group` (collective of humans, including organizations and other defined sets)
• If actor type is uncertain between person/group, `Group` is the safer default.
• Core actor modeling goals are disambiguation and historical role clarity, not exhaustive biography/social-graph capture.
• Identity and equivalence patterns:
• names via `identified_by` (`Name`, optionally partitioned into typed parts)
• external alignment via `equivalent`
• Contact and residence:
• contact details via `contact_point` (`Identifier`-based, not `Name`)
• place-based residence via `residence` (`Place`)
• Actor lifecycle and activity context:
• person events: `born`, `died`
• group events: `formed_by`, `dissolved_by`
• active professional period via embedded `carried_out` activity classified as professional activities
• participation-only events via `participated_in` when actor is participant, not responsible agent
• Classification patterns for actor descriptors:
• nationality as typed classification
• ethnicity/culture as typed classification
• gender as typed classification
• occupation as typed classification
• Organizational membership:
• member relation asserted via `member_of` from member person/group to parent group.

Implementation Mapping — People/Organizations

Apply these requirements to adapters, normalization, and route outputs:

1. Actor-type discipline

• Preserve `Person` vs `Group` distinctions; use `Group` fallback for ambiguous actor references.

1. Name modeling depth

• Preserve primary names and typed name parts when available; do not flatten multi-part names into a single untyped label only.

1. External reconciliation safety

• Preserve `equivalent` links to authority records without collapsing local record identity.

1. Contact/residence separation

• Keep `contact_point` identifier semantics separate from `residence` place semantics.

1. Lifecycle event correctness

• Preserve birth/death for persons and formation/dissolution for groups with event/timespan/place context.

1. Responsibility vs participation

• Preserve distinction between activities the actor carried out (`carried_out`) and events they participated in (`participated_in`).

1. Descriptor classifications

• Preserve meta-classified actor descriptors (nationality, ethnicity, gender, occupation) without coercing them into group membership constructs.

1. Membership directionality

• Preserve `member_of` from member records; do not require synthetic inverse membership arrays in canonical records.

TDD Additions — People/Organizations

Add failing-first tests for actor workflows:

Contract-level:

• validates `Person`/`Group` identity structures with names/classifications
• validates lifecycle event structures (`born`/`died`, `formed_by`/`dissolved_by`)
• validates `contact_point`, `residence`, and `equivalent` structures

Adapter-level:

• preserves typed name parts and actor descriptor classifications
• preserves actor activity distinctions (`carried_out` vs `participated_in`)
• preserves uncertain actor references as `Group` when person/group ambiguity is unresolved

Route-level:

• inspect/import outputs retain actor identity, descriptor, and lifecycle event structures
• entity profile projections preserve membership and descriptor metadata without mutating `_source.raw`
• routes do not convert contact identifiers into name statements or place records incorrectly

Regression:

• actor enrichment does not break provenance role links (`carried_out_by`, transfer parties, etc.)
• external-equivalent reconciliation does not overwrite local actor IDs

Fixture Anchors — People/Organizations Examples

Use these official-example patterns as fixture seeds:

1. Person as group member

• `Person` with `member_of` `Group`.

1. Primary and partitioned names

• primary name with typed parts (given/middle/family).

1. External equivalent alignment

• actor with `equivalent` link to authority URI.

1. Contact and residence

• actor with multiple `contact_point` identifiers and separate `residence` place.

1. Lifecycle events

• person birth/death and group formation examples.

1. Active professional period

• `carried_out` activity classified as professional activities with timespan.

1. Participation event

• `participated_in` burial-style activity with time/place.

1. Descriptor classifications

• nationality, ethnicity, gender, and occupation typed classifications.

---

Round 17 Addendum — Places

Source section basis:

• Linked Art Model 1.0: Places
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• `Place` is foundational for activity location, object location context, and actor residence/association.
• Places are spatial extents independent of time and independent of what currently occupies that space.
• Place model supports:
• core identity metadata (names, identifiers, statements, classifications, equivalents)
• spatial hierarchy via `part_of`
• geospatial geometry via `defined_by` (WKT string)
• Geospatial data can range from detailed polygons to approximations/bounding proxies.
• Approximate location can be represented as a more specific place `part_of` a broader known place.
• Buildings and other "immovable" works remain `HumanMadeObject` records with location references; activities occur at `Place`, not at the object itself.

Implementation Mapping — Places

Apply these requirements to adapters, normalization, and route outputs:

1. Place identity preservation

• Preserve place core metadata and classifications without collapsing into plain location strings.

1. Hierarchy integrity

• Preserve `part_of` place hierarchy links to support spatial navigation and context.

1. Geometry fidelity

• Preserve `defined_by` WKT geometry exactly when supplied.

1. Approximation semantics

• Preserve approximate/specific place modeling via `part_of` rather than forcing uncertain coordinates.

1. Place vs object separation

• Keep built works as objects (`HumanMadeObject`) and their spatial context as `Place`.

1. Activity location discipline

• Preserve event/activity location references as `Place` nodes, not building objects.

1. Immovable-object handling

• Support large/fixed-seeming works as movable-or-locatable objects with `current_location` place references when modeled that way.

TDD Additions — Places

Add failing-first tests for place workflows:

Contract-level:

• validates `Place` entities with core identity metadata and classifications
• validates `defined_by` string preservation for WKT geometry values
• validates hierarchical `part_of` place references

Adapter-level:

• preserves place hierarchy and descriptive statements during normalization
• preserves WKT geometry and does not coerce it to unsupported formats
• preserves approximation patterns (specific place within broader place)

Route-level:

• inspect/import outputs retain place hierarchy and geometry fields
• routes do not convert place references into object references for activity locations
• canonical `_source.raw` place data remains unmutated

Regression:

• immovable-object records remain objects with place references rather than being converted into place entities
• map-oriented fields remain stable across provider imports

Fixture Anchors — Places Examples

Use these official-example patterns as fixture seeds:

1. Place with hierarchy and description

• city `Place` with classification, name/description, and `part_of` nation.

1. Place with WKT geometry

• nation `Place` with polygon in `defined_by`.

1. Approximate sub-location

• specific location place with `part_of` broader city place.

1. Building as object + place location

• building `HumanMadeObject` classified as building with `current_location` place.

---

Round 18 Addendum — Concepts

Source section basis:

• Linked Art Model 1.0: Concepts
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Concepts represent units of thought used for classification and semantic alignment.
• Linked Art typically reuses external vocabularies (especially AAT), with local concept records allowed when needed.
• Core concept classes:
• `Type` (general concept class)
• `Currency`
• `Language`
• `Material`
• `MeasurementUnit`
• Class specificity should be preserved where known (do not default everything to generic `Type` unnecessarily).
• `equivalent` links are critical for interoperability when local concept records mirror or extend external concepts.
• Concept relationships have distinct semantics:
• `broader` for hierarchical/generalization relationships
• `classified_as` for meta-type/category relationships
• `member_of` for concept-scheme/set grouping (orthogonal to hierarchy and meta-typing)
• Coordinated concepts involving non-concept entities are modeled via `created_by.influenced_by` (for example, concept + place).
• Model is aligned with SKOS patterns; concept schemes map well to `Set`.

Implementation Mapping — Concepts

Apply these requirements to adapters, normalization, and route outputs:

1. Concept class fidelity

• Preserve specific concept subclasses (`Currency`, `Language`, `Material`, `MeasurementUnit`) when present.

1. Interoperability equivalence

• Preserve `equivalent` links on local concept records and concept references to maintain cross-system semantics.

1. Hierarchy vs meta-type distinction

• Preserve `broader` and `classified_as` as distinct relations; do not conflate them.

1. Scheme/set grouping

• Preserve `member_of` concept scheme/set links independently of hierarchy and classification.

1. Coordinated concept creation

• Preserve `created_by.influenced_by` links for concept coordination involving non-concept entities.

1. Local concept safety

• Allow local concept records to carry additional metadata while keeping explicit external equivalence anchors.

1. SKOS compatibility guardrail

• Keep concept structures transform-friendly for SKOS-style mappings (labels/notes/broader/scheme).

TDD Additions — Concepts

Add failing-first tests for concept workflows:

Contract-level:

• validates concept class records (`Type` and specialized subclasses) with core identity metadata
• validates `equivalent`, `broader`, `classified_as`, and `member_of` structures
• rejects malformed concept hierarchy and equivalence payloads

Adapter-level:

• preserves local concept records with external equivalence links
• preserves distinction between broader hierarchy and meta-type classification
• preserves concept-scheme memberships without rewriting as hierarchy links
• preserves coordinated concept influences including non-concept entities

Route-level:

• inspect/import outputs retain concept class/relationship semantics
• routes do not collapse concept links to plain labels only
• canonical `_source.raw` concept structures remain unmutated by DTO projection

Regression:

• object/person/place classification references remain stable when concept records are normalized locally
• concept enrichments do not break rights/material/language/unit references across records

Fixture Anchors — Concepts Examples

Use these official-example patterns as fixture seeds:

1. Minimal concept record

• basic `Type` concept with ID and label.

1. Local concept with external equivalent

• local concept primary name plus `equivalent` AAT concept.

1. Concept reference with embedded equivalent

• object classification referencing local concept with explicit external equivalent.

1. Broader + meta-type distinction

• concept with both `broader` and `classified_as` relationships.

1. Concept scheme membership

• concept `member_of` concept-scheme `Set`.

1. Coordinated concept creation influence

• concept `created_by.influenced_by` including both concept and place entities.

---

Round 19 Addendum — Events

Source section basis:

• Linked Art Model 1.0: Events
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Temporal entities include:
• `Period` (time span construct, often conventionally bounded)
• `Event` (occurrence that changes state, not necessarily intentional)
• `Activity` (intentional human-carried occurrence)
• These temporal records are often contextual entities separate from specific object lifecycle/provenance/exhibition models.
• Causality:
• events/activities can reference preceding causes via `caused_by`
• causal events should be first-class records when shared across objects/works/events
• Event relationship semantics must remain distinct:
• `part_of`: strict partition hierarchy
• `during`: inclusion/context without partition semantics
• Relative ordering for uncertain chronology:
• `before`
• `after`
• Relative ordering is especially useful where absolute dates are unknown but sequence is known.

Implementation Mapping — Events

Apply these requirements to adapters, normalization, and route outputs:

1. Temporal class fidelity

• Preserve `Period`/`Event`/`Activity` distinctions without collapsing to generic activity types.

1. Causal-link preservation

• Preserve `caused_by` links as explicit references to causal entities.

1. Partition vs inclusion discipline

• Preserve `part_of` and `during` with their distinct semantics; do not interchange automatically.

1. Relative chronology support

• Preserve `before`/`after` relations for uncertain or partially ordered timelines.

1. Shared-context entity reuse

• Reuse canonical event IDs in references so multiple records can point to the same contextual event.

1. Temporal metadata integrity

• Preserve timespan and place metadata on temporal entities without flattening to display-only labels.

TDD Additions — Events

Add failing-first tests for event workflows:

Contract-level:

• validates `Period`, `Event`, and `Activity` structures with core identity/timespan fields
• validates `caused_by`, `part_of`, `during`, `before`, and `after` relationship structures
• rejects malformed temporal relation payloads

Adapter-level:

• preserves causal chains without role inversion
• preserves `part_of` vs `during` distinction in normalized timelines
• preserves relative ordering fields when no absolute timespan exists

Route-level:

• inspect/import outputs retain temporal class and relation semantics
• routes do not fabricate exact dates from relative ordering alone
• canonical `_source.raw` temporal relationships remain unmutated

Regression:

• provenance/exhibition timelines remain stable with added contextual period/event references
• causal event references remain reusable across multiple object/activity records

Fixture Anchors — Events Examples

Use these official-example patterns as fixture seeds:

1. Period with bounded timespan

• period record (for example, century) with explicit begin/end bounds.

1. Causal event chain

• event record (for example, eruption) referenced as `caused_by` from a destruction/lifecycle event.

1. `part_of` hierarchy

• sub-period/activity linked to a broader parent period/activity via `part_of`.

1. `during` inclusion

• event/activity linked as occurring `during` a period.

1. Relative ordering without exact date

• production or activity with `before`/`after` relation to another event.

---

Round 20 Addendum — About Vocabulary Terms

Source section basis:

• Linked Art Model 1.0: About Vocabulary Terms
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Linked Art relies on vocabulary reuse for semantic interoperability across broad classes.
• Class-level interoperability alone is insufficient; classification-term interoperability is required for comparable analytics and UX.
• Vocabulary requirement classes:
• required terms: mandatory for Linked Art conformance
• recommended terms: expected unless a concrete reason prevents use
• optional terms: available but not compulsory
• Acceptable vocabulary-linking patterns for conformance:
• direct vocabulary URI in `id`
• local/intermediary concept in `id` with external vocabulary URI in `equivalent`
• Vocabulary list change policy:
• required list: changed/removed only in major versions; additions may arrive in minor versions
• recommended list: may change in minor versions
• optional list: informational, can change anytime

Implementation Mapping — Vocabulary Terms

Apply these requirements to adapters, normalization, and route outputs:

1. Requirement-class awareness

• Treat required terms as conformance-critical in validation and import checks.

1. Stable mapping strategy

• Support both direct-`id` and `equivalent`-bridged vocabulary linking without semantic loss.

1. Local concept interoperability

• When local concepts are used, preserve explicit `equivalent` links to canonical external terms.

1. Non-destructive normalization

• Do not rewrite local concept IDs to external IDs if local records carry additional context; preserve both layers.

1. Version-aware validation

• Design validators to handle evolving recommended/optional lists without breaking prior data unnecessarily.

1. Classifier consistency

• Preserve `classified_as` arrays in source order and content; avoid silent dropping of unknown-yet-valid terms.

TDD Additions — Vocabulary Terms

Add failing-first tests for vocabulary conformance workflows:

Contract-level:

• validates required-term usage for constrained fields where Linked Art mandates specific terms
• validates `classified_as` references with direct vocabulary URIs
• validates local term records with `equivalent` references to canonical vocab terms

Adapter-level:

• preserves both vocabulary-link patterns (`id` direct vs `equivalent` bridge)
• preserves local concept metadata while retaining external semantic anchors
• does not downgrade required/recommended classification references during normalization

Route-level:

• inspect/import outputs retain vocabulary semantics and do not collapse intermediary concepts
• validation responses clearly distinguish required-term failures from recommended-term advisories
• canonical `_source.raw` vocabulary links remain unchanged

Regression:

• introducing new recommended terms does not break existing records that remain conformant
• analytics/classification faceting still resolves equivalent-linked local concepts correctly

Fixture Anchors — Vocabulary Terms Examples

Use these official-example patterns as fixture seeds:

1. Direct vocabulary ID usage

• object classification where `classified_as[].id` is canonical external vocabulary URI.

1. Local term with equivalent mapping

• object classification where local concept `id` includes `equivalent` to canonical external vocabulary URI.

1. Mixed dataset compatibility

• dataset fixtures containing both patterns; tests assert consistent downstream classification behavior.

---

Round 21 Addendum — Required Terms

Source section basis:

• Linked Art Model 1.0: Required Terms
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Required terms are conformance-critical: when the concept is present, the required URI must be used.
• Not every record must contain every required term; requirement applies when the modeled concept exists.
• Full URI form must be used in data payloads.
• Required term coverage includes:
• Name/identifier control terms (primary name, display name, sort name, sort value)
• Meta-type control terms (statement, type of work, style, shape, occupation, nationality)
• Color classification on `Dimension`
• Activity flags (exhibition, provenance, professional, publication, promise)
• Broad item flags (collection item, artwork)
• Required term link style can be either:
• direct vocabulary URI in `id`
• intermediary/local term with canonical URI in `equivalent`
• Term-list version policy differs by requirement class; required list is stricter and changes more conservatively.

Implementation Mapping — Required Terms

Apply these requirements to adapters, normalization, validation, and route outputs:

1. Required-term enforcement

• Validate required URI usage whenever corresponding concepts are asserted in records.

1. URI canonicalization policy

• Preserve full canonical URIs in stored/served data; avoid namespace shorthand in canonical JSON-LD payloads.

1. Equivalent-bridge acceptance

• Accept intermediary/local term IDs when canonical required term appears in `equivalent`.

1. Name term semantics

• Preserve:
• primary names for core display identity
• display names for UI labeling
• sort name/sort value for ordering logic
• Enforce uniqueness constraints where modeled (for example, one sort value per entity).

1. Meta-type correctness

• Preserve meta-type classifications that disambiguate statement/type-of-work/style/shape/nationality/occupation semantics.

1. Activity flag correctness

• Preserve required activity classifications for exhibition/provenance/professional/publication/promise contexts.

1. Color-dimension rule

• Preserve required color classification on `Dimension` when color is modeled.

1. Item-flag preservation

• Preserve collection-item/artwork flags where explicitly present; do not infer silently without evidence.

TDD Additions — Required Terms

Add failing-first tests for required-term conformance workflows:

Contract-level:

• validates required term URIs on:
• primary/display/sort names and sort identifiers
• required activity classifications
• required meta-type classifications
• color dimensions and collection/artwork flags when present
• validates intermediary+equivalent pattern as conformant alternative to direct URI IDs

Adapter-level:

• preserves required-term classifications through normalization
• preserves sort-name/sort-value semantics and cardinality expectations
• does not remap required terms to non-canonical alternatives

Route-level:

• inspect/import validation distinguishes:
• required-term failures (hard errors)
• recommended/optional advisories (non-blocking)
• outputs retain required-term URIs and equivalent bridges unchanged
• canonical `_source.raw` is not rewritten destructively during term normalization

Regression:

• evolving recommended/optional term lists do not break required-term validations
• faceting/search keyed on required terms remains stable across providers

Fixture Anchors — Required Terms Examples

Use these official-example patterns as fixture seeds:

1. Primary name + language

• entity with `Name` classified as primary name and language notation.

1. Display name on statement/timespan

• display-name classification used as UI label for statement or timespan.

1. Sort name and sort value

• separate fixtures for linguistic sort name and non-linguistic sort value.

1. Meta-type disambiguation

• statement/type-of-work/style/shape/nationality/occupation classifications.

1. Color dimension

• `Dimension` with required color classification and optional numeric/unit payload.

1. Activity flags

• exhibition/provenance/publication/professional/promise activity classifications.

1. Collection and artwork flags

• object-level required flags for collection-item/artwork categorization.

1. Equivalent-bridge conformance

• intermediary local term with canonical required URI in `equivalent`.

---

Round 22 Addendum — Recommended Terms

Source section basis:

• Linked Art Model 1.0: Recommended Terms
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Recommended terms are strongly advised for interoperability but are not strict conformance blockers.
• Diverging from recommended terms remains valid Linked Art, but should be deliberate and documented.
• Recommended term clusters include:
• name types (alternate/given/middle/family/former)
• identifier types (accession/local/system/call numbers)
• statement types (note/description/materials/provenance/rights/etc.) with statement meta-type usage
• object/place/group/digital/set/dimension type vocabularies
• common instances (languages, units, materials, currencies, nationalities, occupations, shapes)
• Many recommended entries rely on meta-type patterns (for example, nationality/occupation/shape).
• Bias and domain skew may exist in current recommended lists; extension and feedback are expected parts of ecosystem evolution.

Implementation Mapping — Recommended Terms

Apply these requirements to adapters, normalization, validation, and route outputs:

1. Advisory-term support

• Prefer recommended terms when mapping known source semantics, unless source fidelity requires an alternate concept.

1. Non-blocking validation behavior

• Treat recommended-term deviations as advisories/warnings, not hard conformance failures.

1. Meta-type preservation

• Preserve recommended meta-type structures when present (statement/object/shape/nationality/occupation families).

1. Controlled fallback strategy

• When exact recommended terms are unavailable, preserve source concept + include `equivalent` anchors where possible.

1. Domain-set consistency

• Maintain stable mappings for commonly recurring domains:
• language
• units
• materials
• currencies
• nationalities
• occupations
• shapes

1. Explainable mapping

• Capture mapping rationale in adapter tests/docs when intentionally choosing non-recommended terms.

1. Upgrade resilience

• Keep recommended-term checks version-tolerant so list updates do not create unnecessary breakages.

TDD Additions — Recommended Terms

Add failing-first tests for recommended-term interoperability workflows:

Contract-level:

• validates structure of recommended-term classifications where used
• validates statement meta-type patterns for statement categories
• permits alternative non-recommended concepts while emitting advisory results

Adapter-level:

• maps common provider terms to recommended vocabulary when high-confidence matches exist
• preserves alternate/local terms with equivalence links instead of destructive remapping
• preserves recommended domain-instance references (language/unit/material/currency, etc.) when source provides them

Route-level:

• inspect/import outputs include recommended-term advisories when alternatives are used
• routes distinguish required failures from recommended-term warnings clearly
• canonical `_source.raw` remains unchanged by advisory remapping logic

Regression:

• introducing new recommended mappings does not break older records
• classification facets remain stable for both recommended and equivalent-linked local terms

Fixture Anchors — Recommended Terms Examples

Use these official-example patterns as fixture seeds:

1. Name-type variants

• records with alternate/given/middle/family/sort-like name patterns.

1. Identifier-type variants

• records with accession/local/system/call identifiers.

1. Statement-type families

• statement records covering materials/provenance/rights/description/etc. using statement meta-type pattern.

1. Object/place/group/digital/set/dimension recommended types

• typed examples across each family for normalization/faceting tests.

1. Common instance vocabularies

• fixtures for language/unit/material/currency/nationality/occupation/shape references.

1. Intentional non-recommended alternative

• fixture proving advisory behavior with no hard validation failure.

---

Round 23 Addendum — Optional Terms

Source section basis:

• Linked Art Model 1.0: Optional Terms
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Optional terms are interoperability helpers, not conformance requirements.
• They are useful defaults and discovery aids for mapping, but alternatives are fully acceptable.
• Optional-term lists may evolve ad hoc and are suitable for extension, including bias-mitigation additions.
• Optional term families include:
• name types (translated title, subtitle, alias, pseudonym)
• identifier/contact types (auction lot number, DOI/ISBN/ISSN, email/street/phone/fax)
• statement/document/object/place/group/part/dimension type vocabularies
• Optional terms should improve cross-dataset usability when adopted consistently, but must not become hidden hard requirements.

Implementation Mapping — Optional Terms

Apply these requirements to adapters, normalization, validation, and route outputs:

1. Strictly non-blocking semantics

• Treat optional-term mismatches or absences as informational only, never as hard validation failures.

1. Interop-first preference

• Prefer optional terms when there is no better source-specific mapping requirement.

1. Transparent alternatives

• Preserve alternate local/external terms without forced substitution; include equivalence links where feasible.

1. Family-level consistency

• Keep optional term use consistent within each domain family (for example, document types, object part types, contact identifiers).

1. Mapping explainability

• Document adapter mapping rationale when intentionally diverging from optional-term suggestions.

1. Future-list tolerance

• Keep optional-term handling resilient to list additions/removals without schema breakages.

TDD Additions — Optional Terms

Add failing-first tests for optional-term interoperability workflows:

Contract-level:

• validates optional-term structures when present
• confirms missing optional terms do not fail validation
• confirms alternate terms can coexist with valid optional-term usage

Adapter-level:

• preserves optional term classifications when source provides them
• preserves non-optional alternatives without data loss or invalid coercion
• preserves contact/document/part/dimension optional type semantics where provided

Route-level:

• inspect/import outputs expose optional-term advisories as informational hints only
• routes do not escalate optional-term differences into blocking errors
• canonical `_source.raw` remains unchanged by optional-term normalization suggestions

Regression:

• adopting new optional mappings does not alter existing required/recommended validation outcomes
• faceting/classification logic remains stable across mixed optional-term adoption patterns

Fixture Anchors — Optional Terms Examples

Use these official-example patterns as fixture seeds:

1. Optional name types

• translated title/sub-title/alias/pseudonym name-classification examples.

1. Optional identifier and contact types

• DOI/ISBN/ISSN/lot number plus email/street/telephone/fax contact identifiers.

1. Optional statement and document types

• representative statement classes and document-classification examples.

1. Optional place/group/object/part/dimension types

• typed examples across these families for advisory mapping behavior tests.

1. Alternative-term coexistence

• fixture with non-optional alternative term proving non-blocking validation.

---

Round 24 Addendum — Textual Documents

Source section basis:

• Linked Art Model 1.0: Textual Documents
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Text modeling distinguishes:
• physical/digital carriers (`HumanMadeObject`/`DigitalObject`)
• textual content (`LinguisticObject`)
• A single `LinguisticObject` can be carried by many carriers (`carries` / `digitally_carried_by` patterns).
• Scope target is pragmatic bibliographic interoperability, not full FRBR/LRM/BibFrame complexity.
• Common text features include:
• type/classification of textual work
• names and identifiers
• language
• descriptive statements
• Text lifecycle often includes:
• `created_by` for authorship/creation
• publishing activity in `used_for` with required publication activity classification
• Textual structure uses partitioning:
• chapter/article/issue/volume hierarchies via `part_of`
• Pagination/foliation can be represented:
• as statements (human-readable ranges)
• as structured dimension counts (computable)
• Texts can be `about` other core entities (objects, people, places, etc.).
• Abstract-work alignment:
• textual content can be linked to higher-level conceptual abstraction (`PropositionalObject`) via `part_of`.

Implementation Mapping — Textual Documents

Apply these requirements to adapters, normalization, and route outputs:

1. Carrier/content separation

• Preserve distinction between text carriers and textual content entities.

1. Shared-content linkage

• Preserve links from multiple carriers to shared `LinguisticObject` content records.

1. Bibliographic identity

• Preserve textual names/identifiers/language and work-type classifications.

1. Creation vs publication split

• Preserve authorship creation (`created_by`) separately from publishing activities (`used_for`).

1. Structural hierarchy

• Preserve chapter/article/issue/volume partitioning via `part_of` where available.

1. Pagination dual pattern

• Preserve both statement-style pagination and structured page-count dimensions when provided.

1. Aboutness integrity

• Preserve `about` links to core entities without substituting with string-only references.

1. Abstract-work linkage

• Preserve conceptual `part_of` links from `LinguisticObject` to `PropositionalObject` where modeled.

TDD Additions — Textual Documents

Add failing-first tests for textual-document workflows:

Contract-level:

• validates `LinguisticObject` identity/classification/name/identifier/language structures
• validates carrier-to-content links (`carries` and/or digital carry patterns)
• validates publication activity embedding in `used_for` and creation activity in `created_by`

Adapter-level:

• preserves carrier/content separation and shared-content linkage
• preserves textual structure (`part_of`) for sub-documents
• preserves pagination statement and count-dimension structures
• preserves `about` links and abstract-work part-of references

Route-level:

• inspect/import outputs retain textual-document modeling patterns without flattening
• routes do not collapse conceptual/abstract links into plain labels
• canonical `_source.raw` text structures remain unmutated

Regression:

• text modeling enhancements do not break digital-object modeling or concept mappings
• object-centric views continue to resolve related textual references correctly

Fixture Anchors — Textual Documents Examples

Use these official-example patterns as fixture seeds:

1. Physical carrier with textual content link

• `HumanMadeObject` book record carrying a `LinguisticObject`.

1. Linguistic content core record

• monograph-classified `LinguisticObject` with names, identifiers, and language.

1. Authorship + publication

• `created_by` authorship activity plus publishing `used_for` activity.

1. Document structure

• chapter `LinguisticObject` `part_of` larger textual work.

1. Pagination and page count

• pagination statement plus computable page-count dimension.

1. Aboutness

• `LinguisticObject` `about` linked core entity.

1. Abstract-work link

• textual content `part_of` conceptual `PropositionalObject`.

---

Round 25 Addendum — Archival Hierarchies

Source section basis:

• Linked Art Model 1.0: Archival Hierarchies
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Archives are modeled primarily as conceptual hierarchies of `Set` entities.
• Archival intellectual arrangement is distinct from physical containment.
• Conceptual hierarchy pattern:
• archival items (typically `HumanMadeObject`/`DigitalObject`) are `member_of` archival sets
• archival sets can be `member_of` broader archival sets (sub-series -> series -> fonds ...)
• no fixed depth limit; graph allows multi-membership across hierarchies
• Physical containment alignment pattern:
• archival set -> `members_contained_by` -> physical container object
• individual item -> `held_or_supported_by` -> physical container object
• Ordering of members follows the same set-ordering patterns as other `Set` use cases.
• Shared/member-common description can use `members_exemplified_by`; textual statements remain acceptable for many archival descriptions.

Implementation Mapping — Archival Hierarchies

Apply these requirements to adapters, normalization, and route outputs:

1. Conceptual/physical split

• Preserve conceptual membership (`member_of` set hierarchy) separately from physical containment (`members_contained_by`, `held_or_supported_by`).

1. Hierarchy depth support

• Preserve arbitrary-depth set-to-set hierarchies without flattening.

1. Multi-membership support

• Allow items/sets to participate in multiple conceptual archival sets when source data indicates this.

1. Container linkage fidelity

• Preserve links between archival sets and container objects, and between items and physical containers.

1. Archival type preservation

• Preserve archival grouping/sub-grouping classifications on sets when present.

1. Description strategy compatibility

• Preserve both structured collective descriptors (`members_exemplified_by`) and statement-based archival notes.

1. Ordering compatibility

• Preserve sort-value and ordering metadata for archival members where provided.

TDD Additions — Archival Hierarchies

Add failing-first tests for archival workflows:

Contract-level:

• validates archival set hierarchy structures (`Set` + `member_of`)
• validates physical-alignment properties (`members_contained_by`, `held_or_supported_by`)
• validates archival grouping classifications when present

Adapter-level:

• preserves conceptual hierarchy depth and item membership
• preserves physical container links without collapsing into conceptual hierarchy
• preserves collective member descriptors and/or statements

Route-level:

• inspect/import outputs retain both conceptual and physical hierarchy structures
• routes do not infer conceptual membership solely from physical containment
• canonical `_source.raw` archival hierarchy data remains unmutated

Regression:

• collection/set features (ordering, prototypes) remain compatible with archival sets
• object-centric views still resolve both archival set membership and container placement

Fixture Anchors — Archival Hierarchies Examples

Use these official-example patterns as fixture seeds:

1. Archival item membership

• item `HumanMadeObject` `member_of` archival sub-series set.

1. Sub-series to series linkage

• archival sub-grouping `Set` `member_of` archival grouping set.

1. Physical alignment at set level

• archival set with `members_contained_by` archival box object.

1. Physical alignment at item level

• archival item with `held_or_supported_by` same archival box object.

1. Mixed conceptual + physical graph

• fixture where conceptual set hierarchy and physical container hierarchy coexist and must not be conflated.

---

Round 26 Addendum — Specific Assertions

Source section basis:

• Linked Art Model 1.0: Specific Assertions
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• `AttributeAssignment` is used for historically contingent, uncertain, context-specific, or otherwise non-primary assertions.
• Keep use minimal because assertion reification adds complexity and query burden.
• Core assignment pattern (`attributed_by` on subject):
• subject entity has `attributed_by` -> `AttributeAssignment`
• assignment carries `assigned_property` (predicate)
• assignment carries `assigned` (object/value entity)
• Inverse/value-centered pattern (`assigned_by` on value):
• useful for value entities such as identifiers/dimensions
• helps encode who assigned a specific value (for example, institution-specific accession numbers)
• Source-of-knowledge pattern:
• assignment references authority witness via `used_specific_object` (entity reference, not plain citation string)
• Embedded statement provenance/rights:
• statements may carry `created_by`, `technique`, timespan, and `subject_to` rights
• AI-origin metadata can be represented via statement/creation classifications/techniques
• Uncertain/former assertions:
• can target embedded production/activity nodes for "possibly by"/former-attribution scenarios
• Context-specific assertions:
• exhibition- or project-specific names/identifiers/descriptions should use `AttributeAssignment`
• `caused_by` can bind assignment to contextual activity (for example, exhibition)
• Unknown or unmodeled relationships:
• `AttributeAssignment` can express relationship presence when precise model relation is unknown or unavailable
• should be last resort after attempting explicit model properties

Implementation Mapping — Specific Assertions

Apply these requirements to adapters, normalization, and route outputs:

1. Minimal-use policy

• Prefer direct model properties first; use `AttributeAssignment` only when direct expression is inadequate or historically/contextually incorrect.

1. Subject/value direction correctness

• Preserve correct directionality for `attributed_by` vs `assigned_by` patterns depending on assertion use case.

1. Triple integrity

• Preserve subject (`attributed_by` host), predicate (`assigned_property`), object (`assigned`) semantics explicitly.

1. Context linkage

• Preserve `caused_by` and `part_of` links for context-bounded assertions.

1. Source provenance fidelity

• Preserve `used_specific_object` references as source evidence entities.

1. AI/rights annotation safety

• Preserve statement-level creation technique/time and rights markings without collapsing into global record-level assumptions.

1. Uncertainty preservation

• Preserve uncertain/former assignments as assertions; do not auto-promote into canonical fact fields.

1. Relationship-fallback restraint

• Use related-entity assertion patterns only when explicit relationship predicates are unavailable.

TDD Additions — Specific Assertions

Add failing-first tests for specific-assertion workflows:

Contract-level:

• validates `AttributeAssignment` structures for both subject-side and value-side patterns
• validates `assigned_property`, `assigned`, `used_specific_object`, and contextual links when present
• rejects malformed assertion triples and invalid assignment payloads

Adapter-level:

• preserves assertion directionality and context/source links
• preserves exhibition-specific and uncertainty-specific assertions without canonical overwrite
• preserves AI/rights statement metadata attached to embedded linguistic content

Route-level:

• inspect/import outputs retain assertion structures and relation context
• routes do not flatten assertions into canonical direct properties unless explicitly instructed by migration logic
• canonical `_source.raw` assertion history remains unmutated

Regression:

• assertion enrichment does not break baseline property queries for current state
• related-entity fallback assertions do not replace explicit relationships when those are present

Fixture Anchors — Specific Assertions Examples

Use these official-example patterns as fixture seeds:

1. Subject-side assignment triple

• entity `attributed_by` assignment with `assigned_property` + `assigned` value.

1. Value-side assignment provenance

• identifier with `assigned_by` assignment pointing to assigning institution/actor.

1. Source-backed name assertion

• name with `assigned_by.used_specific_object` referencing source text entity.

1. AI-generated embedded statement

• statement with AI-related classification/technique, creation timestamp, and statement-level rights.

1. Uncertain production attribution

• production node with attributed assignment carrying "possibly by" classification and assigned production part.

1. Context-specific exhibition identifier

• object-level assertion assigning exhibition-specific identifier with `caused_by` exhibition activity.

1. Related/unmodeled entity fallback

• attribute assignment used for "related object" / social relationship fallback when explicit model predicate is unavailable.

---

Round 27 Addendum — Profile

Source section basis:

• Linked Art Model 1.0: Profile
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

1. Scope through shared use cases and real world data.

1. Select solutions that are as simple as possible and no simpler.

1. Intelligently manage addition of complexity.

1. Avoid dependency on specific technologies.

1. Follow linked-data principles and best practices.

1. Design for JSON-LD first.

1. Define success, not failure.

• Linked Art is an intentionally reduced application profile of CIDOC-CRM:
• targeted practical coverage for most real-world museum use cases
• reduced ontology complexity to improve implementation and interoperability
• Core mission emphasizes:
• event-based cultural heritage publication for research and general developers
• shared models plus shared software patterns to lower producer/consumer burden
• Design posture is explicitly:
• iterative
• responsive
• responsible
• collaborative
• Seven profile design principles govern modeling decisions:
• Practical implications for implementers:
• no class/property without concrete use case data
• strong preference for reuse over new terms/extensions
• avoid unnecessary multiple instantiation complexity
• support simple "minimum viable" publishing first, with optional expansions
• remain transformable between JSON-LD and RDF triples without information loss
• avoid CIDOC-CRM features that conflict with core linked-data practice

Implementation Mapping — Profile

Apply these requirements to adapters, normalization, and route outputs:

1. Use-case-first modeling gate

• New provider mappings must tie each non-trivial class/property to a documented museum use case and sample payload.

1. Simplicity-first adapter behavior

• Prefer direct baseline Linked Art patterns in normalized output.
• Add complex expansions only when required by explicit source evidence.

1. Reuse-before-extension rule

• Reuse Linked Art and existing CRM-aligned structures before adding local extension fields.
• Any local extension must be documented in contracts and roadmap with rationale.

1. JSON-LD-first output contract

• Canonical route payloads must remain valid JSON-LD oriented structures first, while still enabling RDF materialization.

1. Technology-neutral core

• Source adapters must avoid coupling business logic to a single graph store or query technology.
• Model semantics remain stable regardless of storage backend (files/Postgres/graph layer).

1. Expansion layering discipline

• Keep "current/baseline fact" fields straightforward.
• Hang uncertainty/history/context in additive expansions without forcing all clients to parse them.

1. Success-pattern conformance

• Treat official profile patterns as positive conformance targets; non-profile source fields may be preserved under `_source.raw` without breaking canonical model output.

TDD Additions — Profile

Add failing-first tests for profile-conformance guardrails:

Contract-level:

• validates canonical JSON-LD structure for normalized entities against profile-aligned contracts
• validates that extension fields are namespaced and documented when present
• rejects unsupported "invented" relationship fields in canonical model zone

Adapter-level:

• verifies baseline/simple pattern output exists for each supported provider slice
• verifies optional expansions do not overwrite or obscure baseline fields
• verifies round-trip integrity from source -> normalized JSON-LD -> RDF transform path (shape-level/no-loss checks)

Route-level:

• inspect/import responses expose canonical profile-first shape with optional expansion blocks
• routes preserve raw provider payloads under `_source.raw` for audit/debug without polluting canonical fields
• unsupported source constructs degrade gracefully into raw/annotation zones rather than malformed canonical nodes

Regression:

• introducing a new provider does not regress existing Linked Art conformance fixtures
• conformance suite blocks accidental drift into over-complex local ontology fragments

Fixture Anchors — Profile Examples

Use these official-profile principles as fixture seeds:

1. Shared use case evidence fixture

• each advanced mapping test references an explicit use case ID + real sample payload.

1. Simplicity baseline fixture

• same source record emits a simple canonical representation with optional expansion kept separate.

1. Reuse over extension fixture

• provider-specific nuance modeled via existing Linked Art/CRM patterns, not ad hoc canonical fields.

1. JSON-LD first fixture

• normalized output validates as JSON-LD object graph and remains transformable to triples.

1. Technology-independence fixture

• identical normalized semantics pass with file-backed and Postgres-backed storage implementations.

1. Success-not-failure fixture

• out-of-scope source details retained in `_source.raw`, while canonical profile section remains valid.

---

Round 28 Addendum — Linked Art Terms Ontology (RDF Extensions)

Source section basis:

• Linked Art terms ontology serialization (`https://linked.art/ns/terms/`) as RDF/XML excerpt
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• The RDF terms file defines practical Linked Art extensions and profile conveniences over base CIDOC-CRM.
• Confirmed active terms/classes include:
• assertion support: `property_classified_as` (for dot-one style semantics via `AttributeAssignment`)
• custody convenience: `current_permanent_custodian` and inverse
• identity equivalence: `equivalent` (explicitly avoiding `skos:exactMatch` inference side effects)
• generalized transfer model:
• class `Transfer` with `transferred`, `transferred_from`, `transferred_to`
• subclasses include `Acquisition`, `Move`, `Transfer_of_Custody`
• payment specialization via `Payment` + `paid_amount` / `paid_from` / `paid_to`
• set and membership model:
• class `Set`, membership relations (`has_member`, `member_of`)
• exemplar/containment helpers (`members_exemplified_by`, `members_contained_by`, `contains_members_of`)
• lifecycle activities: `Addition`/`Removal` with directional member and set links
• digital object relations:
• `digitally_carries`, `digitally_shows`
• `access_point`
• `DigitalService` + `digitally_available_via` / `digitally_makes_available`
• rights transfer:
• `RightAcquisition`
• `establishes`/`established_by`, `invalidates`/`invalidated_by`
• The excerpt also contains a commented `Phase` model block marked as not currently used in profile and therefore non-normative for current conformance.

Implementation Mapping — Terms Ontology

Apply these requirements to adapters, normalization, and route outputs:

1. Active-terms allowlist

• Treat the listed active classes/properties as permitted canonical vocabulary in normalized Linked Art output.

1. Inverse-aware graph handling

• Preserve inverse-capable relationship semantics in canonical storage/query layers without forcing both directions into payloads.

1. Transfer abstraction discipline

• Support `Transfer` as a first-class unknown/abstract exchange pattern; avoid coercing ambiguous transfers into acquisition/custody/move when evidence is insufficient.

1. Set lifecycle fidelity

• Preserve `Addition`/`Removal` events and directional membership properties to model collection/list evolution over time.

1. Digital relation fidelity

• Preserve separation between digital carrier/content/display/service/access-point semantics for IIIF and other provider integrations.

1. Rights transition semantics

• Preserve rights establishment and invalidation as explicit activity-driven state changes.

1. Non-normative block protection

• Do not implement commented `Phase` terms as required behavior in current provider slices unless roadmap explicitly activates that scope.

TDD Additions — Terms Ontology

Add failing-first tests for ontology-term conformance:

Contract-level:

• validates acceptance of active `la:` terms in canonical contract schemas
• validates inverse-capable properties as semantically paired where applicable
• rejects/flags non-profile commented terms as required fields

Adapter-level:

• preserves ambiguous exchange as `Transfer` when subtype is unknown
• preserves set membership change events (`Addition`/`Removal`) and directional links
• preserves digital relations (`digitally_carries` vs `digitally_shows` vs `digitally_available_via`) without collapsing semantics
• preserves rights transitions via `RightAcquisition` establish/invalidate pairs

Route-level:

• inspect/import outputs retain canonical `la:` term usage and source fidelity
• routes do not flatten transfer, set-lifecycle, or rights-lifecycle structures into static snapshots only
• canonical `_source.raw` retains original provider modeling where richer than canonical projection

Regression:

• previously accepted object/provenance/digital fixtures continue passing with `la:` term allowlist enabled
• no accidental introduction of inactive/commented ontology sections into required conformance gates

Fixture Anchors — Terms Ontology Examples

Use these ontology-backed patterns as fixture seeds:

1. Attribute-assignment property typing

• `AttributeAssignment` with `property_classified_as` term annotation.

1. Permanent custodian snapshot

• object with `current_permanent_custodian` actor and inverse query check.

1. Equivalent identity link

• entity pair linked with `equivalent` (non-SKOS inference-safe mapping).

1. Abstract transfer

• ambiguous provenance handoff modeled as `Transfer` + transferred/from/to.

1. Payment transfer part

• payment with amount/from/to linked under transfer activity context.

1. Set membership lifecycle

• `Addition` adds member to set; `Removal` removes member from set; both directional relations asserted.

1. Digital service publication

• digital object with `access_point`, `digitally_shows` visual item, and `digitally_available_via` digital service.

1. Rights lifecycle

• `RightAcquisition` that `establishes` one right and `invalidates` another in transition scenario.

---

Round 29 Addendum — CIDOC-CRM Class Analysis (Practical Utility Profile)

Source section basis:

• Linked Art Model 1.0: Class Analysis
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Class usage should be driven by practical interoperability and real dataset utility, not full ontology breadth.
• Explicit classes-to-ignore guidance includes:
• abstract hierarchy anchors that should not be emitted directly in data (for example `E1`, `E2`, `E18`, `E19`, `E20`, `E24`, `E28`, `E63`, `E64`, `E70`, `E71`, `E72`, `E77`, `E90`, `E92`)
• CRM datatype classes (`E59`, `E60`, `E61`, `E62`, `E94`, `E95`) in favor of RDF/XSD/native representations
• overly specific/redundant classes best replaced with parent class + `P2_has_type` and external vocab
• Strong simplification recommendations:
• prefer `E13 Attribute Assignment` patterns over its narrow reification subclasses
• prefer `Name` / `E33_E41 Linguistic Appellation` patterns for names/titles; keep `E42 Identifier` for identifiers
• prefer `E36 Visual Item` for visual content; avoid deprecated/redundant visual subclasses
• prefer Linked Art `Set` model for aggregations over controversial collection-specific CRM distinctions
• Useful class set is explicitly identified and should anchor mapping priorities (for objects, provenance, activities, actors, places, dimensions, money, etc.).
• Optional/not-currently-required classes can remain unsupported unless a concrete source use case appears.
• `E30 Right` is treated as problematic in base CRM semantics; Linked Art’s practical right-acquisition/invalidation patterns are preferred for operational modeling.

Implementation Mapping — Class Analysis

Apply these requirements to adapters, normalization, and route outputs:

1. Canonical class allowlist

• Maintain a practical class allowlist aligned to the "useful classes" set and existing Linked Art profile terms.

1. Ignore/redirect policy

• If source data carries ignored/overly specific classes, normalize to the recommended parent/pattern and preserve original typing in `_source.raw`.

1. Datatype normalization

• Normalize CRM datatype-class usage into concrete literals (`xsd:string`, numeric/date types, etc.) and external geometry vocab when required.

1. Set-first aggregation modeling

• Model collection-like groupings via Linked Art `Set` + type classification rather than forcing curated-holding subclasses.

1. Visual/text distinction discipline

• Route visual manifestations to `VisualItem` patterns and inscriptions/text to linguistic-object patterns when evidence supports that split.

1. Rights modeling guardrail

• For rights change semantics, prefer Linked Art right-acquisition lifecycle patterns over naive static-right assertions.

1. Evidence-based expansion

• Support currently optional classes only when provider evidence and use-case docs justify them.

TDD Additions — Class Analysis

Add failing-first tests for practical class-profile conformance:

Contract-level:

• validates canonical outputs only emit class types from the active practical allowlist
• rejects direct emission of ignored abstract/datatype CRM classes in canonical projection
• validates class remapping paths for known overly specific/deprecated source classes

Adapter-level:

• source class variants normalize to profile-preferred classes without data loss
• identifiers remain distinct from names/titles in normalized output
• visual vs linguistic content splits are preserved according to source evidence
• set aggregation outputs use `Set` semantics with typed classification

Route-level:

• inspect/import responses include canonical remapped class model plus `_source.raw` for provenance
• routes do not leak ignored/deprecated classes into top-level canonical payloads
• rights-related provider data maps to right-lifecycle activity patterns where applicable

Regression:

• existing provenance, digital, and vocabulary fixtures continue to pass under class allowlist enforcement
• legacy fixtures with deprecated/over-specific typing remain ingestible via remap shims

Fixture Anchors — Class Analysis Examples

Use these analysis-derived patterns as fixture seeds:

1. Datatype class replacement

• source payload using CRM datatype-class semantics normalized to concrete typed literals.

1. Over-specific appellation collapse

• legacy title/name subclass mapped into `Name`/linguistic-appellation pattern; identifiers remain `Identifier`.

1. Visual class collapse

• image/mark/inscription edge cases mapped to `VisualItem` or `LinguisticObject` per evidence.

1. Set normalization

• curated-holding-like source mapped to Linked Art `Set` with vocabulary type.

1. Abstract class suppression

• source carrying abstract hierarchy classes ingests successfully but canonical payload omits direct abstract class emissions.

1. Rights lifecycle mapping

• source rights change represented via right-acquisition/invalidates pattern rather than static timeless right-only node.

---

Round 30 Addendum — Linked Art API 1.0 Foundations

Source section basis:

• Linked Art API 1.0: Introduction and API design fundamentals overview
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• The Linked Art model/profile is transport-agnostic; API conformance is a separate web interaction layer.
• Core API expectation:
• entity descriptions serialized as JSON-LD using Linked Art context
• non-semantic HAL block for navigational/API affordance links
• API surface areas called out:
• Entity Description endpoints
• Shared Data Structures
• JSON Schema
• HAL links for versions/cross-format/searches
• Search API response format (query language intentionally unspecified)
• Data discovery/harvest/synchronization APIs
• Search interoperability stance:
• standardized search response shape
• implementation-specific query languages are allowed (SPARQL/GraphQL/Cypher/ES/Solr/etc.)
• clients should discover named searches via HAL links rather than hard-coding query grammar
• Versioning policy:
• semantic versioning `Major.Minor.Patch`
• minor = backwards-compatible feature/clarification
• patch = documentation-only changes
• major = backwards-incompatible changes

Implementation Mapping — API Foundations

Apply these requirements to adapters, normalization, and route outputs:

1. JSON-LD + HAL dual-layer response contract

• Keep canonical entity payload JSON-LD compliant while exposing API navigation in HAL-style metadata blocks.

1. Endpoint consistency

• Ensure route handlers expose consistent entity envelope patterns across objects, people, places, concepts, events, and shared structures.

1. Search-format stability

• Standardize search response structure independent of backend query implementation.
• Allow internal query engine changes without breaking client-facing response shape.

1. Discovery-first integration

• Expose machine-followable links for:
• named searches
• format variants
• version endpoints
• synchronization/discovery feeds where available

1. Schema-governed contracts

• Keep response and request contracts aligned with JSON Schema/Zod boundary checks as implementation guardrails.

1. Versioned compatibility guarantees

• Treat API-breaking response-shape changes as major-version work items only.
• Record minor/patch behavior in changelog/roadmap notes for provider-slice PRs.

TDD Additions — API Foundations

Add failing-first tests for API conformance behavior:

Contract-level:

• validates entity responses as JSON-LD using expected context semantics
• validates HAL block shape and required link relations
• validates search response envelope stability independent of query backend

Route-level:

• entity endpoints return consistent envelope and link conventions
• search endpoints return standardized response shape with discovered query links
• discovery endpoints/links provide harvest/sync affordances when configured

Versioning-level:

• tests enforce non-breaking minor changes for existing response contracts
• tests detect breaking shape changes and require explicit version-bump workflow

Regression:

• provider additions do not alter existing entity/search envelope contracts
• backend query engine swaps do not change public search response schema

Fixture Anchors — API Foundations Examples

Use these API-level patterns as fixture seeds:

1. Entity response fixture

• JSON-LD entity record with HAL links for self/version/related/search.

1. Search response fixture

• standardized result list with pagination/meta independent of query syntax.

1. HAL named-search link fixture

• entity exposing discoverable named searches via stable relation names.

1. Multi-format link fixture

• entity exposing alternate format/version links through HAL metadata.

1. Version-compat fixture

• snapshot tests proving minor update compatibility for entity and search responses.

---

Round 31 Addendum — About Endpoints (Entity Endpoint Taxonomy)

Source section basis:

• Linked Art API 1.0: About Endpoints
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Linked Art API is organized as endpoint families, each with defined response structure aligned to model classes.
• Endpoint families called out:
• Abstract Works
• Concepts
• Digital Objects
• Events
• Groups
• People
• Physical Objects
• Places
• Provenance Activities
• Sets
• Textual Works
• Visual Works
• Endpoints are class-oriented and should remain predictable for consumers regardless of internal storage/query implementation.

Implementation Mapping — Endpoint Taxonomy

Apply these requirements to adapters, normalization, and route outputs:

1. Endpoint family coverage matrix

• Maintain an explicit map of project routes to Linked Art endpoint families (implemented, partial, planned).

1. Family-specific envelope consistency

• Keep consistent JSON-LD + HAL envelope conventions across all family endpoints while allowing family-specific payload fields.

1. Cross-entity linking discipline

• Ensure records link across families through stable identifiers (for example object -> provenance activity -> people/groups/places/concepts).

1. Provenance vs event separation

• Keep provenance activities as a dedicated event family and avoid collapsing them into generic events when provenance semantics are present.

1. Work/entity distinction

• Keep abstract/textual/visual work endpoints distinct from physical object endpoints to avoid conflating conceptual and physical layers.

1. Set modeling consistency

• Route set-like resources through set semantics, including collections and exhibition sets, without forcing physical-object semantics.

TDD Additions — Endpoint Taxonomy

Add failing-first tests for endpoint-family conformance:

Contract-level:

• validates each endpoint family response against its expected entity-class contract profile
• validates shared envelope requirements are consistent across families
• validates family-specific required links/fields are present when applicable

Route-level:

• smoke tests for each supported family endpoint return expected entity type(s)
• unknown family records fail gracefully with clear not-supported/not-found behavior
• provenance-family endpoints retain transfer/acquisition/custody/move semantics

Integration-level:

• cross-family traversal tests (object -> production/provenance -> actor/place/concept)
• set endpoints correctly resolve membership and member entity references
• digital object endpoints correctly resolve access points/services and visual/textual links

Regression:

• adding new provider slices does not alter existing family envelope conventions
• family-specific fixtures remain stable when storage backend changes

Fixture Anchors — Endpoint Taxonomy Examples

Use these endpoint-family patterns as fixture seeds:

1. Physical object fixture

• object record with links to production, provenance, identifiers, and digital representations.

1. Provenance activity fixture

• transfer/acquisition activity linked to object + actors + timespan/place.

1. People/groups fixture

• person and group records linked via participation roles in activities.

1. Place fixture

• place linked from object ownership/location and activity occurrence.

1. Concept fixture

• type/material/language concept records resolved as first-class endpoint entities.

1. Set fixture

• collection/exhibition set with members and membership lifecycle references.

1. Work layer fixtures

• abstract work, textual work, and visual work each represented independently and linked to carrying/showing entities.

1. Digital object fixture

• digital object with access point/service and linked visual/textual content.

---

Round 32 Addendum — Abstract Works Endpoint

Source section basis:

• Linked Art API 1.0: Abstract Works endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Abstract Works endpoint describes conceptual works, especially those instantiated by activities (for example exhibition concepts, performance concepts).
• Endpoint is less common but important for linking multiple concrete realizations to one conceptual work.
• Required core response properties:
• `@context` must include Linked Art context URI (`https://linked.art/ns/v1/linked-art.json`)
• `id` must be dereferenceable HTTP(S) URI
• `type` must be `PropositionalObject`
• Recommended properties:
• `_label`
• `classified_as`
• `identified_by` (Name and/or Identifier patterns)
• Optional properties include:
• `referred_to_by`, `equivalent`, `subject_of`, `representation`, `member_of`
• `attributed_by`, `dimension`, `conceptually_part_of`, `about`, `subject_to`, `created_by`
• Incoming reference patterns called out:
• `about` from Textual Works
• `influenced_by` from Activities

Implementation Mapping — Abstract Works Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Abstract Work endpoint payloads must emit canonical `type: "PropositionalObject"` for top-level records.

1. Context and URI discipline

• Enforce valid Linked Art context placement and stable dereferenceable `id` values.

1. Conceptual-vs-physical separation

• Keep abstract work records distinct from physical/textual/visual instantiations and link them via references.

1. Relationship fidelity

• Preserve `about`, `conceptually_part_of`, `representation`, and `subject_of` links without flattening into local-only text fields.

1. Creation and assertion support

• Preserve `created_by` and `attributed_by` blocks where provided as first-class modeled structures.

1. Set participation

• Preserve optional `member_of` links so abstract works can participate in sets (for example curatorial concept groupings).

TDD Additions — Abstract Works Endpoint

Add failing-first tests for abstract-work endpoint conformance:

Contract-level:

• validates required properties: `@context`, `id`, `type=PropositionalObject`
• validates recommended structures (`classified_as`, `identified_by`) when present
• validates optional relation fields against shared reference patterns

Route-level:

• abstract-work endpoint returns single-entity JSON-LD envelope with HAL-compatible link layer
• unknown/non-abstract IDs fail gracefully with clear status and error shape
• route preserves `created_by` and `about` relation structures end-to-end

Integration-level:

• textual-work records can reference abstract works via `about`
• activity records can reference abstract works via `influenced_by`
• conceptual hierarchy traversal via `conceptually_part_of` remains stable

Regression:

• abstract-work ingestion does not regress physical object or visual/textual work endpoint schemas
• optional abstract-work fields remain additive and do not break minimal valid responses

Fixture Anchors — Abstract Works Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid abstract work

• required-only payload with context, HTTP(S) id, and `type: PropositionalObject`.

1. Exhibition concept fixture

• abstract work classified as exhibition with name and brief descriptive statement.

1. About-link fixture

• abstract work `about` a person/concept/entity with stable external URI reference.

1. Creation fixture

• abstract work with `created_by` creation activity and `carried_out_by` person/group.

1. Conceptual hierarchy fixture

• abstract work linked via `conceptually_part_of` to a broader abstract work.

1. Cross-endpoint incoming fixture

• textual work `about` abstract work and activity `influenced_by` same abstract work.

---

Round 33 Addendum — Concepts Endpoint

Source section basis:

• Linked Art API 1.0: Concepts endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Concepts endpoint provides full concept records (not embedded references) for:
• `Type`
• `Material`
• `Language`
• `Currency`
• `MeasurementUnit`
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is one of the allowed concept classes above
• Recommended properties:
• `_label`
• `classified_as`
• `identified_by` (Name and/or Identifier structures)
• Optional properties:
• `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`
• `attributed_by`, `broader`, `created_by`
• Key incoming links across model:
• `classified_as` (all entities)
• `technique` / `influenced_by` (activities)
• `about` (textual/visual works)
• `assigned` (attribute assignments)
• `language` (linguistic objects)
• `currency` (monetary amounts)
• `unit` (dimensions)
• `made_of` (human-made objects)

Implementation Mapping — Concepts Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type allowlist enforcement

• Concepts endpoint must enforce top-level `type` to allowed concept classes only.

1. Full-record vs embedded-reference separation

• Keep concept endpoint records richer than embedded type stubs while preserving shared identity URIs.

1. Hierarchy fidelity

• Preserve `broader` links for concept navigation without flattening into label-only taxonomies.

1. Cross-domain linkage stability

• Preserve concept usage links from activities, linguistic content, monetary amounts, dimensions, and materials.

1. Creation/attribution traceability

• Preserve `created_by` and `attributed_by` structures when concept provenance is provided.

1. Equivalence integrity

• Keep `equivalent` links as identity mappings without overwriting local canonical URI identity.

TDD Additions — Concepts Endpoint

Add failing-first tests for concept endpoint conformance:

Contract-level:

• validates required `@context`, `id`, and allowed concept `type` values
• validates recommended structures (`identified_by`, `classified_as`) when present
• validates optional relation fields (`broader`, `equivalent`, `member_of`, etc.) against shared reference schemas

Route-level:

• concept endpoint returns full concept records with stable JSON-LD + HAL envelope conventions
• invalid concept `type` values are rejected with clear error responses
• missing or unknown concept IDs return consistent not-found behavior

Integration-level:

• activities can resolve linked concept records for `technique` and `influenced_by`
• dimensions resolve `unit` concepts; monetary amounts resolve `currency` concepts
• linguistic objects resolve `language`; objects resolve `made_of` material concepts

Regression:

• concept endpoint changes do not break embedded concept references in other entity endpoints
• broader/equivalent graph traversal remains stable after provider adapter updates

Fixture Anchors — Concepts Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid concept

• required-only record with `type` in concept allowlist.

1. Hierarchical type concept

• `Type` with `broader` link and primary name.

1. Language concept

• `Language` record used by linguistic object `language` linkage tests.

1. Measurement unit concept

• `MeasurementUnit` record consumed by dimension `unit` tests.

1. Currency concept

• `Currency` record consumed by monetary amount `currency` tests.

1. Material concept

• `Material` record consumed by object `made_of` tests.

1. Concept provenance fixture

• concept with `created_by.influenced_by` links and optional `attributed_by`.

---

Round 34 Addendum — Digital Objects Endpoint

Source section basis:

• Linked Art API 1.0: Digital Objects endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Digital Objects endpoint describes digital content metadata (images, documents, other media) independent of whether bytes are directly accessible.
• `access_point` is the locator mechanism for retrievable file/service representations.
• Required top-level Digital Object properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `DigitalObject`
• Recommended properties:
• `_label`
• `classified_as`
• `identified_by` (Name and/or Identifier)
• Optional Digital Object properties include:
• common linked-art fields (`referred_to_by`, `equivalent`, `member_of`, `subject_of`, `representation`, `attributed_by`)
• digital-specific fields: `dimension`, `part_of`, `format`, `conforms_to`, `digitally_carries`, `digitally_shows`, `digitally_available_via`, `access_point`, `created_by`, `used_for`
• Digital Service sub-structure is first-class with required:
• `@context`, `id`, `type: DigitalService`
• optional `access_point`, `conforms_to`, and common descriptive fields
• Incoming links highlighted:
• `digitally_carried_by` from Textual Works
• `digitally_shown_by` from Visual Works

Implementation Mapping — Digital Objects Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Digital object endpoint payloads must emit top-level `type: "DigitalObject"` only for this family.

1. Metadata-vs-binary separation

• Preserve distinction between metadata records and retrievable content endpoints via `access_point`.

1. Service modeling fidelity

• Preserve `digitally_available_via` as Digital Service objects with their own access/specification links.

1. Content relationship clarity

• Keep `digitally_carries` (textual content) and `digitally_shows` (visual content) semantically separate.

1. Technical conformance capture

• Preserve `format` and `conforms_to` to support IIIF and other technical interoperability checks.

1. Structural linkage

• Preserve `part_of` relations (for example image part of manifest/package object).

1. Creation provenance

• Preserve `created_by` plus `used_specific_object` where digitization provenance is provided.

TDD Additions — Digital Objects Endpoint

Add failing-first tests for digital-object endpoint conformance:

Contract-level:

• validates required `@context`, `id`, `type=DigitalObject`
• validates digital-service nested structure with `type=DigitalService` and valid access/specification references
• validates optional digital-specific fields (`format`, `conforms_to`, `digitally_*`, `access_point`, `part_of`) against schema

Route-level:

• digital endpoint returns consistent JSON-LD + HAL envelope for digital records
• invalid `type` or malformed service/access blocks return clear validation errors
• unknown IDs return consistent not-found behavior

Integration-level:

• visual/textual work endpoints can resolve reciprocal digital links (`digitally_shown_by`, `digitally_carried_by`)
• IIIF-style fixtures resolve service and access-point chains without semantic loss
• dimensions on digital objects retain numeric/unit fidelity (for example pixel height/width)

Regression:

• digital endpoint updates do not regress physical object or visual/textual endpoint contracts
• ingestion from multiple providers preserves both canonical digital semantics and `_source.raw`

Fixture Anchors — Digital Objects Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid digital object

• required-only digital object with context/id/type.

1. Image object with dimensions

• digital image with pixel `Dimension` entries and `MeasurementUnit`.

1. Access point fixture

• digital object with retrievable file URI in `access_point`.

1. Service fixture

• `DigitalService` with IIIF `conforms_to` and service `access_point`.

1. Visual linkage fixture

• digital object `digitally_shows` visual work with reciprocal visual endpoint linkage checks.

1. Text linkage fixture

• digital object `digitally_carries` textual work with reciprocal textual endpoint linkage checks.

1. Part-of fixture

• derivative file/asset linked via `part_of` to a manifest/package digital object.

1. Digitization provenance fixture

• `created_by` activity with `carried_out_by` agent and `used_specific_object` physical source.

---

Round 35 Addendum — Events Endpoint

Source section basis:

• Linked Art API 1.0: Events endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Events endpoint groups `Period`, `Event`, and `Activity` records that are notable but not provenance/exhibition-specific endpoint families.
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` must be one of: `Period`, `Event`, `Activity`
• Recommended:
• `_label`
• `classified_as`
• `identified_by`
• `timespan` (recommended in endpoint table)
• Optional common links:
• `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`, `part_of`
• Optional temporal/spatial ordering:
• `during`, `before`, `after`, `took_place_at`
• Type-conditional properties:
• `caused_by` only for `Event`/`Activity`
• `influenced_by` only for `Activity`
• `carried_out_by` only for `Activity`
• `participant` for `Event`/`Activity`
• `used_specific_object` and `technique` only for `Activity`
• Incoming pattern highlighted:
• `part_of` from any event/activity family to broader periods/events/activities

Implementation Mapping — Events Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type allowlist + conditional validation

• Enforce event `type` allowlist and gate conditional fields by type at validation boundary.

1. Time modeling discipline

• Preserve `timespan` structures with explicit bounds/display names when present.

1. Temporal ordering fidelity

• Preserve `during` / `before` / `after` relationships without flattening to plain-date-only approximations.

1. Causality and influence semantics

• Keep `caused_by` and `influenced_by` distinct and type-correct.

1. Participation role clarity

• Distinguish `carried_out_by` (agentive execution) from `participant` (participation without execution).

1. Activity instrumentation

• Preserve `used_specific_object` and `technique` for activity explainability and reproducibility.

1. Cross-endpoint composition

• Preserve `part_of` composition links between events and broader periods for timeline traversal.

TDD Additions — Events Endpoint

Add failing-first tests for event endpoint conformance:

Contract-level:

• validates required `@context`, `id`, and `type in {Period, Event, Activity}`
• validates recommended `timespan` structure when present
• rejects type-disallowed fields (for example `carried_out_by` on `Period`)

Route-level:

• event endpoint returns stable JSON-LD + HAL envelope
• invalid type/field combinations return clear boundary validation errors
• unknown IDs return consistent not-found behavior

Integration-level:

• `part_of` links resolve across event families and preserve hierarchy constraints
• `during`/`before`/`after` ordering chains remain traversable
• `took_place_at` links resolve to place endpoint records

Regression:

• event endpoint updates do not regress provenance-specific or exhibition-specific workflows
• existing activity fixtures keep role semantics (`carried_out_by` vs `participant`) intact

Fixture Anchors — Events Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal period fixture

• `type: Period` with valid timespan and no activity-only fields.

1. Generic event fixture

• `type: Event` with participant and causality links.

1. Activity fixture

• `type: Activity` with `carried_out_by`, `used_specific_object`, `technique`.

1. Temporal bounds fixture

• timespan with `begin_of_the_begin` and `end_of_the_end` plus display title name.

1. Ordering fixture

• `before`/`after` links across multiple events with deterministic traversal.

1. Part-of hierarchy fixture

• event/activity as `part_of` broader period and inherited timeline navigation checks.

1. Place linkage fixture

• event `took_place_at` stable place reference resolution.

---

Round 36 Addendum — Groups Endpoint

Source section basis:

• Linked Art API 1.0: Groups endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Groups endpoint provides records for sets of actors (families, organizations, companies, departments, etc.).
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `Group`
• Recommended:
• `_label`
• `classified_as`
• `identified_by`
• Optional:
• `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`
• `contact_point`, `residence`
• `carried_out`, `participated_in`
• lifecycle events: `formed_by`, `dissolved_by`
• Incoming links highlighted include:
• actor participation/carrying out activity
• object ownership/custody/permanent custody
• provenance transfer/payment role links
• textual/visual references (`about`, `represents`)

Implementation Mapping — Groups Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Group endpoint payloads must emit top-level `type: "Group"` only.

1. Actor-role differentiation

• Preserve distinction between `carried_out` (responsible actor) and `participated_in` (non-responsible participant).

1. Lifecycle event integrity

• Preserve `formed_by` and `dissolved_by` as structured activity nodes with timespan/place when available.

1. Membership hierarchy support

• Preserve `member_of` links for nested group structures without flattening hierarchy to labels.

1. Custody/ownership interoperability

• Keep group identities stable across ownership, custody, and provenance transfer/payment role edges.

1. Contact/residence fidelity

• Preserve optional `contact_point` and `residence` semantics without conflating with identifiers or labels.

1. Assertion support

• Preserve `attributed_by` relationship assignments for contextual group relationships.

TDD Additions — Groups Endpoint

Add failing-first tests for group endpoint conformance:

Contract-level:

• validates required `@context`, `id`, `type=Group`
• validates optional lifecycle fields (`formed_by`, `dissolved_by`) against activity/time/place structures
• validates actor-role arrays (`carried_out`, `participated_in`) with correct reference typing

Route-level:

• group endpoint returns stable JSON-LD + HAL envelope
• malformed lifecycle or actor-role payloads fail boundary validation with clear errors
• unknown IDs return consistent not-found behavior

Integration-level:

• provenance routes resolve group edges for title/custody transfer and payment roles
• object routes resolve group edges for owner/custodian/permanent custodian roles
• textual/visual routes resolve `about`/`represents` references to group records

Regression:

• group endpoint changes do not regress person endpoint actor semantics
• membership and lifecycle fixtures stay stable across provider adapter updates

Fixture Anchors — Groups Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid group

• required-only group record with context/id/type.

1. Classified + named group

• group with primary name, nationality/type classifications.

1. Lifecycle fixture

• group with `formed_by` and `dissolved_by` including timespan and place.

1. Activity role fixture

• group with both `carried_out` and `participated_in` references.

1. Residence/contact fixture

• group with `residence` place and `contact_point` identifier.

1. Provenance-role fixture

• group as transfer/payment recipient/source across provenance activities.

1. Membership hierarchy fixture

• subgroup linked via `member_of` to parent group.

1. Assertion fixture

• `attributed_by` assignment connecting related groups contextually.

---

Round 37 Addendum — People Endpoint

Source section basis:

• Linked Art API 1.0: People endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• People endpoint provides records for persons (artists, collectors, museum staff, and others).
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `Person`
• Recommended:
• `_label`
• `classified_as`
• `identified_by`
• Optional:
• `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`
• `contact_point`, `residence`
• `carried_out`, `participated_in`
• lifecycle events: `born`, `died`
• Incoming links highlighted include:
• activity execution roles (`carried_out_by`)
• object ownership/custody/permanent custody roles
• provenance transfer/payment role links
• textual/visual references (`about`, `represents`)

Implementation Mapping — People Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• People endpoint payloads must emit top-level `type: "Person"` only.

1. Lifecycle event fidelity

• Preserve `born` and `died` as structured event nodes with timespan/place semantics.

1. Role differentiation

• Preserve distinction between `carried_out` (responsible activity) and `participated_in` (participatory role).

1. Identity semantics

• Keep `identified_by` name/identifier patterns distinct; preserve `equivalent` for external identity links.

1. Residence/contact semantics

• Preserve `residence` as place links and `contact_point` as identifier-like contact/address structures.

1. Group membership integrity

• Preserve `member_of` relationships to groups for social/professional context.

1. Assertion compatibility

• Preserve `attributed_by` relationship assignments for contextual or uncertain links.

TDD Additions — People Endpoint

Add failing-first tests for people endpoint conformance:

Contract-level:

• validates required `@context`, `id`, `type=Person`
• validates lifecycle structures for `born` and `died` when present
• validates optional role arrays and reference typing (`member_of`, `carried_out`, `participated_in`)

Route-level:

• people endpoint returns stable JSON-LD + HAL envelope
• malformed lifecycle/role/contact fields fail boundary validation with clear errors
• unknown IDs return consistent not-found behavior

Integration-level:

• activity/provenance routes resolve person edges for execution, transfer, and payment roles
• object routes resolve person edges for owner/custodian/permanent custodian roles
• textual/visual routes resolve `about`/`represents` references to people records

Regression:

• people endpoint changes do not regress groups endpoint actor-role semantics
• person lifecycle and identity fixtures remain stable across provider adapter updates

Fixture Anchors — People Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid person

• required-only person record with context/id/type.

1. Classified + named person

• person with gender/nationality classifications and primary name.

1. Birth/death lifecycle fixture

• person with structured `born` and `died` events including timespan/place.

1. Activity role fixture

• person with `carried_out` and `participated_in` edges.

1. Residence/contact fixture

• person with place `residence` and street-address `contact_point`.

1. Provenance-role fixture

• person as source/target in title/custody transfer and payment activities.

1. Group-membership fixture

• person linked via `member_of` to one or more group records.

1. External identity fixture

• person with `equivalent` URI to authority source (for example ULAN).

---

Round 38 Addendum — Physical Objects Endpoint

Source section basis:

• Linked Art API 1.0: Physical Objects endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Physical Objects endpoint is a core endpoint for tangible artworks/resources.
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `HumanMadeObject`
• Recommended:
• `_label`
• `classified_as`
• `identified_by`
• Optional object-centric fields include:
• descriptive and linking fields (`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`, `part_of`)
• physical fields (`dimension`, `made_of`, `held_or_supported_by`)
• rights/ownership/location (`current_owner`, `current_custodian`, `current_permanent_custodian`, `current_location`, `current_permanent_location`)
• content linkage (`carries`, `shows`)
• lifecycle/activity linkage (`used_for`, `produced_by`, `destroyed_by`, `removed_by`, `modified_by`, `encountered_by`, `changed_ownership_through`)
• Acquisition objects inside `changed_ownership_through` may include:
• `transferred_title_from`
• `transferred_title_to`
• Incoming links highlighted:
• `used_specific_object`, `influenced_by`
• provenance transfer/move/rights links
• textual `carried_by` and visual `shown_by`

Implementation Mapping — Physical Objects Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Physical object endpoint payloads must emit top-level `type: "HumanMadeObject"` only.

1. Physical/conceptual separation

• Keep object-carried/shown relationships (`carries`, `shows`) distinct from textual/visual work records.

1. Ownership/custody/location semantics

• Preserve current vs permanent owner/custodian/location distinctions without collapsing into single status fields.

1. Material and dimension fidelity

• Preserve `made_of` references and dimensional values/units with full numeric precision.

1. Lifecycle provenance integrity

• Preserve production/destruction/modification/removal/encounter/acquisition chains as structured event nodes.

1. Support relationships

• Preserve `held_or_supported_by` and `part_of` relations for containment/structural modeling.

1. Acquisition detail preservation

• Preserve `transferred_title_from`/`transferred_title_to` within ownership-change activities.

TDD Additions — Physical Objects Endpoint

Add failing-first tests for physical-object endpoint conformance:

Contract-level:

• validates required `@context`, `id`, `type=HumanMadeObject`
• validates object fields for dimensions/materials/location/custody/ownership structures
• validates lifecycle and acquisition nested activity schemas

Route-level:

• physical object endpoint returns stable JSON-LD + HAL envelope
• malformed ownership/custody/location or lifecycle blocks fail boundary validation with clear errors
• unknown IDs return consistent not-found behavior

Integration-level:

• provenance endpoints resolve object links across transfer/custody/move/rights activities
• textual and visual endpoints resolve reciprocal `carried_by`/`shown_by` links
• people/groups/places endpoints resolve owner/custodian/location references

Regression:

• object endpoint updates do not regress digital object or abstract work schemas
• fixture coverage prevents flattening of current/permanent and owner/custodian distinctions

Fixture Anchors — Physical Objects Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid physical object

• required-only record with context/id/type.

1. Multi-name + identifier fixture

• multilingual names plus accession identifier classifications.

1. Dimension + material fixture

• height/width dimensions with units and multiple `made_of` materials.

1. Ownership/custody/location fixture

• current vs permanent owner/custodian/location separation.

1. Production fixture

• `produced_by` with timespan/place/actor.

1. Lifecycle chain fixture

• object with `modified_by`, `removed_by`, `encountered_by`, `destroyed_by`.

1. Ownership-transfer fixture

• `changed_ownership_through` acquisition with `transferred_title_from` and `transferred_title_to`.

1. Support/containment fixture

• object `part_of` and `held_or_supported_by` another physical object.

---

Round 39 Addendum — Places Endpoint

Source section basis:

• Linked Art API 1.0: Places endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Places are spatial extents (independent of time and object presence) used as context for activities and locations.
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `Place`
• Recommended:
• `_label`
• `classified_as`
• `identified_by`
• Optional:
• `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`
• `part_of` (place hierarchy)
• `defined_by` (WKT geometry string)
• Incoming links highlighted:
• `took_place_at` from events/activities
• object `current_location` / `current_permanent_location`
• provenance `moved_from` / `moved_to`
• person/group `residence`

Implementation Mapping — Places Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Places endpoint payloads must emit top-level `type: "Place"` only.

1. Geometry fidelity

• Preserve `defined_by` WKT as canonical geometry representation when provided.

1. Place hierarchy integrity

• Preserve `part_of` relations for nested place modeling (gallery -> museum -> city -> region).

1. Spatial-role separation

• Keep place identity separate from group/organization identity (for example museum institution vs museum building/place).

1. Cross-endpoint location semantics

• Preserve inbound location roles distinctly (`took_place_at`, `current_location`, `moved_from`, `residence`, etc.).

1. Identity and equivalence

• Preserve stable local IDs and `equivalent` external place authorities (for example TGN/GeoNames).

TDD Additions — Places Endpoint

Add failing-first tests for places endpoint conformance:

Contract-level:

• validates required `@context`, `id`, `type=Place`
• validates optional `defined_by` WKT as string payload and reference fields as place-typed links
• validates `part_of` place hierarchy references

Route-level:

• places endpoint returns stable JSON-LD + HAL envelope
• malformed WKT or invalid place reference shapes fail boundary validation clearly
• unknown IDs return consistent not-found behavior

Integration-level:

• object endpoints resolve `current_location` and `current_permanent_location` place references
• event/activity/provenance endpoints resolve `took_place_at`, `moved_from`, `moved_to`
• people/groups endpoints resolve `residence` place references

Regression:

• place endpoint updates do not regress object/event provenance workflows
• hierarchy and geometry fixtures remain stable across provider adapter updates

Fixture Anchors — Places Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid place

• required-only place record with context/id/type.

1. Classified + named place

• place with city/region type classification and primary name/identifier.

1. Geometry fixture

• place with valid `defined_by` WKT polygon.

1. Hierarchy fixture

• place `part_of` parent place chain (gallery -> city -> state/country).

1. Incoming object-location fixture

• physical object with `current_location` referencing place endpoint record.

1. Incoming activity-location fixture

• event/activity `took_place_at` place reference resolution.

1. Move provenance fixture

• provenance `moved_from`/`moved_to` between two place records.

1. Residence fixture

• person/group with `residence` place links.

---

Round 40 Addendum — Provenance Activities Endpoint

Source section basis:

• Linked Art API 1.0: Provenance Activities endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Provenance Activities endpoint is a higher-complexity event/activity endpoint with required structured `part` activities.
• Top-level required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `Event` or `Activity`
• `classified_as` is required and must include Provenance Activity classification
• `part` array is required
• Required provenance classification discriminator:
• one `classified_as.id` must be `http://vocab.getty.edu/aat/300055863`
• Top-level optional/recommended event features include:
• `identified_by`, `timespan`, `took_place_at`, `caused_by`, `influenced_by`, `carried_out_by`, `participant`, `used_specific_object`, temporal ordering and contextual links
• Every `part` entry has shared activity fields and a required `type`, plus type-specific rules:
• `Acquisition`: requires `transferred_title_of`, optional `transferred_title_from` / `transferred_title_to`
• `Payment`: optional `paid_amount`, `paid_from`, `paid_to`
• `TransferOfCustody`: requires `transferred_custody_of`, optional `transferred_custody_from` / `transferred_custody_to`
• `Encounter`: requires `encountered`
• `RightAcquisition`: requires `establishes`, optional `invalidates`
• `Move`: requires `moved`, optional `moved_from` / `moved_to`
• `Promise`: modeled as `type: Activity` with required classification containing `aat:300435599`
• `Transfer`: requires `transferred`, optional `transferred_from` / `transferred_to`
• Rights sub-structure is formally defined (`type: Right`) with identity/classification/applicability/possession dimensions and optional nesting via `part`.

Implementation Mapping — Provenance Activities Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Provenance discriminator enforcement

• Treat provenance endpoint entries as valid only when `classified_as` includes `aat:300055863`.

1. Top-level/part separation discipline

• Preserve top-level provenance context and keep transactional details in explicit `part` entries, not flattened fields.

1. Part-type contract enforcement

• Validate each part by its declared type-specific required fields before persistence or response emission.

1. Promise typing rule

• Enforce promise parts as `type: Activity` plus required classification `aat:300435599`.

1. Rights lifecycle fidelity

• Preserve `RightAcquisition` establish/invalidate semantics with explicit `Right` structures.

1. Monetary fidelity

• Preserve `Payment.paid_amount` numeric/currency semantics and multi-party flows (`paid_from`/`paid_to`).

1. Transfer ambiguity preservation

• Preserve ambiguous transfers as `Transfer` when evidence is insufficient for specific acquisition/custody/move typing.

TDD Additions — Provenance Activities Endpoint

Add failing-first tests for provenance endpoint conformance:

Contract-level:

• validates required top-level fields including provenance classification discriminator and required `part` array
• validates each `part` by subtype required fields
• validates rights sub-structures and promise classification rule

Route-level:

• provenance endpoint returns stable JSON-LD + HAL envelope with structured parts
• malformed part payloads fail boundary validation with clear subtype-specific errors
• unknown IDs return consistent not-found behavior

Integration-level:

• object endpoints resolve provenance edges (ownership/custody/move/rights/payment relationships)
• people/groups endpoints resolve transfer and payment roles consistently
• place endpoints resolve move/took_place_at references for provenance activities

Regression:

• provenance endpoint changes do not regress generic events endpoint behavior
• part-type fixtures prevent flattening of transactional semantics into lossy summaries

Fixture Anchors — Provenance Activities Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid provenance activity

• top-level activity with required provenance classification and non-empty `part`.

1. Acquisition + payment bundle

• single provenance entry with `Acquisition` and `Payment` parts sharing actors/object.

1. Transfer of custody fixture

• `TransferOfCustody` with required transferred object and from/to custodians.

1. Move fixture

• `Move` with moved objects and origin/destination places.

1. Encounter fixture

• `Encounter` part with discovered object and participating actor.

1. Right acquisition fixture

• `RightAcquisition` that establishes one right and invalidates another.

1. Promise fixture

• `type: Activity` part classified with `aat:300435599`.

1. Ambiguous transfer fixture

• `Transfer` part used when ownership-vs-custody evidence is indeterminate.

---

Round 41 Addendum — Sets Endpoint

Source section basis:

• Linked Art API 1.0: Sets endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Sets endpoint describes collections/aggregations across entity types (especially objects, texts, and images).
• Important modeling constraint:
• Set records do not list full members directly; membership is primarily expressed on member entities (`member_of`) or through discovery APIs.
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `Set`
• Recommended:
• `_label`
• `classified_as`
• `identified_by`
• Optional:
• common fields (`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`)
• set-specific fields: `dimension`, `about`, `members_exemplified_by`, `members_contained_by`, `created_by`, `used_for`
• Validation caveat:
• `members_exemplified_by` can only be minimally validated because values may be embedded structures of many endpoint shapes or references.
• Incoming links highlighted:
• `member_of` from most non-person/non-group entities
• `used_specific_object` from events/activities (for example exhibition object sets, auction lots)

Implementation Mapping — Sets Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Sets endpoint payloads must emit top-level `type: "Set"` only.

1. Membership modeling discipline

• Do not force exhaustive inline member lists in set records; preserve membership edges on member entities and discovery/search layers.

1. Exemplification vs containment semantics

• Preserve `members_exemplified_by` (representative examples) distinctly from `members_contained_by` (physical containment context).

1. Set-aboutness and curation context

• Preserve `about`, `used_for`, and `created_by` to represent thematic and publication/exhibition intent.

1. Dimension semantics for aggregates

• Preserve aggregate dimensions (for example member counts) using proper dimension structures.

1. Cross-endpoint set reuse

• Keep set identifiers stable for use by events/provenance/object workflows (lots, exhibitions, institutional holdings).

TDD Additions — Sets Endpoint

Add failing-first tests for set endpoint conformance:

Contract-level:

• validates required `@context`, `id`, `type=Set`
• validates optional set-specific fields and shared reference structures
• allows minimally validated `members_exemplified_by` while still enforcing basic object/reference safety

Route-level:

• sets endpoint returns stable JSON-LD + HAL envelope
• malformed set-specific payloads fail boundary validation clearly
• unknown IDs return consistent not-found behavior

Integration-level:

• member entities across endpoints resolve `member_of` links to set records
• events/provenance can reference sets via `used_specific_object` (for example auction lot sets)
• physical container linkage through `members_contained_by` resolves to object endpoint records

Regression:

• set endpoint changes do not regress group membership semantics (people/groups remain group-membership domain)
• discovery/search pipelines remain the mechanism for expanding full set membership

Fixture Anchors — Sets Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid set

• required-only set record with context/id/type.

1. Classified collection fixture

• set classified as collection with primary name and description statement.

1. Creation fixture

• set with `created_by` creation activity and precise timespan.

1. Aboutness fixture

• thematic set with `about` links to concept/person/place/object.

1. Exemplified-members fixture

• set with mixed embedded/reference `members_exemplified_by` samples.

1. Contained-members fixture

• set with `members_contained_by` physical object reference.

1. Event linkage fixture

• event/provenance `used_specific_object` references set (exhibition selection or auction lot).

1. Member-of traversal fixture

• object/text/visual records referencing set via `member_of`, verified through traversal tests.

---

Round 42 Addendum — Textual Works Endpoint

Source section basis:

• Linked Art API 1.0: Textual Works endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Textual Works endpoint describes linguistic content as first-class entities.
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `LinguisticObject`
• Recommended:
• `_label`
• `classified_as`
• `identified_by`
• Optional fields include:
• `referred_to_by`, `equivalent`, `subject_of`, `representation`, `member_of`, `attributed_by`
• `language`, `dimension`, `part_of`, `conceptually_part_of`
• `content`, `format`, `about`, `subject_to`, `created_by`, `used_for`
• Incoming links highlighted:
• `subject_of` from any endpoint entity
• `carries` from Physical Objects
• `digitally_carries` from Digital Objects

Implementation Mapping — Textual Works Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Textual endpoint payloads must emit top-level `type: "LinguisticObject"` only.

1. Text/content representation separation

• Preserve distinction between textual entity metadata and optional inline `content` serialization.

1. Language fidelity

• Preserve `language` references (and notations when present) for multilingual content behavior.

1. Intellectual structure links

• Preserve `part_of`, `conceptually_part_of`, and `about` relationships for composition and subject modeling.

1. Carrier relationship integrity

• Preserve inbound/outbound linkage with physical and digital carriers (`carries`, `digitally_carries`) without conflating with text identity.

1. Rights and publication provenance

• Preserve `subject_to`, `created_by`, and `used_for` structures for rights and publishing context.

TDD Additions — Textual Works Endpoint

Add failing-first tests for textual endpoint conformance:

Contract-level:

• validates required `@context`, `id`, `type=LinguisticObject`
• validates optional textual fields (`language`, `content`, `format`, `about`, rights/provenance links)
• validates composition links to textual/visual/abstract work references

Route-level:

• textual endpoint returns stable JSON-LD + HAL envelope
• malformed language/content/format or link structures fail boundary validation clearly
• unknown IDs return consistent not-found behavior

Integration-level:

• physical object routes resolve `carries` links to textual works
• digital object routes resolve `digitally_carries` links to textual works
• cross-endpoint `subject_of` traversal remains stable for all core entity families

Regression:

• textual endpoint updates do not regress abstract/visual work endpoint contracts
• multilingual and identifier fixtures remain stable across provider adapter updates

Fixture Anchors — Textual Works Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid textual work

• required-only record with context/id/type.

1. Named + identified textual work

• text with primary name and identifier (for example ISBN classification).

1. Language + content fixture

• text with language references and optional `content`/`format`.

1. Subject/about fixture

• text `about` person/object/concept and reciprocal `subject_of` links.

1. Composition fixture

• text `part_of` larger text/visual container and `conceptually_part_of` abstract work.

1. Publication provenance fixture

• `used_for` publishing activity with timespan/place/actor plus `created_by`.

1. Carrier linkage fixture

• text referenced by both physical `carries` and digital `digitally_carries`.

1. Rights fixture

• text with `subject_to` rights block and classification.

---

Round 43 Addendum — Visual Works Endpoint

Source section basis:

• Linked Art API 1.0: Visual Works endpoint
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Visual Works endpoint describes image/appearance content as first-class entities.
• Required properties:
• `@context` includes Linked Art context URI
• `id` is dereferenceable HTTP(S) URI
• `type` is `VisualItem`
• Recommended:
• `_label`
• `classified_as`
• `identified_by`
• Optional fields include:
• common fields (`referred_to_by`, `equivalent`, `member_of`, `subject_of`, `attributed_by`)
• structure/context fields (`dimension`, `part_of`, `conceptually_part_of`, `about`)
• depiction fields (`represents`, `represents_instance_of_type`)
• rights/provenance/publication (`subject_to`, `created_by`, `used_for`)
• Incoming links highlighted:
• `representation` from all endpoint families
• `shows` from Physical Objects
• `digitally_shows` from Digital Objects

Implementation Mapping — Visual Works Endpoint

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Visual endpoint payloads must emit top-level `type: "VisualItem"` only.

1. Depiction semantics separation

• Preserve `represents` (known entity) separately from `represents_instance_of_type` (unknown individual of known type).

1. Work-layer boundaries

• Keep visual works distinct from physical/digital carriers while preserving `shows`/`digitally_shows` linkage.

1. Conceptual and structural links

• Preserve `part_of` and `conceptually_part_of` for compositional and conceptual hierarchy navigation.

1. Style/aboutness fidelity

• Preserve classification/style and aboutness links without collapsing to plain textual tags.

1. Rights and creation provenance

• Preserve `subject_to`, `created_by`, and `used_for` structures for governance and publishing context.

TDD Additions — Visual Works Endpoint

Add failing-first tests for visual endpoint conformance:

Contract-level:

• validates required `@context`, `id`, `type=VisualItem`
• validates depiction fields (`represents`, `represents_instance_of_type`) with correct reference/type constraints
• validates optional conceptual/rights/provenance fields against shared contracts

Route-level:

• visual endpoint returns stable JSON-LD + HAL envelope
• malformed depiction or link structures fail boundary validation clearly
• unknown IDs return consistent not-found behavior

Integration-level:

• physical object routes resolve `shows` links to visual work records
• digital object routes resolve `digitally_shows` links to visual work records
• cross-endpoint `representation` traversal remains stable for entities referencing visual works

Regression:

• visual endpoint changes do not regress textual/abstract work endpoint contracts
• depiction semantics fixtures prevent conflating concrete represented entities with generic represented types

Fixture Anchors — Visual Works Endpoint Examples

Use these endpoint-specific patterns as fixture seeds:

1. Minimal valid visual work

• required-only record with context/id/type.

1. Style-classified visual work

• visual work with style/type classification and primary name.

1. Represents-entity fixture

• visual work `represents` known entity (for example place/person/object).

1. Represents-instance-of-type fixture

• visual work with unknown depicted individual expressed via `represents_instance_of_type`.

1. Carrier linkage fixture

• reciprocal links from physical `shows` and digital `digitally_shows`.

1. Conceptual hierarchy fixture

• visual work `part_of` and `conceptually_part_of` references.

1. Creation provenance fixture

• `created_by` creation activity with timespan/actor.

1. Rights/publication fixture

• visual work with `subject_to` rights and `used_for` publication activity.

---

Round 44 Addendum — Shared Structures

Source section basis:

• Linked Art API 1.0: About Shared Structures
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Shared structures reused across endpoints include:
• Activities
• Digital Links
• Dimensions
• Identifiers
• Monetary Amounts
• Names
• Rights
• References
• Statements
• TimeSpans
• Types/Concepts
• Relationships
• Embedded shared structures inherit the parent record `@context` and should not repeat `@context` inline.
• If a usually-embedded structure (for example `Name`, `Dimension`) has its own dereferenceable `id` with richer remote data, embedded instance must include `_complete: false`.
• Without `_complete: false`, consumers should assume the embedded structure is complete and URI is informational.

Implementation Mapping — Shared Structures

Apply these requirements to adapters, normalization, and route outputs:

1. Context inheritance rule

• Do not emit nested `@context` for embedded shared structures inside endpoint payloads.

1. Standalone structure rule

• If shared structures are published as standalone Linked Art resources, include root `@context`.

1. Partial-embed signaling

• Enforce `_complete: false` when embedding structures that have richer canonical detail at their own `id`.

1. Contract consistency

• Reuse one shared contract layer for Names/Identifiers/Dimensions/TimeSpans/etc. across all endpoints.

1. Reference integrity

• Preserve stable `id` references in embedded structures to enable deferred retrieval and graph joins.

TDD Additions — Shared Structures

Add failing-first tests for shared-structure conformance:

Contract-level:

• validates embedded shared structures do not include nested `@context`
• validates standalone shared-structure documents include required root `@context`
• validates `_complete: false` requirement for partial embedded structures with dereferenceable IDs

Route-level:

• endpoint responses consistently apply shared structure schemas across entity families
• malformed shared structures fail boundary validation with clear structure-specific errors

Integration-level:

• consumers can resolve referenced shared-structure `id` values for richer retrieval flows
• mixed complete/partial embeddings behave predictably across provider adapters

Regression:

• adding provider slices does not fork shared structure semantics by endpoint
• `_complete` signaling remains stable in snapshots for names/dimensions/identifiers

Fixture Anchors — Shared Structures Examples

Use these shared-structure patterns as fixture seeds:

1. Embedded name (complete) fixture

• embedded `Name` with no nested `@context`, no `_complete` flag.

1. Embedded name (partial) fixture

• embedded `Name` with dereferenceable `id` and `_complete: false`.

1. Embedded dimension fixture

• dimension with value/unit and no nested `@context`.

1. Embedded timespan fixture

• `TimeSpan` with fuzzy bounds and display label.

1. Standalone shared-structure fixture

• standalone shared structure resource with root `@context`.

1. Relationship assignment fixture

• embedded relationship structure with reference integrity and shared schema compliance.

---

Round 45 Addendum — Shared Structure: Activities

Source section basis:

• Linked Art API 1.0: Shared structure for Activities
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Activities are often embedded inside entity records for lifecycle and usage context.
• Core usage covers:
• beginnings (`Production`, `Creation`, `Formation`, `Birth`)
• endings (`Destruction`, `Dissolution`, `Death`)
• other activity context (`Modification`, `Encounter`, generic `Activity`, etc.)
• Shared activity structure:
• required `type`
• optional `id` with `_complete: false` when embedded form is partial and richer data exists remotely
• common contextual fields: `identified_by`, `classified_as`, `referred_to_by`, `took_place_at`, `timespan`, temporal ordering, causal/influence, participants, `used_specific_object`, `technique`, `part`
• Type-conditional restriction:
• `Birth`/`Death` do not use `carried_out_by`, `influenced_by`, `used_specific_object`, `technique`, or `part`
• `PartRemoval` adds `diminished` reference semantics.
• Activity classes vary by endpoint family (for example `Person` uses `Birth`/`Death`, `Physical Object` uses `Production`/`Destruction` plus others, etc.).

Implementation Mapping — Shared Activities

Apply these requirements to adapters, normalization, and route outputs:

1. Shared activity contract reuse

• Use one activity schema layer across all endpoint families, then apply endpoint/type-specific constraints.

1. Partial embed signaling

• Enforce `_complete: false` for embedded activity nodes with dereferenceable IDs when embedded payload is incomplete.

1. Type-conditional guards

• Enforce forbidden fields for `Birth`/`Death` activity types at validation boundary.

1. Lifecycle event precision

• Preserve beginning/end activity distinctions rather than flattening into single status/date fields.

1. Participation semantics

• Preserve role differences (`carried_out_by` vs other participation/context fields) where applicable.

1. Temporal ordering fidelity

• Preserve `timespan`, `during`, `before`, `after`, and `caused_by` without lossy date-only collapse.

1. Nested activity support

• Preserve `part` sub-activities for complex activities except where type restrictions prohibit it.

TDD Additions — Shared Activities

Add failing-first tests for shared activity structure conformance:

Contract-level:

• validates required `type` and shared optional field schemas across embedded activity nodes
• validates `_complete: false` requirement for partial embedded activities with resolvable IDs
• rejects forbidden fields on `Birth`/`Death`

Route-level:

• endpoints emitting embedded activities conform to shared activity schema + endpoint-specific type allowlists
• malformed activity nodes fail boundary validation with explicit field/type diagnostics

Integration-level:

• lifecycle links (`produced_by`, `created_by`, `born`, `died`, `destroyed_by`, etc.) resolve consistently across endpoints
• `used_for`, `carried_out`, and `participated_in` activity traversals preserve actor-role semantics

Regression:

• activity schema updates do not diverge by endpoint family
• nested-part and temporal-ordering fixtures remain stable across provider adapter updates

Fixture Anchors — Shared Activities Examples

Use these shared-activity patterns as fixture seeds:

1. Minimal embedded activity

• embedded activity with required `type` and basic timespan/place.

1. Partial embedded activity fixture

• activity with `id` and `_complete: false` indicating richer standalone representation.

1. Birth/death restriction fixture

• invalid payloads proving forbidden fields are rejected for `Birth`/`Death`.

1. Production activity fixture

• production with technique, timespan, place, actor, and influence links.

1. PartRemoval fixture

• `PartRemoval` activity with `diminished` object reference.

1. Nested part fixture

• complex activity with `part` sub-activities for non-restricted types.

1. Temporal ordering fixture

• activity with `during`, `before`, `after`, `caused_by` chain.

1. Actor role fixture

• distinguishes `carried_out_by` vs participation context across related activities.

---

Round 46 Addendum — Shared Structure: Digital Links

Source section basis:

• Linked Art API 1.0: Shared structure for Digital Links
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Digital Links provide an embedding shortcut for external digital resources (for example web pages/images) within core entity records.
• Structure is nested:
• embedded work (`VisualItem` or `LinguisticObject`)
• embedded `DigitalObject` inside that work
• Embedded work constraints:
• `type` required and must be `VisualItem` or `LinguisticObject`
• exactly one of:
• `digitally_shown_by` (for `VisualItem`)
• `digitally_carried_by` (for `LinguisticObject`)
• optional `_complete: false` when `id` exists and richer remote representation is available
• Embedded digital object constraints:
• `type` required and must be `DigitalObject`
• optional `access_point` entries must each contain required `{ id, type: "DigitalObject" }`
• optional `_complete: false` signaling for partial embedded form
• optional digital metadata (`digitally_available_via`, `format`, `conforms_to`, etc.)
• Incoming usage:
• `representation` when embedded work is visual
• `subject_of` when embedded work is linguistic

Implementation Mapping — Shared Digital Links

Apply these requirements to adapters, normalization, and route outputs:

1. Nested one-of enforcement

• Enforce class-dependent exclusive linkage:
• `VisualItem` -> must include `digitally_shown_by` only
• `LinguisticObject` -> must include `digitally_carried_by` only

1. Embedded partiality signaling

• Require `_complete: false` when embedded work/digital object includes dereferenceable `id` but is not fully represented inline.

1. Access point strictness

• Enforce `access_point` entry shape (`id` + `type: DigitalObject`) and treat as retrieval locators, not identity replacements.

1. Work-vs-carriership separation

• Preserve distinction between work semantics (visual/textual content) and carrier/delivery semantics (digital objects/services).

1. Shared-contract reuse

• Reuse Name/Type/Statement/Language shared structures inside embedded work and digital object nodes.

TDD Additions — Shared Digital Links

Add failing-first tests for digital-link structure conformance:

Contract-level:

• validates embedded work `type` allowlist (`VisualItem` | `LinguisticObject`)
• validates exclusive/class-appropriate presence of `digitally_shown_by` vs `digitally_carried_by`
• validates embedded digital object `type=DigitalObject` and access-point child shape
• validates `_complete: false` requirement for partial embedded nodes with dereferenceable IDs

Route-level:

• entity endpoints embedding digital links conform to nested shared structure contracts
• malformed nested work/digital object payloads fail boundary validation with explicit path-level errors

Integration-level:

• `representation` traversals resolve visual embedded links and downstream digital object access points
• `subject_of` traversals resolve linguistic embedded links and downstream digital object access points
• standalone digital object endpoints remain consistent with embedded digital link nodes

Regression:

• updates to embedded digital-link logic do not regress full digital object endpoint semantics
• one-of constraint fixtures prevent ambiguous or dual-mode linkage in one embedded work node

Fixture Anchors — Shared Digital Links Examples

Use these shared digital-link patterns as fixture seeds:

1. Visual embedding fixture

• embedded `VisualItem` with required `digitally_shown_by` and no `digitally_carried_by`.

1. Linguistic embedding fixture

• embedded `LinguisticObject` with required `digitally_carried_by` and language metadata.

1. Nested digital object fixture

• embedded `DigitalObject` with classification/name and valid `access_point`.

1. Partial embedded node fixture

• embedded work/digital object with `id` and `_complete: false`.

1. Access-point validation fixture

• invalid/missing `id` or incorrect `type` in `access_point` is rejected.

1. Service linkage fixture

• embedded digital object with `digitally_available_via` and `conforms_to` spec link.

---

Round 47 Addendum — Shared Structure: Activities (Reconfirmation)

Source section basis:

• Linked Art API 1.0: Shared structure for Activities (repeat ingestion)
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• This round reconfirms the same activity-shared-structure rules already captured in Round 45.
• No net-new schema fields, type rules, or endpoint-specific constraints were introduced beyond Round 45.
• Reconfirmed constraints include:
• shared embedded activity structure with required `type`
• partial embed signaling via `_complete: false`
• `Birth`/`Death` field restrictions
• endpoint-family mapping of beginning/ending/other activity classes
• `PartRemoval.diminished` usage

Implementation Mapping — Shared Activities (Reconfirmation)

Apply these requirements to adapters, normalization, and route outputs:

1. No new implementation scope

• Keep Round 45 implementation mapping as canonical; no additional code-path requirements from this round.

1. Stability expectation

• Treat this repeated docs drop as a consistency checkpoint for existing activity boundary validation and serializers.

TDD Additions — Shared Activities (Reconfirmation)

Add/retain failing-first tests for stability:

Contract-level:

• keep Round 45 activity conformance suite as authoritative and unchanged

Regression:

• add/retain a snapshot guard that duplicate spec ingestion does not change schemas or route payload shapes
• ensure `Birth`/`Death` forbidden-field checks remain active

Fixture Anchors — Shared Activities (Reconfirmation)

Use existing Round 45 fixtures as anchors:

1. Partial activity embed fixture with `_complete: false`.

1. Birth/death restricted-field negative fixture.

1. Production activity with timespan/place/technique/actor.

1. Nested `part` fixture for non-restricted activity types.

---

Round 48 Addendum — Shared Structure: Dimensions

Source section basis:

• Linked Art API 1.0: Shared structure for Dimensions
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• A Dimension combines:
• numeric `value`
• required `unit` (`MeasurementUnit`)
• classification of what is being measured
• Core requirements:
• `type` required and must be `Dimension`
• `value` required (number)
• `unit` required (MeasurementUnit reference/object)
• Optional semantics:
• uncertainty/range bounds: `upper_value_limit`, `lower_value_limit`
• textual rendering via `identified_by` (Name)
• provenance of measurement via `assigned_by` (AttributeAssignment/measurement activity)
• `_complete: false` when embedded dimension has dereferenceable `id` with richer remote data
• Incoming usage:
• `dimension` across many endpoints (especially physical/digital objects)
• `duration` on `TimeSpan` as dimensionalized temporal length

Implementation Mapping — Shared Dimensions

Apply these requirements to adapters, normalization, and route outputs:

1. Required-field strictness

• Enforce `type=Dimension`, numeric `value`, and required `unit` at boundary validation.

1. Unit integrity

• Require `unit.type = MeasurementUnit` and preserve unit identifiers/labels for interoperability.

1. Uncertainty modeling

• Preserve `upper_value_limit` and `lower_value_limit` as explicit uncertainty bounds, not inferred from display strings.

1. Display-text separation

• Preserve human-readable dimensional strings in `identified_by` without replacing canonical numeric/value/unit fields.

1. Measurement provenance

• Preserve `assigned_by` as explicit measurement activity/provenance trace when available.

1. Partial-embed signaling

• Enforce `_complete: false` for partial embedded dimension nodes with richer dereferenceable representations.

TDD Additions — Shared Dimensions

Add failing-first tests for dimension structure conformance:

Contract-level:

• validates required `type=Dimension`, numeric `value`, and required `unit` object/reference
• validates optional uncertainty bounds as numbers when present
• validates `assigned_by` activity structure and `identified_by` name shape
• validates `_complete: false` requirement for partial embedded dimensions with resolvable IDs

Route-level:

• entity endpoints embedding dimensions conform to shared dimension schema
• malformed dimension/unit/bound payloads fail boundary validation with explicit field-path errors

Integration-level:

• object/text/digital/person/group endpoints preserve dimensional semantics consistently
• timespan duration dimensions interoperate with time modeling without type ambiguity

Regression:

• dimension serializer changes do not collapse bounds into strings or lose unit typing
• provider adapter updates preserve measurement provenance in `assigned_by`

Fixture Anchors — Shared Dimensions Examples

Use these shared-dimension patterns as fixture seeds:

1. Minimal valid dimension

• `type`, numeric `value`, and valid `MeasurementUnit`.

1. Uncertain dimension fixture

• dimension with `lower_value_limit` and `upper_value_limit`.

1. Display-name fixture

• `identified_by` name expressing human-readable measurement string.

1. Measurement provenance fixture

• `assigned_by` measurement activity with classifier and measuring actor.

1. Partial dimension fixture

• embedded dimension with dereferenceable `id` and `_complete: false`.

1. Duration dimension fixture

• `TimeSpan` duration represented as a dimension with unit and numeric value.

---

Round 49 Addendum — Shared Structure: Concept References

Source section basis:

• Linked Art API 1.0: Concept References
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Concept references (Types) are core embedded structures across almost all entities.
• Required fields for embedded concept reference:
• `id` (URI)
• `type` in allowlist: `Type`, `Currency`, `Language`, `Material`, `MeasurementUnit`
• Recommended:
• `_label`
• Optional:
• `equivalent`
• `notation` (commonly used especially for `Language` tags)
• `classified_as` (meta-classification of concept)
• Specialized concept-reference classes:
• `Language` for human language
• `Material` for physical composition
• `Currency` for monetary amounts
• `MeasurementUnit` for dimensions
• Full standalone concept records are handled by the Concept endpoint; this shared structure is for embedded references.

Implementation Mapping — Shared Concept References

Apply these requirements to adapters, normalization, and route outputs:

1. Concept type allowlist enforcement

• Enforce strict embedded concept-reference `type` allowlist at validation boundary.

1. URI-first identity

• Preserve canonical concept `id` URIs as authoritative identity keys for cross-dataset interoperability.

1. Meta-classification preservation

• Preserve `classified_as` on concept references to support meta-typing (for example “Painting” classified as “Type of Work”).

1. Notation handling

• Preserve `notation` values, especially for language tags/codes, without replacing URI identity semantics.

1. Embedded-vs-full-record separation

• Keep embedded concept references lightweight; use Concept endpoint for full concept expansion.

TDD Additions — Shared Concept References

Add failing-first tests for concept-reference conformance:

Contract-level:

• validates required `id` + `type` for embedded concept references
• validates `type` is in allowed concept-reference class set
• validates optional `notation`, `equivalent`, and nested `classified_as` structures

Route-level:

• all endpoint payloads embedding concepts conform to shared concept-reference schema
• malformed concept references fail boundary validation with explicit path-level errors

Integration-level:

• concept references resolve consistently across:
• `classified_as` (all entities)
• `technique` / `influenced_by` (activities)
• `about` (textual/visual works)
• `language` (linguistic objects)
• `currency` (monetary amounts)
• `unit` (dimensions)
• `made_of` (objects/material composition)

Regression:

• provider adapter updates do not drift concept reference typing or URI identity behavior
• meta-classification fixtures remain stable across endpoint families

Fixture Anchors — Shared Concept References Examples

Use these concept-reference patterns as fixture seeds:

1. Minimal type reference

• embedded `Type` with required URI `id` and `type`.

1. Meta-typed concept fixture

• concept with nested `classified_as` meta-type (for example work type hierarchy).

1. Language reference fixture

• `Language` with notation tag/code plus label.

1. Currency reference fixture

• `Currency` used in monetary amount structure.

1. Measurement unit fixture

• `MeasurementUnit` used in dimension structure.

1. Material reference fixture

• `Material` used in object `made_of` array.

---

Round 50 Addendum — Shared Structure: Identifiers

Source section basis:

• Linked Art API 1.0: Identifiers
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Identifiers are non-natural-language codes assigned to resources in context.
• Shared identifier structure is separate from Names:
• no `language`
• no translation/alternative-form semantics like names
• Required fields:
• `type` must be `Identifier`
• `content` must be string
• Optional/recommended:
• `id`, `_label`, `_complete`
• `classified_as`, `identified_by` (display name for identifier), `referred_to_by`, `assigned_by`
• `_complete: false` is required when embedded identifier with dereferenceable `id` is partial and richer remote form exists.
• Incoming usage:
• `identified_by` across all endpoints
• `contact_point` for Person/Group endpoints

Implementation Mapping — Shared Identifiers

Apply these requirements to adapters, normalization, and route outputs:

1. Type/content strictness

• Enforce `type=Identifier` and required string `content` at boundary validation.

1. Identifier-vs-name separation

• Keep identifier semantics distinct from Name semantics (no language/translation assumptions).

1. Classification fidelity

• Preserve identifier type classifications (for example accession number, ISBN) via `classified_as`.

1. Assignment provenance

• Preserve `assigned_by` assignment activities with timespan/actor context where available.

1. Partial embed signaling

• Enforce `_complete: false` for embedded identifiers with dereferenceable IDs and incomplete inline payload.

1. Contact point reuse

• Reuse Identifier shared contract for `contact_point` fields on Person/Group endpoints.

TDD Additions — Shared Identifiers

Add failing-first tests for identifier structure conformance:

Contract-level:

• validates required `type=Identifier` + string `content`
• rejects identifier payloads with invalid/non-string content
• validates optional classification/display-name/assignment fields
• validates `_complete: false` requirement for partial embedded identifiers with resolvable IDs

Route-level:

• all endpoint payloads embedding identifiers conform to shared identifier schema
• malformed identifier/classification/assignment blocks fail boundary validation with explicit path-level errors

Integration-level:

• identifier structures resolve consistently through `identified_by` across endpoint families
• person/group `contact_point` fields validate and serialize as identifiers

Regression:

• provider adapter updates do not collapse identifiers into names or lose assignment provenance
• classification fixtures (accession/ISBN/etc.) remain stable across endpoints

Fixture Anchors — Shared Identifiers Examples

Use these shared-identifier patterns as fixture seeds:

1. Minimal valid identifier

• `type: Identifier` with required string `content`.

1. Classified identifier fixture

• identifier classified as accession/ISBN style concept.

1. Display-name fixture

• identifier with `identified_by` name for UI display semantics.

1. Assignment provenance fixture

• identifier with `assigned_by` activity including timespan and assigning group/person.

1. Partial identifier fixture

• embedded identifier with dereferenceable `id` and `_complete: false`.

1. Contact-point fixture

• person/group `contact_point` modeled and validated as identifier structure.

---

Round 51 Addendum — Shared Structure: Monetary Amounts

Source section basis:

• Linked Art API 1.0: Monetary Amounts
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Monetary Amounts parallel Dimensions but use `currency` instead of `unit`.
• Required fields:
• `type` must be `MonetaryAmount`
• numeric `value`
• required `currency` (must follow Currency concept-reference rules)
• Optional/recommended:
• `id`, `_label`, `_complete`
• `classified_as`, `identified_by`, `upper_value_limit`, `lower_value_limit`, `referred_to_by`
• `_complete: false` is required when embedded amount has dereferenceable `id` and richer remote representation exists.
• Primary usage in Linked Art model/API:
• `paid_amount` within Provenance `Payment` parts
• also usable as `dimension` in other contexts (for example set-level pricing/valuation signals)

Implementation Mapping — Shared Monetary Amounts

Apply these requirements to adapters, normalization, and route outputs:

1. Type/value/currency strictness

• Enforce `type=MonetaryAmount`, numeric `value`, and required `currency` at boundary validation.

1. Currency integrity

• Require `currency.type=Currency` and preserve authoritative concept URI/notation (for example ISO code notation).

1. Uncertainty bounds support

• Preserve optional `upper_value_limit` and `lower_value_limit` for uncertain/estimated amounts.

1. Display-text separation

• Preserve `identified_by` display text without replacing canonical numeric+currency representation.

1. Provenance payment wiring

• Preserve `paid_amount` semantics inside provenance `Payment` parts without flattening into generic note fields.

1. Partial embed signaling

• Enforce `_complete: false` for embedded partial monetary amount nodes with dereferenceable IDs.

TDD Additions — Shared Monetary Amounts

Add failing-first tests for monetary amount conformance:

Contract-level:

• validates required `type=MonetaryAmount`, numeric `value`, and `currency` reference structure
• validates optional bounds (`upper_value_limit`, `lower_value_limit`) as numeric
• validates optional classification/display/reference fields
• validates `_complete: false` requirement for partial embedded monetary amounts with resolvable IDs

Route-level:

• provenance/payment payloads embedding `paid_amount` conform to shared monetary schema
• malformed value/currency/bounds payloads fail boundary validation with explicit path-level errors

Integration-level:

• provenance `Payment` parts preserve paid amount and currency semantics end-to-end
• set/object dimension contexts using monetary amounts remain compatible with shared dimension pipelines

Regression:

• serializer updates do not collapse monetary amounts into raw strings
• currency URI and notation handling remain stable across provider adapters

Fixture Anchors — Shared Monetary Amounts Examples

Use these shared monetary patterns as fixture seeds:

1. Minimal valid monetary amount

• required `type`, numeric `value`, and `currency`.

1. Classified amount fixture

• amount classified as starting price/estimate/hammer price.

1. Display-title fixture

• amount with `identified_by` display name text.

1. Uncertainty fixture

• amount with lower/upper value bounds.

1. Payment integration fixture

• provenance `Payment.paid_amount` with payer/payee links.

1. Partial amount fixture

• embedded amount with dereferenceable `id` and `_complete: false`.

---

Round 52 Addendum — Shared Structure: Names

Source section basis:

• Linked Art API 1.0: Names
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Names are linguistic labels for entities and are shared across all endpoints.
• Required fields:
• `type` must be `Name`
• `content` must be string
• Recommended/optional:
• `classified_as`, `language` (recommended)
• `id`, `_label`, `_complete`, `part`, `identified_by`, `referred_to_by`, `assigned_by`
• `_complete: false` is required when embedded name has dereferenceable `id` and richer remote representation exists.
• Names can be decomposed via recursive `part` structures (for example subtitle component).
• Unlike Identifiers, Names are linguistic and language-tag-aware.

Implementation Mapping — Shared Names

Apply these requirements to adapters, normalization, and route outputs:

1. Type/content strictness

• Enforce `type=Name` and required string `content` at boundary validation.

1. Name-vs-identifier separation

• Keep Name semantics linguistic (with optional language) and separate from Identifier code semantics.

1. Language fidelity

• Preserve one or more `language` references/notations for multilingual name handling.

1. Recursive name-part support

• Preserve `part` arrays as nested Name structures for compound/appellative names.

1. Classification fidelity

• Preserve `classified_as` distinctions (primary name, subtitle, display title, etc.).

1. Partial embed signaling

• Enforce `_complete: false` for embedded partial name nodes with dereferenceable IDs.

1. Assignment readiness

• Support optional `assigned_by` structure even if use cases are currently limited.

TDD Additions — Shared Names

Add failing-first tests for name structure conformance:

Contract-level:

• validates required `type=Name` + string `content`
• validates optional language/classification/referred_to_by/identified_by fields
• validates recursive `part` structures as Name-only nested nodes
• validates `_complete: false` requirement for partial embedded names with resolvable IDs

Route-level:

• endpoint payloads embedding names conform to shared name schema
• malformed name/language/part payloads fail boundary validation with explicit path-level errors

Integration-level:

• multilingual names remain stable across object/person/group/place/textual/visual endpoints
• display-name patterns (`identified_by` on names) remain consistent for UI surfaces

Regression:

• updates do not collapse linguistic names into identifier semantics
• nested-name part fixtures remain stable across provider adapter updates

Fixture Anchors — Shared Names Examples

Use these shared-name patterns as fixture seeds:

1. Minimal valid name

• `type: Name` with required `content`.

1. Classified primary name fixture

• name classified as primary name.

1. Multilingual name fixture

• single name with multiple language references/notations.

1. Nested part fixture

• compound name with subtitle `part` node.

1. Display-title fixture

• name `identified_by` another name classified as display title.

1. Partial name fixture

• embedded name with dereferenceable `id` and `_complete: false`.

---

Round 53 Addendum — Shared Structure: Rights

Source section basis:

• Linked Art API 1.0: Rights
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Rights structure represents machine-comparable rights assertions for intellectual works.
• Required fields:
• `type` must be `Right`
• Recommended/optional:
• `identified_by`, `classified_as` (recommended)
• `id`, `_label`, `_complete`, `referred_to_by`, `possessed_by`
• Rights class/type semantics are conveyed through `classified_as` concept references (for example CC URIs).
• `_complete: false` required when embedded right has dereferenceable `id` and richer remote representation exists.
• Incoming usage emphasized:
• `subject_to` on intellectual resources (Textual Work, Visual Work, Abstract Work, Statement)

Implementation Mapping — Shared Rights

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Enforce `type=Right` at boundary validation for all embedded rights structures.

1. Rights-classification fidelity

• Preserve `classified_as` URIs as canonical machine-comparable rights descriptors.

1. Human-readable display support

• Preserve `identified_by` names (for example “Public Domain”) for UI and downstream reporting.

1. Holder modeling

• Preserve optional `possessed_by` actor references where right-holder context is provided.

1. Partial embed signaling

• Enforce `_complete: false` for partial embedded rights nodes with dereferenceable IDs.

1. Subject linkage integrity

• Preserve `subject_to` edges on intellectual works without flattening rights into unstructured string fields.

TDD Additions — Shared Rights

Add failing-first tests for rights structure conformance:

Contract-level:

• validates required `type=Right`
• validates recommended `classified_as` and `identified_by` structures when present
• validates optional `possessed_by` actor references
• validates `_complete: false` requirement for partial embedded rights with resolvable IDs

Route-level:

• endpoint payloads embedding rights through `subject_to` conform to shared rights schema
• malformed rights/classification/holder payloads fail boundary validation with explicit path-level errors

Integration-level:

• textual/visual/abstract/statement endpoints preserve consistent `subject_to` rights modeling
• rights classifications remain interoperable with concept-reference rules and external rights vocab URIs

Regression:

• provider adapter updates do not collapse structured rights blocks into plain text
• rights display labels and machine-readable URIs remain synchronized in snapshots

Fixture Anchors — Shared Rights Examples

Use these shared-rights patterns as fixture seeds:

1. Minimal valid right

• embedded right with required `type`.

1. Classified rights fixture

• right classified with external rights URI (for example CC0).

1. Display title fixture

• right with `identified_by` display title name.

1. Holder fixture

• right with `possessed_by` person/group references.

1. Subject linkage fixture

• textual/visual/abstract resource linked via `subject_to` to right.

1. Partial right fixture

• embedded right with dereferenceable `id` and `_complete: false`.

---

Round 54 Addendum — Shared Structure: References

Source section basis:

• Linked Art API 1.0: References
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• References are lightweight cross-resource links and must remain clearly distinct from embedded full structures.
• Canonical reference shape:
• required `id` (dereferenceable URI)
• required `type` (must match dereferenced resource type)
• recommended `_label`
• Reference semantics:
• references are inherently incomplete and do not include `_complete`
• dereferencing should yield canonical record with same `id` and `type`
• Allowed optional enrichments on references:
• `equivalent` for external-system identity alignment
• `notation` (especially language tags/codes for language references)
• Types are a special reference case and may include meta-classification to support processing when external vocab resources are not Linked Art-native.
• Client guidance from spec:
• proactively follow references and pre-cache descriptions for responsive UI behavior.

Implementation Mapping — Shared References

Apply these requirements to adapters, normalization, and route outputs:

1. Strict reference envelope

• Treat `id`/`type`/`_label` (+ optional `equivalent`/`notation`) as the only valid reference payload shape.

1. No `_complete` on references

• Do not emit `_complete` for references; reserve `_complete` logic for partially embedded shared structures.

1. Type identity consistency

• Enforce that reference `type` matches dereferenced record `type` in validation/integration checks.

1. Embedded-vs-reference boundary

• Reject hybrid payloads that mix reference-only shape with embedded-structure-only fields.

1. External equivalence handling

• Preserve optional `equivalent` links for reconciliation without replacing local canonical IDs.

1. Language notation support

• Preserve `notation` when references are language concepts to aid i18n consumers.

1. Fetch/caching readiness

• Keep references stable and minimal so clients can dereference/cross-cache deterministically.

TDD Additions — Shared References

Add failing-first tests for reference conformance:

Contract-level:

• validates required `id` + `type` for all reference nodes
• validates absence of `_complete` on references
• validates optional `_label`, `equivalent`, `notation` fields
• rejects embedded-only fields on reference nodes

Route-level:

• endpoint payloads emit reference nodes in canonical lightweight shape
• malformed references fail boundary validation with explicit path-level diagnostics

Integration-level:

• dereferenced records match reference `id` + `type`
• cross-endpoint traversal via references remains stable (object->owner/place/set/work etc.)
• language reference notations round-trip for i18n usage

Regression:

• provider updates do not accidentally expand references into inconsistent partial embeds
• reference serializer remains consistent across all endpoint families

Fixture Anchors — Shared References Examples

Use these shared-reference patterns as fixture seeds:

1. Minimal valid reference

• reference with required `id` and `type`.

1. Labeled reference fixture

• reference including recommended `_label`.

1. Equivalent-link fixture

• local reference with `equivalent` external authority URI.

1. Language notation fixture

• language reference with notation tag/code.

1. Reference-vs-embed negative fixture

• payload wrongly combining reference shape with embedded-only fields is rejected.

1. Dereference consistency fixture

• referenced resource resolves with matching `id` and `type`.

---

Round 55 Addendum — Shared Structure: Statements

Source section basis:

• Linked Art API 1.0: Statements
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Statements are embedded human-readable textual expressions about entities.
• Required fields:
• `type` must be `LinguisticObject`
• `content` must be string
• Recommended/optional:
• `classified_as`, `language`, `identified_by` (recommended)
• `id`, `_label`, `_complete`, `referred_to_by`, `format`, `assigned_by`, `subject_to`, `created_by`
• `_complete: false` required when embedded statement has dereferenceable `id` and richer remote representation exists.
• Primary incoming usage:
• `referred_to_by` across essentially all endpoint families.
• Statements support both:
• internationalized textual content (`language`)
• structured rights over statement text (`subject_to`)

Implementation Mapping — Shared Statements

Apply these requirements to adapters, normalization, and route outputs:

1. Type/content strictness

• Enforce `type=LinguisticObject` and required string `content` for statement nodes.

1. Statement-vs-textual-work boundary

• Keep embedded statement semantics distinct from standalone Textual Work endpoint records.

1. Classification and language fidelity

• Preserve statement purpose classification (description/note/etc.) and language references/notations.

1. Format-aware content handling

• Preserve optional `format` when `content` is non-plain text media.

1. Rights and provenance support

• Preserve `subject_to`, `assigned_by`, and `created_by` for statement governance/provenance.

1. Nested statement support

• Preserve `referred_to_by` on statements for statement-about-statement use cases.

1. Partial embed signaling

• Enforce `_complete: false` for partial embedded statements with dereferenceable IDs.

TDD Additions — Shared Statements

Add failing-first tests for statement structure conformance:

Contract-level:

• validates required `type=LinguisticObject` + string `content`
• validates recommended classification/language/identified_by structures
• validates optional `format`, `subject_to`, `assigned_by`, `created_by`, nested `referred_to_by`
• validates `_complete: false` requirement for partial embedded statements with resolvable IDs

Route-level:

• endpoint payloads embedding statements via `referred_to_by` conform to shared statement schema
• malformed statement/language/rights/format payloads fail boundary validation with explicit path-level errors

Integration-level:

• statement rights (`subject_to`) interoperate with shared rights structure across endpoint families
• statement language and display-name behavior remains stable in UI-facing payloads

Regression:

• provider adapter updates do not collapse structured statements into plain strings
• nested statement fixtures remain stable across endpoint serializers

Fixture Anchors — Shared Statements Examples

Use these shared-statement patterns as fixture seeds:

1. Minimal valid statement

• `type: LinguisticObject` with required `content`.

1. Classified description fixture

• statement classified as description/brief text.

1. Multilingual statement fixture

• statement with language references and notation.

1. Rights-on-statement fixture

• statement with `subject_to` right classification and display name.

1. Nested statement fixture

• statement with `referred_to_by` note about provenance/source of statement.

1. Partial statement fixture

• embedded statement with dereferenceable `id` and `_complete: false`.

---

Round 56 Addendum — Shared Structure: TimeSpans

Source section basis:

• Linked Art API 1.0: TimeSpans
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• TimeSpans model fuzzy temporal boundaries for events/activities and related temporal entities.
• Required field:
• `type` must be `TimeSpan`
• Recommended/optional fields:
• `identified_by`, `begin_of_the_begin`, `end_of_the_end` (recommended)
• `id`, `_label`, `_complete`, `classified_as`, `end_of_the_begin`, `begin_of_the_end`, `referred_to_by`, `duration`
• Critical minimum-information rule:
• each TimeSpan must include at least one of:
• `identified_by`
• `begin_of_the_begin`
• `end_of_the_end`
• Fuzzy boundary semantics:
• `begin_of_the_begin` = earliest possible start
• `end_of_the_begin` = latest possible start
• `begin_of_the_end` = earliest possible end
• `end_of_the_end` = latest possible end
• `duration` is a Dimension structure describing interval length.
• `_complete: false` required when embedded timespan has dereferenceable `id` and richer remote representation exists.

Implementation Mapping — Shared TimeSpans

Apply these requirements to adapters, normalization, and route outputs:

1. Type strictness

• Enforce `type=TimeSpan` at boundary validation.

1. Minimum-information guard

• Enforce “at least one of `identified_by` / `begin_of_the_begin` / `end_of_the_end`” to prevent empty/ambiguous timespan nodes.

1. ISO timestamp fidelity

• Preserve timestamp fields as ISO8601 strings without lossy locale/date parsing transforms.

1. Fuzzy-bound semantics preservation

• Preserve all four boundary fields distinctly; do not collapse to single start/end fields.

1. Duration integration

• Preserve optional `duration` as shared Dimension structure with proper unit typing.

1. Partial embed signaling

• Enforce `_complete: false` for partial embedded timespans with dereferenceable IDs.

TDD Additions — Shared TimeSpans

Add failing-first tests for timespan conformance:

Contract-level:

• validates required `type=TimeSpan`
• validates minimum-information rule (at least one key field present)
• validates optional fuzzy boundary fields as ISO8601 date-time strings
• validates optional `duration` structure via shared Dimension schema
• validates `_complete: false` requirement for partial embedded timespans with resolvable IDs

Route-level:

• endpoint payloads embedding `timespan` conform to shared timespan schema
• malformed/empty timespan nodes fail boundary validation with explicit path-level errors

Integration-level:

• activity/event/provenance/person/group/object lifecycle time fields remain interoperable via shared timespan rules
• duration dimensions on timespans remain consistent with shared dimension processing

Regression:

• provider updates do not collapse fuzzy temporal bounds into single-point dates
• snapshot fixtures preserve all boundary semantics and minimum-information behavior

Fixture Anchors — Shared TimeSpans Examples

Use these shared-timespan patterns as fixture seeds:

1. Minimal valid timespan (label-only)

• `type=TimeSpan` plus `identified_by` display name.

1. Minimal valid timespan (boundary-only)

• `type=TimeSpan` plus `begin_of_the_begin` and/or `end_of_the_end`.

1. Full fuzzy-bound fixture

• all four boundary fields populated for uncertainty windows.

1. Duration fixture

• timespan with `duration` dimension and measurement unit.

1. Descriptive statement fixture

• timespan with `referred_to_by` explanatory statement.

1. Partial timespan fixture

• embedded timespan with dereferenceable `id` and `_complete: false`.

1. Invalid-empty fixture

• timespan missing `identified_by` + missing both key bounds, expected to fail validation.

---

Round 57 Addendum — Shared Structure: Relationships (AttributeAssignment)

Source section basis:

• Linked Art API 1.0: Relationships
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Arbitrary/non-semantic or context-specific relationships are modeled via `AttributeAssignment`.
• Required fields:
• `type` must be `AttributeAssignment`
• `assigned` must be present as references to related entities
• Optional/recommended:
• `identified_by`, `classified_as` (recommended)
• `id`, `_label`, `_complete`, `referred_to_by`, `carried_out_by`, `timespan`, temporal ordering/context fields
• `influenced_by`, `caused_by`, `used_specific_object`, `technique`
• `assigned_property` optional URI/curie-like string for explicit relationship predicate
• Modeling note:
• `assigned` relationship assignment pattern should not be used for Dimension/Identifier assignment use cases (those use dedicated patterns such as `assigned_by` for those structures).
• Incoming usage:
• `attributed_by` across all endpoints
• `assigned_by` specifically for Dimension/Identifier assignment activities

Implementation Mapping — Shared Relationships

Apply these requirements to adapters, normalization, and route outputs:

1. Type/assigned strictness

• Enforce `type=AttributeAssignment` and required non-empty `assigned` reference array.

1. Predicate capture

• Preserve `assigned_property` when provided to retain explicit predicate semantics.

1. Context/provenance fidelity

• Preserve actor/time/cause/influence/object context fields to support explainable relationship provenance.

1. Relationship-vs-assignment boundary

• Route Dimension/Identifier assignment scenarios to dedicated assignment pathways rather than generic `assigned` relation modeling.

1. Partial embed signaling

• Enforce `_complete: false` for partial embedded assignments with dereferenceable IDs.

1. Cross-endpoint consistency

• Keep `attributed_by` handling consistent across all endpoint families.

TDD Additions — Shared Relationships

Add failing-first tests for relationship-assignment conformance:

Contract-level:

• validates required `type=AttributeAssignment` and required `assigned` references
• validates optional `assigned_property` format and context/provenance fields
• rejects malformed/missing assigned target references
• enforces guardrail that Dimension/Identifier assignments are not represented via generic `assigned` misuse
• validates `_complete: false` requirement for partial embedded assignments with resolvable IDs

Route-level:

• endpoint payloads embedding `attributed_by` conform to shared relationship-assignment schema
• malformed assignment nodes fail boundary validation with explicit path-level diagnostics

Integration-level:

• `attributed_by` traversals resolve assigned entities consistently across endpoints
• Dimension/Identifier `assigned_by` flows remain distinct and interoperable with their dedicated shared structures

Regression:

• provider adapter updates do not flatten relationship assignments into untyped “related items” arrays
• explicit `assigned_property` predicates remain stable when present

Fixture Anchors — Shared Relationships Examples

Use these shared-relationship patterns as fixture seeds:

1. Minimal valid assignment

• `type=AttributeAssignment` with one `assigned` reference.

1. Predicate assignment fixture

• assignment with explicit `assigned_property` URI string.

1. Curated recommendation fixture

• assignment classified as recommendation with carried_out_by curator.

1. Temporal/provenance fixture

• assignment including timespan, influenced_by, caused_by, used_specific_object.

1. Partial assignment fixture

• embedded assignment with dereferenceable `id` and `_complete: false`.

1. Guardrail negative fixture

• invalid use of generic `assigned` for identifier/dimension assignment should fail or be remapped.

---

Round 58 Addendum — About Schemas

Source section basis:

• Linked Art API 1.0: About Schemas
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Linked Art publishes JSON Schema definitions (plus generated HTML docs) for the core endpoint families:
• Abstract Work
• Concept
• Digital Object
• Event/Activity
• Group
• Person
• Physical Object
• Place
• Provenance Activity
• Set
• Textual Work
• Visual Work
• These schemas are the normative machine-checkable contract layer for endpoint payload conformance.

Implementation Mapping — Schemas

Apply these requirements to adapters, normalization, and route outputs:

1. Schema-canonical contract policy

• Treat the endpoint schema set as canonical contract references for all route payload validation.

1. Endpoint-to-schema matrix

• Maintain explicit mapping from each project API route/serializer to the corresponding Linked Art schema family.

1. Shared-structure composition

• Ensure endpoint schemas compose shared structures consistently (names, identifiers, timespans, references, rights, etc.).

1. Drift detection

• Add safeguards for schema drift between route handlers, contracts, and fixture expectations.

1. Human + machine docs parity

• Keep generated/internal docs aligned with machine validation behavior for dev clarity.

TDD Additions — Schemas

Add failing-first tests for schema-governed conformance:

Contract-level:

• validates each endpoint payload against its corresponding Linked Art schema family
• validates shared-structure reuse across endpoint schemas

Route-level:

• each public endpoint has schema conformance tests for success and failure cases
• boundary validation errors include actionable field paths

Integration-level:

• cross-endpoint traversals preserve schema-valid reference shapes
• provenance and shared-structure heavy payloads validate under composed schema rules

Regression:

• snapshot tests detect breaking schema-shape changes
• provider adapter updates cannot bypass schema validation gates

Fixture Anchors — Schemas Examples

Use these schema-level anchors as fixture seeds:

1. Per-endpoint golden fixtures

• one canonical valid fixture per endpoint family listed above.

1. Negative schema fixtures

• one invalid payload per endpoint proving boundary rejection behavior.

1. Shared-structure composition fixtures

• payloads stress-testing nested shared structures inside endpoint records.

1. Cross-reference fixtures

• payloads with dense references validating link-shape and type consistency.

---

Round 59 Addendum — Abstract Work Schema

Source section basis:

• Linked Art API 1.0: Abstract Work Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E89_Propositional_Object`
• purely conceptual work representation
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `dimension`
• `subject_to`
• `about`
• `conceptually_part_of`
• `created_by`

Implementation Mapping — Abstract Work Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for abstract work payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only the listed abstract-work fields; reject unknown keys at boundary validation.

1. Class semantics

• Keep abstract work payloads concept-first (propositional object semantics), not physical-object semantics.

TDD Additions — Abstract Work Schema

Add failing-first tests for abstract-work schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional allowed properties by shared-structure schemas

Route-level:

• abstract-work route responses always satisfy schema-required fields
• malformed payloads with unknown keys fail with clear field-path diagnostics

Regression:

• changes to abstract-work serializers cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Abstract Work Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid abstract work

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid abstract work

• uses subset of allowed optional fields (for example `about`, `created_by`, `subject_to`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 60 Addendum — Concept Schema

Source section basis:

• Linked Art API 1.0: Concept Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E55_Type`
• concepts/subjects/categorizations
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `classified_as`
• `identified_by`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `created_by`
• `broader`

Implementation Mapping — Concept Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for concept payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only the listed concept-schema fields; reject unknown keys at boundary validation.

1. Hierarchy semantics

• Preserve `broader` concept links for hierarchical taxonomy navigation.

TDD Additions — Concept Schema

Add failing-first tests for concept schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional allowed properties (especially `broader`) through shared-structure contracts

Route-level:

• concept route responses always satisfy schema-required fields
• malformed concept payloads with unknown keys fail with clear field-path diagnostics

Regression:

• concept serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Concept Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid concept

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid concept

• uses subset of allowed optional fields (for example `broader`, `equivalent`, `created_by`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 61 Addendum — Digital Object Schema

Source section basis:

• Linked Art API 1.0: Digital Object Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `dig:D1_Digital_Object`
• digital resources such as web pages/images
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `dimension`
• `part_of`
• `format`
• `conforms_to`
• `access_point`
• `digitally_available_via`
• `digitally_carries`
• `digitally_shows`
• `used_for`
• `created_by`

Implementation Mapping — Digital Object Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for digital object payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed digital-object fields; reject unknown keys at boundary validation.

1. Carrier/service/access semantics

• Preserve strict separation of `access_point`, `digitally_available_via`, `digitally_carries`, and `digitally_shows`.

1. Technical metadata fidelity

• Preserve `format` and `conforms_to` semantics for media/protocol interoperability.

TDD Additions — Digital Object Schema

Add failing-first tests for digital object schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional allowed fields using shared-structure contracts

Route-level:

• digital object route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid digital-link fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Digital Object Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid digital object

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid digital object

• uses subset of allowed optional fields (for example `access_point`, `format`, `digitally_available_via`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 62 Addendum — Event Schema

Source section basis:

• Linked Art API 1.0: Event Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target classes:
• `crm:E4_Period`
• `crm:E6_Event`
• `crm:E7_Activity`
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `took_place_at`
• `timespan`
• `during`
• `after`
• `before`
• `caused_by`
• `carried_out_by`
• `participant`
• `used_specific_object`
• `influenced_by`
• `technique`
• `part_of`

Implementation Mapping — Event Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for event payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed event-schema fields; reject unknown keys at boundary validation.

1. Temporal/spatial semantics

• Preserve `timespan`, ordering (`before`/`after`/`during`), and `took_place_at` as first-class structured fields.

1. Event/activity role semantics

• Preserve `carried_out_by`, `participant`, `used_specific_object`, and `influenced_by` role/context fields.

TDD Additions — Event Schema

Add failing-first tests for event schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional temporal/spatial/role fields using shared-structure contracts

Route-level:

• event route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid temporal/role fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Event Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid event record

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid event record

• uses subset of allowed optional fields (for example `timespan`, `took_place_at`, `carried_out_by`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 63 Addendum — Group Schema

Source section basis:

• Linked Art API 1.0: Group Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E74_Group`
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `carried_out`
• `participated_in`
• `contact_point`
• `residence`
• `formed_by`
• `dissolved_by`

Implementation Mapping — Group Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for group payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed group-schema fields; reject unknown keys at boundary validation.

1. Lifecycle/activity semantics

• Preserve `formed_by`, `dissolved_by`, `carried_out`, and `participated_in` as structured activity fields.

1. Contact/residence semantics

• Preserve `contact_point` and `residence` as distinct structured fields with shared contracts.

TDD Additions — Group Schema

Add failing-first tests for group schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional activity/contact/residence fields using shared-structure contracts

Route-level:

• group route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid lifecycle/activity fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Group Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid group record

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid group record

• uses subset of allowed optional fields (for example `formed_by`, `residence`, `carried_out`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 64 Addendum — Person Schema

Source section basis:

• Linked Art API 1.0: Person Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E21_Person`
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `carried_out`
• `participated_in`
• `contact_point`
• `residence`
• `born`
• `died`

Implementation Mapping — Person Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for person payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed person-schema fields; reject unknown keys at boundary validation.

1. Lifecycle/activity semantics

• Preserve `born`, `died`, `carried_out`, and `participated_in` as structured activity fields.

1. Contact/residence semantics

• Preserve `contact_point` and `residence` as distinct structured fields with shared contracts.

TDD Additions — Person Schema

Add failing-first tests for person schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional lifecycle/activity/contact/residence fields using shared-structure contracts

Route-level:

• person route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid lifecycle/activity fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Person Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid person record

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid person record

• uses subset of allowed optional fields (for example `born`, `died`, `residence`, `carried_out`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 65 Addendum — Human-Made Object Schema

Source section basis:

• Linked Art API 1.0: Human-Made Object Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E22_Human-Made_Object`
• includes human-made objects, parts, and culturally-valued natural objects
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `dimension`
• `made_of`
• `part_of`
• `current_owner`
• `current_custodian`
• `current_permanent_custodian`
• `current_location`
• `current_permanent_location`
• `held_or_supported_by`
• `used_for`
• `shows`
• `carries`
• `produced_by`
• `destroyed_by`
• `removed_by`
• `encountered_by`
• `modified_by`
• `changed_ownership_through`

Implementation Mapping — Human-Made Object Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for human-made object payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed object-schema fields; reject unknown keys at boundary validation.

1. Ownership/custody/location semantics

• Preserve distinct fields for current vs permanent ownership/custody/location.

1. Lifecycle/provenance semantics

• Preserve structured lifecycle/provenance fields (`produced_by`, `destroyed_by`, `removed_by`, `encountered_by`, `modified_by`, `changed_ownership_through`).

1. Aboutness/carrier semantics

• Preserve `shows` and `carries` link semantics separately from digital/visual/textual standalone records.

TDD Additions — Human-Made Object Schema

Add failing-first tests for human-made object schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional lifecycle, provenance, ownership, custody, location, material, and dimension fields via shared contracts

Route-level:

• object route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid lifecycle/ownership structures fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Human-Made Object Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid object record

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid object record

• uses subset of allowed optional fields (for example `made_of`, `dimension`, `current_owner`, `produced_by`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 66 Addendum — Place Schema

Source section basis:

• Linked Art API 1.0: Place Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E53_Place`
• geographic locations where activities occur
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `classified_as`
• `identified_by`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `defined_by`
• `part_of`

Implementation Mapping — Place Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for place payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed place-schema fields; reject unknown keys at boundary validation.

1. Geometry/hierarchy semantics

• Preserve `defined_by` geometry payload and `part_of` place hierarchy as first-class structured fields.

1. Identity/reference fidelity

• Preserve `equivalent` and classification fields for cross-authority place reconciliation.

TDD Additions — Place Schema

Add failing-first tests for place schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional geometry/hierarchy/reference fields via shared contracts

Route-level:

• place route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid `defined_by`/`part_of` fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Place Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid place record

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid place record

• uses subset of allowed optional fields (for example `defined_by`, `part_of`, `equivalent`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 67 Addendum — Provenance Activity Schema

Source section basis:

• Linked Art API 1.0: Provenance Activity Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E7_Activity`
• broad activities for ownership/custody/location/rights changes
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• `classified_as`
• Additional allowed properties:
• `identified_by`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `during`
• `after`
• `before`
• `took_place_at`
• `timespan`
• `caused_by`
• `carried_out_by`
• `used_specific_object`
• `influenced_by`
• `technique`
• `part_of`
• `part`

Implementation Mapping — Provenance Activity Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for provenance activity payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, `_label`, and `classified_as` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed provenance-schema fields; reject unknown keys at boundary validation.

1. Classification gate

• Preserve and validate `classified_as` entries required to establish provenance semantics.

1. Structured part semantics

• Preserve `part` as first-class structured sub-activity container, not flattened notes.

TDD Additions — Provenance Activity Schema

Add failing-first tests for provenance activity schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`/`classified_as`
• validates rejection of additional unknown properties
• validates optional temporal/spatial/role fields and `part` structure via shared contracts

Route-level:

• provenance route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid `classified_as`/`part` fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `classified_as` and `_label` remain enforced in schema conformance suite

Fixture Anchors — Provenance Activity Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid provenance activity

• contains required `@context`, `id`, `type`, `_label`, `classified_as`.

1. Extended valid provenance activity

• uses subset of allowed optional fields (for example `timespan`, `took_place_at`, `part`, `used_specific_object`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

1. Missing-classification negative fixture

• omits required `classified_as` and must fail validation.

---

Round 68 Addendum — Collection (Set) Schema

Source section basis:

• Linked Art API 1.0: Collection Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `la:Set`
• collection/set of resources
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `dimension`
• `about`
• `members_contained_by`
• `members_exemplified_by`
• `used_for`
• `created_by`

Implementation Mapping — Collection (Set) Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for collection/set payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed collection-schema fields; reject unknown keys at boundary validation.

1. Set semantics preservation

• Preserve `members_contained_by` and `members_exemplified_by` distinctions as separate semantics.

1. Curatorial/context semantics

• Preserve `about`, `used_for`, and `created_by` as structured contextual fields.

TDD Additions — Collection (Set) Schema

Add failing-first tests for collection/set schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional set-specific fields via shared contracts

Route-level:

• set route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid set-specific fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Collection (Set) Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid collection/set record

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid collection/set record

• uses subset of allowed optional fields (for example `about`, `members_exemplified_by`, `created_by`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 69 Addendum — Text Schema

Source section basis:

• Linked Art API 1.0: Text Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E33_Linguistic_Object`
• textual content expressed in one or more human languages
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `representation`
• `member_of`
• `subject_of`
• `attributed_by`
• `dimension`
• `subject_to`
• `format`
• `language`
• `about`
• `created_by`
• `used_for`
• `part_of`
• `content`

Implementation Mapping — Text Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for text payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed text-schema fields; reject unknown keys at boundary validation.

1. Linguistic semantics fidelity

• Preserve `language`, `content`, `format`, and `about` as first-class textual semantics.

1. Rights/provenance/publication semantics

• Preserve `subject_to`, `created_by`, and `used_for` as structured contextual fields.

TDD Additions — Text Schema

Add failing-first tests for text schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional linguistic/rights/provenance fields via shared contracts

Route-level:

• text route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid language/content/rights fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Text Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid text record

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid text record

• uses subset of allowed optional fields (for example `language`, `content`, `subject_to`, `used_for`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 70 Addendum — Visual Content Schema

Source section basis:

• Linked Art API 1.0: Visual Content Schema
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Schema target class:
• `crm:E36_Visual_Item`
• visual content of a work
• Schema form:
• `type: object`
• no additional properties allowed
• Required properties in this schema listing:
• `@context`
• `id`
• `type`
• `_label`
• Additional allowed properties:
• `identified_by`
• `classified_as`
• `referred_to_by`
• `equivalent`
• `member_of`
• `subject_of`
• `attributed_by`
• `dimension`
• `subject_to`
• `part_of`
• `conceptually_part_of`
• `about`
• `created_by`
• `represents`
• `represents_instance_of_type`
• `used_for`

Implementation Mapping — Visual Content Schema

Apply these requirements to adapters, normalization, and route outputs:

1. Strict additional-property rule

• Enforce `additionalProperties: false` behavior for visual content payloads.

1. Required-field alignment

• Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.

1. Property allowlist enforcement

• Permit only listed visual-content schema fields; reject unknown keys at boundary validation.

1. Depiction semantics fidelity

• Preserve `represents` and `represents_instance_of_type` as distinct semantics in serializers and validators.

1. Structural/context semantics

• Preserve `part_of`, `conceptually_part_of`, `about`, and `used_for` as structured contextual fields.

TDD Additions — Visual Content Schema

Add failing-first tests for visual content schema conformance:

Contract-level:

• validates required `@context`/`id`/`type`/`_label`
• validates rejection of additional unknown properties
• validates optional depiction/context/rights fields via shared contracts

Route-level:

• visual content route responses always satisfy schema-required fields
• malformed payloads with unknown keys or invalid depiction fields fail with clear field-path diagnostics

Regression:

• serializer changes cannot silently introduce non-schema fields
• required `_label` remains enforced in schema conformance suite

Fixture Anchors — Visual Content Schema Examples

Use these schema-level patterns as fixture seeds:

1. Minimal valid visual content record

• contains only required `@context`, `id`, `type`, `_label`.

1. Extended valid visual content record

• uses subset of allowed optional fields (for example `represents`, `represents_instance_of_type`, `subject_to`, `created_by`).

1. Additional-property negative fixture

• includes unknown key and must fail validation.

---

Round 71 Addendum — Search API

Source section basis:

• Linked Art API 1.0: Search API
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Search API solves inverse-relationship discovery without requiring clients to author query grammar.
• Discovery mechanism:
• HAL `_links` on entity records expose named links to referring-record result lists.
• relation naming convention is camelCase by current type + relationship + target type (via `curies` expansion).
• links should be omitted when no matching results exist.
• Search response model:
• based on ActivityStreams `OrderedCollection` / `OrderedCollectionPage`.
• HAL links should target first page URI, not necessarily collection root URI.
• Page requirements (`OrderedCollectionPage`):
• `@context` must be `https://linked.art/ns/v1/search.json`
• required: `id`, `type="OrderedCollectionPage"`, `partOf`, `orderedItems`
• `next` required unless last page
• `prev` required unless first page
• `startIndex` should be present (0-based index)
• each `orderedItems` entry has exactly `{ id, type }`
• Collection requirements (`OrderedCollection`):
• required: `id`, `type="OrderedCollection"`, `first`, `last`
• `totalItems` should be present
• `label` and `summary` may be language-map objects
• when embedded in page `partOf`, collection must not repeat `@context`
• if requested separately, collection must include `@context` search context value

Implementation Mapping — Search API

Apply these requirements to adapters, normalization, and route outputs:

1. HAL inverse-link publication

• Emit `_links` search relations for supported inverse traversals and omit relations with zero results.

1. Relation-name stability

• Keep relation naming deterministic and curies-expandable for client interoperability.

1. Page-first retrieval contract

• Ensure relation `href` targets first `OrderedCollectionPage` response with required search context.

1. Ordered page structure enforcement

• Preserve strict page contract (`partOf`, `next`/`prev` conditional presence, `orderedItems` id/type shape).

1. Embedded collection behavior

• Embed collection metadata in `partOf` without duplicate `@context`; include `@context` only for standalone collection responses.

1. Backend-agnostic search execution

• Keep public response shape stable regardless of underlying query engine/indexing strategy.

TDD Additions — Search API

Add failing-first tests for search API conformance:

Contract-level:

• validates `OrderedCollectionPage` required fields and search context
• validates `OrderedCollection` required fields and standalone-vs-embedded context rules
• validates `orderedItems` entry shape as exactly id/type references

Route-level:

• HAL `_links` include only available inverse relationships
• first-page links dereference to valid `OrderedCollectionPage`
• pagination rules enforce `next`/`prev` conditional presence correctly

Integration-level:

• cross-endpoint inverse discovery works via HAL links without query-language coupling
• `startIndex`, `totalItems`, and page traversal semantics remain consistent across providers/backends

Regression:

• serializer changes do not break search context URI, relation naming, or ordered item shape
• empty-result relationships continue omitting link entries

Fixture Anchors — Search API Examples

Use these search-API patterns as fixture seeds:

1. Minimal valid first page

• valid `OrderedCollectionPage` with `partOf`, `next`, and `orderedItems`.

1. Middle page fixture

• page with both `prev` and `next` plus correct `startIndex`.

1. Last page fixture

• page omitting `next` and retaining `prev`.

1. Embedded collection fixture

• `partOf` collection with `first`, `last`, `totalItems`, optional label/summary, and no embedded `@context`.

1. Standalone collection fixture

• separate collection response including required search `@context`.

1. HAL link omission fixture

• source record where absent inverse relations are not emitted in `_links`.

---

Round 72 Addendum — About HAL

Source section basis:

• Linked Art API 1.0: About HAL
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Linked Art embeds non-semantic API metadata in JSON responses using HAL via `_links`.
• HAL block is not RDF-semantic and is not preserved through RDF graph round-tripping.
• Core HAL elements:
• `self` link
• `curies` namespace templates for relation semantics (for example `la`)
• namespaced relation links (Linked Art + local extensions)
• Versioning links:
• required: `la:modelVersion`, `la:apiVersion`
• optional: `la:localVersion`
• each version link requires `href` to human docs and `name` in `v{major}.{minor}.{patch}` format
• Version interpretation guidance:
• major/minor are numeric for compatibility logic
• patch is string-sorted and non-functional (awareness/documentation)
• Other representation links:
• `alternate` links for HTML/Turtle/etc. must include correct `type` media type
• `collection` can point to IIIF Change Discovery endpoint
• Search integration:
• HAL links are primary discovery mechanism for related searches (documented in Search API)

Implementation Mapping — HAL

Apply these requirements to adapters, normalization, and route outputs:

1. HAL envelope consistency

• Emit `_links` consistently on entity responses with valid `self` and curated relation links.

1. CURIE namespace discipline

• Emit `curies` entries with templated link semantics for relation documentation expansion.

1. Version-link enforcement

• Require `la:modelVersion` and `la:apiVersion`; support optional `la:localVersion` for local extension tracking.

1. Version-name parser safety

• Enforce `name` format compatibility and preserve numeric compare behavior for major/minor components.

1. Alternate representation correctness

• Ensure `alternate` links include accurate MIME `type` values.

1. Discovery link integration

• Support `collection` and search relation links without coupling to backend-specific query syntax.

1. Semantic boundary preservation

• Keep HAL metadata separate from semantic JSON-LD graph processing.

TDD Additions — HAL

Add failing-first tests for HAL conformance:

Contract-level:

• validates `_links` presence and required `self` structure
• validates `curies` templated namespace entries
• validates required version links and `name` format constraints
• validates `alternate` links include correct `type` media types

Route-level:

• entity responses include consistent HAL links across endpoint families
• malformed/missing required version links fail contract checks

Integration-level:

• relation links expand via CURIE templates to documentation URIs
• search/discovery links are followable and return schema-valid responses

Regression:

• serializer changes do not drop required HAL version links
• HAL blocks remain non-semantic and do not pollute JSON-LD graph assertions

Fixture Anchors — HAL Examples

Use these HAL patterns as fixture seeds:

1. Minimal HAL fixture

• `_links.self` + `curies` template entry.

1. Versioned HAL fixture

• includes required `la:modelVersion` and `la:apiVersion` plus optional `la:localVersion`.

1. Alternate-format fixture

• `alternate` links for HTML and Turtle with valid media types.

1. Discovery fixture

• `collection` link to change-discovery endpoint.

1. Search-link fixture

• relation links pointing to search result pages.

1. Invalid-version-name fixture

• malformed `name` format must fail validation checks.

---

Round 73 Addendum — Search Relations: HumanMadeObject

Source section basis:

• Linked Art API relation docs (HumanMadeObject-focused search links)
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Documented search relations for `HumanMadeObject` include:
• `activityUsedObject`
• `conceptInfluencedByObject`
• `objectPartOfObject`
• `objectProductionInfluencedByObject`
• `workAboutObject`
• `workAboutOrRepresentsObject`
• `workRepresentsObject`
• Each relation defines:
• source class (`HumanMadeObject`)
• returned class family (`Activity`, `Concept`, `HumanMadeObject`, `Work`)
• semantic relationship basis (`used`, `influencedBy`, `partOf`, `productionInfluencedBy`, `about`, `represents`)
• These relations are exposed as discoverable HAL/search links and should map to OrderedCollectionPage responses.

Implementation Mapping — HumanMadeObject Search Relations

Apply these requirements to adapters, normalization, and route outputs:

1. Relation-name publication

• Publish stable HAL relation links for the listed HumanMadeObject inverse/discovery relations.

1. Result-class fidelity

• Ensure each relation returns the expected entity class family (or documented union) consistently.

1. Relationship-semantic fidelity

• Ensure each relation query is grounded in the documented relationship basis:
• `used` -> activities using object
• `influencedBy` -> concepts influenced by object
• `partOf` -> object parts
• `productionInfluencedBy` -> produced objects influenced by source object
• `about` / `represents` combinations for work relations

1. Page-format compliance

• Relation targets must return valid Search API `OrderedCollectionPage` shape.

1. Empty-result behavior

• Omit relation links when no results exist for a source record (per Search API guidance).

TDD Additions — HumanMadeObject Search Relations

Add failing-first tests for relation conformance:

Contract-level:

• validates each listed relation is either:
• present with valid link shape and followable search-page response, or
• omitted when result set is empty

Route-level:

• validates returned `orderedItems[].type` matches documented class family per relation
• validates each relation endpoint page conforms to search context/page schema

Integration-level:

• object fixture graph tests verify each relation returns expected linked records:
• activities using object
• concepts influenced by object
• child/part objects
• influenced productions/copies
• about/represents work sets

Regression:

• relation name stability tests prevent accidental renaming or semantic drift
• relation-specific queries remain consistent across provider adapters/storage backends

Fixture Anchors — HumanMadeObject Search Relations Examples

Use these relation patterns as fixture seeds:

1. `activityUsedObject` fixture

• object linked to one or more activity records via usage semantics.

1. `conceptInfluencedByObject` fixture

• object linked to concept records via influence semantics.

1. `objectPartOfObject` fixture

• parent object with part/frame/subcomponent object records.

1. `objectProductionInfluencedByObject` fixture

• source object linked to production of derivative/copy object.

1. `workAboutObject` fixture

• textual/visual/abstract works about object.

1. `workAboutOrRepresentsObject` fixture

• combined about-or-represents result set.

1. `workRepresentsObject` fixture

• visual works depicting object.

---

Round 74 Addendum — Search Relations: Work

Source section basis:

• Linked Art API relation docs (Work-focused search links)
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Documented search relations for Work/LinguisticObject/VisualItem contexts include:
• `activityUsedWork`
• `conceptInfluencedByWork`
• `objectCarriesWork`
• `objectProductionInfluencedByWork`
• `objectShowsWork`
• `workAboutOrRepresentsWork`
• `workAboutWork`
• `workPartOfWork`
• `workRepresentsWork`
• Relation details include:
• source class (`Work`, `LinguisticObject`, or `VisualItem` depending on relation)
• returned class family (`Activity`, `Concept`, `HumanMadeObject`, `Work`)
• semantic basis (`used`, `influencedBy`, `carries`, `productionInfluencedBy`, `shows`, `about`, `represents`, `partOf`)
• These relations should be exposed through HAL/search links and return Search API page structures.

Implementation Mapping — Work Search Relations

Apply these requirements to adapters, normalization, and route outputs:

1. Relation-name publication

• Publish stable HAL relation links for the listed Work-family inverse/discovery relations.

1. Source-class correctness

• Enforce correct source-class gating per relation (for example `objectCarriesWork` from `LinguisticObject`, `objectShowsWork` from `VisualItem`).

1. Result-class fidelity

• Ensure each relation returns the documented class family consistently.

1. Relationship-semantic fidelity

• Map each relation to its documented semantic edge:
• `used`
• `influencedBy`
• `carries`
• `productionInfluencedBy`
• `shows`
• `about`
• `represents`
• `partOf`

1. Search-page compliance

• Relation targets must return valid `OrderedCollectionPage` responses with correct search context.

1. Empty-result link omission

• Omit relation links where no referring records exist.

TDD Additions — Work Search Relations

Add failing-first tests for relation conformance:

Contract-level:

• validates listed relations are either present with valid HAL link shape or omitted when empty
• validates link targets return schema-valid search pages

Route-level:

• validates relation result item `type` matches documented class family
• validates source-class-specific relations are not emitted on incompatible source classes

Integration-level:

• work graph fixtures verify inverse discovery for:
• activities using work
• concepts influenced by work
• objects carrying linguistic work
• objects showing visual work
• objects produced under work influence
• work-about/work-represents/work-part relations

Regression:

• relation names remain stable across backend/provider changes
• about-vs-represents-vs-partOf semantics do not collapse into one generic “related works” bucket

Fixture Anchors — Work Search Relations Examples

Use these relation patterns as fixture seeds:

1. `activityUsedWork` fixture

• work linked to activity records via usage semantics.

1. `conceptInfluencedByWork` fixture

• work linked to concept records via influence semantics.

1. `objectCarriesWork` fixture

• linguistic work linked to physical carrier objects.

1. `objectShowsWork` fixture

• visual work linked to physical objects that show it.

1. `objectProductionInfluencedByWork` fixture

• work linked to objects whose production it influenced.

1. `workAboutWork` fixture

• work linked to works about it.

1. `workAboutOrRepresentsWork` fixture

• mixed about-or-represents work result set.

1. `workPartOfWork` fixture

• parent work linked to component/sub-work records.

1. `workRepresentsWork` fixture

• work linked to works that depict/represent it.

---

Round 75 Addendum — Search Relations: Agent

Source section basis:

• Linked Art API relation docs (Agent-focused search links with SPARQL patterns)
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Documented agent-centric search relations include:
• `activityCarriedOutByAgent`
• `activityParticipantAgent`
• `agentMemberOfGroup`
• `conceptInfluencedByAgent`
• `groupFoundedByAgent`
• `objectCuratedByAgent`
• `objectEncounteredByAgent`
• `objectOwnedByAgent`
• `objectProducedByAgent`
• `objectProductionInfluencedByAgent`
• `setCreatedByAgent`
• `workAboutAgent`
• `workAboutOrRepresentsAgent`
• `workCreatedByAgent`
• `workPublishedByAgent`
• `workRepresentsAgent`
• Each relation specifies:
• source class (`Agent` or `Group` where noted)
• return class family (`Activity`, `Event/Activity`, `Agent`, `Concept`, `Group`, `HumanMadeObject`, `Set`, `Work`)
• semantic edge (`carriedOutBy`, `participant`, `memberOf`, `influencedBy`, `foundedBy`, etc.)
• Provided SPARQL snippets establish expected inverse-traversal semantics and can be used as behavioral oracle for query correctness.

Implementation Mapping — Agent Search Relations

Apply these requirements to adapters, normalization, and route outputs:

1. Relation-name publication

• Publish stable HAL relation links for the documented agent-centric relations.

1. Source-class gating

• Enforce relation availability by source class (for example `agentMemberOfGroup` source is `Group`).

1. Result-class fidelity

• Ensure returned item types match the documented class family per relation.

1. Semantic-query fidelity

• Align relation execution to documented inverse semantics (including production/event path traversals and union branches where specified).

1. Complex-branch relation fidelity

• Preserve union/path logic for relations like `objectCuratedByAgent` and multi-edge creation/production queries.

1. Search-page compliance

• Relation targets must return valid Search API `OrderedCollectionPage` structures.

1. Empty-result omission

• Omit relation link entries when no matching records exist.

TDD Additions — Agent Search Relations

Add failing-first tests for agent-relation conformance:

Contract-level:

• validates each listed relation is either present with valid HAL link shape or omitted when empty
• validates followable relation targets return schema-valid search pages

Route-level:

• validates `orderedItems[].type` against documented return class family per relation
• validates source-class-incompatible relations are not emitted

Integration-level:

• graph fixtures verify inverse discovery for:
• activities carried out by/participated in by agents
• group membership and group formation links
• owned/curated/encountered/produced/influenced objects
• sets created by agents
• works about/representing/created/published by agents

Regression:

• relation naming and semantics remain stable across storage backends/providers
• SPARQL-equivalence checks detect semantic drift in traversal logic

Fixture Anchors — Agent Search Relations Examples

Use these relation patterns as fixture seeds:

1. `activityCarriedOutByAgent` fixture

• agent linked to carried-out activity records.

1. `activityParticipantAgent` fixture

• agent linked to participation-only event/activity records.

1. `agentMemberOfGroup` fixture

• group with person/group members returned via inverse membership.

1. `objectProducedByAgent` fixture

• agent linked to produced objects through production-participant paths.

1. `objectCuratedByAgent` fixture

• curator/department linked to objects through custody or curating-activity pathways.

1. `objectOwnedByAgent` fixture

• agent linked to currently owned objects.

1. `workCreatedByAgent` and `workPublishedByAgent` fixtures

• agent linked to created/published works via creation/publication activities.

1. `workAboutOrRepresentsAgent` fixture

• mixed work result set combining about and represents relations.

1. `setCreatedByAgent` fixture

• agent linked to created sets/collections.

1. `conceptInfluencedByAgent` fixture

• agent linked to concept creation influence chains.

---

Round 76 Addendum — Search Relations: Place

Source section basis:

• Linked Art API relation docs (Place-focused search links with SPARQL patterns)
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Documented place-centric search relations include:
• `activityTookPlaceAtPlace`
• `agentActiveAtPlace`
• `agentBornOrFormedAtPlace`
• `agentDiedOrDissolvedAtPlace`
• `agentResidentAtPlace`
• `conceptInfluencedByPlace`
• `groupActiveAtPlace`
• `groupDissolvedAtPlace`
• `groupFormedAtPlace`
• `objectCurrentPlace`
• `objectEncounteredAtPlace`
• `objectProducedAtPlace`
• `objectProductionInfluencedByPlace`
• `personActiveAtPlace`
• `personBornAtPlace`
• `personDiedAtPlace`
• `placePartOfPlace`
• `setCreatedAtPlace`
• `workAboutOrRepresentsPlace`
• `workAboutPlace`
• `workCreatedAtPlace`
• `workPublishedAtPlace`
• `workRepresentsPlace`
• Relation details define:
• source class (`Place`)
• return class family (`Event/Activity`, `Agent`, `Group`, `Person`, `HumanMadeObject`, `Place`, `Set`, `Work`, `Concept`)
• semantic edge basis (`tookPlaceAt`, `bornAt`, `diedAt`, `formedAt`, `dissolvedAt`, `about`, `represents`, `createdAt`, etc.)
• Provided SPARQL snippets establish expected inverse traversal behavior and should guide semantic correctness tests.

Implementation Mapping — Place Search Relations

Apply these requirements to adapters, normalization, and route outputs:

1. Relation-name publication

• Publish stable HAL relation links for the documented place-centric relation set.

1. Result-class fidelity

• Ensure each relation returns the documented class family (including union-style families where specified).

1. Temporal/lifecycle edge fidelity

• Preserve birth/death/formation/dissolution/activity location semantics distinctly across relation handlers.

1. Production/publication/location path fidelity

• Preserve multi-hop path semantics for produced/created/published relations as indicated by model/SPARQL patterns.

1. About-vs-represents separation

• Preserve distinction between `about`, `represents`, and combined `aboutOrRepresents` relation results.

1. Search-page compliance

• Relation targets must return valid Search API `OrderedCollectionPage` responses.

1. Empty-result omission

• Omit HAL relation links when no matching records exist.

TDD Additions — Place Search Relations

Add failing-first tests for place-relation conformance:

Contract-level:

• validates each listed place relation is either present with valid HAL link shape or omitted when empty
• validates followable relation targets return schema-valid search pages

Route-level:

• validates `orderedItems[].type` matches documented return class family per relation
• validates combined relations (`workAboutOrRepresentsPlace`, agent born/formed, died/dissolved) preserve union semantics

Integration-level:

• graph fixtures verify inverse discovery for:
• activities/events at place
• agents active/resident/born/formed/died/dissolved at place
• groups formed/dissolved/active at place
• objects currently at, encountered at, produced at, production-influenced by place
• sets created at place
• places part-of place
• works about/representing/created/published at place
• concepts influenced by place

Regression:

• relation naming and source/return class mappings remain stable across adapters/backends
• SPARQL-equivalence assertions detect path-semantics drift in query implementations

Fixture Anchors — Place Search Relations Examples

Use these relation patterns as fixture seeds:

1. `activityTookPlaceAtPlace` fixture

• place linked to event/activity records via `took_place_at`.

1. Lifecycle-at-place fixtures

• `personBornAtPlace`, `personDiedAtPlace`, `groupFormedAtPlace`, `groupDissolvedAtPlace`.

1. Agent-at-place fixtures

• `agentActiveAtPlace`, `agentResidentAtPlace`, plus combined born/formed and died/dissolved relations.

1. Object-at-place fixtures

• current location, encountered-at, produced-at, and production-influenced-by place relations.

1. Place hierarchy fixture

• `placePartOfPlace` inverse discovery.

1. Set-at-place fixture

• `setCreatedAtPlace` via creation activities.

1. Work-at-place fixtures

• `workAboutPlace`, `workRepresentsPlace`, combined `workAboutOrRepresentsPlace`, `workCreatedAtPlace`, `workPublishedAtPlace`.

1. Concept-influence fixture

• `conceptInfluencedByPlace` relation from place to concept records.

---

Round 77 Addendum — Search Relations: Concept

Source section basis:

• Linked Art API relation docs (Concept-focused search links, including Language/Material specializations)
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Documented concept-centric search relations include:
• `activityClassifiedAsConcept`
• `agentClassifiedAsConcept`
• `conceptBroaderConcept`
• `conceptClassifiedAsConcept`
• `conceptInfluencedByConcept`
• `objectClassifiedAsConcept`
• `objectMadeOfMaterial`
• `objectProductionTechniqueConcept`
• `placeClassifiedAsConcept`
• `setClassifiedAsConcept`
• `workAboutConcept`
• `workAboutOrRepresentsConcept`
• `workClassifiedAsConcept`
• `workCreationTechniqueConcept`
• `workLanguageLanguage`
• `workRepresentsConcept`
• Relation definitions specify:
• source class (`Concept`, plus special-source subclasses such as `Language` and `Material`)
• return class family (`Temporal`, `Agent`, `Concept`, `HumanMadeObject`, `Place`, `Set`, `Work`, `LinguisticObject`)
• semantic edge (`classifiedAs`, `broader`, `influencedBy`, `madeOf`, `productionTechnique`, `about`, `represents`, `creationTechnique`, `language`)
• Provided SPARQL references act as semantic oracle for inverse traversal correctness.

Implementation Mapping — Concept Search Relations

Apply these requirements to adapters, normalization, and route outputs:

1. Relation-name publication

• Publish stable HAL relation links for the documented concept-centric relation set.

1. Source-class specialization

• Enforce source-class-specific relations:
• `objectMadeOfMaterial` expects material-class source semantics
• `workLanguageLanguage` expects language-class source semantics

1. Result-class fidelity

• Ensure each relation returns the documented class family (including broader “Temporal” or “Work” family aliases where used).

1. Classification-vs-technique-vs-about semantics

• Keep `classifiedAs`, `production/creationTechnique`, `about`, and `represents` semantics separated in relation handlers.

1. Hierarchy and influence semantics

• Preserve `broader` inverse/narrower behavior and concept influence chains distinctly.

1. Search-page compliance

• Relation targets must return valid Search API `OrderedCollectionPage` responses.

1. Empty-result omission

• Omit relation links when no matching referring records exist.

TDD Additions — Concept Search Relations

Add failing-first tests for concept-relation conformance:

Contract-level:

• validates each listed relation is either present with valid HAL link shape or omitted when empty
• validates followable relation targets return schema-valid search pages

Route-level:

• validates `orderedItems[].type` matches documented return class family per relation
• validates source-class-specific relations are only emitted for compatible concept subclasses

Integration-level:

• graph fixtures verify inverse discovery for:
• entities classified as concept (activity/agent/object/place/set/work/concept)
• concept hierarchy (`broader`) and influence relations
• material-based object queries
• concept-as-technique queries for object production and work creation
• work about / represents concept and combined about-or-represents
• linguistic works by language concept

Regression:

• relation naming and source/return mappings remain stable across adapters/backends
• classifier-vs-depiction semantics do not collapse into generic “related concepts” results

Fixture Anchors — Concept Search Relations Examples

Use these relation patterns as fixture seeds:

1. `objectClassifiedAsConcept` fixture

• concept returns objects classified with that concept.

1. `agentClassifiedAsConcept` fixture

• concept returns people/groups classified with that concept.

1. `conceptBroaderConcept` fixture

• broader/narrower concept hierarchy inverse traversal.

1. `objectMadeOfMaterial` fixture

• material concept returns objects made of it.

1. `objectProductionTechniqueConcept` fixture

• concept returns objects whose production uses that technique.

1. `workCreationTechniqueConcept` fixture

• concept returns works whose creation uses that technique.

1. `workLanguageLanguage` fixture

• language concept returns linguistic works in that language.

1. `workAboutConcept` / `workRepresentsConcept` fixture

• works about concept vs works depicting concept, plus combined relation.

1. `setClassifiedAsConcept` / `placeClassifiedAsConcept` fixture

• concept returns classified sets and places.

1. `activityClassifiedAsConcept` fixture

• concept returns temporal/activity records classified as concept.

---

Round 78 Addendum — Search Relations: Temporal / Event / Activity

Source section basis:

• Linked Art API relation docs (Temporal/Event/Activity-focused search links)
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Documented temporal/activity-centric search relations include:
• `activityCausedByActivity`
• `activityPartOfActivity`
• `conceptCreationCausedByActivity`
• `conceptInfluencedByActivity`
• `objectDestructionCausedByActivity`
• `objectProductionCausedByActivity`
• `personDeathCausedByActivity`
• `setCreationCausedByActivity`
• `workAboutActivity`
• `workAboutOrRepresentsActivity`
• `workCreationCausedByActivity`
• `workRepresentsActivity`
• Relation definitions specify:
• source class family (`Event`, `Activity`, or broader `Temporal`)
• return class family (`Temporal`, `Concept`, `HumanMadeObject`, `Person`, `Set`, `Work`)
• causal, partitive, aboutness, and depiction inverse semantics
• Provided examples emphasize:
• causality chains (event/activity causing creation, destruction, death)
• temporal containment (`partOf`)
• works about/representing temporal entities

Implementation Mapping — Temporal/Activity Search Relations

Apply these requirements to adapters, normalization, and route outputs:

1. Relation-name publication

• Publish stable HAL relation links for the documented temporal/event/activity relation set.

1. Source-class family gating

• Enforce source compatibility for `Event`/`Activity`-specific vs broader `Temporal` relations.

1. Result-class fidelity

• Ensure relation result item classes match documented return families.

1. Causality semantics preservation

• Preserve explicit caused-by inverse semantics for production/destruction/creation/death related relations.

1. Part-of temporal hierarchy semantics

• Preserve temporal part/whole traversal semantics for period/event/activity nesting.

1. About-vs-represents separation

• Preserve distinction between `about`, `represents`, and combined about-or-represents relation behavior.

1. Search-page compliance

• Relation targets must return valid Search API `OrderedCollectionPage` responses.

1. Empty-result omission

• Omit relation links when no matching records exist.

TDD Additions — Temporal/Activity Search Relations

Add failing-first tests for temporal/activity relation conformance:

Contract-level:

• validates each listed relation is either present with valid HAL link shape or omitted when empty
• validates followable relation targets return schema-valid search pages

Route-level:

• validates `orderedItems[].type` against documented return class family per relation
• validates source-family-incompatible relations are not emitted

Integration-level:

• graph fixtures verify inverse discovery for:
• activities caused by source event/activity
• temporal part-of hierarchies
• concepts created/ influenced by temporal entities
• objects whose production/destruction is causally linked
• persons whose death is causally linked
• sets created due to event/activity
• works about/representing temporal entities
• works created due to event/activity

Regression:

• relation naming and class mapping remain stable across adapters/backends
• causality and partitive semantics do not collapse into generic related-item queries

Fixture Anchors — Temporal/Activity Search Relations Examples

Use these relation patterns as fixture seeds:

1. `activityCausedByActivity` fixture

• event/activity returning downstream caused activities.

1. `activityPartOfActivity` fixture

• period/event/activity with nested temporal components.

1. `objectProductionCausedByActivity` fixture

• causal activity returning produced object records.

1. `objectDestructionCausedByActivity` fixture

• destructive event returning destroyed object records.

1. `personDeathCausedByActivity` fixture

• event/activity returning persons with causally linked deaths.

1. `conceptInfluencedByActivity` fixture

• temporal source returning influenced concept records.

1. `workAboutActivity` / `workRepresentsActivity` fixture

• separated about vs represents work sets.

1. `workAboutOrRepresentsActivity` fixture

• combined about-or-represents work set behavior.

1. `workCreationCausedByActivity` fixture

• event/activity returning works created as causal outcome.

1. `setCreationCausedByActivity` fixture

• event/activity returning sets created due to source activity.

---

Round 79 Addendum — Search Relations: Set

Source section basis:

• Linked Art API relation docs (Set-focused search links)
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Documented set-centric search relations include:
• `activityUsedSet`
• `conceptInfluencedBySet`
• `conceptMemberOfSet`
• `entityMemberOfSet`
• `objectMemberOfSet`
• `placeMemberOfSet`
• `setMemberOfSet`
• `temporalMemberOfSet`
• `workAboutOrRepresentsSet`
• `workAboutSet`
• `workMemberOfSet`
• `workRepresentsSet`
• Relation definitions specify:
• source class (`Set`)
• return class family (`Activity`, `Concept`, `Entity`, `HumanMadeObject`, `Place`, `Set`, `Temporal`, `Work`)
• semantic basis (`used`, `influencedBy`, `memberOf`, `about`, `represents`)
• These relations extend set discoverability without requiring full member embedding in set records.

Implementation Mapping — Set Search Relations

Apply these requirements to adapters, normalization, and route outputs:

1. Relation-name publication

• Publish stable HAL relation links for the documented set-centric relations.

1. Membership-matrix fidelity

• Preserve distinct membership relation views by target class (`entity`, `object`, `place`, `set`, `temporal`, `work`, `concept`).

1. Generic-vs-specialized relation coherence

• Ensure `entityMemberOfSet` remains a superset-compatible view while specialized member relations return filtered class families.

1. About-vs-represents semantics

• Preserve distinct `workAboutSet`, `workRepresentsSet`, and combined `workAboutOrRepresentsSet` relation behavior.

1. Activity/influence semantics

• Preserve `activityUsedSet` and `conceptInfluencedBySet` edges without collapsing into generic related-item sets.

1. Search-page compliance

• Relation targets must return valid Search API `OrderedCollectionPage` responses.

1. Empty-result omission

• Omit relation links when no matching records exist.

TDD Additions — Set Search Relations

Add failing-first tests for set-relation conformance:

Contract-level:

• validates each listed set relation is either present with valid HAL link shape or omitted when empty
• validates followable relation targets return schema-valid search pages

Route-level:

• validates `orderedItems[].type` matches documented return class family per relation
• validates specialized member relations enforce class-specific filtering

Integration-level:

• graph fixtures verify inverse discovery for:
• activities using set
• concepts influenced by set
• concepts/entities/objects/places/sets/temporals/works that are members of set
• works about set
• works representing set
• combined about-or-represents set relation

Regression:

• relation naming and class-return mappings remain stable across providers/backends
• specialized relations do not regress into only generic `entityMemberOfSet` behavior

Fixture Anchors — Set Search Relations Examples

Use these relation patterns as fixture seeds:

1. `activityUsedSet` fixture

• set linked to one or more activities using it.

1. `entityMemberOfSet` fixture

• set with mixed-member classes returned in generic member relation.

1. Specialized membership fixtures

• `objectMemberOfSet`, `placeMemberOfSet`, `setMemberOfSet`, `temporalMemberOfSet`, `workMemberOfSet`, `conceptMemberOfSet`.

1. `conceptInfluencedBySet` fixture

• set linked to concept(s) influenced by set context.

1. `workAboutSet` fixture

• works about set.

1. `workRepresentsSet` fixture

• visual works depicting set.

1. `workAboutOrRepresentsSet` fixture

• combined result set of about-or-represents relations.

---

Round 80 Addendum — Data Discovery

Source section basis:

• Linked Art API 1.0: Data Discovery
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Linked Art records should be discoverable from non-Linked-Art entrypoints, especially HTML pages.
• Discovery/signposting requirements:
• HTML `<head>` link with `rel="describedby"` to Linked Art JSON-LD record is required.
• HTTP `Link` header with `rel="describedby"` is recommended where possible.
• exactly one linked-art `describedby` target per page to avoid client ambiguity.
• media type should declare Linked Art JSON-LD profile:
• `application/ld+json;profile='https://linked.art/ns/v1/linked-art.json'`
• This aligns with FAIR Signposting profile behavior.
• Harvesting/synchronization guidance:
• use IIIF Change Discovery API for cross-collection aggregation and sync.
• include Linked Art record-type extension context:
• `https://linked.art/ns/v1/record-types.json`
• alongside IIIF discovery context
• enables change stream entries to carry Linked Art record `type` values (for example `HumanMadeObject`).

Implementation Mapping — Data Discovery

Apply these requirements to adapters, normalization, and route outputs:

1. HTML signposting requirement

• Ensure HTML views include exactly one `<link rel="describedby" ...>` to canonical Linked Art record.

1. HTTP link-header support

• Emit `Link: <...>; rel="describedby"; type="application/ld+json;profile='...'"` when transport/runtime allows.

1. Canonical record binding

• Keep describedby target stable, canonical, and one-to-one with rendered page entity.

1. Change-discovery integration

• Expose or integrate IIIF Change Discovery endpoints for harvesting/sync workflows.

1. Context extension compliance

• Ensure IIIF change stream contexts include both Linked Art record-types context and IIIF discovery context.

1. Type propagation in change events

• Preserve Linked Art record types in change event `object.type` fields.

TDD Additions — Data Discovery

Add failing-first tests for discovery conformance:

Contract-level:

• validates HTML responses include exactly one valid describedby link in `<head>`
• validates describedby link MIME/profile declaration format
• validates optional HTTP `Link` header format when enabled

Route-level:

• HTML view route and JSON-LD data route stay correctly paired by describedby URI
• duplicate/missing describedby link scenarios fail checks

Integration-level:

• IIIF change stream includes required dual contexts (`record-types` + IIIF discovery)
• change events include Linked Art record `id` and `type` values

Regression:

• page template updates cannot remove or duplicate describedby signposts
• harvesting stream changes cannot drop Linked Art record type extension context

Fixture Anchors — Data Discovery Examples

Use these discovery patterns as fixture seeds:

1. HTML head signpost fixture

• one `<link rel="describedby" ...>` to canonical Linked Art JSON-LD URI.

1. HTTP header signpost fixture

• response with correct `Link` header profile/media type.

1. Duplicate-link negative fixture

• page with multiple describedby links fails validation.

1. IIIF context fixture

• change discovery payload with both required contexts in proper order.

1. Change event type fixture

• update event object with Linked Art `id` and `type` (for example `HumanMadeObject`).

---

Round 81 Addendum — API Design Principles and Practical Requirements

Source section basis:

• Linked Art API: Design Principles + Requirements and Design Specifics
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

1. scope via shared use cases

1. internationalization support

1. as simple as possible (progressive complexity)

1. avoid stack lock-in

1. REST/web compatibility and cacheability

1. JSON-LD-first while following LOD principles

1. standards/best-practice reuse when practical

1. define success-not-failure for extensibility

1. network-aware design

1. solve at the correct layer (API vs model)

• Core design principles (IIIF-inspired) emphasize:
• Practical requirements reinforce:
• trivial implementation possible via static files
• hand-authorable JSON should remain possible
• response count/size should stay minimal while consistent
• each statement should appear in one response where possible
• if a resource has many incoming references, it should be its own response
• inverse relationships should be resolved via dedicated APIs rather than duplicate assertions
• partition/part relationships generally flow from many -> one
• embed 1:1 dependent constructs where separate dereference is unnecessary
• URIs should remain opaque; no required URI structure assumptions

Implementation Mapping — API Design Requirements

Apply these requirements to adapters, normalization, and route outputs:

1. File-first operability

• Ensure core read-paths can run from static JSON artifacts without requiring dynamic query infrastructure.

1. Single-assertion direction policy

• Encode relationships once in canonical direction; provide inverse-discovery via search/HAL links.

1. Many-to-one partitioning discipline

• Prefer child-to-parent links for partition-heavy domains (for example page -> book, part -> whole).

1. Minimal redundancy guardrail

• Avoid duplicating the same fact across multiple payloads unless explicitly justified as performance exception.

1. 1:1 embed policy

• Embed dependent 1:1 structures (names, dimensions, timespans, etc.) unless separate dereference is needed.

1. URI opacity

• Avoid route/client logic that depends on URI path-shape assumptions beyond dereferenceability.

1. Layer-correct solutions

• Put data-description problems in model contracts; interaction/navigation problems in API/HAL/search layers.

TDD Additions — API Design Requirements

Add failing-first tests for architecture conformance:

Contract-level:

• validates no duplicated canonical assertions across designated record pairs where single-direction policy applies
• validates embedded 1:1 structures follow shared-structure contracts

Route-level:

• validates inverse relationship discoverability through search/HAL links rather than duplicated forward+inverse fields
• validates URI consumers treat IDs as opaque strings, not path-pattern parsed keys

Integration-level:

• static-file fixture mode produces equivalent read responses to dynamic mode for core endpoints
• partition fixtures confirm many->one link direction and inverse discovery behavior

Regression:

• optimization changes cannot silently introduce broad statement duplication
• backend swaps cannot break file-first minimum implementation mode

Fixture Anchors — API Design Requirements Examples

Use these architecture patterns as fixture seeds:

1. Static-mode parity fixture

• endpoint responses from static artifacts match dynamic pipeline outputs.

1. Single-direction relationship fixture

• fact appears once; inverse discovered via search link.

1. Partition direction fixture

• child records reference parent; parent inverse list discovered via search API.

1. Opaque URI fixture

• consumer utilities handle arbitrary URI structures without path-shape coupling.

1. 1:1 embed fixture

• embedded dependent structures (name/dimension/timespan) validate without separate dereference requirement.

---

Round 82 Addendum — JSON-LD and Context Design

Source section basis:

• Linked Art API: JSON-LD serialization + context design rules
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Canonical Linked Art context:
• `https://linked.art/ns/v1/linked-art.json`
• Canonical media type/profile:
• `application/ld+json;profile="https://linked.art/ns/v1/linked-art.json"`
• Core serialization constraints:
• terms are case-sensitive (for example `Type` vs `type`)
• JSON properties cannot be repeated; multi-values use arrays
• Linked Art avoids RDF ordered list structures and relies on array order
• Other RDF/graph serializations may exist but are optional and must not be assumed.
• Context design goals:
• valid JSON-LD + LOD semantics
• developer-friendly JSON shapes
• cross-language implementation usability
• Context transformation strategy from CRM terms includes:
• namespace/prefix cleanup
• number/punctuation simplification
• class naming to UpperCamelCase
• property naming to lower_snake_case
• collision resolution and inconsistency normalization
• Context uses JSON-LD 1.1 scoped contexts and set containers:
• `@container: @set` for properties that may have multiple values
• mapped partition relationships to consistent `part` / `part_of` keys

Implementation Mapping — JSON-LD Context Design

Apply these requirements to adapters, normalization, and route outputs:

1. Context/media-type correctness

• Always emit canonical Linked Art context and correct JSON-LD profile media type on API responses.

1. Case-sensitive key discipline

• Enforce key casing exactly per context definitions in serializers and validators.

1. Array-normalization rule

• Emit array form for potentially multi-valued properties, even when only one value is present.

1. Context-driven naming consistency

• Use context-resolved canonical keys (including normalized collision-resolved keys) consistently across all routes.

1. Scoped-context behavior preservation

• Preserve `part` / `part_of` unified readability while keeping underlying semantic precision.

1. Optional format tolerance

• Support alternate serializations where offered, but do not require them for conformance.

1. Collision-map stability

• Treat documented collision/inconsistency remappings as stable API contract behavior, not implementation details.

TDD Additions — JSON-LD Context Design

Add failing-first tests for JSON-LD/context conformance:

Contract-level:

• validates root `@context` matches canonical Linked Art context URI
• validates case-sensitive keys and rejection of incorrect-cased alternatives
• validates single-or-many fields are serialized as arrays where context requires set behavior

Route-level:

• validates `Content-Type` profile string for JSON-LD responses
• validates partition relationships serialize consistently as `part` / `part_of` where scoped context applies

Integration-level:

• round-trip tests verify JSON-LD expansions preserve expected RDF semantics
• context collision-remap keys stay stable across endpoint families

Regression:

• serializer changes cannot reintroduce CRM raw-term inconsistencies into payload keys
• profile/media-type drift is caught by response-header contract tests

Fixture Anchors — JSON-LD Context Design Examples

Use these JSON-LD patterns as fixture seeds:

1. Canonical context fixture

• payload with exact linked-art context URI and profile media type.

1. Case-sensitivity negative fixture

• incorrect-cased term keys fail validation.

1. Array-singleton fixture

• potentially multi-valued property serialized as single-entry array.

1. Partition key fixture

• scoped-context mapped `part` / `part_of` relations with expected semantics.

1. Collision-key stability fixture

• payload uses normalized context keys (not raw CRM-numbered property names).

1. Expansion integrity fixture

• JSON-LD expansion check confirming preserved predicate mapping.

---

Round 83 Addendum — Protocol (HTTP/REST)

Source section basis:

• Linked Art API: Protocol
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• Linked Art protocol profile is REST/resource-centric over HTTP.
• Transport/security/version guidance:
• HTTPS strongly recommended
• servers must support HTTP/1.1
• servers should support HTTP/2+
• Operation support:
• publishers must support `GET` and `OPTIONS`
• publishers should support `HEAD`
• clients must not rely on `HEAD` support
• Content negotiation:
• request `Accept: application/ld+json;profile="https://linked.art/ns/v1/linked-art.json"`
• response `Content-Type: application/ld+json;profile="https://linked.art/ns/v1/linked-art.json"`
• alternate serializations may be supported, but discovery mechanism is not standardized by Linked Art
• CORS requirements:
• responses must include `Access-Control-Allow-Origin: *`
• `OPTIONS` preflight responses must include CORS headers as well
• URI policy:
• no strict URI structure requirements (URIs remain opaque)
• preferred shape: `scheme://hostname/prefix/endpoint/identifier`
• preferred endpoint path names:
• `concept`, `digital`, `event`, `group`, `object`, `person`, `place`, `provenance`, `set`, `text`, `visual`

Implementation Mapping — Protocol

Apply these requirements to adapters, normalization, and route outputs:

1. Method support compliance

• Ensure all public API routes support `GET` and `OPTIONS`; optionally support `HEAD` without client dependency.

1. JSON-LD conneg compliance

• Enforce Accept/Content-Type profile handling for Linked Art JSON-LD responses.

1. CORS baseline compliance

• Emit `Access-Control-Allow-Origin: *` on both normal and preflight responses for API resources.

1. HTTP-version readiness

• Maintain HTTP/1.1 compatibility; prefer HTTP/2+ deployment where available.

1. URI opacity discipline

• Treat all URIs as opaque in client/server logic; never depend on URI path parsing for semantics.

1. URI good-practice alignment

• Where controllable, align endpoint naming and URI patterns with preferred conventions for maintainability.

TDD Additions — Protocol

Add failing-first tests for protocol conformance:

Contract-level:

• validates response `Content-Type` includes Linked Art JSON-LD profile
• validates preflight and normal responses include required CORS header

Route-level:

• validates `GET` and `OPTIONS` are supported for endpoint families
• validates unsupported methods return controlled/consistent status behavior

Integration-level:

• validates conneg behavior for profile-accepting requests
• validates route behavior remains stable regardless of URI shape assumptions

Regression:

• deployment/config changes cannot drop CORS headers or content-profile headers
• router changes cannot break preferred endpoint namespace mapping where implemented

Fixture Anchors — Protocol Examples

Use these protocol patterns as fixture seeds:

1. GET success fixture

• endpoint returns JSON-LD payload with canonical Content-Type profile.

1. OPTIONS preflight fixture

• preflight response includes `Access-Control-Allow-Origin: *`.

1. HEAD optional-support fixture

• if implemented, returns headers-only response; client tests remain non-dependent.

1. Conneg fixture

• request with Linked Art Accept profile returns matching profile Content-Type.

1. URI opacity fixture

• alternative URI path patterns still resolve correctly without parser assumptions.

1. Endpoint-name mapping fixture

• canonical endpoint paths (`object`, `person`, etc.) map to expected serializers.

---

Round 84 Addendum — Code and Tools Ecosystem

Source section basis:

• Linked Art: Code and Tools references
• Captured for this addendum on: May 30, 2026

Official-model takeaways captured for implementation:

• This section is ecosystem guidance rather than normative API contract rules.
• Referenced software/library/platform categories include:
• Libraries:
• Crom (Python)
• LinkedArt.js (JavaScript)
• Linked.Art.Net (C#/.NET)
• Platforms:
• LUX (open-source cross-collection discovery implementation)
• Arches
• Ogee Arches package (Linked Art model + vocabulary support)
• Documentation/pattern tooling:
• Zellij (semantic pattern library representation)
• Validators:
• JSON validator service based on Linked Art schemas
• Other resources:
• data-model visualization tools
• Mermaid Live Editor
• OpenRefine for collections data cleanup/handling

Implementation Mapping — Code and Tools

Apply these requirements to adapters, normalization, and route outputs:

1. Non-normative dependency policy

• Treat tooling references as implementation accelerators, not as conformance requirements.

1. Toolchain selection criteria

• Prefer tools that preserve Linked Art schema/context fidelity and integrate with existing test/validation workflows.

1. Validator integration

• Keep JSON Schema validation in automated pipelines regardless of chosen library/platform stack.

1. Pattern documentation integration

• Use pattern libraries/visualization tools to strengthen onboarding, mapping clarity, and query/template generation.

1. Data hygiene workflow support

• Integrate data-cleaning tooling (for example OpenRefine-compatible flows) upstream of ingestion where helpful.

TDD Additions — Code and Tools

Add failing-first tests for toolchain reliability expectations:

Contract-level:

• validate core payloads with schema validators independent of runtime language/library

Integration-level:

• smoke tests confirm chosen serializer/parser libraries preserve canonical context and key semantics
• import/cleanup workflows retain required Linked Art fields after transformation

Regression:

• library/platform upgrades do not alter canonical payload shape or break schema conformance
• toolchain swaps maintain identical API-facing contracts

Fixture Anchors — Code and Tools Examples

Use these ecosystem-oriented patterns as fixture seeds:

1. Cross-library parity fixture

• same record serialized/parsed through selected library paths yields equivalent canonical JSON-LD.

1. Validator parity fixture

• local CI schema validation and external validator results agree on pass/fail.

1. Data-cleaning fixture

• pre/post-cleaning payloads retain required Linked Art semantics and identifiers.

1. Visualization/documentation fixture

• model pattern artifacts generated from fixture graph remain consistent with schema contracts.

---

Round 1 Open Items For Next Docs Drop

Please add official material in future rounds for:

• detailed basic pattern examples
• required vs recommended vs optional terminology specifics
• concrete JSON-LD examples for activities, provenance, exhibitions, conservation, and object production/destruction
• model versioning rules and upgrade guidance
• specific assertions and archival hierarchy examples

When those arrive, we should extend this file with explicit fixture-driven test plans.