{"id":"linked-art/LinkedArtModel1.0-Reference","relativePath":"linked-art/LinkedArtModel1.0-Reference.md","title":"Linked Art Model 1.0 Reference (Round 1)","markdown":"# Linked Art Model 1.0 Reference (Round 1)\n\nStatus: Working reference for Meta Museum engineering and TDD alignment  \nSource: <https://linked.art/>  \nSource document basis: Linked Art Model 1.0 (`1.0.0`)  \nLicense note from source: Linked Art Data Model is published under CC BY 4.0  \nCaptured for this reference on: May 30, 2026\n\n---\n\n## Purpose\n\nThis file turns official Linked Art model guidance into project-ready engineering notes for Meta Museum.  \nIt is designed to support:\n\n- implementation decisions in adapters, contracts, routes, and UI\n- roadmap updates across Era B and Era C\n- test-driven development (TDD) with explicit behavior checks\n\nThis is a living reference. Future rounds append additional official sections and examples.\n\n---\n\n## Canonical Model Summary\n\nLinked Art 1.0 is an application profile for describing cultural heritage resources, especially artworks and museum-oriented activities.\n\nCore characteristics:\n\n- event-centric modeling grounded in CIDOC-CRM\n- streamlined subset of CIDOC-CRM 7.1.3 for practical interoperability\n- JSON-LD 1.1 as core serialization format\n- vocabulary and term discipline to keep data interoperable across institutions\n\nThe model is finalized at version `1.0.0`, with future evolution expected through community process.\n\n---\n\n## Model Coverage Areas (from official structure)\n\nThe model documentation includes guidance for:\n\n- basic patterns used throughout\n- artworks and other physical objects\n- digital content about/depicting objects\n- sets and collections\n- provenance\n- exhibitions\n- conservation\n- related people, organizations, places, concepts, events\n- cultural context\n- textual documents\n- archival hierarchies\n- specific assertions\n\nImplementation note for Meta Museum:\n\n- these areas should map to explicit contract and validation coverage, not implicit adapter behavior\n\n---\n\n## Design Principles To Preserve\n\nLinked Art model development emphasizes:\n\n- iterative improvement\n- responsive change from feedback\n- responsible complexity management\n- collaborative evolution\n\nFor this codebase, this means:\n\n- prioritize clear contract boundaries over one-off transforms\n- prefer additive schema/version migration over breaking storage changes\n- keep provider-specific logic isolated in adapters\n\n---\n\n## Scope Boundaries (Important)\n\nFrom the official scope limitations:\n\n- goal is interoperability across systems, not perfect modeling of every local institutional detail\n- complete bibliographic/archival description is intentionally out of scope for Linked Art alone\n- detailed provenance of the data-recording process itself is out of scope at this stage\n- quantification of uncertainty/belief is valuable but intentionally deferred due to complexity\n\nEngineering implication:\n\n- avoid over-modeling unsupported certainty/provenance semantics until explicitly scoped in roadmap\n- keep import outputs interoperable-first and standards-aligned\n\n---\n\n## Meta Museum Implementation Mapping (Round 1)\n\nUse this as a standards checklist when adding/changing features:\n\n1. Canonical layer\n- Stored records remain Linked Art JSON-LD centric (`SourceRecord` + `_source.raw` preservation).\n\n2. Event-centric modeling\n- Do not flatten event semantics (production/acquisition/exhibition/conservation) into untyped strings when structured activity is available.\n\n3. Serialization discipline\n- APIs and adapters should preserve JSON-LD compatibility and context handling.\n\n4. Vocabulary discipline\n- Keep required/recommended/optional term usage explicit where feasible in contracts and validation.\n\n5. Interoperability over local convenience\n- Route and UI DTOs can simplify for UX, but source-level structures must stay standards-safe.\n\n---\n\n## TDD Guidance Derived From Linked Art 1.0\n\nWhen implementing any new provider, route, or transform, test first against these minimum behaviors.\n\n### Contract-level tests\n\n- rejects malformed Linked Art top-level shape\n- preserves core identity fields (`id`, `type`, `_label` when present)\n- preserves structured event/activity nodes\n- preserves controlled-term links/classifications when present\n\n### Adapter-level tests\n\n- transforms provider payloads into Linked Art-compatible structures\n- does not discard important relationships (people/place/concept/event)\n- keeps source provenance fields for citation and audit surfaces\n- handles sparse data conservatively (warnings instead of silent loss)\n\n### Route-level tests\n\n- inspect/resolve/import routes validate request boundaries\n- import routes return standards-safe normalized output and stable error shapes\n- provider routes do not leak provider-specific quirks into shared contracts\n\n### Regression tests\n\n- adding a provider does not break existing provider adapters\n- DTO simplification never mutates canonical stored source data\n\n---\n\n## Roadmap Hooks (What this reference should drive)\n\nThis reference directly supports:\n\n- Era B1/B2: schema mirrors + formal validation alignment\n- Era B5: provider expansion with consistent Linked Art boundary behavior\n- Era B6: authority strategy and controlled vocabulary consistency\n- Era C: richer model coverage (documents, archival hierarchies, assertions) without breaking core interoperability\n\nRecommended follow-up after each documentation round:\n\n- update `docs/roadmap.md` acceptance language where needed\n- add or tighten failing tests before feature code\n- record gaps between source docs and current contracts in a tracked checklist\n\n---\n\n## Round 2 Addendum — Objects (Physical Object Modeling)\n\nSource section basis:\n\n- Linked Art Model 1.0: Objects\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- `HumanMadeObject` is the core class for art objects and other physical objects with social/cultural value.\n- Even minimally altered natural objects (for example, a shell) are still modeled as `HumanMadeObject` when value is socially conferred.\n- This simplifies interoperability and avoids ambiguous thresholds for \"how modified is modified enough\".\n- Shared/basic patterns and digital integration patterns still apply to object records.\n- Object-specific documentation focus areas:\n  - production and destruction\n  - physical characteristics\n  - aboutness\n  - ownership\n  - rights information (non-ownership rights)\n  - digital representation linkage\n  - immovable objects handled through place-oriented modeling\n\n### Implementation Mapping — Objects\n\nApply these requirements to adapters, normalization, and stored source records:\n\n1. Object typing\n- Default culturally valued physical works to `HumanMadeObject` unless there is explicit evidence for a different canonical class.\n\n2. Event modeling\n- Production and destruction must remain activity/event-shaped when present; do not flatten into untyped date/label strings only.\n\n3. Physical characteristics\n- Preserve structured dimensions/materials/parts where provided; avoid collapsing to display-only text.\n\n4. Aboutness and descriptive statements\n- Keep descriptive content in structured statement fields; do not discard language-tagged or classified descriptions.\n\n5. Ownership and location\n- Keep ownership/location assertions distinct from general rights statements.\n\n6. Rights split\n- Distinguish ownership from usage/reproduction rights in normalization and UI summaries.\n\n7. Digital linkage\n- Keep physical object and digital surrogates distinct, linked through representation/documentation patterns.\n\n8. Immovable handling\n- For immovable works, prefer place-connected modeling patterns instead of forcing moveable-object assumptions.\n\n### TDD Additions — Objects\n\nAdd failing-first tests for object workflows:\n\nContract-level:\n\n- accepts `HumanMadeObject` as canonical object class for valued physical objects\n- preserves event structures for production/destruction when present\n- preserves dimensions/materials/parts structures without forced flattening\n\nAdapter-level:\n\n- normalizes provider object payloads into `HumanMadeObject`-compatible output\n- keeps ownership/location and rights information separated in normalized output\n- preserves links to digital surrogates without collapsing physical and digital identities\n\nRoute-level:\n\n- inspect/import paths retain object event + physical-characteristics structure after normalization\n- responses include stable rights/ownership-safe summaries without mutating canonical source fields\n\nRegression:\n\n- immovable/place-centric records remain standards-safe and are not coerced into moveable-only assumptions\n\n---\n\n## Round 3 Addendum — Digital Content\n\nSource section basis:\n\n- Linked Art Model 1.0: Digital Content\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- `DigitalObject` is a carrier of information, not the information itself.\n- Information/content should remain modeled as `LinguisticObject` or `VisualItem`, with digital/physical carriers linked to that same content.\n- Digital object core properties include:\n  - `access_point` for file/resource URLs\n  - `format` for media type (MIME)\n  - `conforms_to` for standards/specifications\n  - `dimension` for digital characteristics (for example, file size, pixels)\n  - `created_by` using `Creation` activity pattern\n- Digital erasure/deletion is not yet modeled in Linked Art 1.0 and should not be invented ad hoc.\n- Digital surrogates should be distinguished from generic depictions:\n  - physical object `shows` a `VisualItem`\n  - digital surrogate `digitally_shows` the same `VisualItem`\n- Embedded representation pattern is valid when the digital image is auxiliary to the main entity.\n- Web pages about entities should be linked via `subject_of` with intermediary `LinguisticObject`, then `digitally_carried_by` a `DigitalObject` classified as web page.\n- IIIF Presentation manifests:\n  - treat as `DigitalObject` in `subject_of` pattern\n  - include `conforms_to` = `http://iiif.io/api/presentation/`\n  - use presentation media type in `format`\n- IIIF Image API:\n  - model service as `DigitalService` under `digitally_available_via`\n  - service (not the image file itself) carries `conforms_to` = `http://iiif.io/api/image/`\n  - service `format` refers to `info.json` media type profile\n\n### Implementation Mapping — Digital Content\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Carrier/content separation\n- Never collapse `DigitalObject` and information content into a single semantic layer.\n\n2. URL and media handling\n- Preserve canonical access URLs in `access_point`; preserve MIME/media-type detail in `format`.\n\n3. Standards linkage\n- Use `conforms_to` for protocol/spec alignment (IIIF, HTML spec, etc.), not broad topical classification.\n\n4. Creation semantics\n- Use `Creation` for digital-object creation events, not `Production`.\n\n5. Surrogate clarity\n- Preserve shared `VisualItem` linkage between physical `shows` and digital `digitally_shows` when surrogate semantics are present.\n\n6. Embedded digital references\n- Allow embedded digital representation objects in records where that improves interoperability and UI usability.\n\n7. IIIF compatibility\n- Preserve both direct image access points and service endpoints when both are available.\n\n8. Deletion semantics guardrail\n- Do not synthesize unsupported digital deletion/erasure events in 1.0 workflows.\n\n### TDD Additions — Digital Content\n\nAdd failing-first tests for digital-content workflows:\n\nContract-level:\n\n- preserves `DigitalObject` records with `access_point`, `format`, and optional `conforms_to`\n- preserves `Creation` event shape on digital objects where present\n- rejects or flags malformed digital access points/media shapes\n\nAdapter-level:\n\n- keeps content-carrier separation (`DigitalObject` vs `LinguisticObject`/`VisualItem`)\n- preserves surrogate linkage where physical and digital records point at the same `VisualItem`\n- preserves `subject_of` → `LinguisticObject` → `digitally_carried_by` web-page pattern\n- preserves IIIF manifest and IIIF image service structures (`digitally_available_via` with `DigitalService`)\n\nRoute-level:\n\n- inspect/import outputs preserve digital fields without flattening to plain strings only\n- resolve/import routes keep IIIF `conforms_to` and `format` metadata when present\n- API DTO simplification does not mutate canonical `_source.raw` digital structure\n\nRegression:\n\n- existing physical-object workflows remain stable when digital enrichment is added\n- adapter updates do not regress rights/provenance fields while adding digital metadata\n\n### Fixture Anchors — Digital Content Examples\n\nUse these official-example patterns as fixture seeds for contract and route tests:\n\n1. Web publication as first-class `DigitalObject`\n- `type: DigitalObject`\n- `classified_as` includes web page (`aat:300264578`) when applicable\n- `access_point` contains the direct human/web resource URL\n- `format` preserves media type such as `text/html`\n- `conforms_to` can point to relevant standards (for example, HTML)\n- `created_by.type` is `Creation`\n- `digitally_carries` links the content entity (`LinguisticObject`)\n\n2. Digital surrogate parity pattern\n- Physical object `shows` a `VisualItem`\n- Digital surrogate `digitally_shows` the same `VisualItem` identifier\n- Tests should verify shared visual-content identity across carriers\n\n3. Embedded representation image pattern\n- Entity `representation[]` includes `VisualItem`\n- `digitally_shown_by[]` contains a `DigitalObject`\n- digital image keeps `format` and image `access_point`\n\n4. Web page about an object pattern\n- Object `subject_of[]` contains `LinguisticObject`\n- `digitally_carried_by[]` contains a `DigitalObject`\n- web page classification and `text/html` format remain intact\n\n5. IIIF Presentation manifest pattern\n- linked through `subject_of -> LinguisticObject -> digitally_carried_by`\n- `conforms_to` includes `http://iiif.io/api/presentation/`\n- `format` preserves profile media type (Presentation 3 context)\n\n6. IIIF Image API service pattern\n- digital image may include both `access_point` and `digitally_available_via`\n- `digitally_available_via[].type` is `DigitalService`\n- service `conforms_to` includes `http://iiif.io/api/image/`\n- service `format` preserves profile media type (Image 3 context / `info.json`)\n\n---\n\n## Round 4 Addendum — Collections and Sets\n\nSource section basis:\n\n- Linked Art Model 1.0: Collections\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Use `Set` for conceptual groupings across many use cases (collections, exhibition sets, auction lots, archival sets, conceptual/person sets).\n- `Set` is a Linked Art class introduced outside base CIDOC-CRM to support consistent multi-type grouping semantics.\n- Sets are conceptual, not physical aggregations:\n  - created via `Creation`, not `Production`\n  - cannot be destroyed in this model\n  - may have zero members and still exist\n- Membership is asserted on the member entity via `member_of` pointing to the set.\n- Linked Art API expectations focus membership on core record-capable entities.\n- Ordered sets use sort value identifiers (for example, AAT sort value typing) on members, optionally contextualized with `AttributeAssignment` influenced by a specific `Set`.\n- Prototypical member description uses `members_exemplified_by` embedded in the `Set`.\n- Collection membership should not be conflated with ownership or custody; objects can be members of multiple sets simultaneously.\n- 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).\n\n### Implementation Mapping — Collections/Sets\n\nApply these requirements to adapters, normalization, contracts, and route outputs:\n\n1. Set identity and lifecycle\n- Preserve `Set` as first-class record type with stable `id`, `type`, names, statements, and optional classification.\n- Model set creation with `created_by.type = Creation` where known.\n\n2. Membership directionality\n- Preserve `member_of` on member entities; do not require inverse `member` materialization on sets in API responses.\n\n3. Collection-context separation\n- Keep collection membership separate from ownership/custody semantics.\n\n4. Ordering semantics\n- Preserve sort-value identifiers and contextual assignment patterns when present; do not flatten away set-specific ordering signals.\n\n5. Prototypical member semantics\n- Preserve `members_exemplified_by` as descriptive prototype, not as highlighted members or strict universal constraints.\n\n6. Nested set structures\n- Preserve set-to-set `member_of` relations for institutional and departmental collection hierarchies.\n\n7. Group compatibility\n- 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.\n\n### TDD Additions — Collections/Sets\n\nAdd failing-first tests for set and collection workflows:\n\nContract-level:\n\n- accepts `Set` with core identity fields and optional statements/classifications\n- preserves `created_by` creation semantics for sets\n- rejects malformed `member_of` and `members_exemplified_by` structures\n\nAdapter-level:\n\n- preserves `member_of` links on imported member entities\n- does not collapse membership into inferred ownership/custody\n- preserves set ordering metadata (`Identifier` sort value + optional assignment context)\n- preserves `members_exemplified_by` without converting it into concrete membership\n\nRoute-level:\n\n- inspect/import outputs preserve set structures and membership links\n- collection and entity endpoints return memberships without mutating `_source.raw`\n- set-related DTO projections remain additive and do not erase canonical set semantics\n\nRegression:\n\n- object and digital-content workflows remain stable when set membership metadata is introduced\n- multi-set membership for a single entity remains supported\n\n### Fixture Anchors — Collections/Sets Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Exhibition object set\n- `Set` with primary name, description statement, and `created_by` `Creation`.\n\n2. Member entity linkage\n- `HumanMadeObject` with `member_of` pointing to exhibition set.\n\n3. Ordered membership context\n- member `Identifier` classified as sort value with optional `AttributeAssignment` influenced by the target set.\n\n4. Prototypical member pattern\n- `Set.members_exemplified_by` embedding a prototype entity and typical characteristics.\n\n5. Institutional + departmental collections\n- institutional collection `Set`\n- departmental collection `Set` as `member_of` institutional set\n- departmental curation context modeled via `used_for` activity.\n\n6. Member in curated set\n- object with `member_of` departmental collection.\n\n---\n\n## Round 5 Addendum — Object Provenance\n\nSource section basis:\n\n- Linked Art Model 1.0: Object Provenance\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Provenance is modeled as a chain of activities across an object's lifecycle.\n- A provenance entry is often a wrapper `Activity` (\"Provenance Event\") that groups multiple granular parts.\n- Typical `part` activities can include:\n  - `Acquisition` (ownership transfer)\n  - `Payment` (monetary exchange)\n  - other legal/physical/contextual activities as needed\n- Production and destruction are lifecycle boundaries but are modeled using object lifecycle patterns, not the same pattern as wrapper provenance events.\n- Provenance event classification is important (for example, provenance activity, gift, purchase-like variants).\n- Unknown/approximate chronology can be represented with relative ordering:\n  - `after`: current event starts after referenced event ends\n  - `before`: current event ends before referenced event starts\n- Provenance can include events beyond ownership transfer:\n  - custody transfer\n  - encountering/rediscovery\n  - rights acquisition\n  - promises/auction commitments\n  - movement\n  - unknown transfer type when evidence is incomplete\n\n### Implementation Mapping — Provenance\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Wrapper-event pattern\n- Preserve provenance entries as top-level `Activity` wrappers with classifications and optional timespans.\n\n2. Part decomposition\n- Preserve granular `part` activities (`Acquisition`, `Payment`, etc.) rather than flattening to narrative strings.\n\n3. Actor/object role integrity\n- Preserve explicit transfer/payment roles (`transferred_title_from`, `transferred_title_to`, `paid_from`, `paid_to`, `transferred_title_of`).\n\n4. Monetary structure integrity\n- Preserve `MonetaryAmount` + `currency` structures for payment parts when present.\n\n5. Relative-time support\n- Preserve `after`/`before` references for events with uncertain absolute dating.\n\n6. Classification precision\n- Preserve both broad provenance classification and specific transaction-type classifications.\n\n7. Uncertain transfer handling\n- Do not force uncertain evidence into overly specific ownership/custody/movement types; preserve uncertainty safely.\n\n### TDD Additions — Provenance\n\nAdd failing-first tests for provenance workflows:\n\nContract-level:\n\n- accepts wrapper provenance `Activity` with `classified_as` and optional `timespan`\n- preserves valid `part` arrays with `Acquisition`/`Payment` structures\n- rejects malformed transfer-role structures and malformed monetary/currency payloads\n\nAdapter-level:\n\n- normalizes provider provenance entries into wrapper activity + granular part structure\n- preserves transfer and payment roles without role collapse\n- preserves specific provenance classification terms (for example, gift)\n- preserves `after`/`before` relations when explicit dates are absent\n\nRoute-level:\n\n- inspect/import outputs preserve provenance wrapper + part structures\n- provenance-rich records remain queryable without losing role-specific fields\n- DTO simplification does not mutate canonical provenance structure in `_source.raw`\n\nRegression:\n\n- object lifecycle activity fields (production/destruction) are not overwritten by provenance-wrapper logic\n- uncertain/unknown transfer records remain represented as uncertain, not force-cast to a specific event type\n\n### Fixture Anchors — Provenance Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Purchase provenance event with payment\n- wrapper `Activity` classified as provenance activity\n- `part[]` includes:\n  - `Acquisition` with title transfer roles and object\n  - `Payment` with `MonetaryAmount` and currency\n\n2. Gift provenance event\n- wrapper `Activity` classified as provenance activity + gift\n- `part[]` includes `Acquisition` transfer from donor to receiving group/institution\n\n3. Relative-time-only provenance event\n- wrapper `Activity` with `after` and/or `before` references\n- no requirement for explicit absolute timespan\n\n4. Unknown transfer scenarios\n- fixtures where textual evidence is ambiguous; tests assert preservation of uncertainty and non-overstatement of event type.\n\n---\n\n## Round 6 Addendum — Acquisitions and Loans\n\nSource section basis:\n\n- Linked Art Model 1.0: Acquisitions and Loans\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Most provenance events involve ownership transfer and are modeled via `Acquisition` parts inside a wrapper provenance `Activity`.\n- \"Seller\" and \"buyer\" are role labels for transfer clarity, not strictly cash-sale semantics.\n- `Acquisition` encodes title transfer:\n  - `transferred_title_of` (object)\n  - `transferred_title_from` (relinquishing owner)\n  - `transferred_title_to` (gaining owner)\n- Unknown seller or buyer can be omitted when evidence is incomplete.\n- A single provenance event can contain multiple `Acquisition` parts (for example, multiple objects in one transaction).\n- Simultaneous co-ownership can be represented by multiple `transferred_title_to` (or `transferred_title_from`) entries when split details are unknown/even.\n- If legal ownership is held by a consortium, model consortium as `Group` and use that group as owner.\n- Agents can be modeled via `carried_out_by` on acquisition activity; model does not distinguish seller-agent vs buyer-agent semantics.\n- Exchanges can be represented by multiple acquisitions with inverse transfer directions.\n- Purchases include `Payment` parts with:\n  - `paid_from`\n  - `paid_to`\n  - `paid_amount` (`MonetaryAmount` with `value` + `currency`)\n- Separate monetary flows (seller price, commissions, service payments) should be separate `Payment` instances.\n- Monetary amounts are face-value constructs; diachronic comparison requires time context of referencing events.\n- Loan/custody-centric transfer scenarios are related but documented in custody-specific patterns; do not force custody into ownership transfer semantics.\n\n### Implementation Mapping — Acquisitions/Payments\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Ownership transfer fidelity\n- Preserve acquisition role edges explicitly; do not collapse into a generic \"changed owner\" string.\n\n2. Multi-object and multi-party support\n- Support arrays in transfer fields to preserve multi-object transactions and co-owner/co-seller patterns.\n\n3. Agent representation\n- Preserve acquisition-level `carried_out_by` agents when present.\n\n4. Exchange modeling\n- Preserve multi-acquisition exchange structures rather than flattening to one ambiguous transfer.\n\n5. Payment decomposition\n- Preserve each payment as a distinct part activity, especially where commissions/services are known.\n\n6. Monetary structure preservation\n- Preserve `MonetaryAmount` + `currency` (+ optional notation/classification) without type degradation.\n\n7. Uncertainty discipline\n- Where seller/buyer detail is unknown, preserve partial role assertions without speculative completion.\n\n8. Ownership vs custody guardrail\n- Do not encode loans/custody movements as title transfers unless evidence explicitly indicates ownership transfer.\n\n### TDD Additions — Acquisitions/Payments\n\nAdd failing-first tests for acquisition and payment workflows:\n\nContract-level:\n\n- validates `Acquisition` role structure with object/from/to fields when provided\n- allows omitted transfer-role fields for uncertain historical evidence\n- validates `Payment` structure with `paid_from`, `paid_to`, and `MonetaryAmount` currency/value\n\nAdapter-level:\n\n- preserves multi-acquisition provenance events for bundled transactions\n- preserves multi-party ownership transfer arrays without collapsing to a single actor\n- preserves `carried_out_by` agents on acquisition parts\n- preserves multiple payment parts (object price + commission/service) as separate events\n\nRoute-level:\n\n- inspect/import outputs preserve acquisition/payment part granularity and actor roles\n- routes do not synthesize missing seller/buyer values when source evidence is incomplete\n- DTO projections preserve canonical `_source.raw` transaction structure\n\nRegression:\n\n- exchange-of-objects scenarios continue to round-trip without role inversion bugs\n- commission/service payments do not overwrite or merge with primary seller payment\n\n### Fixture Anchors — Acquisitions/Payments Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Simple acquisition\n- wrapper provenance `Activity` with one `Acquisition` transferring one object from seller to buyer.\n\n2. Joint acquisition / multiple owners\n- acquisition with multiple `transferred_title_to` entries for co-ownership.\n\n3. Agent-mediated acquisition\n- acquisition with `carried_out_by` agent plus explicit seller and buyer.\n\n4. Exchange transaction\n- wrapper event with multiple `Acquisition` parts modeling reciprocal transfers.\n\n5. Purchase + payment\n- acquisition part plus separate payment part with `MonetaryAmount`.\n\n6. Service/commission payments\n- multiple payment parts distinguishing seller payment from commission payment.\n\n---\n\n## Round 7 Addendum — Auctions\n\nSource section basis:\n\n- Linked Art Model 1.0: Auctions\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Auction modeling separates several entities/activities:\n  - overall auction event (`Activity`, auction-event classification)\n  - auction of a single lot (`Activity`, auction-of-lot classification)\n  - lot itself as a `Set` of objects\n  - resulting provenance purchase activity (if sale completes)\n- Key vocabulary anchors include:\n  - Auction Activity (`aat:300054751`)\n  - Auction of Lot Activity (`aat:300420001`)\n  - Auction House Organization (`aat:300417515`)\n  - Auction House Premises (`aat:300005234`)\n  - Auction Lot (`aat:300411307`)\n  - Lot Number (`aat:300404628`)\n  - Auction Catalog (`aat:300026068`)\n- Auction event (`Activity`):\n  - `carried_out_by` auction house `Group`\n  - `took_place_at` auction house premises `Place`\n  - timespan/name/classification as regular activity metadata\n- Auction of lot (`Activity`):\n  - `part_of` overall auction event\n  - references lot set via `used_specific_object`\n  - may cause provenance purchase event if reserve conditions are met\n- Lot modeled as `Set`:\n  - classified as auction lot\n  - includes lot number identifier\n  - membership expressed on member objects via `member_of`\n- Pre-set prices (starting/reserve/estimated) are modeled on lot set as monetary dimensions, independent of sale completion.\n- Purchase of lot:\n  - provenance event references set via `used_specific_object`\n  - has per-object `Acquisition` parts and payment part(s)\n  - may include agent via `carried_out_by`\n  - can link back to auction-of-lot via `part_of`\n- Auction catalogs are `LinguisticObject` records classified as auction catalogs and can reference auction event via `about`.\n- Non-sale outcomes must be represented explicitly without over-asserting ownership transfers:\n  - lot withdrawn (catalog + lot set, but no auction-of-lot activity)\n  - object withdrawn from multi-object lot\n  - reserve not met / bought in\n  - owner buys own lot\n  - winner unable to pay\n\n### Implementation Mapping — Auctions\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Layer separation\n- Preserve distinction between auction event, lot-auction activity, lot set, and resulting provenance purchase.\n\n2. Lot membership directionality\n- Preserve lot membership on objects (`member_of`) rather than synthesizing set-owned member lists in canonical data.\n\n3. Event linkage integrity\n- Preserve `part_of` links (lot-auction -> auction event, purchase provenance -> lot-auction when known).\n\n4. Price semantics\n- Preserve pre-set lot prices as lot-level monetary dimensions, separate from realized payment amounts.\n\n5. Auction-house context\n- Preserve place and organization context for auction event (`took_place_at`, `carried_out_by`) with classifications when present.\n\n6. Catalog evidence\n- Preserve auction-catalog documents as evidence entities linked through `about`.\n\n7. Outcome discipline\n- Do not infer ownership transfer when outcomes indicate no completed sale.\n- Preserve custody/commission/bid context separately when available.\n\n8. Multi-object lots\n- Preserve per-object acquisition granularity even when one payment covers the lot.\n\n### TDD Additions — Auctions\n\nAdd failing-first tests for auction workflows:\n\nContract-level:\n\n- validates auction event and auction-of-lot activity shapes with correct linkage fields\n- validates lot set structures with lot number and classification\n- validates pre-set price monetary dimensions on lot sets\n\nAdapter-level:\n\n- preserves auction-event vs lot-auction vs purchase-provenance boundaries\n- preserves lot membership on member objects via `member_of`\n- preserves lot-level estimated/reserve/starting price metadata without merging into sale price\n- preserves auction catalog modeling as `LinguisticObject` evidence\n\nRoute-level:\n\n- inspect/import outputs preserve auction chain linkage (`part_of`, `used_specific_object`) when present\n- purchase-provenance imports preserve per-object acquisition + payment decomposition for lot sales\n- non-sale scenarios do not fabricate transfer-of-title events\n\nRegression:\n\n- adding auction metadata does not overwrite existing provenance transfer roles\n- multi-lot and multi-object scenarios preserve object-level membership and acquisition details\n\n### Fixture Anchors — Auctions Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Auction event\n- auction `Activity` with timespan, auction-house place, and auction-house organization.\n\n2. Auction of lot\n- lot-auction `Activity` with auction-of-lot classification, `used_specific_object` set, and `part_of` auction event.\n\n3. Lot set + member object\n- lot `Set` with lot-number identifier and object `member_of` link.\n\n4. Pre-set estimated price\n- lot `Set` with `dimension` `MonetaryAmount` classified as estimated price.\n\n5. Purchase of lot\n- provenance `Activity` referencing lot set, with acquisition part(s) plus payment and `part_of` lot-auction.\n\n6. Auction catalog\n- catalog `LinguisticObject` classified as auction catalog and `about` auction event.\n\n7. No-sale outcomes\n- fixtures for withdrawn lot, reserve not met, owner buy-back, and winner unable to pay that preserve uncertainty and avoid false ownership-transfer assertions.\n\n---\n\n## Round 8 Addendum — Changes of Custody\n\nSource section basis:\n\n- Linked Art Model 1.0: Changes of Custody\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Custody transfer is distinct from ownership transfer.\n- Temporary possession changes (loan, return, theft, loss, recovery) are modeled as custody changes, not title changes.\n- Custody uses `TransferOfCustody` (not `Acquisition`) with equivalent role fields:\n  - `transferred_custody_of`\n  - `transferred_custody_from`\n  - `transferred_custody_to`\n- Loan lifecycle is typically modeled as paired custody transfers (outbound + return), potentially open-ended for active long-term loans.\n- Institutional ownership can co-exist with departmental custody:\n  - institution as owner\n  - department as current keeper/custodian\n- Theft/looting are illegal custody transfers; ownership remains unchanged.\n- Lost-object scenarios can omit recipient custodian where unknown.\n- Sale of stolen goods should be modeled as custody transfer + payment, not ownership acquisition.\n\n### Implementation Mapping — Custody\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Ownership/custody separation\n- Do not translate `TransferOfCustody` into `Acquisition` unless evidence explicitly indicates title transfer.\n\n2. Custody role fidelity\n- Preserve custody role edges and allow partial role assertions for unknown recipients.\n\n3. Loan pairing semantics\n- Preserve paired transfer patterns when present without forcing synthetic return events.\n\n4. Departmental custody\n- Preserve departmental custodian context without altering institutional ownership assertions.\n\n5. Theft/loss semantics\n- Preserve theft/loss classifications as custody events and avoid ownership mutations.\n\n6. Stolen-sale handling\n- Preserve custody-transfer + payment decomposition in stolen-sale scenarios.\n\n### TDD Additions — Custody\n\nAdd failing-first tests for custody workflows:\n\nContract-level:\n\n- validates `TransferOfCustody` structures with custody role fields\n- allows omitted `transferred_custody_to` in loss/unknown-recipient scenarios\n- preserves classification for loan/return/theft/sale-of-stolen-goods cases\n\nAdapter-level:\n\n- preserves distinction between `Acquisition` and `TransferOfCustody`\n- preserves departmental custody part in mixed acquisition+custody provenance events\n- preserves stolen-sale pattern as custody transfer plus payment\n\nRoute-level:\n\n- inspect/import outputs preserve custody part structures and role edges\n- routes do not fabricate ownership transfer events from custody-only evidence\n- canonical `_source.raw` retains original custody semantics\n\nRegression:\n\n- ownership summaries remain stable when custody events are added\n- exhibition-related custody chains do not regress into ownership chains\n\n### Fixture Anchors — Custody Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Loan out\n- provenance `Activity` with `TransferOfCustody` classified as loan.\n\n2. Return of loan\n- subsequent `TransferOfCustody` reversing from/to custodians.\n\n3. Mixed acquisition and departmental custody\n- single provenance event with both `Acquisition` and `TransferOfCustody` parts.\n\n4. Theft event\n- `TransferOfCustody` classified as theft.\n\n5. Sale of stolen goods\n- custody transfer classified as stolen-goods sale plus payment part.\n\n---\n\n## Round 9 Addendum — Exhibitions\n\nSource section basis:\n\n- Linked Art Model 1.0: Exhibitions\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Exhibition modeling separates:\n  - exhibition activity (`Activity`) at place/time with organizers\n  - exhibition concept (`PropositionalObject`) representing the abstract idea/theme\n- Exhibition activity:\n  - classify as exhibiting (`aat:300054766`)\n  - include `timespan`, `took_place_at`, `carried_out_by`\n  - link exhibited-object set via `used_specific_object`\n  - link conceptual work via `influenced_by`\n- Exhibition concept:\n  - `PropositionalObject` classified as exhibition (`aat:300417531`)\n  - can include `about` subjects and `created_by` creators\n  - can model known artist influence when specific exhibited objects are unknown\n- Multi-venue exhibitions:\n  - each venue is its own exhibition activity\n  - venue activities may be `part_of` a broader travelling exhibition activity (`aat:300054773`)\n  - top-level travelling activity should not duplicate venue-specific place/org details\n- Exhibition object membership:\n  - represented through exhibition `Set` and object `member_of`\n  - venue-specific sets should be used where object lists differ materially\n- Provenance integration:\n  - exhibition-linked custody transfers can be `part_of` exhibition activity\n  - if owning institution exhibits its own object, movement may apply instead of custody transfer\n\n### Implementation Mapping — Exhibitions\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Activity/concept split\n- Preserve separate records/structures for exhibition activity and exhibition concept.\n\n2. Venue fidelity\n- Preserve per-venue exhibition activities and avoid collapsing multi-venue runs into one venue-level event.\n\n3. Concept linkage\n- Preserve `influenced_by` linkage from exhibition activities to concept records.\n\n4. Object-set linkage\n- Preserve `used_specific_object` set references and object-side `member_of` membership.\n\n5. Artist-known/object-unknown scenario\n- Preserve artist relation on exhibition concept (`about` or concept-creation influence) rather than forcing fake object assertions.\n\n6. Travel hierarchy\n- Preserve `part_of` links to travelling exhibition umbrella activities.\n\n7. Provenance integration\n- Preserve exhibition-related custody provenance and avoid over-converting to ownership change.\n\n### TDD Additions — Exhibitions\n\nAdd failing-first tests for exhibition workflows:\n\nContract-level:\n\n- validates exhibition activity and exhibition concept as distinct entity types\n- validates `used_specific_object` linkage to set and object `member_of` membership pattern\n- validates travelling exhibition classification and `part_of` structure\n\nAdapter-level:\n\n- preserves venue-specific activity details (time/place/organizer) and concept linkage\n- preserves concept-side subject/influence assertions for artist-known/object-unknown data\n- preserves venue-specific object sets when input indicates different object lists by venue\n\nRoute-level:\n\n- inspect/import outputs keep exhibition activity/concept separation intact\n- entity and artwork projections preserve exhibition membership without mutating canonical source\n- provenance endpoints/surfaces preserve exhibition custody links where present\n\nRegression:\n\n- exhibitions do not collapse into generic events without exhibition classification\n- multi-venue hierarchies remain navigable after import/normalization\n\n### Fixture Anchors — Exhibitions Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Single-venue exhibition activity\n- exhibiting `Activity` with timespan/place/organizer, used object set, and concept influence.\n\n2. Exhibition concept\n- `PropositionalObject` classified as exhibition with `about` and `created_by`.\n\n3. Artist-known/object-unknown concept variant\n- concept creation influenced by artist without asserting specific exhibited object list.\n\n4. Multi-venue exhibition\n- venue activity with `part_of` broader travelling exhibition activity.\n\n5. Travelling exhibition umbrella\n- top-level multi-location activity with broader timespan and concept influence.\n\n6. Exhibition object set + member object\n- exhibition `Set` plus `HumanMadeObject` with `member_of`.\n\n7. Exhibition custody provenance linkage\n- custody transfer provenance entries linked `part_of` exhibition activity when applicable.\n\n---\n\n## Round 10 Addendum — Encounters with Objects\n\nSource section basis:\n\n- Linked Art Model 1.0: Encounters with Objects\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Encounter events model rediscovery/find scenarios in provenance chains, especially where objects re-enter documented knowledge long after production.\n- An object may have multiple encounters over time (encountered, lost, rediscovered).\n- Encounter is modeled as `Encounter` activity part within a provenance wrapper `Activity`.\n- `Encounter` has dedicated object linkage via `encountered` to distinguish found object(s) from other objects used in related activities.\n- Encounter actors are linked via `carried_out_by` on the encounter activity.\n- Ownership/custody consequences are not implicit:\n  - ownership transfer should be modeled explicitly (for example, adjacent `Acquisition` part)\n  - custody-only outcomes should remain custody semantics\n- Encounter can be modeled directly in object descriptions in simpler scenarios, even without full ownership transfer logic.\n\n### Implementation Mapping — Encounters\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Encounter activity preservation\n- Preserve `Encounter` as an explicit activity type; do not flatten into narrative notes.\n\n2. Dedicated encountered linkage\n- Preserve `encountered` object relations distinctly from `used_specific_object` or transfer-role fields.\n\n3. Actor/event integrity\n- Preserve encounter actors in `carried_out_by` and keep encounter-specific metadata on the encounter part.\n\n4. Ownership/custody explicitness\n- Do not infer title transfer from encounter alone.\n- Preserve explicit ownership (`Acquisition`) or custody (`TransferOfCustody`) parts when present in the same provenance event.\n\n5. Multi-encounter support\n- Support repeated encounters in chains without overwriting prior encounter history.\n\n6. Archaeological uncertainty guardrail\n- Preserve partial/uncertain encounter context without inventing missing chronology or legal outcomes.\n\n### TDD Additions — Encounters\n\nAdd failing-first tests for encounter workflows:\n\nContract-level:\n\n- validates `Encounter` parts with `encountered` linkage and optional `carried_out_by`\n- rejects malformed encounter object references\n- permits encounter events with or without adjacent acquisition/custody parts\n\nAdapter-level:\n\n- preserves encounter parts in normalized provenance chains\n- preserves combined encounter + acquisition pattern when source indicates ownership transfer on discovery\n- preserves encounter-only cases without fabricating ownership changes\n\nRoute-level:\n\n- inspect/import outputs preserve encounter activity structure and object references\n- route responses maintain explicit distinction between encounter, acquisition, and custody parts\n- canonical `_source.raw` encounter content remains unmutated\n\nRegression:\n\n- existing acquisition/custody logic remains stable when encounter parts are introduced\n- multi-encounter histories do not collapse into a single event\n\n### Fixture Anchors — Encounters Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Encounter with ownership transfer\n- wrapper provenance `Activity` containing:\n  - `Encounter` part (`carried_out_by` + `encountered`)\n  - `Acquisition` part transferring title to discoverer entity.\n\n2. Encounter without explicit ownership transfer\n- encounter part present, no acquisition part; tests assert no inferred title transfer.\n\n3. Encounter chain continuity\n- multiple encounter events across time with distinct IDs and preserved ordering/links.\n\n---\n\n## Round 11 Addendum — Location and Movement\n\nSource section basis:\n\n- Linked Art Model 1.0: Location and Movement\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Object location is, in principle, derivable from movement history; many CH systems only track selected movement events.\n- Movement tracking is especially useful for:\n  - display/storage transitions\n  - exhibition display where ownership/custody might not change\n  - moves between facilities (storage, conservation, galleries)\n  - scenarios coupled with departmental custody transfer\n- Movement is modeled with `Move` activity parts within provenance/event wrappers.\n- `Move` captures:\n  - `moved` (object)\n  - `moved_from` (origin place)\n  - `moved_to` (destination place)\n- Movement is semantically separate from ownership (`Acquisition`) and custody (`TransferOfCustody`), though they may co-occur in the same broader event chain.\n\n### Implementation Mapping — Movement\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Movement activity preservation\n- Preserve `Move` as explicit activity structure; do not collapse to plain location strings.\n\n2. Origin/destination integrity\n- Preserve both `moved_from` and `moved_to` place nodes when known.\n\n3. Movement/object linkage\n- Preserve `moved` object references distinctly from ownership/custody role edges.\n\n4. Co-occurring event separation\n- When movement and custody changes co-occur, preserve each as separate parts in the same wrapper activity/event chain.\n\n5. Display/exhibition movement support\n- Preserve movement-only exhibition/display scenarios without forcing ownership or custody transfer.\n\n6. Current-location inference guardrail\n- Do not overwrite canonical history with inferred present location; keep derived views separate from source event history.\n\n### TDD Additions — Movement\n\nAdd failing-first tests for movement workflows:\n\nContract-level:\n\n- validates `Move` parts with `moved`, `moved_from`, and `moved_to` structures\n- rejects malformed place/object references in movement parts\n- allows movement events without acquisition/custody parts\n\nAdapter-level:\n\n- preserves movement events as structured `Move` parts during normalization\n- preserves co-occurring movement + custody structures without semantic merging\n- preserves movement-only exhibition/internal-transfer scenarios\n\nRoute-level:\n\n- inspect/import outputs retain movement part structure and place references\n- routes do not synthesize ownership changes from movement-only evidence\n- canonical `_source.raw` movement history remains unmutated\n\nRegression:\n\n- existing ownership/custody summaries remain stable when movement events are added\n- derived location views do not erase historical movement events\n\n### Fixture Anchors — Movement Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Routine move between two galleries\n- wrapper provenance `Activity` with one `Move` part:\n  - `moved` object\n  - `moved_from` place\n  - `moved_to` place\n\n2. Movement with departmental handoff\n- event chain where movement and custody transfer are both present as separate parts.\n\n3. Exhibition-owned-object move\n- movement event for institution-owned object used in exhibition context without custody transfer.\n\n---\n\n## Round 12 Addendum — Promised Activities\n\nSource section basis:\n\n- Linked Art Model 1.0: Promised Activities\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Promises model planned future actions (gift, sale, exchange, commission-related obligations) that may precede final ownership transfer.\n- Promise uses activity classification with the required vocabulary term:\n  - Promise (`aat:300435599`)\n- Current model does not fully model the future planned event object directly; promise context is expressed via:\n  - `participant` (promised party/counterparty)\n  - `used_specific_object` (promised object when known)\n  - descriptive note (`referred_to_by`) for contract/terms details\n- Promised gift pattern:\n  - promise activity carried out by promisor\n  - participant references intended recipient\n  - object referenced via `used_specific_object`\n- Commissioning pattern can include paired promises:\n  - commissioner promise to pay\n  - artist promise to produce\n- Later production, title transfer, and payment settlement remain separate lifecycle/provenance events using their standard patterns.\n\n### Implementation Mapping — Promises\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Promise classification integrity\n- Preserve promise activities as `Activity` parts classified as `Promise` (`aat:300435599`).\n\n2. Obligation context preservation\n- Preserve promisor (`carried_out_by`), participant/counterparty, and promised object links where present.\n\n3. Contract/terms evidence\n- Preserve descriptive statements on promise activities for legal/contractual context.\n\n4. Future-event separation\n- Do not collapse promises into completed acquisitions/payments/productions.\n- Keep promise events separate from eventual fulfillment events.\n\n5. Commission pair modeling\n- Preserve dual-obligation structures in commission scenarios when both sides are known.\n\n6. Unfulfilled/open promise support\n- Preserve open promise state without fabricating completion events.\n\n### TDD Additions — Promised Activities\n\nAdd failing-first tests for promised-activity workflows:\n\nContract-level:\n\n- validates promise activity parts with required promise classification\n- validates optional `participant`, `used_specific_object`, and descriptive note structures\n- rejects malformed promise activity payloads and role/link fields\n\nAdapter-level:\n\n- preserves promised-gift pattern (promisor + object + recipient) without converting to acquisition\n- preserves commissioning paired promises (pay obligation + produce obligation) as separate parts\n- preserves commission/provenance classifications when present\n\nRoute-level:\n\n- inspect/import outputs retain promise activity parts and contract-note descriptions\n- routes do not synthesize title transfer or payment completion from promise-only evidence\n- canonical `_source.raw` promise structures remain unmutated\n\nRegression:\n\n- existing acquisition/payment/production chains remain stable when promise events are introduced\n- later fulfillment events can co-exist without overwriting original promise records\n\n### Fixture Anchors — Promised Activities Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Promised gift\n- wrapper provenance `Activity` containing promise-classified part with:\n  - promisor (`carried_out_by`)\n  - promised object (`used_specific_object`)\n  - recipient (`participant`)\n  - descriptive note for promise context\n\n2. Commissioning pair\n- wrapper provenance `Activity` classified as commissioning with two promise parts:\n  - obligation to pay artist\n  - obligation to produce artwork\n\n3. Promise without fulfillment\n- promise record with no immediate acquisition/payment/production part; tests assert no inferred completion.\n\n---\n\n## Round 13 Addendum — Transfer of Rights\n\nSource section basis:\n\n- Linked Art Model 1.0: Transfer of Rights\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Some provenance scenarios require explicit modeling of rights rather than only title-transfer shorthand.\n- `Acquisition` is concise for standard ownership transfer, but explicit `Right` modeling is needed for complex right states (partial shares, IP rights, etc.).\n- Rights are conceptual entities with key properties:\n  - `possessed_by` (holder)\n  - `applies_to` (thing the right concerns)\n- Rights transitions are modeled with `RightAcquisition` activity parts using:\n  - `establishes` (newly established right instances)\n  - `invalidates` (rights superseded/terminated by the change)\n- It is valid (but often redundant) to include both `Acquisition` and `RightAcquisition` in the same provenance entry.\n- Shared ownership with uneven stakes:\n  - partition ownership right into component rights (`part`)\n  - represent proportions using `Dimension` with percent unit\n- Subsequent share transfers should model the new resulting state directly (establish new rights, invalidate prior rights).\n- Intellectual property and other non-physical rights can be modeled with the same `RightAcquisition` pattern.\n\n### Implementation Mapping — Rights\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Right model activation\n- Use explicit `Right` + `RightAcquisition` when acquisition shorthand would lose legal/state detail.\n\n2. Right-holder/object linkage\n- Preserve `possessed_by` and `applies_to` links for every explicit right record.\n\n3. State-transition integrity\n- Preserve `establishes`/`invalidates` pairs as explicit state transitions, not implicit deltas.\n\n4. Share partitioning\n- Preserve ownership-share partitions as child rights with quantitative dimensions.\n\n5. Result-state modeling\n- For share trades, represent the post-transaction right state explicitly; do not rely on inferred arithmetic-only deltas.\n\n6. Acquisition coexistence\n- Where both acquisition and right transitions are present, preserve both without forcing deduplication.\n\n7. IP-right support\n- Preserve copyright/performance/right-type classifications independent of physical carrier transfers.\n\n### TDD Additions — Rights\n\nAdd failing-first tests for rights workflows:\n\nContract-level:\n\n- validates `Right` structures with `possessed_by` and `applies_to`\n- validates `RightAcquisition` with `establishes` and optional `invalidates`\n- validates share dimensions and measurement units for partitioned ownership rights\n\nAdapter-level:\n\n- preserves explicit rights transitions when source includes complex ownership/legal data\n- preserves partitioned ownership rights and per-holder percentages\n- preserves invalidation of superseded rights in share-transfer scenarios\n- preserves IP-right acquisitions without conflating with physical ownership transfer\n\nRoute-level:\n\n- inspect/import outputs retain `RightAcquisition` transitions and right partitions\n- routes do not collapse explicit rights models into flat acquisition-only summaries\n- canonical `_source.raw` rights structures remain unchanged by DTO projections\n\nRegression:\n\n- simple acquisition paths remain stable and concise where explicit rights are unnecessary\n- mixed records (acquisition + rights + payments) maintain cross-part consistency\n\n### Fixture Anchors — Rights Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Basic right establishment alongside acquisition\n- provenance wrapper with `Acquisition` plus `RightAcquisition.establishes` ownership right.\n\n2. Uneven shared ownership\n- total ownership right partitioned into component rights with percent dimensions per holder.\n\n3. Share transfer between existing owners\n- rights transition where new shares are established and prior shares invalidated.\n\n4. Intellectual property right acquisition\n- `RightAcquisition` establishing copyright-like right held by organization and applied to artwork.\n\n---\n\n## Round 14 Addendum — Unknown Transfers\n\nSource section basis:\n\n- Linked Art Model 1.0: Unknown Transfers\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Historical evidence can be insufficient to determine whether a transfer was ownership, custody, loan, or another mechanism.\n- To avoid false precision, model ambiguous exchanges with `Transfer` rather than forcing `Acquisition`, `TransferOfCustody`, or right-transfer semantics.\n- `Transfer` has dedicated role properties:\n  - `transferred` (object(s))\n  - `transferred_from` (source actor(s))\n  - `transferred_to` (destination actor(s))\n- This mirrors other transfer-like activity parts while preserving indeterminacy.\n\n### Implementation Mapping — Unknown Transfers\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Uncertainty-first modeling\n- Use `Transfer` when source evidence is ambiguous about legal/physical semantics.\n\n2. No forced disambiguation\n- Do not auto-convert ambiguous transfers to acquisition, custody, move, or rights transfer.\n\n3. Role fidelity\n- Preserve `transferred`, `transferred_from`, and `transferred_to` structures as provided.\n\n4. Future refinement safety\n- Allow later evidence to supersede/augment ambiguous transfer entries without destructive rewrites.\n\n5. Provenance-chain continuity\n- Keep unknown transfers in chronology so event ordering remains intact even when semantics are partial.\n\n### TDD Additions — Unknown Transfers\n\nAdd failing-first tests for unknown-transfer workflows:\n\nContract-level:\n\n- validates `Transfer` parts with `transferred`, `transferred_from`, `transferred_to`\n- rejects malformed transfer role structures\n- supports transfer entries with sparse contextual metadata when evidence is limited\n\nAdapter-level:\n\n- preserves ambiguous source records as `Transfer` instead of over-classifying\n- preserves actor/object role edges without semantic coercion\n\nRoute-level:\n\n- inspect/import outputs retain `Transfer` part type and fields unchanged\n- routes do not fabricate ownership/custody outcomes from ambiguous transfer records\n- canonical `_source.raw` uncertainty semantics remain unmutated\n\nRegression:\n\n- known acquisition/custody/move workflows remain unaffected when `Transfer` parts are introduced\n- future enrichment paths can add precise events without deleting prior uncertain records\n\n### Fixture Anchors — Unknown Transfers Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Ambiguous person-to-person transfer\n- wrapper provenance `Activity` with one `Transfer` part:\n  - `transferred` object\n  - `transferred_from` person/group\n  - `transferred_to` person/group\n- no assertion of ownership, custody, or permanence.\n\n---\n\n## Round 15 Addendum — Conservation\n\nSource section basis:\n\n- Linked Art Model 1.0: Conservation\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Conservation modeling includes:\n  - condition assessment (state/damage identification)\n  - conservation intervention activities (physical modifications)\n  - conservation projects as wrapper activities\n- Condition assessment pattern:\n  - represented via `AttributeAssignment` on the object (`attributed_by`)\n  - uses `assigned_property` (for example `classified_as`) and `assigned` condition types\n  - can include description, timespan, actor, and `part_of` project linkage\n- Conservation intervention pattern:\n  - represented via `Modification` on object (`modified_by`)\n  - can include technique, description, timespan, actor, and `part_of` project linkage\n- Conservation project pattern:\n  - top-level wrapper `Activity` with conservation classification\n  - regular activity metadata (name, description, timespan, actors) describing overall context\n- Conservation links to other model areas:\n  - statements for object state and conservation context\n  - sampling/production-by-removal patterns in object production sections\n\n### Implementation Mapping — Conservation\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Assessment/intervention separation\n- Preserve condition assessments (`AttributeAssignment`) separately from intervention work (`Modification`).\n\n2. Assignment semantics\n- Preserve `assigned_property` and `assigned` condition types without collapsing into plain narrative text.\n\n3. Intervention detail preservation\n- Preserve `technique`, actor, timespan, and descriptions on modification activities.\n\n4. Project wrapper integrity\n- Preserve conservation project wrapper `Activity` and `part_of` links from assessments/modifications.\n\n5. Multi-object project support\n- Allow one project to contextualize many object-level assessments/modifications without duplicating project metadata per object.\n\n6. No provenance-role coercion\n- Do not coerce conservation activities into ownership/custody transfer semantics.\n\n### TDD Additions — Conservation\n\nAdd failing-first tests for conservation workflows:\n\nContract-level:\n\n- validates object-level `attributed_by` condition-assessment structures\n- validates object-level `modified_by` conservation-modification structures\n- validates project-level conservation activity structures and classification\n\nAdapter-level:\n\n- preserves condition assignment structure (`assigned_property`, `assigned`) during normalization\n- preserves modification technique + temporal/actor metadata\n- preserves `part_of` links tying granular events to conservation project wrapper\n\nRoute-level:\n\n- inspect/import outputs retain conservation assessment and modification structures without flattening\n- routes preserve project wrappers and links across object and event views\n- canonical `_source.raw` conservation data remains unmutated\n\nRegression:\n\n- conservation metadata does not overwrite core classification/title fields\n- adding project context does not remove object-level condition/intervention details\n\n### Fixture Anchors — Conservation Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Condition assessment on object\n- `HumanMadeObject` with `attributed_by` `AttributeAssignment`:\n  - condition assignment via `assigned_property` + `assigned`\n  - description/timespan/actor\n  - `part_of` conservation project\n\n2. Conservation intervention on object\n- `HumanMadeObject` with `modified_by` `Modification`:\n  - conservation description\n  - technique classification\n  - timespan/actor\n  - `part_of` conservation project\n\n3. Conservation project wrapper\n- conservation `Activity` with name/description/timespan and multiple actors.\n\n---\n\n## Round 16 Addendum — People and Organizations\n\nSource section basis:\n\n- Linked Art Model 1.0: People and Organizations\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Actors in Linked Art are modeled as:\n  - `Person` (human individual)\n  - `Group` (collective of humans, including organizations and other defined sets)\n- If actor type is uncertain between person/group, `Group` is the safer default.\n- Core actor modeling goals are disambiguation and historical role clarity, not exhaustive biography/social-graph capture.\n- Identity and equivalence patterns:\n  - names via `identified_by` (`Name`, optionally partitioned into typed parts)\n  - external alignment via `equivalent`\n- Contact and residence:\n  - contact details via `contact_point` (`Identifier`-based, not `Name`)\n  - place-based residence via `residence` (`Place`)\n- Actor lifecycle and activity context:\n  - person events: `born`, `died`\n  - group events: `formed_by`, `dissolved_by`\n  - active professional period via embedded `carried_out` activity classified as professional activities\n  - participation-only events via `participated_in` when actor is participant, not responsible agent\n- Classification patterns for actor descriptors:\n  - nationality as typed classification\n  - ethnicity/culture as typed classification\n  - gender as typed classification\n  - occupation as typed classification\n- Organizational membership:\n  - member relation asserted via `member_of` from member person/group to parent group.\n\n### Implementation Mapping — People/Organizations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Actor-type discipline\n- Preserve `Person` vs `Group` distinctions; use `Group` fallback for ambiguous actor references.\n\n2. Name modeling depth\n- Preserve primary names and typed name parts when available; do not flatten multi-part names into a single untyped label only.\n\n3. External reconciliation safety\n- Preserve `equivalent` links to authority records without collapsing local record identity.\n\n4. Contact/residence separation\n- Keep `contact_point` identifier semantics separate from `residence` place semantics.\n\n5. Lifecycle event correctness\n- Preserve birth/death for persons and formation/dissolution for groups with event/timespan/place context.\n\n6. Responsibility vs participation\n- Preserve distinction between activities the actor carried out (`carried_out`) and events they participated in (`participated_in`).\n\n7. Descriptor classifications\n- Preserve meta-classified actor descriptors (nationality, ethnicity, gender, occupation) without coercing them into group membership constructs.\n\n8. Membership directionality\n- Preserve `member_of` from member records; do not require synthetic inverse membership arrays in canonical records.\n\n### TDD Additions — People/Organizations\n\nAdd failing-first tests for actor workflows:\n\nContract-level:\n\n- validates `Person`/`Group` identity structures with names/classifications\n- validates lifecycle event structures (`born`/`died`, `formed_by`/`dissolved_by`)\n- validates `contact_point`, `residence`, and `equivalent` structures\n\nAdapter-level:\n\n- preserves typed name parts and actor descriptor classifications\n- preserves actor activity distinctions (`carried_out` vs `participated_in`)\n- preserves uncertain actor references as `Group` when person/group ambiguity is unresolved\n\nRoute-level:\n\n- inspect/import outputs retain actor identity, descriptor, and lifecycle event structures\n- entity profile projections preserve membership and descriptor metadata without mutating `_source.raw`\n- routes do not convert contact identifiers into name statements or place records incorrectly\n\nRegression:\n\n- actor enrichment does not break provenance role links (`carried_out_by`, transfer parties, etc.)\n- external-equivalent reconciliation does not overwrite local actor IDs\n\n### Fixture Anchors — People/Organizations Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Person as group member\n- `Person` with `member_of` `Group`.\n\n2. Primary and partitioned names\n- primary name with typed parts (given/middle/family).\n\n3. External equivalent alignment\n- actor with `equivalent` link to authority URI.\n\n4. Contact and residence\n- actor with multiple `contact_point` identifiers and separate `residence` place.\n\n5. Lifecycle events\n- person birth/death and group formation examples.\n\n6. Active professional period\n- `carried_out` activity classified as professional activities with timespan.\n\n7. Participation event\n- `participated_in` burial-style activity with time/place.\n\n8. Descriptor classifications\n- nationality, ethnicity, gender, and occupation typed classifications.\n\n---\n\n## Round 17 Addendum — Places\n\nSource section basis:\n\n- Linked Art Model 1.0: Places\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- `Place` is foundational for activity location, object location context, and actor residence/association.\n- Places are spatial extents independent of time and independent of what currently occupies that space.\n- Place model supports:\n  - core identity metadata (names, identifiers, statements, classifications, equivalents)\n  - spatial hierarchy via `part_of`\n  - geospatial geometry via `defined_by` (WKT string)\n- Geospatial data can range from detailed polygons to approximations/bounding proxies.\n- Approximate location can be represented as a more specific place `part_of` a broader known place.\n- Buildings and other \"immovable\" works remain `HumanMadeObject` records with location references; activities occur at `Place`, not at the object itself.\n\n### Implementation Mapping — Places\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Place identity preservation\n- Preserve place core metadata and classifications without collapsing into plain location strings.\n\n2. Hierarchy integrity\n- Preserve `part_of` place hierarchy links to support spatial navigation and context.\n\n3. Geometry fidelity\n- Preserve `defined_by` WKT geometry exactly when supplied.\n\n4. Approximation semantics\n- Preserve approximate/specific place modeling via `part_of` rather than forcing uncertain coordinates.\n\n5. Place vs object separation\n- Keep built works as objects (`HumanMadeObject`) and their spatial context as `Place`.\n\n6. Activity location discipline\n- Preserve event/activity location references as `Place` nodes, not building objects.\n\n7. Immovable-object handling\n- Support large/fixed-seeming works as movable-or-locatable objects with `current_location` place references when modeled that way.\n\n### TDD Additions — Places\n\nAdd failing-first tests for place workflows:\n\nContract-level:\n\n- validates `Place` entities with core identity metadata and classifications\n- validates `defined_by` string preservation for WKT geometry values\n- validates hierarchical `part_of` place references\n\nAdapter-level:\n\n- preserves place hierarchy and descriptive statements during normalization\n- preserves WKT geometry and does not coerce it to unsupported formats\n- preserves approximation patterns (specific place within broader place)\n\nRoute-level:\n\n- inspect/import outputs retain place hierarchy and geometry fields\n- routes do not convert place references into object references for activity locations\n- canonical `_source.raw` place data remains unmutated\n\nRegression:\n\n- immovable-object records remain objects with place references rather than being converted into place entities\n- map-oriented fields remain stable across provider imports\n\n### Fixture Anchors — Places Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Place with hierarchy and description\n- city `Place` with classification, name/description, and `part_of` nation.\n\n2. Place with WKT geometry\n- nation `Place` with polygon in `defined_by`.\n\n3. Approximate sub-location\n- specific location place with `part_of` broader city place.\n\n4. Building as object + place location\n- building `HumanMadeObject` classified as building with `current_location` place.\n\n---\n\n## Round 18 Addendum — Concepts\n\nSource section basis:\n\n- Linked Art Model 1.0: Concepts\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Concepts represent units of thought used for classification and semantic alignment.\n- Linked Art typically reuses external vocabularies (especially AAT), with local concept records allowed when needed.\n- Core concept classes:\n  - `Type` (general concept class)\n  - `Currency`\n  - `Language`\n  - `Material`\n  - `MeasurementUnit`\n- Class specificity should be preserved where known (do not default everything to generic `Type` unnecessarily).\n- `equivalent` links are critical for interoperability when local concept records mirror or extend external concepts.\n- Concept relationships have distinct semantics:\n  - `broader` for hierarchical/generalization relationships\n  - `classified_as` for meta-type/category relationships\n  - `member_of` for concept-scheme/set grouping (orthogonal to hierarchy and meta-typing)\n- Coordinated concepts involving non-concept entities are modeled via `created_by.influenced_by` (for example, concept + place).\n- Model is aligned with SKOS patterns; concept schemes map well to `Set`.\n\n### Implementation Mapping — Concepts\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Concept class fidelity\n- Preserve specific concept subclasses (`Currency`, `Language`, `Material`, `MeasurementUnit`) when present.\n\n2. Interoperability equivalence\n- Preserve `equivalent` links on local concept records and concept references to maintain cross-system semantics.\n\n3. Hierarchy vs meta-type distinction\n- Preserve `broader` and `classified_as` as distinct relations; do not conflate them.\n\n4. Scheme/set grouping\n- Preserve `member_of` concept scheme/set links independently of hierarchy and classification.\n\n5. Coordinated concept creation\n- Preserve `created_by.influenced_by` links for concept coordination involving non-concept entities.\n\n6. Local concept safety\n- Allow local concept records to carry additional metadata while keeping explicit external equivalence anchors.\n\n7. SKOS compatibility guardrail\n- Keep concept structures transform-friendly for SKOS-style mappings (labels/notes/broader/scheme).\n\n### TDD Additions — Concepts\n\nAdd failing-first tests for concept workflows:\n\nContract-level:\n\n- validates concept class records (`Type` and specialized subclasses) with core identity metadata\n- validates `equivalent`, `broader`, `classified_as`, and `member_of` structures\n- rejects malformed concept hierarchy and equivalence payloads\n\nAdapter-level:\n\n- preserves local concept records with external equivalence links\n- preserves distinction between broader hierarchy and meta-type classification\n- preserves concept-scheme memberships without rewriting as hierarchy links\n- preserves coordinated concept influences including non-concept entities\n\nRoute-level:\n\n- inspect/import outputs retain concept class/relationship semantics\n- routes do not collapse concept links to plain labels only\n- canonical `_source.raw` concept structures remain unmutated by DTO projection\n\nRegression:\n\n- object/person/place classification references remain stable when concept records are normalized locally\n- concept enrichments do not break rights/material/language/unit references across records\n\n### Fixture Anchors — Concepts Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Minimal concept record\n- basic `Type` concept with ID and label.\n\n2. Local concept with external equivalent\n- local concept primary name plus `equivalent` AAT concept.\n\n3. Concept reference with embedded equivalent\n- object classification referencing local concept with explicit external equivalent.\n\n4. Broader + meta-type distinction\n- concept with both `broader` and `classified_as` relationships.\n\n5. Concept scheme membership\n- concept `member_of` concept-scheme `Set`.\n\n6. Coordinated concept creation influence\n- concept `created_by.influenced_by` including both concept and place entities.\n\n---\n\n## Round 19 Addendum — Events\n\nSource section basis:\n\n- Linked Art Model 1.0: Events\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Temporal entities include:\n  - `Period` (time span construct, often conventionally bounded)\n  - `Event` (occurrence that changes state, not necessarily intentional)\n  - `Activity` (intentional human-carried occurrence)\n- These temporal records are often contextual entities separate from specific object lifecycle/provenance/exhibition models.\n- Causality:\n  - events/activities can reference preceding causes via `caused_by`\n  - causal events should be first-class records when shared across objects/works/events\n- Event relationship semantics must remain distinct:\n  - `part_of`: strict partition hierarchy\n  - `during`: inclusion/context without partition semantics\n- Relative ordering for uncertain chronology:\n  - `before`\n  - `after`\n- Relative ordering is especially useful where absolute dates are unknown but sequence is known.\n\n### Implementation Mapping — Events\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Temporal class fidelity\n- Preserve `Period`/`Event`/`Activity` distinctions without collapsing to generic activity types.\n\n2. Causal-link preservation\n- Preserve `caused_by` links as explicit references to causal entities.\n\n3. Partition vs inclusion discipline\n- Preserve `part_of` and `during` with their distinct semantics; do not interchange automatically.\n\n4. Relative chronology support\n- Preserve `before`/`after` relations for uncertain or partially ordered timelines.\n\n5. Shared-context entity reuse\n- Reuse canonical event IDs in references so multiple records can point to the same contextual event.\n\n6. Temporal metadata integrity\n- Preserve timespan and place metadata on temporal entities without flattening to display-only labels.\n\n### TDD Additions — Events\n\nAdd failing-first tests for event workflows:\n\nContract-level:\n\n- validates `Period`, `Event`, and `Activity` structures with core identity/timespan fields\n- validates `caused_by`, `part_of`, `during`, `before`, and `after` relationship structures\n- rejects malformed temporal relation payloads\n\nAdapter-level:\n\n- preserves causal chains without role inversion\n- preserves `part_of` vs `during` distinction in normalized timelines\n- preserves relative ordering fields when no absolute timespan exists\n\nRoute-level:\n\n- inspect/import outputs retain temporal class and relation semantics\n- routes do not fabricate exact dates from relative ordering alone\n- canonical `_source.raw` temporal relationships remain unmutated\n\nRegression:\n\n- provenance/exhibition timelines remain stable with added contextual period/event references\n- causal event references remain reusable across multiple object/activity records\n\n### Fixture Anchors — Events Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Period with bounded timespan\n- period record (for example, century) with explicit begin/end bounds.\n\n2. Causal event chain\n- event record (for example, eruption) referenced as `caused_by` from a destruction/lifecycle event.\n\n3. `part_of` hierarchy\n- sub-period/activity linked to a broader parent period/activity via `part_of`.\n\n4. `during` inclusion\n- event/activity linked as occurring `during` a period.\n\n5. Relative ordering without exact date\n- production or activity with `before`/`after` relation to another event.\n\n---\n\n## Round 20 Addendum — About Vocabulary Terms\n\nSource section basis:\n\n- Linked Art Model 1.0: About Vocabulary Terms\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Linked Art relies on vocabulary reuse for semantic interoperability across broad classes.\n- Class-level interoperability alone is insufficient; classification-term interoperability is required for comparable analytics and UX.\n- Vocabulary requirement classes:\n  - required terms: mandatory for Linked Art conformance\n  - recommended terms: expected unless a concrete reason prevents use\n  - optional terms: available but not compulsory\n- Acceptable vocabulary-linking patterns for conformance:\n  - direct vocabulary URI in `id`\n  - local/intermediary concept in `id` with external vocabulary URI in `equivalent`\n- Vocabulary list change policy:\n  - required list: changed/removed only in major versions; additions may arrive in minor versions\n  - recommended list: may change in minor versions\n  - optional list: informational, can change anytime\n\n### Implementation Mapping — Vocabulary Terms\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Requirement-class awareness\n- Treat required terms as conformance-critical in validation and import checks.\n\n2. Stable mapping strategy\n- Support both direct-`id` and `equivalent`-bridged vocabulary linking without semantic loss.\n\n3. Local concept interoperability\n- When local concepts are used, preserve explicit `equivalent` links to canonical external terms.\n\n4. Non-destructive normalization\n- Do not rewrite local concept IDs to external IDs if local records carry additional context; preserve both layers.\n\n5. Version-aware validation\n- Design validators to handle evolving recommended/optional lists without breaking prior data unnecessarily.\n\n6. Classifier consistency\n- Preserve `classified_as` arrays in source order and content; avoid silent dropping of unknown-yet-valid terms.\n\n### TDD Additions — Vocabulary Terms\n\nAdd failing-first tests for vocabulary conformance workflows:\n\nContract-level:\n\n- validates required-term usage for constrained fields where Linked Art mandates specific terms\n- validates `classified_as` references with direct vocabulary URIs\n- validates local term records with `equivalent` references to canonical vocab terms\n\nAdapter-level:\n\n- preserves both vocabulary-link patterns (`id` direct vs `equivalent` bridge)\n- preserves local concept metadata while retaining external semantic anchors\n- does not downgrade required/recommended classification references during normalization\n\nRoute-level:\n\n- inspect/import outputs retain vocabulary semantics and do not collapse intermediary concepts\n- validation responses clearly distinguish required-term failures from recommended-term advisories\n- canonical `_source.raw` vocabulary links remain unchanged\n\nRegression:\n\n- introducing new recommended terms does not break existing records that remain conformant\n- analytics/classification faceting still resolves equivalent-linked local concepts correctly\n\n### Fixture Anchors — Vocabulary Terms Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Direct vocabulary ID usage\n- object classification where `classified_as[].id` is canonical external vocabulary URI.\n\n2. Local term with equivalent mapping\n- object classification where local concept `id` includes `equivalent` to canonical external vocabulary URI.\n\n3. Mixed dataset compatibility\n- dataset fixtures containing both patterns; tests assert consistent downstream classification behavior.\n\n---\n\n## Round 21 Addendum — Required Terms\n\nSource section basis:\n\n- Linked Art Model 1.0: Required Terms\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Required terms are conformance-critical: when the concept is present, the required URI must be used.\n- Not every record must contain every required term; requirement applies when the modeled concept exists.\n- Full URI form must be used in data payloads.\n- Required term coverage includes:\n  - Name/identifier control terms (primary name, display name, sort name, sort value)\n  - Meta-type control terms (statement, type of work, style, shape, occupation, nationality)\n  - Color classification on `Dimension`\n  - Activity flags (exhibition, provenance, professional, publication, promise)\n  - Broad item flags (collection item, artwork)\n- Required term link style can be either:\n  - direct vocabulary URI in `id`\n  - intermediary/local term with canonical URI in `equivalent`\n- Term-list version policy differs by requirement class; required list is stricter and changes more conservatively.\n\n### Implementation Mapping — Required Terms\n\nApply these requirements to adapters, normalization, validation, and route outputs:\n\n1. Required-term enforcement\n- Validate required URI usage whenever corresponding concepts are asserted in records.\n\n2. URI canonicalization policy\n- Preserve full canonical URIs in stored/served data; avoid namespace shorthand in canonical JSON-LD payloads.\n\n3. Equivalent-bridge acceptance\n- Accept intermediary/local term IDs when canonical required term appears in `equivalent`.\n\n4. Name term semantics\n- Preserve:\n  - primary names for core display identity\n  - display names for UI labeling\n  - sort name/sort value for ordering logic\n- Enforce uniqueness constraints where modeled (for example, one sort value per entity).\n\n5. Meta-type correctness\n- Preserve meta-type classifications that disambiguate statement/type-of-work/style/shape/nationality/occupation semantics.\n\n6. Activity flag correctness\n- Preserve required activity classifications for exhibition/provenance/professional/publication/promise contexts.\n\n7. Color-dimension rule\n- Preserve required color classification on `Dimension` when color is modeled.\n\n8. Item-flag preservation\n- Preserve collection-item/artwork flags where explicitly present; do not infer silently without evidence.\n\n### TDD Additions — Required Terms\n\nAdd failing-first tests for required-term conformance workflows:\n\nContract-level:\n\n- validates required term URIs on:\n  - primary/display/sort names and sort identifiers\n  - required activity classifications\n  - required meta-type classifications\n  - color dimensions and collection/artwork flags when present\n- validates intermediary+equivalent pattern as conformant alternative to direct URI IDs\n\nAdapter-level:\n\n- preserves required-term classifications through normalization\n- preserves sort-name/sort-value semantics and cardinality expectations\n- does not remap required terms to non-canonical alternatives\n\nRoute-level:\n\n- inspect/import validation distinguishes:\n  - required-term failures (hard errors)\n  - recommended/optional advisories (non-blocking)\n- outputs retain required-term URIs and equivalent bridges unchanged\n- canonical `_source.raw` is not rewritten destructively during term normalization\n\nRegression:\n\n- evolving recommended/optional term lists do not break required-term validations\n- faceting/search keyed on required terms remains stable across providers\n\n### Fixture Anchors — Required Terms Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Primary name + language\n- entity with `Name` classified as primary name and language notation.\n\n2. Display name on statement/timespan\n- display-name classification used as UI label for statement or timespan.\n\n3. Sort name and sort value\n- separate fixtures for linguistic sort name and non-linguistic sort value.\n\n4. Meta-type disambiguation\n- statement/type-of-work/style/shape/nationality/occupation classifications.\n\n5. Color dimension\n- `Dimension` with required color classification and optional numeric/unit payload.\n\n6. Activity flags\n- exhibition/provenance/publication/professional/promise activity classifications.\n\n7. Collection and artwork flags\n- object-level required flags for collection-item/artwork categorization.\n\n8. Equivalent-bridge conformance\n- intermediary local term with canonical required URI in `equivalent`.\n\n---\n\n## Round 22 Addendum — Recommended Terms\n\nSource section basis:\n\n- Linked Art Model 1.0: Recommended Terms\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Recommended terms are strongly advised for interoperability but are not strict conformance blockers.\n- Diverging from recommended terms remains valid Linked Art, but should be deliberate and documented.\n- Recommended term clusters include:\n  - name types (alternate/given/middle/family/former)\n  - identifier types (accession/local/system/call numbers)\n  - statement types (note/description/materials/provenance/rights/etc.) with statement meta-type usage\n  - object/place/group/digital/set/dimension type vocabularies\n  - common instances (languages, units, materials, currencies, nationalities, occupations, shapes)\n- Many recommended entries rely on meta-type patterns (for example, nationality/occupation/shape).\n- Bias and domain skew may exist in current recommended lists; extension and feedback are expected parts of ecosystem evolution.\n\n### Implementation Mapping — Recommended Terms\n\nApply these requirements to adapters, normalization, validation, and route outputs:\n\n1. Advisory-term support\n- Prefer recommended terms when mapping known source semantics, unless source fidelity requires an alternate concept.\n\n2. Non-blocking validation behavior\n- Treat recommended-term deviations as advisories/warnings, not hard conformance failures.\n\n3. Meta-type preservation\n- Preserve recommended meta-type structures when present (statement/object/shape/nationality/occupation families).\n\n4. Controlled fallback strategy\n- When exact recommended terms are unavailable, preserve source concept + include `equivalent` anchors where possible.\n\n5. Domain-set consistency\n- Maintain stable mappings for commonly recurring domains:\n  - language\n  - units\n  - materials\n  - currencies\n  - nationalities\n  - occupations\n  - shapes\n\n6. Explainable mapping\n- Capture mapping rationale in adapter tests/docs when intentionally choosing non-recommended terms.\n\n7. Upgrade resilience\n- Keep recommended-term checks version-tolerant so list updates do not create unnecessary breakages.\n\n### TDD Additions — Recommended Terms\n\nAdd failing-first tests for recommended-term interoperability workflows:\n\nContract-level:\n\n- validates structure of recommended-term classifications where used\n- validates statement meta-type patterns for statement categories\n- permits alternative non-recommended concepts while emitting advisory results\n\nAdapter-level:\n\n- maps common provider terms to recommended vocabulary when high-confidence matches exist\n- preserves alternate/local terms with equivalence links instead of destructive remapping\n- preserves recommended domain-instance references (language/unit/material/currency, etc.) when source provides them\n\nRoute-level:\n\n- inspect/import outputs include recommended-term advisories when alternatives are used\n- routes distinguish required failures from recommended-term warnings clearly\n- canonical `_source.raw` remains unchanged by advisory remapping logic\n\nRegression:\n\n- introducing new recommended mappings does not break older records\n- classification facets remain stable for both recommended and equivalent-linked local terms\n\n### Fixture Anchors — Recommended Terms Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Name-type variants\n- records with alternate/given/middle/family/sort-like name patterns.\n\n2. Identifier-type variants\n- records with accession/local/system/call identifiers.\n\n3. Statement-type families\n- statement records covering materials/provenance/rights/description/etc. using statement meta-type pattern.\n\n4. Object/place/group/digital/set/dimension recommended types\n- typed examples across each family for normalization/faceting tests.\n\n5. Common instance vocabularies\n- fixtures for language/unit/material/currency/nationality/occupation/shape references.\n\n6. Intentional non-recommended alternative\n- fixture proving advisory behavior with no hard validation failure.\n\n---\n\n## Round 23 Addendum — Optional Terms\n\nSource section basis:\n\n- Linked Art Model 1.0: Optional Terms\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Optional terms are interoperability helpers, not conformance requirements.\n- They are useful defaults and discovery aids for mapping, but alternatives are fully acceptable.\n- Optional-term lists may evolve ad hoc and are suitable for extension, including bias-mitigation additions.\n- Optional term families include:\n  - name types (translated title, subtitle, alias, pseudonym)\n  - identifier/contact types (auction lot number, DOI/ISBN/ISSN, email/street/phone/fax)\n  - statement/document/object/place/group/part/dimension type vocabularies\n- Optional terms should improve cross-dataset usability when adopted consistently, but must not become hidden hard requirements.\n\n### Implementation Mapping — Optional Terms\n\nApply these requirements to adapters, normalization, validation, and route outputs:\n\n1. Strictly non-blocking semantics\n- Treat optional-term mismatches or absences as informational only, never as hard validation failures.\n\n2. Interop-first preference\n- Prefer optional terms when there is no better source-specific mapping requirement.\n\n3. Transparent alternatives\n- Preserve alternate local/external terms without forced substitution; include equivalence links where feasible.\n\n4. Family-level consistency\n- Keep optional term use consistent within each domain family (for example, document types, object part types, contact identifiers).\n\n5. Mapping explainability\n- Document adapter mapping rationale when intentionally diverging from optional-term suggestions.\n\n6. Future-list tolerance\n- Keep optional-term handling resilient to list additions/removals without schema breakages.\n\n### TDD Additions — Optional Terms\n\nAdd failing-first tests for optional-term interoperability workflows:\n\nContract-level:\n\n- validates optional-term structures when present\n- confirms missing optional terms do not fail validation\n- confirms alternate terms can coexist with valid optional-term usage\n\nAdapter-level:\n\n- preserves optional term classifications when source provides them\n- preserves non-optional alternatives without data loss or invalid coercion\n- preserves contact/document/part/dimension optional type semantics where provided\n\nRoute-level:\n\n- inspect/import outputs expose optional-term advisories as informational hints only\n- routes do not escalate optional-term differences into blocking errors\n- canonical `_source.raw` remains unchanged by optional-term normalization suggestions\n\nRegression:\n\n- adopting new optional mappings does not alter existing required/recommended validation outcomes\n- faceting/classification logic remains stable across mixed optional-term adoption patterns\n\n### Fixture Anchors — Optional Terms Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Optional name types\n- translated title/sub-title/alias/pseudonym name-classification examples.\n\n2. Optional identifier and contact types\n- DOI/ISBN/ISSN/lot number plus email/street/telephone/fax contact identifiers.\n\n3. Optional statement and document types\n- representative statement classes and document-classification examples.\n\n4. Optional place/group/object/part/dimension types\n- typed examples across these families for advisory mapping behavior tests.\n\n5. Alternative-term coexistence\n- fixture with non-optional alternative term proving non-blocking validation.\n\n---\n\n## Round 24 Addendum — Textual Documents\n\nSource section basis:\n\n- Linked Art Model 1.0: Textual Documents\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Text modeling distinguishes:\n  - physical/digital carriers (`HumanMadeObject`/`DigitalObject`)\n  - textual content (`LinguisticObject`)\n- A single `LinguisticObject` can be carried by many carriers (`carries` / `digitally_carried_by` patterns).\n- Scope target is pragmatic bibliographic interoperability, not full FRBR/LRM/BibFrame complexity.\n- Common text features include:\n  - type/classification of textual work\n  - names and identifiers\n  - language\n  - descriptive statements\n- Text lifecycle often includes:\n  - `created_by` for authorship/creation\n  - publishing activity in `used_for` with required publication activity classification\n- Textual structure uses partitioning:\n  - chapter/article/issue/volume hierarchies via `part_of`\n- Pagination/foliation can be represented:\n  - as statements (human-readable ranges)\n  - as structured dimension counts (computable)\n- Texts can be `about` other core entities (objects, people, places, etc.).\n- Abstract-work alignment:\n  - textual content can be linked to higher-level conceptual abstraction (`PropositionalObject`) via `part_of`.\n\n### Implementation Mapping — Textual Documents\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Carrier/content separation\n- Preserve distinction between text carriers and textual content entities.\n\n2. Shared-content linkage\n- Preserve links from multiple carriers to shared `LinguisticObject` content records.\n\n3. Bibliographic identity\n- Preserve textual names/identifiers/language and work-type classifications.\n\n4. Creation vs publication split\n- Preserve authorship creation (`created_by`) separately from publishing activities (`used_for`).\n\n5. Structural hierarchy\n- Preserve chapter/article/issue/volume partitioning via `part_of` where available.\n\n6. Pagination dual pattern\n- Preserve both statement-style pagination and structured page-count dimensions when provided.\n\n7. Aboutness integrity\n- Preserve `about` links to core entities without substituting with string-only references.\n\n8. Abstract-work linkage\n- Preserve conceptual `part_of` links from `LinguisticObject` to `PropositionalObject` where modeled.\n\n### TDD Additions — Textual Documents\n\nAdd failing-first tests for textual-document workflows:\n\nContract-level:\n\n- validates `LinguisticObject` identity/classification/name/identifier/language structures\n- validates carrier-to-content links (`carries` and/or digital carry patterns)\n- validates publication activity embedding in `used_for` and creation activity in `created_by`\n\nAdapter-level:\n\n- preserves carrier/content separation and shared-content linkage\n- preserves textual structure (`part_of`) for sub-documents\n- preserves pagination statement and count-dimension structures\n- preserves `about` links and abstract-work part-of references\n\nRoute-level:\n\n- inspect/import outputs retain textual-document modeling patterns without flattening\n- routes do not collapse conceptual/abstract links into plain labels\n- canonical `_source.raw` text structures remain unmutated\n\nRegression:\n\n- text modeling enhancements do not break digital-object modeling or concept mappings\n- object-centric views continue to resolve related textual references correctly\n\n### Fixture Anchors — Textual Documents Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Physical carrier with textual content link\n- `HumanMadeObject` book record carrying a `LinguisticObject`.\n\n2. Linguistic content core record\n- monograph-classified `LinguisticObject` with names, identifiers, and language.\n\n3. Authorship + publication\n- `created_by` authorship activity plus publishing `used_for` activity.\n\n4. Document structure\n- chapter `LinguisticObject` `part_of` larger textual work.\n\n5. Pagination and page count\n- pagination statement plus computable page-count dimension.\n\n6. Aboutness\n- `LinguisticObject` `about` linked core entity.\n\n7. Abstract-work link\n- textual content `part_of` conceptual `PropositionalObject`.\n\n---\n\n## Round 25 Addendum — Archival Hierarchies\n\nSource section basis:\n\n- Linked Art Model 1.0: Archival Hierarchies\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Archives are modeled primarily as conceptual hierarchies of `Set` entities.\n- Archival intellectual arrangement is distinct from physical containment.\n- Conceptual hierarchy pattern:\n  - archival items (typically `HumanMadeObject`/`DigitalObject`) are `member_of` archival sets\n  - archival sets can be `member_of` broader archival sets (sub-series -> series -> fonds ...)\n  - no fixed depth limit; graph allows multi-membership across hierarchies\n- Physical containment alignment pattern:\n  - archival set -> `members_contained_by` -> physical container object\n  - individual item -> `held_or_supported_by` -> physical container object\n- Ordering of members follows the same set-ordering patterns as other `Set` use cases.\n- Shared/member-common description can use `members_exemplified_by`; textual statements remain acceptable for many archival descriptions.\n\n### Implementation Mapping — Archival Hierarchies\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Conceptual/physical split\n- Preserve conceptual membership (`member_of` set hierarchy) separately from physical containment (`members_contained_by`, `held_or_supported_by`).\n\n2. Hierarchy depth support\n- Preserve arbitrary-depth set-to-set hierarchies without flattening.\n\n3. Multi-membership support\n- Allow items/sets to participate in multiple conceptual archival sets when source data indicates this.\n\n4. Container linkage fidelity\n- Preserve links between archival sets and container objects, and between items and physical containers.\n\n5. Archival type preservation\n- Preserve archival grouping/sub-grouping classifications on sets when present.\n\n6. Description strategy compatibility\n- Preserve both structured collective descriptors (`members_exemplified_by`) and statement-based archival notes.\n\n7. Ordering compatibility\n- Preserve sort-value and ordering metadata for archival members where provided.\n\n### TDD Additions — Archival Hierarchies\n\nAdd failing-first tests for archival workflows:\n\nContract-level:\n\n- validates archival set hierarchy structures (`Set` + `member_of`)\n- validates physical-alignment properties (`members_contained_by`, `held_or_supported_by`)\n- validates archival grouping classifications when present\n\nAdapter-level:\n\n- preserves conceptual hierarchy depth and item membership\n- preserves physical container links without collapsing into conceptual hierarchy\n- preserves collective member descriptors and/or statements\n\nRoute-level:\n\n- inspect/import outputs retain both conceptual and physical hierarchy structures\n- routes do not infer conceptual membership solely from physical containment\n- canonical `_source.raw` archival hierarchy data remains unmutated\n\nRegression:\n\n- collection/set features (ordering, prototypes) remain compatible with archival sets\n- object-centric views still resolve both archival set membership and container placement\n\n### Fixture Anchors — Archival Hierarchies Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Archival item membership\n- item `HumanMadeObject` `member_of` archival sub-series set.\n\n2. Sub-series to series linkage\n- archival sub-grouping `Set` `member_of` archival grouping set.\n\n3. Physical alignment at set level\n- archival set with `members_contained_by` archival box object.\n\n4. Physical alignment at item level\n- archival item with `held_or_supported_by` same archival box object.\n\n5. Mixed conceptual + physical graph\n- fixture where conceptual set hierarchy and physical container hierarchy coexist and must not be conflated.\n\n---\n\n## Round 26 Addendum — Specific Assertions\n\nSource section basis:\n\n- Linked Art Model 1.0: Specific Assertions\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- `AttributeAssignment` is used for historically contingent, uncertain, context-specific, or otherwise non-primary assertions.\n- Keep use minimal because assertion reification adds complexity and query burden.\n- Core assignment pattern (`attributed_by` on subject):\n  - subject entity has `attributed_by` -> `AttributeAssignment`\n  - assignment carries `assigned_property` (predicate)\n  - assignment carries `assigned` (object/value entity)\n- Inverse/value-centered pattern (`assigned_by` on value):\n  - useful for value entities such as identifiers/dimensions\n  - helps encode who assigned a specific value (for example, institution-specific accession numbers)\n- Source-of-knowledge pattern:\n  - assignment references authority witness via `used_specific_object` (entity reference, not plain citation string)\n- Embedded statement provenance/rights:\n  - statements may carry `created_by`, `technique`, timespan, and `subject_to` rights\n  - AI-origin metadata can be represented via statement/creation classifications/techniques\n- Uncertain/former assertions:\n  - can target embedded production/activity nodes for \"possibly by\"/former-attribution scenarios\n- Context-specific assertions:\n  - exhibition- or project-specific names/identifiers/descriptions should use `AttributeAssignment`\n  - `caused_by` can bind assignment to contextual activity (for example, exhibition)\n- Unknown or unmodeled relationships:\n  - `AttributeAssignment` can express relationship presence when precise model relation is unknown or unavailable\n  - should be last resort after attempting explicit model properties\n\n### Implementation Mapping — Specific Assertions\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Minimal-use policy\n- Prefer direct model properties first; use `AttributeAssignment` only when direct expression is inadequate or historically/contextually incorrect.\n\n2. Subject/value direction correctness\n- Preserve correct directionality for `attributed_by` vs `assigned_by` patterns depending on assertion use case.\n\n3. Triple integrity\n- Preserve subject (`attributed_by` host), predicate (`assigned_property`), object (`assigned`) semantics explicitly.\n\n4. Context linkage\n- Preserve `caused_by` and `part_of` links for context-bounded assertions.\n\n5. Source provenance fidelity\n- Preserve `used_specific_object` references as source evidence entities.\n\n6. AI/rights annotation safety\n- Preserve statement-level creation technique/time and rights markings without collapsing into global record-level assumptions.\n\n7. Uncertainty preservation\n- Preserve uncertain/former assignments as assertions; do not auto-promote into canonical fact fields.\n\n8. Relationship-fallback restraint\n- Use related-entity assertion patterns only when explicit relationship predicates are unavailable.\n\n### TDD Additions — Specific Assertions\n\nAdd failing-first tests for specific-assertion workflows:\n\nContract-level:\n\n- validates `AttributeAssignment` structures for both subject-side and value-side patterns\n- validates `assigned_property`, `assigned`, `used_specific_object`, and contextual links when present\n- rejects malformed assertion triples and invalid assignment payloads\n\nAdapter-level:\n\n- preserves assertion directionality and context/source links\n- preserves exhibition-specific and uncertainty-specific assertions without canonical overwrite\n- preserves AI/rights statement metadata attached to embedded linguistic content\n\nRoute-level:\n\n- inspect/import outputs retain assertion structures and relation context\n- routes do not flatten assertions into canonical direct properties unless explicitly instructed by migration logic\n- canonical `_source.raw` assertion history remains unmutated\n\nRegression:\n\n- assertion enrichment does not break baseline property queries for current state\n- related-entity fallback assertions do not replace explicit relationships when those are present\n\n### Fixture Anchors — Specific Assertions Examples\n\nUse these official-example patterns as fixture seeds:\n\n1. Subject-side assignment triple\n- entity `attributed_by` assignment with `assigned_property` + `assigned` value.\n\n2. Value-side assignment provenance\n- identifier with `assigned_by` assignment pointing to assigning institution/actor.\n\n3. Source-backed name assertion\n- name with `assigned_by.used_specific_object` referencing source text entity.\n\n4. AI-generated embedded statement\n- statement with AI-related classification/technique, creation timestamp, and statement-level rights.\n\n5. Uncertain production attribution\n- production node with attributed assignment carrying \"possibly by\" classification and assigned production part.\n\n6. Context-specific exhibition identifier\n- object-level assertion assigning exhibition-specific identifier with `caused_by` exhibition activity.\n\n7. Related/unmodeled entity fallback\n- attribute assignment used for \"related object\" / social relationship fallback when explicit model predicate is unavailable.\n\n---\n\n## Round 27 Addendum — Profile\n\nSource section basis:\n\n- Linked Art Model 1.0: Profile\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Linked Art is an intentionally reduced application profile of CIDOC-CRM:\n  - targeted practical coverage for most real-world museum use cases\n  - reduced ontology complexity to improve implementation and interoperability\n- Core mission emphasizes:\n  - event-based cultural heritage publication for research and general developers\n  - shared models plus shared software patterns to lower producer/consumer burden\n- Design posture is explicitly:\n  - iterative\n  - responsive\n  - responsible\n  - collaborative\n- Seven profile design principles govern modeling decisions:\n  1. Scope through shared use cases and real world data.\n  2. Select solutions that are as simple as possible and no simpler.\n  3. Intelligently manage addition of complexity.\n  4. Avoid dependency on specific technologies.\n  5. Follow linked-data principles and best practices.\n  6. Design for JSON-LD first.\n  7. Define success, not failure.\n- Practical implications for implementers:\n  - no class/property without concrete use case data\n  - strong preference for reuse over new terms/extensions\n  - avoid unnecessary multiple instantiation complexity\n  - support simple \"minimum viable\" publishing first, with optional expansions\n  - remain transformable between JSON-LD and RDF triples without information loss\n  - avoid CIDOC-CRM features that conflict with core linked-data practice\n\n### Implementation Mapping — Profile\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Use-case-first modeling gate\n- New provider mappings must tie each non-trivial class/property to a documented museum use case and sample payload.\n\n2. Simplicity-first adapter behavior\n- Prefer direct baseline Linked Art patterns in normalized output.\n- Add complex expansions only when required by explicit source evidence.\n\n3. Reuse-before-extension rule\n- Reuse Linked Art and existing CRM-aligned structures before adding local extension fields.\n- Any local extension must be documented in contracts and roadmap with rationale.\n\n4. JSON-LD-first output contract\n- Canonical route payloads must remain valid JSON-LD oriented structures first, while still enabling RDF materialization.\n\n5. Technology-neutral core\n- Source adapters must avoid coupling business logic to a single graph store or query technology.\n- Model semantics remain stable regardless of storage backend (files/Postgres/graph layer).\n\n6. Expansion layering discipline\n- Keep \"current/baseline fact\" fields straightforward.\n- Hang uncertainty/history/context in additive expansions without forcing all clients to parse them.\n\n7. Success-pattern conformance\n- Treat official profile patterns as positive conformance targets; non-profile source fields may be preserved under `_source.raw` without breaking canonical model output.\n\n### TDD Additions — Profile\n\nAdd failing-first tests for profile-conformance guardrails:\n\nContract-level:\n\n- validates canonical JSON-LD structure for normalized entities against profile-aligned contracts\n- validates that extension fields are namespaced and documented when present\n- rejects unsupported \"invented\" relationship fields in canonical model zone\n\nAdapter-level:\n\n- verifies baseline/simple pattern output exists for each supported provider slice\n- verifies optional expansions do not overwrite or obscure baseline fields\n- verifies round-trip integrity from source -> normalized JSON-LD -> RDF transform path (shape-level/no-loss checks)\n\nRoute-level:\n\n- inspect/import responses expose canonical profile-first shape with optional expansion blocks\n- routes preserve raw provider payloads under `_source.raw` for audit/debug without polluting canonical fields\n- unsupported source constructs degrade gracefully into raw/annotation zones rather than malformed canonical nodes\n\nRegression:\n\n- introducing a new provider does not regress existing Linked Art conformance fixtures\n- conformance suite blocks accidental drift into over-complex local ontology fragments\n\n### Fixture Anchors — Profile Examples\n\nUse these official-profile principles as fixture seeds:\n\n1. Shared use case evidence fixture\n- each advanced mapping test references an explicit use case ID + real sample payload.\n\n2. Simplicity baseline fixture\n- same source record emits a simple canonical representation with optional expansion kept separate.\n\n3. Reuse over extension fixture\n- provider-specific nuance modeled via existing Linked Art/CRM patterns, not ad hoc canonical fields.\n\n4. JSON-LD first fixture\n- normalized output validates as JSON-LD object graph and remains transformable to triples.\n\n5. Technology-independence fixture\n- identical normalized semantics pass with file-backed and Postgres-backed storage implementations.\n\n6. Success-not-failure fixture\n- out-of-scope source details retained in `_source.raw`, while canonical profile section remains valid.\n\n---\n\n## Round 28 Addendum — Linked Art Terms Ontology (RDF Extensions)\n\nSource section basis:\n\n- Linked Art terms ontology serialization (`https://linked.art/ns/terms/`) as RDF/XML excerpt\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- The RDF terms file defines practical Linked Art extensions and profile conveniences over base CIDOC-CRM.\n- Confirmed active terms/classes include:\n  - assertion support: `property_classified_as` (for dot-one style semantics via `AttributeAssignment`)\n  - custody convenience: `current_permanent_custodian` and inverse\n  - identity equivalence: `equivalent` (explicitly avoiding `skos:exactMatch` inference side effects)\n  - generalized transfer model:\n    - class `Transfer` with `transferred`, `transferred_from`, `transferred_to`\n    - subclasses include `Acquisition`, `Move`, `Transfer_of_Custody`\n    - payment specialization via `Payment` + `paid_amount` / `paid_from` / `paid_to`\n  - set and membership model:\n    - class `Set`, membership relations (`has_member`, `member_of`)\n    - exemplar/containment helpers (`members_exemplified_by`, `members_contained_by`, `contains_members_of`)\n    - lifecycle activities: `Addition`/`Removal` with directional member and set links\n  - digital object relations:\n    - `digitally_carries`, `digitally_shows`\n    - `access_point`\n    - `DigitalService` + `digitally_available_via` / `digitally_makes_available`\n  - rights transfer:\n    - `RightAcquisition`\n    - `establishes`/`established_by`, `invalidates`/`invalidated_by`\n- The excerpt also contains a commented `Phase` model block marked as not currently used in profile and therefore non-normative for current conformance.\n\n### Implementation Mapping — Terms Ontology\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Active-terms allowlist\n- Treat the listed active classes/properties as permitted canonical vocabulary in normalized Linked Art output.\n\n2. Inverse-aware graph handling\n- Preserve inverse-capable relationship semantics in canonical storage/query layers without forcing both directions into payloads.\n\n3. Transfer abstraction discipline\n- Support `Transfer` as a first-class unknown/abstract exchange pattern; avoid coercing ambiguous transfers into acquisition/custody/move when evidence is insufficient.\n\n4. Set lifecycle fidelity\n- Preserve `Addition`/`Removal` events and directional membership properties to model collection/list evolution over time.\n\n5. Digital relation fidelity\n- Preserve separation between digital carrier/content/display/service/access-point semantics for IIIF and other provider integrations.\n\n6. Rights transition semantics\n- Preserve rights establishment and invalidation as explicit activity-driven state changes.\n\n7. Non-normative block protection\n- Do not implement commented `Phase` terms as required behavior in current provider slices unless roadmap explicitly activates that scope.\n\n### TDD Additions — Terms Ontology\n\nAdd failing-first tests for ontology-term conformance:\n\nContract-level:\n\n- validates acceptance of active `la:` terms in canonical contract schemas\n- validates inverse-capable properties as semantically paired where applicable\n- rejects/flags non-profile commented terms as required fields\n\nAdapter-level:\n\n- preserves ambiguous exchange as `Transfer` when subtype is unknown\n- preserves set membership change events (`Addition`/`Removal`) and directional links\n- preserves digital relations (`digitally_carries` vs `digitally_shows` vs `digitally_available_via`) without collapsing semantics\n- preserves rights transitions via `RightAcquisition` establish/invalidate pairs\n\nRoute-level:\n\n- inspect/import outputs retain canonical `la:` term usage and source fidelity\n- routes do not flatten transfer, set-lifecycle, or rights-lifecycle structures into static snapshots only\n- canonical `_source.raw` retains original provider modeling where richer than canonical projection\n\nRegression:\n\n- previously accepted object/provenance/digital fixtures continue passing with `la:` term allowlist enabled\n- no accidental introduction of inactive/commented ontology sections into required conformance gates\n\n### Fixture Anchors — Terms Ontology Examples\n\nUse these ontology-backed patterns as fixture seeds:\n\n1. Attribute-assignment property typing\n- `AttributeAssignment` with `property_classified_as` term annotation.\n\n2. Permanent custodian snapshot\n- object with `current_permanent_custodian` actor and inverse query check.\n\n3. Equivalent identity link\n- entity pair linked with `equivalent` (non-SKOS inference-safe mapping).\n\n4. Abstract transfer\n- ambiguous provenance handoff modeled as `Transfer` + transferred/from/to.\n\n5. Payment transfer part\n- payment with amount/from/to linked under transfer activity context.\n\n6. Set membership lifecycle\n- `Addition` adds member to set; `Removal` removes member from set; both directional relations asserted.\n\n7. Digital service publication\n- digital object with `access_point`, `digitally_shows` visual item, and `digitally_available_via` digital service.\n\n8. Rights lifecycle\n- `RightAcquisition` that `establishes` one right and `invalidates` another in transition scenario.\n\n---\n\n## Round 29 Addendum — CIDOC-CRM Class Analysis (Practical Utility Profile)\n\nSource section basis:\n\n- Linked Art Model 1.0: Class Analysis\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Class usage should be driven by practical interoperability and real dataset utility, not full ontology breadth.\n- Explicit classes-to-ignore guidance includes:\n  - 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`)\n  - CRM datatype classes (`E59`, `E60`, `E61`, `E62`, `E94`, `E95`) in favor of RDF/XSD/native representations\n  - overly specific/redundant classes best replaced with parent class + `P2_has_type` and external vocab\n- Strong simplification recommendations:\n  - prefer `E13 Attribute Assignment` patterns over its narrow reification subclasses\n  - prefer `Name` / `E33_E41 Linguistic Appellation` patterns for names/titles; keep `E42 Identifier` for identifiers\n  - prefer `E36 Visual Item` for visual content; avoid deprecated/redundant visual subclasses\n  - prefer Linked Art `Set` model for aggregations over controversial collection-specific CRM distinctions\n- Useful class set is explicitly identified and should anchor mapping priorities (for objects, provenance, activities, actors, places, dimensions, money, etc.).\n- Optional/not-currently-required classes can remain unsupported unless a concrete source use case appears.\n- `E30 Right` is treated as problematic in base CRM semantics; Linked Art’s practical right-acquisition/invalidation patterns are preferred for operational modeling.\n\n### Implementation Mapping — Class Analysis\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Canonical class allowlist\n- Maintain a practical class allowlist aligned to the \"useful classes\" set and existing Linked Art profile terms.\n\n2. Ignore/redirect policy\n- If source data carries ignored/overly specific classes, normalize to the recommended parent/pattern and preserve original typing in `_source.raw`.\n\n3. Datatype normalization\n- Normalize CRM datatype-class usage into concrete literals (`xsd:string`, numeric/date types, etc.) and external geometry vocab when required.\n\n4. Set-first aggregation modeling\n- Model collection-like groupings via Linked Art `Set` + type classification rather than forcing curated-holding subclasses.\n\n5. Visual/text distinction discipline\n- Route visual manifestations to `VisualItem` patterns and inscriptions/text to linguistic-object patterns when evidence supports that split.\n\n6. Rights modeling guardrail\n- For rights change semantics, prefer Linked Art right-acquisition lifecycle patterns over naive static-right assertions.\n\n7. Evidence-based expansion\n- Support currently optional classes only when provider evidence and use-case docs justify them.\n\n### TDD Additions — Class Analysis\n\nAdd failing-first tests for practical class-profile conformance:\n\nContract-level:\n\n- validates canonical outputs only emit class types from the active practical allowlist\n- rejects direct emission of ignored abstract/datatype CRM classes in canonical projection\n- validates class remapping paths for known overly specific/deprecated source classes\n\nAdapter-level:\n\n- source class variants normalize to profile-preferred classes without data loss\n- identifiers remain distinct from names/titles in normalized output\n- visual vs linguistic content splits are preserved according to source evidence\n- set aggregation outputs use `Set` semantics with typed classification\n\nRoute-level:\n\n- inspect/import responses include canonical remapped class model plus `_source.raw` for provenance\n- routes do not leak ignored/deprecated classes into top-level canonical payloads\n- rights-related provider data maps to right-lifecycle activity patterns where applicable\n\nRegression:\n\n- existing provenance, digital, and vocabulary fixtures continue to pass under class allowlist enforcement\n- legacy fixtures with deprecated/over-specific typing remain ingestible via remap shims\n\n### Fixture Anchors — Class Analysis Examples\n\nUse these analysis-derived patterns as fixture seeds:\n\n1. Datatype class replacement\n- source payload using CRM datatype-class semantics normalized to concrete typed literals.\n\n2. Over-specific appellation collapse\n- legacy title/name subclass mapped into `Name`/linguistic-appellation pattern; identifiers remain `Identifier`.\n\n3. Visual class collapse\n- image/mark/inscription edge cases mapped to `VisualItem` or `LinguisticObject` per evidence.\n\n4. Set normalization\n- curated-holding-like source mapped to Linked Art `Set` with vocabulary type.\n\n5. Abstract class suppression\n- source carrying abstract hierarchy classes ingests successfully but canonical payload omits direct abstract class emissions.\n\n6. Rights lifecycle mapping\n- source rights change represented via right-acquisition/invalidates pattern rather than static timeless right-only node.\n\n---\n\n## Round 30 Addendum — Linked Art API 1.0 Foundations\n\nSource section basis:\n\n- Linked Art API 1.0: Introduction and API design fundamentals overview\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- The Linked Art model/profile is transport-agnostic; API conformance is a separate web interaction layer.\n- Core API expectation:\n  - entity descriptions serialized as JSON-LD using Linked Art context\n  - non-semantic HAL block for navigational/API affordance links\n- API surface areas called out:\n  - Entity Description endpoints\n  - Shared Data Structures\n  - JSON Schema\n  - HAL links for versions/cross-format/searches\n  - Search API response format (query language intentionally unspecified)\n  - Data discovery/harvest/synchronization APIs\n- Search interoperability stance:\n  - standardized search response shape\n  - implementation-specific query languages are allowed (SPARQL/GraphQL/Cypher/ES/Solr/etc.)\n  - clients should discover named searches via HAL links rather than hard-coding query grammar\n- Versioning policy:\n  - semantic versioning `Major.Minor.Patch`\n  - minor = backwards-compatible feature/clarification\n  - patch = documentation-only changes\n  - major = backwards-incompatible changes\n\n### Implementation Mapping — API Foundations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. JSON-LD + HAL dual-layer response contract\n- Keep canonical entity payload JSON-LD compliant while exposing API navigation in HAL-style metadata blocks.\n\n2. Endpoint consistency\n- Ensure route handlers expose consistent entity envelope patterns across objects, people, places, concepts, events, and shared structures.\n\n3. Search-format stability\n- Standardize search response structure independent of backend query implementation.\n- Allow internal query engine changes without breaking client-facing response shape.\n\n4. Discovery-first integration\n- Expose machine-followable links for:\n  - named searches\n  - format variants\n  - version endpoints\n  - synchronization/discovery feeds where available\n\n5. Schema-governed contracts\n- Keep response and request contracts aligned with JSON Schema/Zod boundary checks as implementation guardrails.\n\n6. Versioned compatibility guarantees\n- Treat API-breaking response-shape changes as major-version work items only.\n- Record minor/patch behavior in changelog/roadmap notes for provider-slice PRs.\n\n### TDD Additions — API Foundations\n\nAdd failing-first tests for API conformance behavior:\n\nContract-level:\n\n- validates entity responses as JSON-LD using expected context semantics\n- validates HAL block shape and required link relations\n- validates search response envelope stability independent of query backend\n\nRoute-level:\n\n- entity endpoints return consistent envelope and link conventions\n- search endpoints return standardized response shape with discovered query links\n- discovery endpoints/links provide harvest/sync affordances when configured\n\nVersioning-level:\n\n- tests enforce non-breaking minor changes for existing response contracts\n- tests detect breaking shape changes and require explicit version-bump workflow\n\nRegression:\n\n- provider additions do not alter existing entity/search envelope contracts\n- backend query engine swaps do not change public search response schema\n\n### Fixture Anchors — API Foundations Examples\n\nUse these API-level patterns as fixture seeds:\n\n1. Entity response fixture\n- JSON-LD entity record with HAL links for self/version/related/search.\n\n2. Search response fixture\n- standardized result list with pagination/meta independent of query syntax.\n\n3. HAL named-search link fixture\n- entity exposing discoverable named searches via stable relation names.\n\n4. Multi-format link fixture\n- entity exposing alternate format/version links through HAL metadata.\n\n5. Version-compat fixture\n- snapshot tests proving minor update compatibility for entity and search responses.\n\n---\n\n## Round 31 Addendum — About Endpoints (Entity Endpoint Taxonomy)\n\nSource section basis:\n\n- Linked Art API 1.0: About Endpoints\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Linked Art API is organized as endpoint families, each with defined response structure aligned to model classes.\n- Endpoint families called out:\n  - Abstract Works\n  - Concepts\n  - Digital Objects\n  - Events\n  - Groups\n  - People\n  - Physical Objects\n  - Places\n  - Provenance Activities\n  - Sets\n  - Textual Works\n  - Visual Works\n- Endpoints are class-oriented and should remain predictable for consumers regardless of internal storage/query implementation.\n\n### Implementation Mapping — Endpoint Taxonomy\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Endpoint family coverage matrix\n- Maintain an explicit map of project routes to Linked Art endpoint families (implemented, partial, planned).\n\n2. Family-specific envelope consistency\n- Keep consistent JSON-LD + HAL envelope conventions across all family endpoints while allowing family-specific payload fields.\n\n3. Cross-entity linking discipline\n- Ensure records link across families through stable identifiers (for example object -> provenance activity -> people/groups/places/concepts).\n\n4. Provenance vs event separation\n- Keep provenance activities as a dedicated event family and avoid collapsing them into generic events when provenance semantics are present.\n\n5. Work/entity distinction\n- Keep abstract/textual/visual work endpoints distinct from physical object endpoints to avoid conflating conceptual and physical layers.\n\n6. Set modeling consistency\n- Route set-like resources through set semantics, including collections and exhibition sets, without forcing physical-object semantics.\n\n### TDD Additions — Endpoint Taxonomy\n\nAdd failing-first tests for endpoint-family conformance:\n\nContract-level:\n\n- validates each endpoint family response against its expected entity-class contract profile\n- validates shared envelope requirements are consistent across families\n- validates family-specific required links/fields are present when applicable\n\nRoute-level:\n\n- smoke tests for each supported family endpoint return expected entity type(s)\n- unknown family records fail gracefully with clear not-supported/not-found behavior\n- provenance-family endpoints retain transfer/acquisition/custody/move semantics\n\nIntegration-level:\n\n- cross-family traversal tests (object -> production/provenance -> actor/place/concept)\n- set endpoints correctly resolve membership and member entity references\n- digital object endpoints correctly resolve access points/services and visual/textual links\n\nRegression:\n\n- adding new provider slices does not alter existing family envelope conventions\n- family-specific fixtures remain stable when storage backend changes\n\n### Fixture Anchors — Endpoint Taxonomy Examples\n\nUse these endpoint-family patterns as fixture seeds:\n\n1. Physical object fixture\n- object record with links to production, provenance, identifiers, and digital representations.\n\n2. Provenance activity fixture\n- transfer/acquisition activity linked to object + actors + timespan/place.\n\n3. People/groups fixture\n- person and group records linked via participation roles in activities.\n\n4. Place fixture\n- place linked from object ownership/location and activity occurrence.\n\n5. Concept fixture\n- type/material/language concept records resolved as first-class endpoint entities.\n\n6. Set fixture\n- collection/exhibition set with members and membership lifecycle references.\n\n7. Work layer fixtures\n- abstract work, textual work, and visual work each represented independently and linked to carrying/showing entities.\n\n8. Digital object fixture\n- digital object with access point/service and linked visual/textual content.\n\n---\n\n## Round 32 Addendum — Abstract Works Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Abstract Works endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Abstract Works endpoint describes conceptual works, especially those instantiated by activities (for example exhibition concepts, performance concepts).\n- Endpoint is less common but important for linking multiple concrete realizations to one conceptual work.\n- Required core response properties:\n  - `@context` must include Linked Art context URI (`https://linked.art/ns/v1/linked-art.json`)\n  - `id` must be dereferenceable HTTP(S) URI\n  - `type` must be `PropositionalObject`\n- Recommended properties:\n  - `_label`\n  - `classified_as`\n  - `identified_by` (Name and/or Identifier patterns)\n- Optional properties include:\n  - `referred_to_by`, `equivalent`, `subject_of`, `representation`, `member_of`\n  - `attributed_by`, `dimension`, `conceptually_part_of`, `about`, `subject_to`, `created_by`\n- Incoming reference patterns called out:\n  - `about` from Textual Works\n  - `influenced_by` from Activities\n\n### Implementation Mapping — Abstract Works Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Abstract Work endpoint payloads must emit canonical `type: \"PropositionalObject\"` for top-level records.\n\n2. Context and URI discipline\n- Enforce valid Linked Art context placement and stable dereferenceable `id` values.\n\n3. Conceptual-vs-physical separation\n- Keep abstract work records distinct from physical/textual/visual instantiations and link them via references.\n\n4. Relationship fidelity\n- Preserve `about`, `conceptually_part_of`, `representation`, and `subject_of` links without flattening into local-only text fields.\n\n5. Creation and assertion support\n- Preserve `created_by` and `attributed_by` blocks where provided as first-class modeled structures.\n\n6. Set participation\n- Preserve optional `member_of` links so abstract works can participate in sets (for example curatorial concept groupings).\n\n### TDD Additions — Abstract Works Endpoint\n\nAdd failing-first tests for abstract-work endpoint conformance:\n\nContract-level:\n\n- validates required properties: `@context`, `id`, `type=PropositionalObject`\n- validates recommended structures (`classified_as`, `identified_by`) when present\n- validates optional relation fields against shared reference patterns\n\nRoute-level:\n\n- abstract-work endpoint returns single-entity JSON-LD envelope with HAL-compatible link layer\n- unknown/non-abstract IDs fail gracefully with clear status and error shape\n- route preserves `created_by` and `about` relation structures end-to-end\n\nIntegration-level:\n\n- textual-work records can reference abstract works via `about`\n- activity records can reference abstract works via `influenced_by`\n- conceptual hierarchy traversal via `conceptually_part_of` remains stable\n\nRegression:\n\n- abstract-work ingestion does not regress physical object or visual/textual work endpoint schemas\n- optional abstract-work fields remain additive and do not break minimal valid responses\n\n### Fixture Anchors — Abstract Works Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid abstract work\n- required-only payload with context, HTTP(S) id, and `type: PropositionalObject`.\n\n2. Exhibition concept fixture\n- abstract work classified as exhibition with name and brief descriptive statement.\n\n3. About-link fixture\n- abstract work `about` a person/concept/entity with stable external URI reference.\n\n4. Creation fixture\n- abstract work with `created_by` creation activity and `carried_out_by` person/group.\n\n5. Conceptual hierarchy fixture\n- abstract work linked via `conceptually_part_of` to a broader abstract work.\n\n6. Cross-endpoint incoming fixture\n- textual work `about` abstract work and activity `influenced_by` same abstract work.\n\n---\n\n## Round 33 Addendum — Concepts Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Concepts endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Concepts endpoint provides full concept records (not embedded references) for:\n  - `Type`\n  - `Material`\n  - `Language`\n  - `Currency`\n  - `MeasurementUnit`\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is one of the allowed concept classes above\n- Recommended properties:\n  - `_label`\n  - `classified_as`\n  - `identified_by` (Name and/or Identifier structures)\n- Optional properties:\n  - `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`\n  - `attributed_by`, `broader`, `created_by`\n- Key incoming links across model:\n  - `classified_as` (all entities)\n  - `technique` / `influenced_by` (activities)\n  - `about` (textual/visual works)\n  - `assigned` (attribute assignments)\n  - `language` (linguistic objects)\n  - `currency` (monetary amounts)\n  - `unit` (dimensions)\n  - `made_of` (human-made objects)\n\n### Implementation Mapping — Concepts Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type allowlist enforcement\n- Concepts endpoint must enforce top-level `type` to allowed concept classes only.\n\n2. Full-record vs embedded-reference separation\n- Keep concept endpoint records richer than embedded type stubs while preserving shared identity URIs.\n\n3. Hierarchy fidelity\n- Preserve `broader` links for concept navigation without flattening into label-only taxonomies.\n\n4. Cross-domain linkage stability\n- Preserve concept usage links from activities, linguistic content, monetary amounts, dimensions, and materials.\n\n5. Creation/attribution traceability\n- Preserve `created_by` and `attributed_by` structures when concept provenance is provided.\n\n6. Equivalence integrity\n- Keep `equivalent` links as identity mappings without overwriting local canonical URI identity.\n\n### TDD Additions — Concepts Endpoint\n\nAdd failing-first tests for concept endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, and allowed concept `type` values\n- validates recommended structures (`identified_by`, `classified_as`) when present\n- validates optional relation fields (`broader`, `equivalent`, `member_of`, etc.) against shared reference schemas\n\nRoute-level:\n\n- concept endpoint returns full concept records with stable JSON-LD + HAL envelope conventions\n- invalid concept `type` values are rejected with clear error responses\n- missing or unknown concept IDs return consistent not-found behavior\n\nIntegration-level:\n\n- activities can resolve linked concept records for `technique` and `influenced_by`\n- dimensions resolve `unit` concepts; monetary amounts resolve `currency` concepts\n- linguistic objects resolve `language`; objects resolve `made_of` material concepts\n\nRegression:\n\n- concept endpoint changes do not break embedded concept references in other entity endpoints\n- broader/equivalent graph traversal remains stable after provider adapter updates\n\n### Fixture Anchors — Concepts Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid concept\n- required-only record with `type` in concept allowlist.\n\n2. Hierarchical type concept\n- `Type` with `broader` link and primary name.\n\n3. Language concept\n- `Language` record used by linguistic object `language` linkage tests.\n\n4. Measurement unit concept\n- `MeasurementUnit` record consumed by dimension `unit` tests.\n\n5. Currency concept\n- `Currency` record consumed by monetary amount `currency` tests.\n\n6. Material concept\n- `Material` record consumed by object `made_of` tests.\n\n7. Concept provenance fixture\n- concept with `created_by.influenced_by` links and optional `attributed_by`.\n\n---\n\n## Round 34 Addendum — Digital Objects Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Digital Objects endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Digital Objects endpoint describes digital content metadata (images, documents, other media) independent of whether bytes are directly accessible.\n- `access_point` is the locator mechanism for retrievable file/service representations.\n- Required top-level Digital Object properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `DigitalObject`\n- Recommended properties:\n  - `_label`\n  - `classified_as`\n  - `identified_by` (Name and/or Identifier)\n- Optional Digital Object properties include:\n  - common linked-art fields (`referred_to_by`, `equivalent`, `member_of`, `subject_of`, `representation`, `attributed_by`)\n  - digital-specific fields: `dimension`, `part_of`, `format`, `conforms_to`, `digitally_carries`, `digitally_shows`, `digitally_available_via`, `access_point`, `created_by`, `used_for`\n- Digital Service sub-structure is first-class with required:\n  - `@context`, `id`, `type: DigitalService`\n  - optional `access_point`, `conforms_to`, and common descriptive fields\n- Incoming links highlighted:\n  - `digitally_carried_by` from Textual Works\n  - `digitally_shown_by` from Visual Works\n\n### Implementation Mapping — Digital Objects Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Digital object endpoint payloads must emit top-level `type: \"DigitalObject\"` only for this family.\n\n2. Metadata-vs-binary separation\n- Preserve distinction between metadata records and retrievable content endpoints via `access_point`.\n\n3. Service modeling fidelity\n- Preserve `digitally_available_via` as Digital Service objects with their own access/specification links.\n\n4. Content relationship clarity\n- Keep `digitally_carries` (textual content) and `digitally_shows` (visual content) semantically separate.\n\n5. Technical conformance capture\n- Preserve `format` and `conforms_to` to support IIIF and other technical interoperability checks.\n\n6. Structural linkage\n- Preserve `part_of` relations (for example image part of manifest/package object).\n\n7. Creation provenance\n- Preserve `created_by` plus `used_specific_object` where digitization provenance is provided.\n\n### TDD Additions — Digital Objects Endpoint\n\nAdd failing-first tests for digital-object endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, `type=DigitalObject`\n- validates digital-service nested structure with `type=DigitalService` and valid access/specification references\n- validates optional digital-specific fields (`format`, `conforms_to`, `digitally_*`, `access_point`, `part_of`) against schema\n\nRoute-level:\n\n- digital endpoint returns consistent JSON-LD + HAL envelope for digital records\n- invalid `type` or malformed service/access blocks return clear validation errors\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- visual/textual work endpoints can resolve reciprocal digital links (`digitally_shown_by`, `digitally_carried_by`)\n- IIIF-style fixtures resolve service and access-point chains without semantic loss\n- dimensions on digital objects retain numeric/unit fidelity (for example pixel height/width)\n\nRegression:\n\n- digital endpoint updates do not regress physical object or visual/textual endpoint contracts\n- ingestion from multiple providers preserves both canonical digital semantics and `_source.raw`\n\n### Fixture Anchors — Digital Objects Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid digital object\n- required-only digital object with context/id/type.\n\n2. Image object with dimensions\n- digital image with pixel `Dimension` entries and `MeasurementUnit`.\n\n3. Access point fixture\n- digital object with retrievable file URI in `access_point`.\n\n4. Service fixture\n- `DigitalService` with IIIF `conforms_to` and service `access_point`.\n\n5. Visual linkage fixture\n- digital object `digitally_shows` visual work with reciprocal visual endpoint linkage checks.\n\n6. Text linkage fixture\n- digital object `digitally_carries` textual work with reciprocal textual endpoint linkage checks.\n\n7. Part-of fixture\n- derivative file/asset linked via `part_of` to a manifest/package digital object.\n\n8. Digitization provenance fixture\n- `created_by` activity with `carried_out_by` agent and `used_specific_object` physical source.\n\n---\n\n## Round 35 Addendum — Events Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Events endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Events endpoint groups `Period`, `Event`, and `Activity` records that are notable but not provenance/exhibition-specific endpoint families.\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` must be one of: `Period`, `Event`, `Activity`\n- Recommended:\n  - `_label`\n  - `classified_as`\n  - `identified_by`\n  - `timespan` (recommended in endpoint table)\n- Optional common links:\n  - `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`, `part_of`\n- Optional temporal/spatial ordering:\n  - `during`, `before`, `after`, `took_place_at`\n- Type-conditional properties:\n  - `caused_by` only for `Event`/`Activity`\n  - `influenced_by` only for `Activity`\n  - `carried_out_by` only for `Activity`\n  - `participant` for `Event`/`Activity`\n  - `used_specific_object` and `technique` only for `Activity`\n- Incoming pattern highlighted:\n  - `part_of` from any event/activity family to broader periods/events/activities\n\n### Implementation Mapping — Events Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type allowlist + conditional validation\n- Enforce event `type` allowlist and gate conditional fields by type at validation boundary.\n\n2. Time modeling discipline\n- Preserve `timespan` structures with explicit bounds/display names when present.\n\n3. Temporal ordering fidelity\n- Preserve `during` / `before` / `after` relationships without flattening to plain-date-only approximations.\n\n4. Causality and influence semantics\n- Keep `caused_by` and `influenced_by` distinct and type-correct.\n\n5. Participation role clarity\n- Distinguish `carried_out_by` (agentive execution) from `participant` (participation without execution).\n\n6. Activity instrumentation\n- Preserve `used_specific_object` and `technique` for activity explainability and reproducibility.\n\n7. Cross-endpoint composition\n- Preserve `part_of` composition links between events and broader periods for timeline traversal.\n\n### TDD Additions — Events Endpoint\n\nAdd failing-first tests for event endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, and `type in {Period, Event, Activity}`\n- validates recommended `timespan` structure when present\n- rejects type-disallowed fields (for example `carried_out_by` on `Period`)\n\nRoute-level:\n\n- event endpoint returns stable JSON-LD + HAL envelope\n- invalid type/field combinations return clear boundary validation errors\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- `part_of` links resolve across event families and preserve hierarchy constraints\n- `during`/`before`/`after` ordering chains remain traversable\n- `took_place_at` links resolve to place endpoint records\n\nRegression:\n\n- event endpoint updates do not regress provenance-specific or exhibition-specific workflows\n- existing activity fixtures keep role semantics (`carried_out_by` vs `participant`) intact\n\n### Fixture Anchors — Events Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal period fixture\n- `type: Period` with valid timespan and no activity-only fields.\n\n2. Generic event fixture\n- `type: Event` with participant and causality links.\n\n3. Activity fixture\n- `type: Activity` with `carried_out_by`, `used_specific_object`, `technique`.\n\n4. Temporal bounds fixture\n- timespan with `begin_of_the_begin` and `end_of_the_end` plus display title name.\n\n5. Ordering fixture\n- `before`/`after` links across multiple events with deterministic traversal.\n\n6. Part-of hierarchy fixture\n- event/activity as `part_of` broader period and inherited timeline navigation checks.\n\n7. Place linkage fixture\n- event `took_place_at` stable place reference resolution.\n\n---\n\n## Round 36 Addendum — Groups Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Groups endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Groups endpoint provides records for sets of actors (families, organizations, companies, departments, etc.).\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `Group`\n- Recommended:\n  - `_label`\n  - `classified_as`\n  - `identified_by`\n- Optional:\n  - `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`\n  - `contact_point`, `residence`\n  - `carried_out`, `participated_in`\n  - lifecycle events: `formed_by`, `dissolved_by`\n- Incoming links highlighted include:\n  - actor participation/carrying out activity\n  - object ownership/custody/permanent custody\n  - provenance transfer/payment role links\n  - textual/visual references (`about`, `represents`)\n\n### Implementation Mapping — Groups Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Group endpoint payloads must emit top-level `type: \"Group\"` only.\n\n2. Actor-role differentiation\n- Preserve distinction between `carried_out` (responsible actor) and `participated_in` (non-responsible participant).\n\n3. Lifecycle event integrity\n- Preserve `formed_by` and `dissolved_by` as structured activity nodes with timespan/place when available.\n\n4. Membership hierarchy support\n- Preserve `member_of` links for nested group structures without flattening hierarchy to labels.\n\n5. Custody/ownership interoperability\n- Keep group identities stable across ownership, custody, and provenance transfer/payment role edges.\n\n6. Contact/residence fidelity\n- Preserve optional `contact_point` and `residence` semantics without conflating with identifiers or labels.\n\n7. Assertion support\n- Preserve `attributed_by` relationship assignments for contextual group relationships.\n\n### TDD Additions — Groups Endpoint\n\nAdd failing-first tests for group endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, `type=Group`\n- validates optional lifecycle fields (`formed_by`, `dissolved_by`) against activity/time/place structures\n- validates actor-role arrays (`carried_out`, `participated_in`) with correct reference typing\n\nRoute-level:\n\n- group endpoint returns stable JSON-LD + HAL envelope\n- malformed lifecycle or actor-role payloads fail boundary validation with clear errors\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- provenance routes resolve group edges for title/custody transfer and payment roles\n- object routes resolve group edges for owner/custodian/permanent custodian roles\n- textual/visual routes resolve `about`/`represents` references to group records\n\nRegression:\n\n- group endpoint changes do not regress person endpoint actor semantics\n- membership and lifecycle fixtures stay stable across provider adapter updates\n\n### Fixture Anchors — Groups Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid group\n- required-only group record with context/id/type.\n\n2. Classified + named group\n- group with primary name, nationality/type classifications.\n\n3. Lifecycle fixture\n- group with `formed_by` and `dissolved_by` including timespan and place.\n\n4. Activity role fixture\n- group with both `carried_out` and `participated_in` references.\n\n5. Residence/contact fixture\n- group with `residence` place and `contact_point` identifier.\n\n6. Provenance-role fixture\n- group as transfer/payment recipient/source across provenance activities.\n\n7. Membership hierarchy fixture\n- subgroup linked via `member_of` to parent group.\n\n8. Assertion fixture\n- `attributed_by` assignment connecting related groups contextually.\n\n---\n\n## Round 37 Addendum — People Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: People endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- People endpoint provides records for persons (artists, collectors, museum staff, and others).\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `Person`\n- Recommended:\n  - `_label`\n  - `classified_as`\n  - `identified_by`\n- Optional:\n  - `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`\n  - `contact_point`, `residence`\n  - `carried_out`, `participated_in`\n  - lifecycle events: `born`, `died`\n- Incoming links highlighted include:\n  - activity execution roles (`carried_out_by`)\n  - object ownership/custody/permanent custody roles\n  - provenance transfer/payment role links\n  - textual/visual references (`about`, `represents`)\n\n### Implementation Mapping — People Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- People endpoint payloads must emit top-level `type: \"Person\"` only.\n\n2. Lifecycle event fidelity\n- Preserve `born` and `died` as structured event nodes with timespan/place semantics.\n\n3. Role differentiation\n- Preserve distinction between `carried_out` (responsible activity) and `participated_in` (participatory role).\n\n4. Identity semantics\n- Keep `identified_by` name/identifier patterns distinct; preserve `equivalent` for external identity links.\n\n5. Residence/contact semantics\n- Preserve `residence` as place links and `contact_point` as identifier-like contact/address structures.\n\n6. Group membership integrity\n- Preserve `member_of` relationships to groups for social/professional context.\n\n7. Assertion compatibility\n- Preserve `attributed_by` relationship assignments for contextual or uncertain links.\n\n### TDD Additions — People Endpoint\n\nAdd failing-first tests for people endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, `type=Person`\n- validates lifecycle structures for `born` and `died` when present\n- validates optional role arrays and reference typing (`member_of`, `carried_out`, `participated_in`)\n\nRoute-level:\n\n- people endpoint returns stable JSON-LD + HAL envelope\n- malformed lifecycle/role/contact fields fail boundary validation with clear errors\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- activity/provenance routes resolve person edges for execution, transfer, and payment roles\n- object routes resolve person edges for owner/custodian/permanent custodian roles\n- textual/visual routes resolve `about`/`represents` references to people records\n\nRegression:\n\n- people endpoint changes do not regress groups endpoint actor-role semantics\n- person lifecycle and identity fixtures remain stable across provider adapter updates\n\n### Fixture Anchors — People Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid person\n- required-only person record with context/id/type.\n\n2. Classified + named person\n- person with gender/nationality classifications and primary name.\n\n3. Birth/death lifecycle fixture\n- person with structured `born` and `died` events including timespan/place.\n\n4. Activity role fixture\n- person with `carried_out` and `participated_in` edges.\n\n5. Residence/contact fixture\n- person with place `residence` and street-address `contact_point`.\n\n6. Provenance-role fixture\n- person as source/target in title/custody transfer and payment activities.\n\n7. Group-membership fixture\n- person linked via `member_of` to one or more group records.\n\n8. External identity fixture\n- person with `equivalent` URI to authority source (for example ULAN).\n\n---\n\n## Round 38 Addendum — Physical Objects Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Physical Objects endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Physical Objects endpoint is a core endpoint for tangible artworks/resources.\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `HumanMadeObject`\n- Recommended:\n  - `_label`\n  - `classified_as`\n  - `identified_by`\n- Optional object-centric fields include:\n  - descriptive and linking fields (`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`, `part_of`)\n  - physical fields (`dimension`, `made_of`, `held_or_supported_by`)\n  - rights/ownership/location (`current_owner`, `current_custodian`, `current_permanent_custodian`, `current_location`, `current_permanent_location`)\n  - content linkage (`carries`, `shows`)\n  - lifecycle/activity linkage (`used_for`, `produced_by`, `destroyed_by`, `removed_by`, `modified_by`, `encountered_by`, `changed_ownership_through`)\n- Acquisition objects inside `changed_ownership_through` may include:\n  - `transferred_title_from`\n  - `transferred_title_to`\n- Incoming links highlighted:\n  - `used_specific_object`, `influenced_by`\n  - provenance transfer/move/rights links\n  - textual `carried_by` and visual `shown_by`\n\n### Implementation Mapping — Physical Objects Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Physical object endpoint payloads must emit top-level `type: \"HumanMadeObject\"` only.\n\n2. Physical/conceptual separation\n- Keep object-carried/shown relationships (`carries`, `shows`) distinct from textual/visual work records.\n\n3. Ownership/custody/location semantics\n- Preserve current vs permanent owner/custodian/location distinctions without collapsing into single status fields.\n\n4. Material and dimension fidelity\n- Preserve `made_of` references and dimensional values/units with full numeric precision.\n\n5. Lifecycle provenance integrity\n- Preserve production/destruction/modification/removal/encounter/acquisition chains as structured event nodes.\n\n6. Support relationships\n- Preserve `held_or_supported_by` and `part_of` relations for containment/structural modeling.\n\n7. Acquisition detail preservation\n- Preserve `transferred_title_from`/`transferred_title_to` within ownership-change activities.\n\n### TDD Additions — Physical Objects Endpoint\n\nAdd failing-first tests for physical-object endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, `type=HumanMadeObject`\n- validates object fields for dimensions/materials/location/custody/ownership structures\n- validates lifecycle and acquisition nested activity schemas\n\nRoute-level:\n\n- physical object endpoint returns stable JSON-LD + HAL envelope\n- malformed ownership/custody/location or lifecycle blocks fail boundary validation with clear errors\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- provenance endpoints resolve object links across transfer/custody/move/rights activities\n- textual and visual endpoints resolve reciprocal `carried_by`/`shown_by` links\n- people/groups/places endpoints resolve owner/custodian/location references\n\nRegression:\n\n- object endpoint updates do not regress digital object or abstract work schemas\n- fixture coverage prevents flattening of current/permanent and owner/custodian distinctions\n\n### Fixture Anchors — Physical Objects Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid physical object\n- required-only record with context/id/type.\n\n2. Multi-name + identifier fixture\n- multilingual names plus accession identifier classifications.\n\n3. Dimension + material fixture\n- height/width dimensions with units and multiple `made_of` materials.\n\n4. Ownership/custody/location fixture\n- current vs permanent owner/custodian/location separation.\n\n5. Production fixture\n- `produced_by` with timespan/place/actor.\n\n6. Lifecycle chain fixture\n- object with `modified_by`, `removed_by`, `encountered_by`, `destroyed_by`.\n\n7. Ownership-transfer fixture\n- `changed_ownership_through` acquisition with `transferred_title_from` and `transferred_title_to`.\n\n8. Support/containment fixture\n- object `part_of` and `held_or_supported_by` another physical object.\n\n---\n\n## Round 39 Addendum — Places Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Places endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Places are spatial extents (independent of time and object presence) used as context for activities and locations.\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `Place`\n- Recommended:\n  - `_label`\n  - `classified_as`\n  - `identified_by`\n- Optional:\n  - `referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`\n  - `part_of` (place hierarchy)\n  - `defined_by` (WKT geometry string)\n- Incoming links highlighted:\n  - `took_place_at` from events/activities\n  - object `current_location` / `current_permanent_location`\n  - provenance `moved_from` / `moved_to`\n  - person/group `residence`\n\n### Implementation Mapping — Places Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Places endpoint payloads must emit top-level `type: \"Place\"` only.\n\n2. Geometry fidelity\n- Preserve `defined_by` WKT as canonical geometry representation when provided.\n\n3. Place hierarchy integrity\n- Preserve `part_of` relations for nested place modeling (gallery -> museum -> city -> region).\n\n4. Spatial-role separation\n- Keep place identity separate from group/organization identity (for example museum institution vs museum building/place).\n\n5. Cross-endpoint location semantics\n- Preserve inbound location roles distinctly (`took_place_at`, `current_location`, `moved_from`, `residence`, etc.).\n\n6. Identity and equivalence\n- Preserve stable local IDs and `equivalent` external place authorities (for example TGN/GeoNames).\n\n### TDD Additions — Places Endpoint\n\nAdd failing-first tests for places endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, `type=Place`\n- validates optional `defined_by` WKT as string payload and reference fields as place-typed links\n- validates `part_of` place hierarchy references\n\nRoute-level:\n\n- places endpoint returns stable JSON-LD + HAL envelope\n- malformed WKT or invalid place reference shapes fail boundary validation clearly\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- object endpoints resolve `current_location` and `current_permanent_location` place references\n- event/activity/provenance endpoints resolve `took_place_at`, `moved_from`, `moved_to`\n- people/groups endpoints resolve `residence` place references\n\nRegression:\n\n- place endpoint updates do not regress object/event provenance workflows\n- hierarchy and geometry fixtures remain stable across provider adapter updates\n\n### Fixture Anchors — Places Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid place\n- required-only place record with context/id/type.\n\n2. Classified + named place\n- place with city/region type classification and primary name/identifier.\n\n3. Geometry fixture\n- place with valid `defined_by` WKT polygon.\n\n4. Hierarchy fixture\n- place `part_of` parent place chain (gallery -> city -> state/country).\n\n5. Incoming object-location fixture\n- physical object with `current_location` referencing place endpoint record.\n\n6. Incoming activity-location fixture\n- event/activity `took_place_at` place reference resolution.\n\n7. Move provenance fixture\n- provenance `moved_from`/`moved_to` between two place records.\n\n8. Residence fixture\n- person/group with `residence` place links.\n\n---\n\n## Round 40 Addendum — Provenance Activities Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Provenance Activities endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Provenance Activities endpoint is a higher-complexity event/activity endpoint with required structured `part` activities.\n- Top-level required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `Event` or `Activity`\n  - `classified_as` is required and must include Provenance Activity classification\n  - `part` array is required\n- Required provenance classification discriminator:\n  - one `classified_as.id` must be `http://vocab.getty.edu/aat/300055863`\n- Top-level optional/recommended event features include:\n  - `identified_by`, `timespan`, `took_place_at`, `caused_by`, `influenced_by`, `carried_out_by`, `participant`, `used_specific_object`, temporal ordering and contextual links\n- Every `part` entry has shared activity fields and a required `type`, plus type-specific rules:\n  - `Acquisition`: requires `transferred_title_of`, optional `transferred_title_from` / `transferred_title_to`\n  - `Payment`: optional `paid_amount`, `paid_from`, `paid_to`\n  - `TransferOfCustody`: requires `transferred_custody_of`, optional `transferred_custody_from` / `transferred_custody_to`\n  - `Encounter`: requires `encountered`\n  - `RightAcquisition`: requires `establishes`, optional `invalidates`\n  - `Move`: requires `moved`, optional `moved_from` / `moved_to`\n  - `Promise`: modeled as `type: Activity` with required classification containing `aat:300435599`\n  - `Transfer`: requires `transferred`, optional `transferred_from` / `transferred_to`\n- Rights sub-structure is formally defined (`type: Right`) with identity/classification/applicability/possession dimensions and optional nesting via `part`.\n\n### Implementation Mapping — Provenance Activities Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Provenance discriminator enforcement\n- Treat provenance endpoint entries as valid only when `classified_as` includes `aat:300055863`.\n\n2. Top-level/part separation discipline\n- Preserve top-level provenance context and keep transactional details in explicit `part` entries, not flattened fields.\n\n3. Part-type contract enforcement\n- Validate each part by its declared type-specific required fields before persistence or response emission.\n\n4. Promise typing rule\n- Enforce promise parts as `type: Activity` plus required classification `aat:300435599`.\n\n5. Rights lifecycle fidelity\n- Preserve `RightAcquisition` establish/invalidate semantics with explicit `Right` structures.\n\n6. Monetary fidelity\n- Preserve `Payment.paid_amount` numeric/currency semantics and multi-party flows (`paid_from`/`paid_to`).\n\n7. Transfer ambiguity preservation\n- Preserve ambiguous transfers as `Transfer` when evidence is insufficient for specific acquisition/custody/move typing.\n\n### TDD Additions — Provenance Activities Endpoint\n\nAdd failing-first tests for provenance endpoint conformance:\n\nContract-level:\n\n- validates required top-level fields including provenance classification discriminator and required `part` array\n- validates each `part` by subtype required fields\n- validates rights sub-structures and promise classification rule\n\nRoute-level:\n\n- provenance endpoint returns stable JSON-LD + HAL envelope with structured parts\n- malformed part payloads fail boundary validation with clear subtype-specific errors\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- object endpoints resolve provenance edges (ownership/custody/move/rights/payment relationships)\n- people/groups endpoints resolve transfer and payment roles consistently\n- place endpoints resolve move/took_place_at references for provenance activities\n\nRegression:\n\n- provenance endpoint changes do not regress generic events endpoint behavior\n- part-type fixtures prevent flattening of transactional semantics into lossy summaries\n\n### Fixture Anchors — Provenance Activities Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid provenance activity\n- top-level activity with required provenance classification and non-empty `part`.\n\n2. Acquisition + payment bundle\n- single provenance entry with `Acquisition` and `Payment` parts sharing actors/object.\n\n3. Transfer of custody fixture\n- `TransferOfCustody` with required transferred object and from/to custodians.\n\n4. Move fixture\n- `Move` with moved objects and origin/destination places.\n\n5. Encounter fixture\n- `Encounter` part with discovered object and participating actor.\n\n6. Right acquisition fixture\n- `RightAcquisition` that establishes one right and invalidates another.\n\n7. Promise fixture\n- `type: Activity` part classified with `aat:300435599`.\n\n8. Ambiguous transfer fixture\n- `Transfer` part used when ownership-vs-custody evidence is indeterminate.\n\n---\n\n## Round 41 Addendum — Sets Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Sets endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Sets endpoint describes collections/aggregations across entity types (especially objects, texts, and images).\n- Important modeling constraint:\n  - Set records do not list full members directly; membership is primarily expressed on member entities (`member_of`) or through discovery APIs.\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `Set`\n- Recommended:\n  - `_label`\n  - `classified_as`\n  - `identified_by`\n- Optional:\n  - common fields (`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`)\n  - set-specific fields: `dimension`, `about`, `members_exemplified_by`, `members_contained_by`, `created_by`, `used_for`\n- Validation caveat:\n  - `members_exemplified_by` can only be minimally validated because values may be embedded structures of many endpoint shapes or references.\n- Incoming links highlighted:\n  - `member_of` from most non-person/non-group entities\n  - `used_specific_object` from events/activities (for example exhibition object sets, auction lots)\n\n### Implementation Mapping — Sets Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Sets endpoint payloads must emit top-level `type: \"Set\"` only.\n\n2. Membership modeling discipline\n- Do not force exhaustive inline member lists in set records; preserve membership edges on member entities and discovery/search layers.\n\n3. Exemplification vs containment semantics\n- Preserve `members_exemplified_by` (representative examples) distinctly from `members_contained_by` (physical containment context).\n\n4. Set-aboutness and curation context\n- Preserve `about`, `used_for`, and `created_by` to represent thematic and publication/exhibition intent.\n\n5. Dimension semantics for aggregates\n- Preserve aggregate dimensions (for example member counts) using proper dimension structures.\n\n6. Cross-endpoint set reuse\n- Keep set identifiers stable for use by events/provenance/object workflows (lots, exhibitions, institutional holdings).\n\n### TDD Additions — Sets Endpoint\n\nAdd failing-first tests for set endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, `type=Set`\n- validates optional set-specific fields and shared reference structures\n- allows minimally validated `members_exemplified_by` while still enforcing basic object/reference safety\n\nRoute-level:\n\n- sets endpoint returns stable JSON-LD + HAL envelope\n- malformed set-specific payloads fail boundary validation clearly\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- member entities across endpoints resolve `member_of` links to set records\n- events/provenance can reference sets via `used_specific_object` (for example auction lot sets)\n- physical container linkage through `members_contained_by` resolves to object endpoint records\n\nRegression:\n\n- set endpoint changes do not regress group membership semantics (people/groups remain group-membership domain)\n- discovery/search pipelines remain the mechanism for expanding full set membership\n\n### Fixture Anchors — Sets Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid set\n- required-only set record with context/id/type.\n\n2. Classified collection fixture\n- set classified as collection with primary name and description statement.\n\n3. Creation fixture\n- set with `created_by` creation activity and precise timespan.\n\n4. Aboutness fixture\n- thematic set with `about` links to concept/person/place/object.\n\n5. Exemplified-members fixture\n- set with mixed embedded/reference `members_exemplified_by` samples.\n\n6. Contained-members fixture\n- set with `members_contained_by` physical object reference.\n\n7. Event linkage fixture\n- event/provenance `used_specific_object` references set (exhibition selection or auction lot).\n\n8. Member-of traversal fixture\n- object/text/visual records referencing set via `member_of`, verified through traversal tests.\n\n---\n\n## Round 42 Addendum — Textual Works Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Textual Works endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Textual Works endpoint describes linguistic content as first-class entities.\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `LinguisticObject`\n- Recommended:\n  - `_label`\n  - `classified_as`\n  - `identified_by`\n- Optional fields include:\n  - `referred_to_by`, `equivalent`, `subject_of`, `representation`, `member_of`, `attributed_by`\n  - `language`, `dimension`, `part_of`, `conceptually_part_of`\n  - `content`, `format`, `about`, `subject_to`, `created_by`, `used_for`\n- Incoming links highlighted:\n  - `subject_of` from any endpoint entity\n  - `carries` from Physical Objects\n  - `digitally_carries` from Digital Objects\n\n### Implementation Mapping — Textual Works Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Textual endpoint payloads must emit top-level `type: \"LinguisticObject\"` only.\n\n2. Text/content representation separation\n- Preserve distinction between textual entity metadata and optional inline `content` serialization.\n\n3. Language fidelity\n- Preserve `language` references (and notations when present) for multilingual content behavior.\n\n4. Intellectual structure links\n- Preserve `part_of`, `conceptually_part_of`, and `about` relationships for composition and subject modeling.\n\n5. Carrier relationship integrity\n- Preserve inbound/outbound linkage with physical and digital carriers (`carries`, `digitally_carries`) without conflating with text identity.\n\n6. Rights and publication provenance\n- Preserve `subject_to`, `created_by`, and `used_for` structures for rights and publishing context.\n\n### TDD Additions — Textual Works Endpoint\n\nAdd failing-first tests for textual endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, `type=LinguisticObject`\n- validates optional textual fields (`language`, `content`, `format`, `about`, rights/provenance links)\n- validates composition links to textual/visual/abstract work references\n\nRoute-level:\n\n- textual endpoint returns stable JSON-LD + HAL envelope\n- malformed language/content/format or link structures fail boundary validation clearly\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- physical object routes resolve `carries` links to textual works\n- digital object routes resolve `digitally_carries` links to textual works\n- cross-endpoint `subject_of` traversal remains stable for all core entity families\n\nRegression:\n\n- textual endpoint updates do not regress abstract/visual work endpoint contracts\n- multilingual and identifier fixtures remain stable across provider adapter updates\n\n### Fixture Anchors — Textual Works Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid textual work\n- required-only record with context/id/type.\n\n2. Named + identified textual work\n- text with primary name and identifier (for example ISBN classification).\n\n3. Language + content fixture\n- text with language references and optional `content`/`format`.\n\n4. Subject/about fixture\n- text `about` person/object/concept and reciprocal `subject_of` links.\n\n5. Composition fixture\n- text `part_of` larger text/visual container and `conceptually_part_of` abstract work.\n\n6. Publication provenance fixture\n- `used_for` publishing activity with timespan/place/actor plus `created_by`.\n\n7. Carrier linkage fixture\n- text referenced by both physical `carries` and digital `digitally_carries`.\n\n8. Rights fixture\n- text with `subject_to` rights block and classification.\n\n---\n\n## Round 43 Addendum — Visual Works Endpoint\n\nSource section basis:\n\n- Linked Art API 1.0: Visual Works endpoint\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Visual Works endpoint describes image/appearance content as first-class entities.\n- Required properties:\n  - `@context` includes Linked Art context URI\n  - `id` is dereferenceable HTTP(S) URI\n  - `type` is `VisualItem`\n- Recommended:\n  - `_label`\n  - `classified_as`\n  - `identified_by`\n- Optional fields include:\n  - common fields (`referred_to_by`, `equivalent`, `member_of`, `subject_of`, `attributed_by`)\n  - structure/context fields (`dimension`, `part_of`, `conceptually_part_of`, `about`)\n  - depiction fields (`represents`, `represents_instance_of_type`)\n  - rights/provenance/publication (`subject_to`, `created_by`, `used_for`)\n- Incoming links highlighted:\n  - `representation` from all endpoint families\n  - `shows` from Physical Objects\n  - `digitally_shows` from Digital Objects\n\n### Implementation Mapping — Visual Works Endpoint\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Visual endpoint payloads must emit top-level `type: \"VisualItem\"` only.\n\n2. Depiction semantics separation\n- Preserve `represents` (known entity) separately from `represents_instance_of_type` (unknown individual of known type).\n\n3. Work-layer boundaries\n- Keep visual works distinct from physical/digital carriers while preserving `shows`/`digitally_shows` linkage.\n\n4. Conceptual and structural links\n- Preserve `part_of` and `conceptually_part_of` for compositional and conceptual hierarchy navigation.\n\n5. Style/aboutness fidelity\n- Preserve classification/style and aboutness links without collapsing to plain textual tags.\n\n6. Rights and creation provenance\n- Preserve `subject_to`, `created_by`, and `used_for` structures for governance and publishing context.\n\n### TDD Additions — Visual Works Endpoint\n\nAdd failing-first tests for visual endpoint conformance:\n\nContract-level:\n\n- validates required `@context`, `id`, `type=VisualItem`\n- validates depiction fields (`represents`, `represents_instance_of_type`) with correct reference/type constraints\n- validates optional conceptual/rights/provenance fields against shared contracts\n\nRoute-level:\n\n- visual endpoint returns stable JSON-LD + HAL envelope\n- malformed depiction or link structures fail boundary validation clearly\n- unknown IDs return consistent not-found behavior\n\nIntegration-level:\n\n- physical object routes resolve `shows` links to visual work records\n- digital object routes resolve `digitally_shows` links to visual work records\n- cross-endpoint `representation` traversal remains stable for entities referencing visual works\n\nRegression:\n\n- visual endpoint changes do not regress textual/abstract work endpoint contracts\n- depiction semantics fixtures prevent conflating concrete represented entities with generic represented types\n\n### Fixture Anchors — Visual Works Endpoint Examples\n\nUse these endpoint-specific patterns as fixture seeds:\n\n1. Minimal valid visual work\n- required-only record with context/id/type.\n\n2. Style-classified visual work\n- visual work with style/type classification and primary name.\n\n3. Represents-entity fixture\n- visual work `represents` known entity (for example place/person/object).\n\n4. Represents-instance-of-type fixture\n- visual work with unknown depicted individual expressed via `represents_instance_of_type`.\n\n5. Carrier linkage fixture\n- reciprocal links from physical `shows` and digital `digitally_shows`.\n\n6. Conceptual hierarchy fixture\n- visual work `part_of` and `conceptually_part_of` references.\n\n7. Creation provenance fixture\n- `created_by` creation activity with timespan/actor.\n\n8. Rights/publication fixture\n- visual work with `subject_to` rights and `used_for` publication activity.\n\n---\n\n## Round 44 Addendum — Shared Structures\n\nSource section basis:\n\n- Linked Art API 1.0: About Shared Structures\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Shared structures reused across endpoints include:\n  - Activities\n  - Digital Links\n  - Dimensions\n  - Identifiers\n  - Monetary Amounts\n  - Names\n  - Rights\n  - References\n  - Statements\n  - TimeSpans\n  - Types/Concepts\n  - Relationships\n- Embedded shared structures inherit the parent record `@context` and should not repeat `@context` inline.\n- If a usually-embedded structure (for example `Name`, `Dimension`) has its own dereferenceable `id` with richer remote data, embedded instance must include `_complete: false`.\n- Without `_complete: false`, consumers should assume the embedded structure is complete and URI is informational.\n\n### Implementation Mapping — Shared Structures\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Context inheritance rule\n- Do not emit nested `@context` for embedded shared structures inside endpoint payloads.\n\n2. Standalone structure rule\n- If shared structures are published as standalone Linked Art resources, include root `@context`.\n\n3. Partial-embed signaling\n- Enforce `_complete: false` when embedding structures that have richer canonical detail at their own `id`.\n\n4. Contract consistency\n- Reuse one shared contract layer for Names/Identifiers/Dimensions/TimeSpans/etc. across all endpoints.\n\n5. Reference integrity\n- Preserve stable `id` references in embedded structures to enable deferred retrieval and graph joins.\n\n### TDD Additions — Shared Structures\n\nAdd failing-first tests for shared-structure conformance:\n\nContract-level:\n\n- validates embedded shared structures do not include nested `@context`\n- validates standalone shared-structure documents include required root `@context`\n- validates `_complete: false` requirement for partial embedded structures with dereferenceable IDs\n\nRoute-level:\n\n- endpoint responses consistently apply shared structure schemas across entity families\n- malformed shared structures fail boundary validation with clear structure-specific errors\n\nIntegration-level:\n\n- consumers can resolve referenced shared-structure `id` values for richer retrieval flows\n- mixed complete/partial embeddings behave predictably across provider adapters\n\nRegression:\n\n- adding provider slices does not fork shared structure semantics by endpoint\n- `_complete` signaling remains stable in snapshots for names/dimensions/identifiers\n\n### Fixture Anchors — Shared Structures Examples\n\nUse these shared-structure patterns as fixture seeds:\n\n1. Embedded name (complete) fixture\n- embedded `Name` with no nested `@context`, no `_complete` flag.\n\n2. Embedded name (partial) fixture\n- embedded `Name` with dereferenceable `id` and `_complete: false`.\n\n3. Embedded dimension fixture\n- dimension with value/unit and no nested `@context`.\n\n4. Embedded timespan fixture\n- `TimeSpan` with fuzzy bounds and display label.\n\n5. Standalone shared-structure fixture\n- standalone shared structure resource with root `@context`.\n\n6. Relationship assignment fixture\n- embedded relationship structure with reference integrity and shared schema compliance.\n\n---\n\n## Round 45 Addendum — Shared Structure: Activities\n\nSource section basis:\n\n- Linked Art API 1.0: Shared structure for Activities\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Activities are often embedded inside entity records for lifecycle and usage context.\n- Core usage covers:\n  - beginnings (`Production`, `Creation`, `Formation`, `Birth`)\n  - endings (`Destruction`, `Dissolution`, `Death`)\n  - other activity context (`Modification`, `Encounter`, generic `Activity`, etc.)\n- Shared activity structure:\n  - required `type`\n  - optional `id` with `_complete: false` when embedded form is partial and richer data exists remotely\n  - common contextual fields: `identified_by`, `classified_as`, `referred_to_by`, `took_place_at`, `timespan`, temporal ordering, causal/influence, participants, `used_specific_object`, `technique`, `part`\n- Type-conditional restriction:\n  - `Birth`/`Death` do not use `carried_out_by`, `influenced_by`, `used_specific_object`, `technique`, or `part`\n- `PartRemoval` adds `diminished` reference semantics.\n- Activity classes vary by endpoint family (for example `Person` uses `Birth`/`Death`, `Physical Object` uses `Production`/`Destruction` plus others, etc.).\n\n### Implementation Mapping — Shared Activities\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Shared activity contract reuse\n- Use one activity schema layer across all endpoint families, then apply endpoint/type-specific constraints.\n\n2. Partial embed signaling\n- Enforce `_complete: false` for embedded activity nodes with dereferenceable IDs when embedded payload is incomplete.\n\n3. Type-conditional guards\n- Enforce forbidden fields for `Birth`/`Death` activity types at validation boundary.\n\n4. Lifecycle event precision\n- Preserve beginning/end activity distinctions rather than flattening into single status/date fields.\n\n5. Participation semantics\n- Preserve role differences (`carried_out_by` vs other participation/context fields) where applicable.\n\n6. Temporal ordering fidelity\n- Preserve `timespan`, `during`, `before`, `after`, and `caused_by` without lossy date-only collapse.\n\n7. Nested activity support\n- Preserve `part` sub-activities for complex activities except where type restrictions prohibit it.\n\n### TDD Additions — Shared Activities\n\nAdd failing-first tests for shared activity structure conformance:\n\nContract-level:\n\n- validates required `type` and shared optional field schemas across embedded activity nodes\n- validates `_complete: false` requirement for partial embedded activities with resolvable IDs\n- rejects forbidden fields on `Birth`/`Death`\n\nRoute-level:\n\n- endpoints emitting embedded activities conform to shared activity schema + endpoint-specific type allowlists\n- malformed activity nodes fail boundary validation with explicit field/type diagnostics\n\nIntegration-level:\n\n- lifecycle links (`produced_by`, `created_by`, `born`, `died`, `destroyed_by`, etc.) resolve consistently across endpoints\n- `used_for`, `carried_out`, and `participated_in` activity traversals preserve actor-role semantics\n\nRegression:\n\n- activity schema updates do not diverge by endpoint family\n- nested-part and temporal-ordering fixtures remain stable across provider adapter updates\n\n### Fixture Anchors — Shared Activities Examples\n\nUse these shared-activity patterns as fixture seeds:\n\n1. Minimal embedded activity\n- embedded activity with required `type` and basic timespan/place.\n\n2. Partial embedded activity fixture\n- activity with `id` and `_complete: false` indicating richer standalone representation.\n\n3. Birth/death restriction fixture\n- invalid payloads proving forbidden fields are rejected for `Birth`/`Death`.\n\n4. Production activity fixture\n- production with technique, timespan, place, actor, and influence links.\n\n5. PartRemoval fixture\n- `PartRemoval` activity with `diminished` object reference.\n\n6. Nested part fixture\n- complex activity with `part` sub-activities for non-restricted types.\n\n7. Temporal ordering fixture\n- activity with `during`, `before`, `after`, `caused_by` chain.\n\n8. Actor role fixture\n- distinguishes `carried_out_by` vs participation context across related activities.\n\n---\n\n## Round 46 Addendum — Shared Structure: Digital Links\n\nSource section basis:\n\n- Linked Art API 1.0: Shared structure for Digital Links\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Digital Links provide an embedding shortcut for external digital resources (for example web pages/images) within core entity records.\n- Structure is nested:\n  - embedded work (`VisualItem` or `LinguisticObject`)\n  - embedded `DigitalObject` inside that work\n- Embedded work constraints:\n  - `type` required and must be `VisualItem` or `LinguisticObject`\n  - exactly one of:\n    - `digitally_shown_by` (for `VisualItem`)\n    - `digitally_carried_by` (for `LinguisticObject`)\n  - optional `_complete: false` when `id` exists and richer remote representation is available\n- Embedded digital object constraints:\n  - `type` required and must be `DigitalObject`\n  - optional `access_point` entries must each contain required `{ id, type: \"DigitalObject\" }`\n  - optional `_complete: false` signaling for partial embedded form\n  - optional digital metadata (`digitally_available_via`, `format`, `conforms_to`, etc.)\n- Incoming usage:\n  - `representation` when embedded work is visual\n  - `subject_of` when embedded work is linguistic\n\n### Implementation Mapping — Shared Digital Links\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Nested one-of enforcement\n- Enforce class-dependent exclusive linkage:\n  - `VisualItem` -> must include `digitally_shown_by` only\n  - `LinguisticObject` -> must include `digitally_carried_by` only\n\n2. Embedded partiality signaling\n- Require `_complete: false` when embedded work/digital object includes dereferenceable `id` but is not fully represented inline.\n\n3. Access point strictness\n- Enforce `access_point` entry shape (`id` + `type: DigitalObject`) and treat as retrieval locators, not identity replacements.\n\n4. Work-vs-carriership separation\n- Preserve distinction between work semantics (visual/textual content) and carrier/delivery semantics (digital objects/services).\n\n5. Shared-contract reuse\n- Reuse Name/Type/Statement/Language shared structures inside embedded work and digital object nodes.\n\n### TDD Additions — Shared Digital Links\n\nAdd failing-first tests for digital-link structure conformance:\n\nContract-level:\n\n- validates embedded work `type` allowlist (`VisualItem` | `LinguisticObject`)\n- validates exclusive/class-appropriate presence of `digitally_shown_by` vs `digitally_carried_by`\n- validates embedded digital object `type=DigitalObject` and access-point child shape\n- validates `_complete: false` requirement for partial embedded nodes with dereferenceable IDs\n\nRoute-level:\n\n- entity endpoints embedding digital links conform to nested shared structure contracts\n- malformed nested work/digital object payloads fail boundary validation with explicit path-level errors\n\nIntegration-level:\n\n- `representation` traversals resolve visual embedded links and downstream digital object access points\n- `subject_of` traversals resolve linguistic embedded links and downstream digital object access points\n- standalone digital object endpoints remain consistent with embedded digital link nodes\n\nRegression:\n\n- updates to embedded digital-link logic do not regress full digital object endpoint semantics\n- one-of constraint fixtures prevent ambiguous or dual-mode linkage in one embedded work node\n\n### Fixture Anchors — Shared Digital Links Examples\n\nUse these shared digital-link patterns as fixture seeds:\n\n1. Visual embedding fixture\n- embedded `VisualItem` with required `digitally_shown_by` and no `digitally_carried_by`.\n\n2. Linguistic embedding fixture\n- embedded `LinguisticObject` with required `digitally_carried_by` and language metadata.\n\n3. Nested digital object fixture\n- embedded `DigitalObject` with classification/name and valid `access_point`.\n\n4. Partial embedded node fixture\n- embedded work/digital object with `id` and `_complete: false`.\n\n5. Access-point validation fixture\n- invalid/missing `id` or incorrect `type` in `access_point` is rejected.\n\n6. Service linkage fixture\n- embedded digital object with `digitally_available_via` and `conforms_to` spec link.\n\n---\n\n## Round 47 Addendum — Shared Structure: Activities (Reconfirmation)\n\nSource section basis:\n\n- Linked Art API 1.0: Shared structure for Activities (repeat ingestion)\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- This round reconfirms the same activity-shared-structure rules already captured in Round 45.\n- No net-new schema fields, type rules, or endpoint-specific constraints were introduced beyond Round 45.\n- Reconfirmed constraints include:\n  - shared embedded activity structure with required `type`\n  - partial embed signaling via `_complete: false`\n  - `Birth`/`Death` field restrictions\n  - endpoint-family mapping of beginning/ending/other activity classes\n  - `PartRemoval.diminished` usage\n\n### Implementation Mapping — Shared Activities (Reconfirmation)\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. No new implementation scope\n- Keep Round 45 implementation mapping as canonical; no additional code-path requirements from this round.\n\n2. Stability expectation\n- Treat this repeated docs drop as a consistency checkpoint for existing activity boundary validation and serializers.\n\n### TDD Additions — Shared Activities (Reconfirmation)\n\nAdd/retain failing-first tests for stability:\n\nContract-level:\n\n- keep Round 45 activity conformance suite as authoritative and unchanged\n\nRegression:\n\n- add/retain a snapshot guard that duplicate spec ingestion does not change schemas or route payload shapes\n- ensure `Birth`/`Death` forbidden-field checks remain active\n\n### Fixture Anchors — Shared Activities (Reconfirmation)\n\nUse existing Round 45 fixtures as anchors:\n\n1. Partial activity embed fixture with `_complete: false`.\n2. Birth/death restricted-field negative fixture.\n3. Production activity with timespan/place/technique/actor.\n4. Nested `part` fixture for non-restricted activity types.\n\n---\n\n## Round 48 Addendum — Shared Structure: Dimensions\n\nSource section basis:\n\n- Linked Art API 1.0: Shared structure for Dimensions\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- A Dimension combines:\n  - numeric `value`\n  - required `unit` (`MeasurementUnit`)\n  - classification of what is being measured\n- Core requirements:\n  - `type` required and must be `Dimension`\n  - `value` required (number)\n  - `unit` required (MeasurementUnit reference/object)\n- Optional semantics:\n  - uncertainty/range bounds: `upper_value_limit`, `lower_value_limit`\n  - textual rendering via `identified_by` (Name)\n  - provenance of measurement via `assigned_by` (AttributeAssignment/measurement activity)\n  - `_complete: false` when embedded dimension has dereferenceable `id` with richer remote data\n- Incoming usage:\n  - `dimension` across many endpoints (especially physical/digital objects)\n  - `duration` on `TimeSpan` as dimensionalized temporal length\n\n### Implementation Mapping — Shared Dimensions\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Required-field strictness\n- Enforce `type=Dimension`, numeric `value`, and required `unit` at boundary validation.\n\n2. Unit integrity\n- Require `unit.type = MeasurementUnit` and preserve unit identifiers/labels for interoperability.\n\n3. Uncertainty modeling\n- Preserve `upper_value_limit` and `lower_value_limit` as explicit uncertainty bounds, not inferred from display strings.\n\n4. Display-text separation\n- Preserve human-readable dimensional strings in `identified_by` without replacing canonical numeric/value/unit fields.\n\n5. Measurement provenance\n- Preserve `assigned_by` as explicit measurement activity/provenance trace when available.\n\n6. Partial-embed signaling\n- Enforce `_complete: false` for partial embedded dimension nodes with richer dereferenceable representations.\n\n### TDD Additions — Shared Dimensions\n\nAdd failing-first tests for dimension structure conformance:\n\nContract-level:\n\n- validates required `type=Dimension`, numeric `value`, and required `unit` object/reference\n- validates optional uncertainty bounds as numbers when present\n- validates `assigned_by` activity structure and `identified_by` name shape\n- validates `_complete: false` requirement for partial embedded dimensions with resolvable IDs\n\nRoute-level:\n\n- entity endpoints embedding dimensions conform to shared dimension schema\n- malformed dimension/unit/bound payloads fail boundary validation with explicit field-path errors\n\nIntegration-level:\n\n- object/text/digital/person/group endpoints preserve dimensional semantics consistently\n- timespan duration dimensions interoperate with time modeling without type ambiguity\n\nRegression:\n\n- dimension serializer changes do not collapse bounds into strings or lose unit typing\n- provider adapter updates preserve measurement provenance in `assigned_by`\n\n### Fixture Anchors — Shared Dimensions Examples\n\nUse these shared-dimension patterns as fixture seeds:\n\n1. Minimal valid dimension\n- `type`, numeric `value`, and valid `MeasurementUnit`.\n\n2. Uncertain dimension fixture\n- dimension with `lower_value_limit` and `upper_value_limit`.\n\n3. Display-name fixture\n- `identified_by` name expressing human-readable measurement string.\n\n4. Measurement provenance fixture\n- `assigned_by` measurement activity with classifier and measuring actor.\n\n5. Partial dimension fixture\n- embedded dimension with dereferenceable `id` and `_complete: false`.\n\n6. Duration dimension fixture\n- `TimeSpan` duration represented as a dimension with unit and numeric value.\n\n---\n\n## Round 49 Addendum — Shared Structure: Concept References\n\nSource section basis:\n\n- Linked Art API 1.0: Concept References\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Concept references (Types) are core embedded structures across almost all entities.\n- Required fields for embedded concept reference:\n  - `id` (URI)\n  - `type` in allowlist: `Type`, `Currency`, `Language`, `Material`, `MeasurementUnit`\n- Recommended:\n  - `_label`\n- Optional:\n  - `equivalent`\n  - `notation` (commonly used especially for `Language` tags)\n  - `classified_as` (meta-classification of concept)\n- Specialized concept-reference classes:\n  - `Language` for human language\n  - `Material` for physical composition\n  - `Currency` for monetary amounts\n  - `MeasurementUnit` for dimensions\n- Full standalone concept records are handled by the Concept endpoint; this shared structure is for embedded references.\n\n### Implementation Mapping — Shared Concept References\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Concept type allowlist enforcement\n- Enforce strict embedded concept-reference `type` allowlist at validation boundary.\n\n2. URI-first identity\n- Preserve canonical concept `id` URIs as authoritative identity keys for cross-dataset interoperability.\n\n3. Meta-classification preservation\n- Preserve `classified_as` on concept references to support meta-typing (for example “Painting” classified as “Type of Work”).\n\n4. Notation handling\n- Preserve `notation` values, especially for language tags/codes, without replacing URI identity semantics.\n\n5. Embedded-vs-full-record separation\n- Keep embedded concept references lightweight; use Concept endpoint for full concept expansion.\n\n### TDD Additions — Shared Concept References\n\nAdd failing-first tests for concept-reference conformance:\n\nContract-level:\n\n- validates required `id` + `type` for embedded concept references\n- validates `type` is in allowed concept-reference class set\n- validates optional `notation`, `equivalent`, and nested `classified_as` structures\n\nRoute-level:\n\n- all endpoint payloads embedding concepts conform to shared concept-reference schema\n- malformed concept references fail boundary validation with explicit path-level errors\n\nIntegration-level:\n\n- concept references resolve consistently across:\n  - `classified_as` (all entities)\n  - `technique` / `influenced_by` (activities)\n  - `about` (textual/visual works)\n  - `language` (linguistic objects)\n  - `currency` (monetary amounts)\n  - `unit` (dimensions)\n  - `made_of` (objects/material composition)\n\nRegression:\n\n- provider adapter updates do not drift concept reference typing or URI identity behavior\n- meta-classification fixtures remain stable across endpoint families\n\n### Fixture Anchors — Shared Concept References Examples\n\nUse these concept-reference patterns as fixture seeds:\n\n1. Minimal type reference\n- embedded `Type` with required URI `id` and `type`.\n\n2. Meta-typed concept fixture\n- concept with nested `classified_as` meta-type (for example work type hierarchy).\n\n3. Language reference fixture\n- `Language` with notation tag/code plus label.\n\n4. Currency reference fixture\n- `Currency` used in monetary amount structure.\n\n5. Measurement unit fixture\n- `MeasurementUnit` used in dimension structure.\n\n6. Material reference fixture\n- `Material` used in object `made_of` array.\n\n---\n\n## Round 50 Addendum — Shared Structure: Identifiers\n\nSource section basis:\n\n- Linked Art API 1.0: Identifiers\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Identifiers are non-natural-language codes assigned to resources in context.\n- Shared identifier structure is separate from Names:\n  - no `language`\n  - no translation/alternative-form semantics like names\n- Required fields:\n  - `type` must be `Identifier`\n  - `content` must be string\n- Optional/recommended:\n  - `id`, `_label`, `_complete`\n  - `classified_as`, `identified_by` (display name for identifier), `referred_to_by`, `assigned_by`\n- `_complete: false` is required when embedded identifier with dereferenceable `id` is partial and richer remote form exists.\n- Incoming usage:\n  - `identified_by` across all endpoints\n  - `contact_point` for Person/Group endpoints\n\n### Implementation Mapping — Shared Identifiers\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type/content strictness\n- Enforce `type=Identifier` and required string `content` at boundary validation.\n\n2. Identifier-vs-name separation\n- Keep identifier semantics distinct from Name semantics (no language/translation assumptions).\n\n3. Classification fidelity\n- Preserve identifier type classifications (for example accession number, ISBN) via `classified_as`.\n\n4. Assignment provenance\n- Preserve `assigned_by` assignment activities with timespan/actor context where available.\n\n5. Partial embed signaling\n- Enforce `_complete: false` for embedded identifiers with dereferenceable IDs and incomplete inline payload.\n\n6. Contact point reuse\n- Reuse Identifier shared contract for `contact_point` fields on Person/Group endpoints.\n\n### TDD Additions — Shared Identifiers\n\nAdd failing-first tests for identifier structure conformance:\n\nContract-level:\n\n- validates required `type=Identifier` + string `content`\n- rejects identifier payloads with invalid/non-string content\n- validates optional classification/display-name/assignment fields\n- validates `_complete: false` requirement for partial embedded identifiers with resolvable IDs\n\nRoute-level:\n\n- all endpoint payloads embedding identifiers conform to shared identifier schema\n- malformed identifier/classification/assignment blocks fail boundary validation with explicit path-level errors\n\nIntegration-level:\n\n- identifier structures resolve consistently through `identified_by` across endpoint families\n- person/group `contact_point` fields validate and serialize as identifiers\n\nRegression:\n\n- provider adapter updates do not collapse identifiers into names or lose assignment provenance\n- classification fixtures (accession/ISBN/etc.) remain stable across endpoints\n\n### Fixture Anchors — Shared Identifiers Examples\n\nUse these shared-identifier patterns as fixture seeds:\n\n1. Minimal valid identifier\n- `type: Identifier` with required string `content`.\n\n2. Classified identifier fixture\n- identifier classified as accession/ISBN style concept.\n\n3. Display-name fixture\n- identifier with `identified_by` name for UI display semantics.\n\n4. Assignment provenance fixture\n- identifier with `assigned_by` activity including timespan and assigning group/person.\n\n5. Partial identifier fixture\n- embedded identifier with dereferenceable `id` and `_complete: false`.\n\n6. Contact-point fixture\n- person/group `contact_point` modeled and validated as identifier structure.\n\n---\n\n## Round 51 Addendum — Shared Structure: Monetary Amounts\n\nSource section basis:\n\n- Linked Art API 1.0: Monetary Amounts\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Monetary Amounts parallel Dimensions but use `currency` instead of `unit`.\n- Required fields:\n  - `type` must be `MonetaryAmount`\n  - numeric `value`\n  - required `currency` (must follow Currency concept-reference rules)\n- Optional/recommended:\n  - `id`, `_label`, `_complete`\n  - `classified_as`, `identified_by`, `upper_value_limit`, `lower_value_limit`, `referred_to_by`\n- `_complete: false` is required when embedded amount has dereferenceable `id` and richer remote representation exists.\n- Primary usage in Linked Art model/API:\n  - `paid_amount` within Provenance `Payment` parts\n  - also usable as `dimension` in other contexts (for example set-level pricing/valuation signals)\n\n### Implementation Mapping — Shared Monetary Amounts\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type/value/currency strictness\n- Enforce `type=MonetaryAmount`, numeric `value`, and required `currency` at boundary validation.\n\n2. Currency integrity\n- Require `currency.type=Currency` and preserve authoritative concept URI/notation (for example ISO code notation).\n\n3. Uncertainty bounds support\n- Preserve optional `upper_value_limit` and `lower_value_limit` for uncertain/estimated amounts.\n\n4. Display-text separation\n- Preserve `identified_by` display text without replacing canonical numeric+currency representation.\n\n5. Provenance payment wiring\n- Preserve `paid_amount` semantics inside provenance `Payment` parts without flattening into generic note fields.\n\n6. Partial embed signaling\n- Enforce `_complete: false` for embedded partial monetary amount nodes with dereferenceable IDs.\n\n### TDD Additions — Shared Monetary Amounts\n\nAdd failing-first tests for monetary amount conformance:\n\nContract-level:\n\n- validates required `type=MonetaryAmount`, numeric `value`, and `currency` reference structure\n- validates optional bounds (`upper_value_limit`, `lower_value_limit`) as numeric\n- validates optional classification/display/reference fields\n- validates `_complete: false` requirement for partial embedded monetary amounts with resolvable IDs\n\nRoute-level:\n\n- provenance/payment payloads embedding `paid_amount` conform to shared monetary schema\n- malformed value/currency/bounds payloads fail boundary validation with explicit path-level errors\n\nIntegration-level:\n\n- provenance `Payment` parts preserve paid amount and currency semantics end-to-end\n- set/object dimension contexts using monetary amounts remain compatible with shared dimension pipelines\n\nRegression:\n\n- serializer updates do not collapse monetary amounts into raw strings\n- currency URI and notation handling remain stable across provider adapters\n\n### Fixture Anchors — Shared Monetary Amounts Examples\n\nUse these shared monetary patterns as fixture seeds:\n\n1. Minimal valid monetary amount\n- required `type`, numeric `value`, and `currency`.\n\n2. Classified amount fixture\n- amount classified as starting price/estimate/hammer price.\n\n3. Display-title fixture\n- amount with `identified_by` display name text.\n\n4. Uncertainty fixture\n- amount with lower/upper value bounds.\n\n5. Payment integration fixture\n- provenance `Payment.paid_amount` with payer/payee links.\n\n6. Partial amount fixture\n- embedded amount with dereferenceable `id` and `_complete: false`.\n\n---\n\n## Round 52 Addendum — Shared Structure: Names\n\nSource section basis:\n\n- Linked Art API 1.0: Names\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Names are linguistic labels for entities and are shared across all endpoints.\n- Required fields:\n  - `type` must be `Name`\n  - `content` must be string\n- Recommended/optional:\n  - `classified_as`, `language` (recommended)\n  - `id`, `_label`, `_complete`, `part`, `identified_by`, `referred_to_by`, `assigned_by`\n- `_complete: false` is required when embedded name has dereferenceable `id` and richer remote representation exists.\n- Names can be decomposed via recursive `part` structures (for example subtitle component).\n- Unlike Identifiers, Names are linguistic and language-tag-aware.\n\n### Implementation Mapping — Shared Names\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type/content strictness\n- Enforce `type=Name` and required string `content` at boundary validation.\n\n2. Name-vs-identifier separation\n- Keep Name semantics linguistic (with optional language) and separate from Identifier code semantics.\n\n3. Language fidelity\n- Preserve one or more `language` references/notations for multilingual name handling.\n\n4. Recursive name-part support\n- Preserve `part` arrays as nested Name structures for compound/appellative names.\n\n5. Classification fidelity\n- Preserve `classified_as` distinctions (primary name, subtitle, display title, etc.).\n\n6. Partial embed signaling\n- Enforce `_complete: false` for embedded partial name nodes with dereferenceable IDs.\n\n7. Assignment readiness\n- Support optional `assigned_by` structure even if use cases are currently limited.\n\n### TDD Additions — Shared Names\n\nAdd failing-first tests for name structure conformance:\n\nContract-level:\n\n- validates required `type=Name` + string `content`\n- validates optional language/classification/referred_to_by/identified_by fields\n- validates recursive `part` structures as Name-only nested nodes\n- validates `_complete: false` requirement for partial embedded names with resolvable IDs\n\nRoute-level:\n\n- endpoint payloads embedding names conform to shared name schema\n- malformed name/language/part payloads fail boundary validation with explicit path-level errors\n\nIntegration-level:\n\n- multilingual names remain stable across object/person/group/place/textual/visual endpoints\n- display-name patterns (`identified_by` on names) remain consistent for UI surfaces\n\nRegression:\n\n- updates do not collapse linguistic names into identifier semantics\n- nested-name part fixtures remain stable across provider adapter updates\n\n### Fixture Anchors — Shared Names Examples\n\nUse these shared-name patterns as fixture seeds:\n\n1. Minimal valid name\n- `type: Name` with required `content`.\n\n2. Classified primary name fixture\n- name classified as primary name.\n\n3. Multilingual name fixture\n- single name with multiple language references/notations.\n\n4. Nested part fixture\n- compound name with subtitle `part` node.\n\n5. Display-title fixture\n- name `identified_by` another name classified as display title.\n\n6. Partial name fixture\n- embedded name with dereferenceable `id` and `_complete: false`.\n\n---\n\n## Round 53 Addendum — Shared Structure: Rights\n\nSource section basis:\n\n- Linked Art API 1.0: Rights\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Rights structure represents machine-comparable rights assertions for intellectual works.\n- Required fields:\n  - `type` must be `Right`\n- Recommended/optional:\n  - `identified_by`, `classified_as` (recommended)\n  - `id`, `_label`, `_complete`, `referred_to_by`, `possessed_by`\n- Rights class/type semantics are conveyed through `classified_as` concept references (for example CC URIs).\n- `_complete: false` required when embedded right has dereferenceable `id` and richer remote representation exists.\n- Incoming usage emphasized:\n  - `subject_to` on intellectual resources (Textual Work, Visual Work, Abstract Work, Statement)\n\n### Implementation Mapping — Shared Rights\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Enforce `type=Right` at boundary validation for all embedded rights structures.\n\n2. Rights-classification fidelity\n- Preserve `classified_as` URIs as canonical machine-comparable rights descriptors.\n\n3. Human-readable display support\n- Preserve `identified_by` names (for example “Public Domain”) for UI and downstream reporting.\n\n4. Holder modeling\n- Preserve optional `possessed_by` actor references where right-holder context is provided.\n\n5. Partial embed signaling\n- Enforce `_complete: false` for partial embedded rights nodes with dereferenceable IDs.\n\n6. Subject linkage integrity\n- Preserve `subject_to` edges on intellectual works without flattening rights into unstructured string fields.\n\n### TDD Additions — Shared Rights\n\nAdd failing-first tests for rights structure conformance:\n\nContract-level:\n\n- validates required `type=Right`\n- validates recommended `classified_as` and `identified_by` structures when present\n- validates optional `possessed_by` actor references\n- validates `_complete: false` requirement for partial embedded rights with resolvable IDs\n\nRoute-level:\n\n- endpoint payloads embedding rights through `subject_to` conform to shared rights schema\n- malformed rights/classification/holder payloads fail boundary validation with explicit path-level errors\n\nIntegration-level:\n\n- textual/visual/abstract/statement endpoints preserve consistent `subject_to` rights modeling\n- rights classifications remain interoperable with concept-reference rules and external rights vocab URIs\n\nRegression:\n\n- provider adapter updates do not collapse structured rights blocks into plain text\n- rights display labels and machine-readable URIs remain synchronized in snapshots\n\n### Fixture Anchors — Shared Rights Examples\n\nUse these shared-rights patterns as fixture seeds:\n\n1. Minimal valid right\n- embedded right with required `type`.\n\n2. Classified rights fixture\n- right classified with external rights URI (for example CC0).\n\n3. Display title fixture\n- right with `identified_by` display title name.\n\n4. Holder fixture\n- right with `possessed_by` person/group references.\n\n5. Subject linkage fixture\n- textual/visual/abstract resource linked via `subject_to` to right.\n\n6. Partial right fixture\n- embedded right with dereferenceable `id` and `_complete: false`.\n\n---\n\n## Round 54 Addendum — Shared Structure: References\n\nSource section basis:\n\n- Linked Art API 1.0: References\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- References are lightweight cross-resource links and must remain clearly distinct from embedded full structures.\n- Canonical reference shape:\n  - required `id` (dereferenceable URI)\n  - required `type` (must match dereferenced resource type)\n  - recommended `_label`\n- Reference semantics:\n  - references are inherently incomplete and do not include `_complete`\n  - dereferencing should yield canonical record with same `id` and `type`\n- Allowed optional enrichments on references:\n  - `equivalent` for external-system identity alignment\n  - `notation` (especially language tags/codes for language references)\n- Types are a special reference case and may include meta-classification to support processing when external vocab resources are not Linked Art-native.\n- Client guidance from spec:\n  - proactively follow references and pre-cache descriptions for responsive UI behavior.\n\n### Implementation Mapping — Shared References\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict reference envelope\n- Treat `id`/`type`/`_label` (+ optional `equivalent`/`notation`) as the only valid reference payload shape.\n\n2. No `_complete` on references\n- Do not emit `_complete` for references; reserve `_complete` logic for partially embedded shared structures.\n\n3. Type identity consistency\n- Enforce that reference `type` matches dereferenced record `type` in validation/integration checks.\n\n4. Embedded-vs-reference boundary\n- Reject hybrid payloads that mix reference-only shape with embedded-structure-only fields.\n\n5. External equivalence handling\n- Preserve optional `equivalent` links for reconciliation without replacing local canonical IDs.\n\n6. Language notation support\n- Preserve `notation` when references are language concepts to aid i18n consumers.\n\n7. Fetch/caching readiness\n- Keep references stable and minimal so clients can dereference/cross-cache deterministically.\n\n### TDD Additions — Shared References\n\nAdd failing-first tests for reference conformance:\n\nContract-level:\n\n- validates required `id` + `type` for all reference nodes\n- validates absence of `_complete` on references\n- validates optional `_label`, `equivalent`, `notation` fields\n- rejects embedded-only fields on reference nodes\n\nRoute-level:\n\n- endpoint payloads emit reference nodes in canonical lightweight shape\n- malformed references fail boundary validation with explicit path-level diagnostics\n\nIntegration-level:\n\n- dereferenced records match reference `id` + `type`\n- cross-endpoint traversal via references remains stable (object->owner/place/set/work etc.)\n- language reference notations round-trip for i18n usage\n\nRegression:\n\n- provider updates do not accidentally expand references into inconsistent partial embeds\n- reference serializer remains consistent across all endpoint families\n\n### Fixture Anchors — Shared References Examples\n\nUse these shared-reference patterns as fixture seeds:\n\n1. Minimal valid reference\n- reference with required `id` and `type`.\n\n2. Labeled reference fixture\n- reference including recommended `_label`.\n\n3. Equivalent-link fixture\n- local reference with `equivalent` external authority URI.\n\n4. Language notation fixture\n- language reference with notation tag/code.\n\n5. Reference-vs-embed negative fixture\n- payload wrongly combining reference shape with embedded-only fields is rejected.\n\n6. Dereference consistency fixture\n- referenced resource resolves with matching `id` and `type`.\n\n---\n\n## Round 55 Addendum — Shared Structure: Statements\n\nSource section basis:\n\n- Linked Art API 1.0: Statements\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Statements are embedded human-readable textual expressions about entities.\n- Required fields:\n  - `type` must be `LinguisticObject`\n  - `content` must be string\n- Recommended/optional:\n  - `classified_as`, `language`, `identified_by` (recommended)\n  - `id`, `_label`, `_complete`, `referred_to_by`, `format`, `assigned_by`, `subject_to`, `created_by`\n- `_complete: false` required when embedded statement has dereferenceable `id` and richer remote representation exists.\n- Primary incoming usage:\n  - `referred_to_by` across essentially all endpoint families.\n- Statements support both:\n  - internationalized textual content (`language`)\n  - structured rights over statement text (`subject_to`)\n\n### Implementation Mapping — Shared Statements\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type/content strictness\n- Enforce `type=LinguisticObject` and required string `content` for statement nodes.\n\n2. Statement-vs-textual-work boundary\n- Keep embedded statement semantics distinct from standalone Textual Work endpoint records.\n\n3. Classification and language fidelity\n- Preserve statement purpose classification (description/note/etc.) and language references/notations.\n\n4. Format-aware content handling\n- Preserve optional `format` when `content` is non-plain text media.\n\n5. Rights and provenance support\n- Preserve `subject_to`, `assigned_by`, and `created_by` for statement governance/provenance.\n\n6. Nested statement support\n- Preserve `referred_to_by` on statements for statement-about-statement use cases.\n\n7. Partial embed signaling\n- Enforce `_complete: false` for partial embedded statements with dereferenceable IDs.\n\n### TDD Additions — Shared Statements\n\nAdd failing-first tests for statement structure conformance:\n\nContract-level:\n\n- validates required `type=LinguisticObject` + string `content`\n- validates recommended classification/language/identified_by structures\n- validates optional `format`, `subject_to`, `assigned_by`, `created_by`, nested `referred_to_by`\n- validates `_complete: false` requirement for partial embedded statements with resolvable IDs\n\nRoute-level:\n\n- endpoint payloads embedding statements via `referred_to_by` conform to shared statement schema\n- malformed statement/language/rights/format payloads fail boundary validation with explicit path-level errors\n\nIntegration-level:\n\n- statement rights (`subject_to`) interoperate with shared rights structure across endpoint families\n- statement language and display-name behavior remains stable in UI-facing payloads\n\nRegression:\n\n- provider adapter updates do not collapse structured statements into plain strings\n- nested statement fixtures remain stable across endpoint serializers\n\n### Fixture Anchors — Shared Statements Examples\n\nUse these shared-statement patterns as fixture seeds:\n\n1. Minimal valid statement\n- `type: LinguisticObject` with required `content`.\n\n2. Classified description fixture\n- statement classified as description/brief text.\n\n3. Multilingual statement fixture\n- statement with language references and notation.\n\n4. Rights-on-statement fixture\n- statement with `subject_to` right classification and display name.\n\n5. Nested statement fixture\n- statement with `referred_to_by` note about provenance/source of statement.\n\n6. Partial statement fixture\n- embedded statement with dereferenceable `id` and `_complete: false`.\n\n---\n\n## Round 56 Addendum — Shared Structure: TimeSpans\n\nSource section basis:\n\n- Linked Art API 1.0: TimeSpans\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- TimeSpans model fuzzy temporal boundaries for events/activities and related temporal entities.\n- Required field:\n  - `type` must be `TimeSpan`\n- Recommended/optional fields:\n  - `identified_by`, `begin_of_the_begin`, `end_of_the_end` (recommended)\n  - `id`, `_label`, `_complete`, `classified_as`, `end_of_the_begin`, `begin_of_the_end`, `referred_to_by`, `duration`\n- Critical minimum-information rule:\n  - each TimeSpan must include at least one of:\n    - `identified_by`\n    - `begin_of_the_begin`\n    - `end_of_the_end`\n- Fuzzy boundary semantics:\n  - `begin_of_the_begin` = earliest possible start\n  - `end_of_the_begin` = latest possible start\n  - `begin_of_the_end` = earliest possible end\n  - `end_of_the_end` = latest possible end\n- `duration` is a Dimension structure describing interval length.\n- `_complete: false` required when embedded timespan has dereferenceable `id` and richer remote representation exists.\n\n### Implementation Mapping — Shared TimeSpans\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type strictness\n- Enforce `type=TimeSpan` at boundary validation.\n\n2. Minimum-information guard\n- Enforce “at least one of `identified_by` / `begin_of_the_begin` / `end_of_the_end`” to prevent empty/ambiguous timespan nodes.\n\n3. ISO timestamp fidelity\n- Preserve timestamp fields as ISO8601 strings without lossy locale/date parsing transforms.\n\n4. Fuzzy-bound semantics preservation\n- Preserve all four boundary fields distinctly; do not collapse to single start/end fields.\n\n5. Duration integration\n- Preserve optional `duration` as shared Dimension structure with proper unit typing.\n\n6. Partial embed signaling\n- Enforce `_complete: false` for partial embedded timespans with dereferenceable IDs.\n\n### TDD Additions — Shared TimeSpans\n\nAdd failing-first tests for timespan conformance:\n\nContract-level:\n\n- validates required `type=TimeSpan`\n- validates minimum-information rule (at least one key field present)\n- validates optional fuzzy boundary fields as ISO8601 date-time strings\n- validates optional `duration` structure via shared Dimension schema\n- validates `_complete: false` requirement for partial embedded timespans with resolvable IDs\n\nRoute-level:\n\n- endpoint payloads embedding `timespan` conform to shared timespan schema\n- malformed/empty timespan nodes fail boundary validation with explicit path-level errors\n\nIntegration-level:\n\n- activity/event/provenance/person/group/object lifecycle time fields remain interoperable via shared timespan rules\n- duration dimensions on timespans remain consistent with shared dimension processing\n\nRegression:\n\n- provider updates do not collapse fuzzy temporal bounds into single-point dates\n- snapshot fixtures preserve all boundary semantics and minimum-information behavior\n\n### Fixture Anchors — Shared TimeSpans Examples\n\nUse these shared-timespan patterns as fixture seeds:\n\n1. Minimal valid timespan (label-only)\n- `type=TimeSpan` plus `identified_by` display name.\n\n2. Minimal valid timespan (boundary-only)\n- `type=TimeSpan` plus `begin_of_the_begin` and/or `end_of_the_end`.\n\n3. Full fuzzy-bound fixture\n- all four boundary fields populated for uncertainty windows.\n\n4. Duration fixture\n- timespan with `duration` dimension and measurement unit.\n\n5. Descriptive statement fixture\n- timespan with `referred_to_by` explanatory statement.\n\n6. Partial timespan fixture\n- embedded timespan with dereferenceable `id` and `_complete: false`.\n\n7. Invalid-empty fixture\n- timespan missing `identified_by` + missing both key bounds, expected to fail validation.\n\n---\n\n## Round 57 Addendum — Shared Structure: Relationships (AttributeAssignment)\n\nSource section basis:\n\n- Linked Art API 1.0: Relationships\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Arbitrary/non-semantic or context-specific relationships are modeled via `AttributeAssignment`.\n- Required fields:\n  - `type` must be `AttributeAssignment`\n  - `assigned` must be present as references to related entities\n- Optional/recommended:\n  - `identified_by`, `classified_as` (recommended)\n  - `id`, `_label`, `_complete`, `referred_to_by`, `carried_out_by`, `timespan`, temporal ordering/context fields\n  - `influenced_by`, `caused_by`, `used_specific_object`, `technique`\n  - `assigned_property` optional URI/curie-like string for explicit relationship predicate\n- Modeling note:\n  - `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).\n- Incoming usage:\n  - `attributed_by` across all endpoints\n  - `assigned_by` specifically for Dimension/Identifier assignment activities\n\n### Implementation Mapping — Shared Relationships\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Type/assigned strictness\n- Enforce `type=AttributeAssignment` and required non-empty `assigned` reference array.\n\n2. Predicate capture\n- Preserve `assigned_property` when provided to retain explicit predicate semantics.\n\n3. Context/provenance fidelity\n- Preserve actor/time/cause/influence/object context fields to support explainable relationship provenance.\n\n4. Relationship-vs-assignment boundary\n- Route Dimension/Identifier assignment scenarios to dedicated assignment pathways rather than generic `assigned` relation modeling.\n\n5. Partial embed signaling\n- Enforce `_complete: false` for partial embedded assignments with dereferenceable IDs.\n\n6. Cross-endpoint consistency\n- Keep `attributed_by` handling consistent across all endpoint families.\n\n### TDD Additions — Shared Relationships\n\nAdd failing-first tests for relationship-assignment conformance:\n\nContract-level:\n\n- validates required `type=AttributeAssignment` and required `assigned` references\n- validates optional `assigned_property` format and context/provenance fields\n- rejects malformed/missing assigned target references\n- enforces guardrail that Dimension/Identifier assignments are not represented via generic `assigned` misuse\n- validates `_complete: false` requirement for partial embedded assignments with resolvable IDs\n\nRoute-level:\n\n- endpoint payloads embedding `attributed_by` conform to shared relationship-assignment schema\n- malformed assignment nodes fail boundary validation with explicit path-level diagnostics\n\nIntegration-level:\n\n- `attributed_by` traversals resolve assigned entities consistently across endpoints\n- Dimension/Identifier `assigned_by` flows remain distinct and interoperable with their dedicated shared structures\n\nRegression:\n\n- provider adapter updates do not flatten relationship assignments into untyped “related items” arrays\n- explicit `assigned_property` predicates remain stable when present\n\n### Fixture Anchors — Shared Relationships Examples\n\nUse these shared-relationship patterns as fixture seeds:\n\n1. Minimal valid assignment\n- `type=AttributeAssignment` with one `assigned` reference.\n\n2. Predicate assignment fixture\n- assignment with explicit `assigned_property` URI string.\n\n3. Curated recommendation fixture\n- assignment classified as recommendation with carried_out_by curator.\n\n4. Temporal/provenance fixture\n- assignment including timespan, influenced_by, caused_by, used_specific_object.\n\n5. Partial assignment fixture\n- embedded assignment with dereferenceable `id` and `_complete: false`.\n\n6. Guardrail negative fixture\n- invalid use of generic `assigned` for identifier/dimension assignment should fail or be remapped.\n\n---\n\n## Round 58 Addendum — About Schemas\n\nSource section basis:\n\n- Linked Art API 1.0: About Schemas\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Linked Art publishes JSON Schema definitions (plus generated HTML docs) for the core endpoint families:\n  - Abstract Work\n  - Concept\n  - Digital Object\n  - Event/Activity\n  - Group\n  - Person\n  - Physical Object\n  - Place\n  - Provenance Activity\n  - Set\n  - Textual Work\n  - Visual Work\n- These schemas are the normative machine-checkable contract layer for endpoint payload conformance.\n\n### Implementation Mapping — Schemas\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Schema-canonical contract policy\n- Treat the endpoint schema set as canonical contract references for all route payload validation.\n\n2. Endpoint-to-schema matrix\n- Maintain explicit mapping from each project API route/serializer to the corresponding Linked Art schema family.\n\n3. Shared-structure composition\n- Ensure endpoint schemas compose shared structures consistently (names, identifiers, timespans, references, rights, etc.).\n\n4. Drift detection\n- Add safeguards for schema drift between route handlers, contracts, and fixture expectations.\n\n5. Human + machine docs parity\n- Keep generated/internal docs aligned with machine validation behavior for dev clarity.\n\n### TDD Additions — Schemas\n\nAdd failing-first tests for schema-governed conformance:\n\nContract-level:\n\n- validates each endpoint payload against its corresponding Linked Art schema family\n- validates shared-structure reuse across endpoint schemas\n\nRoute-level:\n\n- each public endpoint has schema conformance tests for success and failure cases\n- boundary validation errors include actionable field paths\n\nIntegration-level:\n\n- cross-endpoint traversals preserve schema-valid reference shapes\n- provenance and shared-structure heavy payloads validate under composed schema rules\n\nRegression:\n\n- snapshot tests detect breaking schema-shape changes\n- provider adapter updates cannot bypass schema validation gates\n\n### Fixture Anchors — Schemas Examples\n\nUse these schema-level anchors as fixture seeds:\n\n1. Per-endpoint golden fixtures\n- one canonical valid fixture per endpoint family listed above.\n\n2. Negative schema fixtures\n- one invalid payload per endpoint proving boundary rejection behavior.\n\n3. Shared-structure composition fixtures\n- payloads stress-testing nested shared structures inside endpoint records.\n\n4. Cross-reference fixtures\n- payloads with dense references validating link-shape and type consistency.\n\n---\n\n## Round 59 Addendum — Abstract Work Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Abstract Work Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E89_Propositional_Object`\n  - purely conceptual work representation\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `dimension`\n  - `subject_to`\n  - `about`\n  - `conceptually_part_of`\n  - `created_by`\n\n### Implementation Mapping — Abstract Work Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for abstract work payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only the listed abstract-work fields; reject unknown keys at boundary validation.\n\n4. Class semantics\n- Keep abstract work payloads concept-first (propositional object semantics), not physical-object semantics.\n\n### TDD Additions — Abstract Work Schema\n\nAdd failing-first tests for abstract-work schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional allowed properties by shared-structure schemas\n\nRoute-level:\n\n- abstract-work route responses always satisfy schema-required fields\n- malformed payloads with unknown keys fail with clear field-path diagnostics\n\nRegression:\n\n- changes to abstract-work serializers cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Abstract Work Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid abstract work\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid abstract work\n- uses subset of allowed optional fields (for example `about`, `created_by`, `subject_to`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 60 Addendum — Concept Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Concept Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E55_Type`\n  - concepts/subjects/categorizations\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `classified_as`\n  - `identified_by`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `created_by`\n  - `broader`\n\n### Implementation Mapping — Concept Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for concept payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only the listed concept-schema fields; reject unknown keys at boundary validation.\n\n4. Hierarchy semantics\n- Preserve `broader` concept links for hierarchical taxonomy navigation.\n\n### TDD Additions — Concept Schema\n\nAdd failing-first tests for concept schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional allowed properties (especially `broader`) through shared-structure contracts\n\nRoute-level:\n\n- concept route responses always satisfy schema-required fields\n- malformed concept payloads with unknown keys fail with clear field-path diagnostics\n\nRegression:\n\n- concept serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Concept Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid concept\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid concept\n- uses subset of allowed optional fields (for example `broader`, `equivalent`, `created_by`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 61 Addendum — Digital Object Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Digital Object Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `dig:D1_Digital_Object`\n  - digital resources such as web pages/images\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `dimension`\n  - `part_of`\n  - `format`\n  - `conforms_to`\n  - `access_point`\n  - `digitally_available_via`\n  - `digitally_carries`\n  - `digitally_shows`\n  - `used_for`\n  - `created_by`\n\n### Implementation Mapping — Digital Object Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for digital object payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed digital-object fields; reject unknown keys at boundary validation.\n\n4. Carrier/service/access semantics\n- Preserve strict separation of `access_point`, `digitally_available_via`, `digitally_carries`, and `digitally_shows`.\n\n5. Technical metadata fidelity\n- Preserve `format` and `conforms_to` semantics for media/protocol interoperability.\n\n### TDD Additions — Digital Object Schema\n\nAdd failing-first tests for digital object schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional allowed fields using shared-structure contracts\n\nRoute-level:\n\n- digital object route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid digital-link fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Digital Object Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid digital object\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid digital object\n- uses subset of allowed optional fields (for example `access_point`, `format`, `digitally_available_via`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 62 Addendum — Event Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Event Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target classes:\n  - `crm:E4_Period`\n  - `crm:E6_Event`\n  - `crm:E7_Activity`\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `took_place_at`\n  - `timespan`\n  - `during`\n  - `after`\n  - `before`\n  - `caused_by`\n  - `carried_out_by`\n  - `participant`\n  - `used_specific_object`\n  - `influenced_by`\n  - `technique`\n  - `part_of`\n\n### Implementation Mapping — Event Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for event payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed event-schema fields; reject unknown keys at boundary validation.\n\n4. Temporal/spatial semantics\n- Preserve `timespan`, ordering (`before`/`after`/`during`), and `took_place_at` as first-class structured fields.\n\n5. Event/activity role semantics\n- Preserve `carried_out_by`, `participant`, `used_specific_object`, and `influenced_by` role/context fields.\n\n### TDD Additions — Event Schema\n\nAdd failing-first tests for event schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional temporal/spatial/role fields using shared-structure contracts\n\nRoute-level:\n\n- event route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid temporal/role fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Event Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid event record\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid event record\n- uses subset of allowed optional fields (for example `timespan`, `took_place_at`, `carried_out_by`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 63 Addendum — Group Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Group Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E74_Group`\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `carried_out`\n  - `participated_in`\n  - `contact_point`\n  - `residence`\n  - `formed_by`\n  - `dissolved_by`\n\n### Implementation Mapping — Group Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for group payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed group-schema fields; reject unknown keys at boundary validation.\n\n4. Lifecycle/activity semantics\n- Preserve `formed_by`, `dissolved_by`, `carried_out`, and `participated_in` as structured activity fields.\n\n5. Contact/residence semantics\n- Preserve `contact_point` and `residence` as distinct structured fields with shared contracts.\n\n### TDD Additions — Group Schema\n\nAdd failing-first tests for group schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional activity/contact/residence fields using shared-structure contracts\n\nRoute-level:\n\n- group route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid lifecycle/activity fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Group Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid group record\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid group record\n- uses subset of allowed optional fields (for example `formed_by`, `residence`, `carried_out`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 64 Addendum — Person Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Person Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E21_Person`\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `carried_out`\n  - `participated_in`\n  - `contact_point`\n  - `residence`\n  - `born`\n  - `died`\n\n### Implementation Mapping — Person Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for person payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed person-schema fields; reject unknown keys at boundary validation.\n\n4. Lifecycle/activity semantics\n- Preserve `born`, `died`, `carried_out`, and `participated_in` as structured activity fields.\n\n5. Contact/residence semantics\n- Preserve `contact_point` and `residence` as distinct structured fields with shared contracts.\n\n### TDD Additions — Person Schema\n\nAdd failing-first tests for person schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional lifecycle/activity/contact/residence fields using shared-structure contracts\n\nRoute-level:\n\n- person route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid lifecycle/activity fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Person Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid person record\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid person record\n- uses subset of allowed optional fields (for example `born`, `died`, `residence`, `carried_out`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 65 Addendum — Human-Made Object Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Human-Made Object Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E22_Human-Made_Object`\n  - includes human-made objects, parts, and culturally-valued natural objects\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `dimension`\n  - `made_of`\n  - `part_of`\n  - `current_owner`\n  - `current_custodian`\n  - `current_permanent_custodian`\n  - `current_location`\n  - `current_permanent_location`\n  - `held_or_supported_by`\n  - `used_for`\n  - `shows`\n  - `carries`\n  - `produced_by`\n  - `destroyed_by`\n  - `removed_by`\n  - `encountered_by`\n  - `modified_by`\n  - `changed_ownership_through`\n\n### Implementation Mapping — Human-Made Object Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for human-made object payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed object-schema fields; reject unknown keys at boundary validation.\n\n4. Ownership/custody/location semantics\n- Preserve distinct fields for current vs permanent ownership/custody/location.\n\n5. Lifecycle/provenance semantics\n- Preserve structured lifecycle/provenance fields (`produced_by`, `destroyed_by`, `removed_by`, `encountered_by`, `modified_by`, `changed_ownership_through`).\n\n6. Aboutness/carrier semantics\n- Preserve `shows` and `carries` link semantics separately from digital/visual/textual standalone records.\n\n### TDD Additions — Human-Made Object Schema\n\nAdd failing-first tests for human-made object schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional lifecycle, provenance, ownership, custody, location, material, and dimension fields via shared contracts\n\nRoute-level:\n\n- object route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid lifecycle/ownership structures fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Human-Made Object Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid object record\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid object record\n- uses subset of allowed optional fields (for example `made_of`, `dimension`, `current_owner`, `produced_by`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 66 Addendum — Place Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Place Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E53_Place`\n  - geographic locations where activities occur\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `classified_as`\n  - `identified_by`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `defined_by`\n  - `part_of`\n\n### Implementation Mapping — Place Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for place payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed place-schema fields; reject unknown keys at boundary validation.\n\n4. Geometry/hierarchy semantics\n- Preserve `defined_by` geometry payload and `part_of` place hierarchy as first-class structured fields.\n\n5. Identity/reference fidelity\n- Preserve `equivalent` and classification fields for cross-authority place reconciliation.\n\n### TDD Additions — Place Schema\n\nAdd failing-first tests for place schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional geometry/hierarchy/reference fields via shared contracts\n\nRoute-level:\n\n- place route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid `defined_by`/`part_of` fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Place Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid place record\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid place record\n- uses subset of allowed optional fields (for example `defined_by`, `part_of`, `equivalent`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 67 Addendum — Provenance Activity Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Provenance Activity Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E7_Activity`\n  - broad activities for ownership/custody/location/rights changes\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n  - `classified_as`\n- Additional allowed properties:\n  - `identified_by`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `during`\n  - `after`\n  - `before`\n  - `took_place_at`\n  - `timespan`\n  - `caused_by`\n  - `carried_out_by`\n  - `used_specific_object`\n  - `influenced_by`\n  - `technique`\n  - `part_of`\n  - `part`\n\n### Implementation Mapping — Provenance Activity Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for provenance activity payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, `_label`, and `classified_as` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed provenance-schema fields; reject unknown keys at boundary validation.\n\n4. Classification gate\n- Preserve and validate `classified_as` entries required to establish provenance semantics.\n\n5. Structured part semantics\n- Preserve `part` as first-class structured sub-activity container, not flattened notes.\n\n### TDD Additions — Provenance Activity Schema\n\nAdd failing-first tests for provenance activity schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`/`classified_as`\n- validates rejection of additional unknown properties\n- validates optional temporal/spatial/role fields and `part` structure via shared contracts\n\nRoute-level:\n\n- provenance route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid `classified_as`/`part` fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `classified_as` and `_label` remain enforced in schema conformance suite\n\n### Fixture Anchors — Provenance Activity Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid provenance activity\n- contains required `@context`, `id`, `type`, `_label`, `classified_as`.\n\n2. Extended valid provenance activity\n- uses subset of allowed optional fields (for example `timespan`, `took_place_at`, `part`, `used_specific_object`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n4. Missing-classification negative fixture\n- omits required `classified_as` and must fail validation.\n\n---\n\n## Round 68 Addendum — Collection (Set) Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Collection Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `la:Set`\n  - collection/set of resources\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `dimension`\n  - `about`\n  - `members_contained_by`\n  - `members_exemplified_by`\n  - `used_for`\n  - `created_by`\n\n### Implementation Mapping — Collection (Set) Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for collection/set payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed collection-schema fields; reject unknown keys at boundary validation.\n\n4. Set semantics preservation\n- Preserve `members_contained_by` and `members_exemplified_by` distinctions as separate semantics.\n\n5. Curatorial/context semantics\n- Preserve `about`, `used_for`, and `created_by` as structured contextual fields.\n\n### TDD Additions — Collection (Set) Schema\n\nAdd failing-first tests for collection/set schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional set-specific fields via shared contracts\n\nRoute-level:\n\n- set route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid set-specific fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Collection (Set) Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid collection/set record\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid collection/set record\n- uses subset of allowed optional fields (for example `about`, `members_exemplified_by`, `created_by`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 69 Addendum — Text Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Text Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E33_Linguistic_Object`\n  - textual content expressed in one or more human languages\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `representation`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `dimension`\n  - `subject_to`\n  - `format`\n  - `language`\n  - `about`\n  - `created_by`\n  - `used_for`\n  - `part_of`\n  - `content`\n\n### Implementation Mapping — Text Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for text payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed text-schema fields; reject unknown keys at boundary validation.\n\n4. Linguistic semantics fidelity\n- Preserve `language`, `content`, `format`, and `about` as first-class textual semantics.\n\n5. Rights/provenance/publication semantics\n- Preserve `subject_to`, `created_by`, and `used_for` as structured contextual fields.\n\n### TDD Additions — Text Schema\n\nAdd failing-first tests for text schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional linguistic/rights/provenance fields via shared contracts\n\nRoute-level:\n\n- text route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid language/content/rights fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Text Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid text record\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid text record\n- uses subset of allowed optional fields (for example `language`, `content`, `subject_to`, `used_for`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 70 Addendum — Visual Content Schema\n\nSource section basis:\n\n- Linked Art API 1.0: Visual Content Schema\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Schema target class:\n  - `crm:E36_Visual_Item`\n  - visual content of a work\n- Schema form:\n  - `type: object`\n  - no additional properties allowed\n- Required properties in this schema listing:\n  - `@context`\n  - `id`\n  - `type`\n  - `_label`\n- Additional allowed properties:\n  - `identified_by`\n  - `classified_as`\n  - `referred_to_by`\n  - `equivalent`\n  - `member_of`\n  - `subject_of`\n  - `attributed_by`\n  - `dimension`\n  - `subject_to`\n  - `part_of`\n  - `conceptually_part_of`\n  - `about`\n  - `created_by`\n  - `represents`\n  - `represents_instance_of_type`\n  - `used_for`\n\n### Implementation Mapping — Visual Content Schema\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Strict additional-property rule\n- Enforce `additionalProperties: false` behavior for visual content payloads.\n\n2. Required-field alignment\n- Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.\n\n3. Property allowlist enforcement\n- Permit only listed visual-content schema fields; reject unknown keys at boundary validation.\n\n4. Depiction semantics fidelity\n- Preserve `represents` and `represents_instance_of_type` as distinct semantics in serializers and validators.\n\n5. Structural/context semantics\n- Preserve `part_of`, `conceptually_part_of`, `about`, and `used_for` as structured contextual fields.\n\n### TDD Additions — Visual Content Schema\n\nAdd failing-first tests for visual content schema conformance:\n\nContract-level:\n\n- validates required `@context`/`id`/`type`/`_label`\n- validates rejection of additional unknown properties\n- validates optional depiction/context/rights fields via shared contracts\n\nRoute-level:\n\n- visual content route responses always satisfy schema-required fields\n- malformed payloads with unknown keys or invalid depiction fields fail with clear field-path diagnostics\n\nRegression:\n\n- serializer changes cannot silently introduce non-schema fields\n- required `_label` remains enforced in schema conformance suite\n\n### Fixture Anchors — Visual Content Schema Examples\n\nUse these schema-level patterns as fixture seeds:\n\n1. Minimal valid visual content record\n- contains only required `@context`, `id`, `type`, `_label`.\n\n2. Extended valid visual content record\n- uses subset of allowed optional fields (for example `represents`, `represents_instance_of_type`, `subject_to`, `created_by`).\n\n3. Additional-property negative fixture\n- includes unknown key and must fail validation.\n\n---\n\n## Round 71 Addendum — Search API\n\nSource section basis:\n\n- Linked Art API 1.0: Search API\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Search API solves inverse-relationship discovery without requiring clients to author query grammar.\n- Discovery mechanism:\n  - HAL `_links` on entity records expose named links to referring-record result lists.\n  - relation naming convention is camelCase by current type + relationship + target type (via `curies` expansion).\n  - links should be omitted when no matching results exist.\n- Search response model:\n  - based on ActivityStreams `OrderedCollection` / `OrderedCollectionPage`.\n  - HAL links should target first page URI, not necessarily collection root URI.\n- Page requirements (`OrderedCollectionPage`):\n  - `@context` must be `https://linked.art/ns/v1/search.json`\n  - required: `id`, `type=\"OrderedCollectionPage\"`, `partOf`, `orderedItems`\n  - `next` required unless last page\n  - `prev` required unless first page\n  - `startIndex` should be present (0-based index)\n  - each `orderedItems` entry has exactly `{ id, type }`\n- Collection requirements (`OrderedCollection`):\n  - required: `id`, `type=\"OrderedCollection\"`, `first`, `last`\n  - `totalItems` should be present\n  - `label` and `summary` may be language-map objects\n  - when embedded in page `partOf`, collection must not repeat `@context`\n  - if requested separately, collection must include `@context` search context value\n\n### Implementation Mapping — Search API\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. HAL inverse-link publication\n- Emit `_links` search relations for supported inverse traversals and omit relations with zero results.\n\n2. Relation-name stability\n- Keep relation naming deterministic and curies-expandable for client interoperability.\n\n3. Page-first retrieval contract\n- Ensure relation `href` targets first `OrderedCollectionPage` response with required search context.\n\n4. Ordered page structure enforcement\n- Preserve strict page contract (`partOf`, `next`/`prev` conditional presence, `orderedItems` id/type shape).\n\n5. Embedded collection behavior\n- Embed collection metadata in `partOf` without duplicate `@context`; include `@context` only for standalone collection responses.\n\n6. Backend-agnostic search execution\n- Keep public response shape stable regardless of underlying query engine/indexing strategy.\n\n### TDD Additions — Search API\n\nAdd failing-first tests for search API conformance:\n\nContract-level:\n\n- validates `OrderedCollectionPage` required fields and search context\n- validates `OrderedCollection` required fields and standalone-vs-embedded context rules\n- validates `orderedItems` entry shape as exactly id/type references\n\nRoute-level:\n\n- HAL `_links` include only available inverse relationships\n- first-page links dereference to valid `OrderedCollectionPage`\n- pagination rules enforce `next`/`prev` conditional presence correctly\n\nIntegration-level:\n\n- cross-endpoint inverse discovery works via HAL links without query-language coupling\n- `startIndex`, `totalItems`, and page traversal semantics remain consistent across providers/backends\n\nRegression:\n\n- serializer changes do not break search context URI, relation naming, or ordered item shape\n- empty-result relationships continue omitting link entries\n\n### Fixture Anchors — Search API Examples\n\nUse these search-API patterns as fixture seeds:\n\n1. Minimal valid first page\n- valid `OrderedCollectionPage` with `partOf`, `next`, and `orderedItems`.\n\n2. Middle page fixture\n- page with both `prev` and `next` plus correct `startIndex`.\n\n3. Last page fixture\n- page omitting `next` and retaining `prev`.\n\n4. Embedded collection fixture\n- `partOf` collection with `first`, `last`, `totalItems`, optional label/summary, and no embedded `@context`.\n\n5. Standalone collection fixture\n- separate collection response including required search `@context`.\n\n6. HAL link omission fixture\n- source record where absent inverse relations are not emitted in `_links`.\n\n---\n\n## Round 72 Addendum — About HAL\n\nSource section basis:\n\n- Linked Art API 1.0: About HAL\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Linked Art embeds non-semantic API metadata in JSON responses using HAL via `_links`.\n- HAL block is not RDF-semantic and is not preserved through RDF graph round-tripping.\n- Core HAL elements:\n  - `self` link\n  - `curies` namespace templates for relation semantics (for example `la`)\n  - namespaced relation links (Linked Art + local extensions)\n- Versioning links:\n  - required: `la:modelVersion`, `la:apiVersion`\n  - optional: `la:localVersion`\n  - each version link requires `href` to human docs and `name` in `v{major}.{minor}.{patch}` format\n- Version interpretation guidance:\n  - major/minor are numeric for compatibility logic\n  - patch is string-sorted and non-functional (awareness/documentation)\n- Other representation links:\n  - `alternate` links for HTML/Turtle/etc. must include correct `type` media type\n  - `collection` can point to IIIF Change Discovery endpoint\n- Search integration:\n  - HAL links are primary discovery mechanism for related searches (documented in Search API)\n\n### Implementation Mapping — HAL\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. HAL envelope consistency\n- Emit `_links` consistently on entity responses with valid `self` and curated relation links.\n\n2. CURIE namespace discipline\n- Emit `curies` entries with templated link semantics for relation documentation expansion.\n\n3. Version-link enforcement\n- Require `la:modelVersion` and `la:apiVersion`; support optional `la:localVersion` for local extension tracking.\n\n4. Version-name parser safety\n- Enforce `name` format compatibility and preserve numeric compare behavior for major/minor components.\n\n5. Alternate representation correctness\n- Ensure `alternate` links include accurate MIME `type` values.\n\n6. Discovery link integration\n- Support `collection` and search relation links without coupling to backend-specific query syntax.\n\n7. Semantic boundary preservation\n- Keep HAL metadata separate from semantic JSON-LD graph processing.\n\n### TDD Additions — HAL\n\nAdd failing-first tests for HAL conformance:\n\nContract-level:\n\n- validates `_links` presence and required `self` structure\n- validates `curies` templated namespace entries\n- validates required version links and `name` format constraints\n- validates `alternate` links include correct `type` media types\n\nRoute-level:\n\n- entity responses include consistent HAL links across endpoint families\n- malformed/missing required version links fail contract checks\n\nIntegration-level:\n\n- relation links expand via CURIE templates to documentation URIs\n- search/discovery links are followable and return schema-valid responses\n\nRegression:\n\n- serializer changes do not drop required HAL version links\n- HAL blocks remain non-semantic and do not pollute JSON-LD graph assertions\n\n### Fixture Anchors — HAL Examples\n\nUse these HAL patterns as fixture seeds:\n\n1. Minimal HAL fixture\n- `_links.self` + `curies` template entry.\n\n2. Versioned HAL fixture\n- includes required `la:modelVersion` and `la:apiVersion` plus optional `la:localVersion`.\n\n3. Alternate-format fixture\n- `alternate` links for HTML and Turtle with valid media types.\n\n4. Discovery fixture\n- `collection` link to change-discovery endpoint.\n\n5. Search-link fixture\n- relation links pointing to search result pages.\n\n6. Invalid-version-name fixture\n- malformed `name` format must fail validation checks.\n\n---\n\n## Round 73 Addendum — Search Relations: HumanMadeObject\n\nSource section basis:\n\n- Linked Art API relation docs (HumanMadeObject-focused search links)\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Documented search relations for `HumanMadeObject` include:\n  - `activityUsedObject`\n  - `conceptInfluencedByObject`\n  - `objectPartOfObject`\n  - `objectProductionInfluencedByObject`\n  - `workAboutObject`\n  - `workAboutOrRepresentsObject`\n  - `workRepresentsObject`\n- Each relation defines:\n  - source class (`HumanMadeObject`)\n  - returned class family (`Activity`, `Concept`, `HumanMadeObject`, `Work`)\n  - semantic relationship basis (`used`, `influencedBy`, `partOf`, `productionInfluencedBy`, `about`, `represents`)\n- These relations are exposed as discoverable HAL/search links and should map to OrderedCollectionPage responses.\n\n### Implementation Mapping — HumanMadeObject Search Relations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Relation-name publication\n- Publish stable HAL relation links for the listed HumanMadeObject inverse/discovery relations.\n\n2. Result-class fidelity\n- Ensure each relation returns the expected entity class family (or documented union) consistently.\n\n3. Relationship-semantic fidelity\n- Ensure each relation query is grounded in the documented relationship basis:\n  - `used` -> activities using object\n  - `influencedBy` -> concepts influenced by object\n  - `partOf` -> object parts\n  - `productionInfluencedBy` -> produced objects influenced by source object\n  - `about` / `represents` combinations for work relations\n\n4. Page-format compliance\n- Relation targets must return valid Search API `OrderedCollectionPage` shape.\n\n5. Empty-result behavior\n- Omit relation links when no results exist for a source record (per Search API guidance).\n\n### TDD Additions — HumanMadeObject Search Relations\n\nAdd failing-first tests for relation conformance:\n\nContract-level:\n\n- validates each listed relation is either:\n  - present with valid link shape and followable search-page response, or\n  - omitted when result set is empty\n\nRoute-level:\n\n- validates returned `orderedItems[].type` matches documented class family per relation\n- validates each relation endpoint page conforms to search context/page schema\n\nIntegration-level:\n\n- object fixture graph tests verify each relation returns expected linked records:\n  - activities using object\n  - concepts influenced by object\n  - child/part objects\n  - influenced productions/copies\n  - about/represents work sets\n\nRegression:\n\n- relation name stability tests prevent accidental renaming or semantic drift\n- relation-specific queries remain consistent across provider adapters/storage backends\n\n### Fixture Anchors — HumanMadeObject Search Relations Examples\n\nUse these relation patterns as fixture seeds:\n\n1. `activityUsedObject` fixture\n- object linked to one or more activity records via usage semantics.\n\n2. `conceptInfluencedByObject` fixture\n- object linked to concept records via influence semantics.\n\n3. `objectPartOfObject` fixture\n- parent object with part/frame/subcomponent object records.\n\n4. `objectProductionInfluencedByObject` fixture\n- source object linked to production of derivative/copy object.\n\n5. `workAboutObject` fixture\n- textual/visual/abstract works about object.\n\n6. `workAboutOrRepresentsObject` fixture\n- combined about-or-represents result set.\n\n7. `workRepresentsObject` fixture\n- visual works depicting object.\n\n---\n\n## Round 74 Addendum — Search Relations: Work\n\nSource section basis:\n\n- Linked Art API relation docs (Work-focused search links)\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Documented search relations for Work/LinguisticObject/VisualItem contexts include:\n  - `activityUsedWork`\n  - `conceptInfluencedByWork`\n  - `objectCarriesWork`\n  - `objectProductionInfluencedByWork`\n  - `objectShowsWork`\n  - `workAboutOrRepresentsWork`\n  - `workAboutWork`\n  - `workPartOfWork`\n  - `workRepresentsWork`\n- Relation details include:\n  - source class (`Work`, `LinguisticObject`, or `VisualItem` depending on relation)\n  - returned class family (`Activity`, `Concept`, `HumanMadeObject`, `Work`)\n  - semantic basis (`used`, `influencedBy`, `carries`, `productionInfluencedBy`, `shows`, `about`, `represents`, `partOf`)\n- These relations should be exposed through HAL/search links and return Search API page structures.\n\n### Implementation Mapping — Work Search Relations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Relation-name publication\n- Publish stable HAL relation links for the listed Work-family inverse/discovery relations.\n\n2. Source-class correctness\n- Enforce correct source-class gating per relation (for example `objectCarriesWork` from `LinguisticObject`, `objectShowsWork` from `VisualItem`).\n\n3. Result-class fidelity\n- Ensure each relation returns the documented class family consistently.\n\n4. Relationship-semantic fidelity\n- Map each relation to its documented semantic edge:\n  - `used`\n  - `influencedBy`\n  - `carries`\n  - `productionInfluencedBy`\n  - `shows`\n  - `about`\n  - `represents`\n  - `partOf`\n\n5. Search-page compliance\n- Relation targets must return valid `OrderedCollectionPage` responses with correct search context.\n\n6. Empty-result link omission\n- Omit relation links where no referring records exist.\n\n### TDD Additions — Work Search Relations\n\nAdd failing-first tests for relation conformance:\n\nContract-level:\n\n- validates listed relations are either present with valid HAL link shape or omitted when empty\n- validates link targets return schema-valid search pages\n\nRoute-level:\n\n- validates relation result item `type` matches documented class family\n- validates source-class-specific relations are not emitted on incompatible source classes\n\nIntegration-level:\n\n- work graph fixtures verify inverse discovery for:\n  - activities using work\n  - concepts influenced by work\n  - objects carrying linguistic work\n  - objects showing visual work\n  - objects produced under work influence\n  - work-about/work-represents/work-part relations\n\nRegression:\n\n- relation names remain stable across backend/provider changes\n- about-vs-represents-vs-partOf semantics do not collapse into one generic “related works” bucket\n\n### Fixture Anchors — Work Search Relations Examples\n\nUse these relation patterns as fixture seeds:\n\n1. `activityUsedWork` fixture\n- work linked to activity records via usage semantics.\n\n2. `conceptInfluencedByWork` fixture\n- work linked to concept records via influence semantics.\n\n3. `objectCarriesWork` fixture\n- linguistic work linked to physical carrier objects.\n\n4. `objectShowsWork` fixture\n- visual work linked to physical objects that show it.\n\n5. `objectProductionInfluencedByWork` fixture\n- work linked to objects whose production it influenced.\n\n6. `workAboutWork` fixture\n- work linked to works about it.\n\n7. `workAboutOrRepresentsWork` fixture\n- mixed about-or-represents work result set.\n\n8. `workPartOfWork` fixture\n- parent work linked to component/sub-work records.\n\n9. `workRepresentsWork` fixture\n- work linked to works that depict/represent it.\n\n---\n\n## Round 75 Addendum — Search Relations: Agent\n\nSource section basis:\n\n- Linked Art API relation docs (Agent-focused search links with SPARQL patterns)\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Documented agent-centric search relations include:\n  - `activityCarriedOutByAgent`\n  - `activityParticipantAgent`\n  - `agentMemberOfGroup`\n  - `conceptInfluencedByAgent`\n  - `groupFoundedByAgent`\n  - `objectCuratedByAgent`\n  - `objectEncounteredByAgent`\n  - `objectOwnedByAgent`\n  - `objectProducedByAgent`\n  - `objectProductionInfluencedByAgent`\n  - `setCreatedByAgent`\n  - `workAboutAgent`\n  - `workAboutOrRepresentsAgent`\n  - `workCreatedByAgent`\n  - `workPublishedByAgent`\n  - `workRepresentsAgent`\n- Each relation specifies:\n  - source class (`Agent` or `Group` where noted)\n  - return class family (`Activity`, `Event/Activity`, `Agent`, `Concept`, `Group`, `HumanMadeObject`, `Set`, `Work`)\n  - semantic edge (`carriedOutBy`, `participant`, `memberOf`, `influencedBy`, `foundedBy`, etc.)\n- Provided SPARQL snippets establish expected inverse-traversal semantics and can be used as behavioral oracle for query correctness.\n\n### Implementation Mapping — Agent Search Relations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Relation-name publication\n- Publish stable HAL relation links for the documented agent-centric relations.\n\n2. Source-class gating\n- Enforce relation availability by source class (for example `agentMemberOfGroup` source is `Group`).\n\n3. Result-class fidelity\n- Ensure returned item types match the documented class family per relation.\n\n4. Semantic-query fidelity\n- Align relation execution to documented inverse semantics (including production/event path traversals and union branches where specified).\n\n5. Complex-branch relation fidelity\n- Preserve union/path logic for relations like `objectCuratedByAgent` and multi-edge creation/production queries.\n\n6. Search-page compliance\n- Relation targets must return valid Search API `OrderedCollectionPage` structures.\n\n7. Empty-result omission\n- Omit relation link entries when no matching records exist.\n\n### TDD Additions — Agent Search Relations\n\nAdd failing-first tests for agent-relation conformance:\n\nContract-level:\n\n- validates each listed relation is either present with valid HAL link shape or omitted when empty\n- validates followable relation targets return schema-valid search pages\n\nRoute-level:\n\n- validates `orderedItems[].type` against documented return class family per relation\n- validates source-class-incompatible relations are not emitted\n\nIntegration-level:\n\n- graph fixtures verify inverse discovery for:\n  - activities carried out by/participated in by agents\n  - group membership and group formation links\n  - owned/curated/encountered/produced/influenced objects\n  - sets created by agents\n  - works about/representing/created/published by agents\n\nRegression:\n\n- relation naming and semantics remain stable across storage backends/providers\n- SPARQL-equivalence checks detect semantic drift in traversal logic\n\n### Fixture Anchors — Agent Search Relations Examples\n\nUse these relation patterns as fixture seeds:\n\n1. `activityCarriedOutByAgent` fixture\n- agent linked to carried-out activity records.\n\n2. `activityParticipantAgent` fixture\n- agent linked to participation-only event/activity records.\n\n3. `agentMemberOfGroup` fixture\n- group with person/group members returned via inverse membership.\n\n4. `objectProducedByAgent` fixture\n- agent linked to produced objects through production-participant paths.\n\n5. `objectCuratedByAgent` fixture\n- curator/department linked to objects through custody or curating-activity pathways.\n\n6. `objectOwnedByAgent` fixture\n- agent linked to currently owned objects.\n\n7. `workCreatedByAgent` and `workPublishedByAgent` fixtures\n- agent linked to created/published works via creation/publication activities.\n\n8. `workAboutOrRepresentsAgent` fixture\n- mixed work result set combining about and represents relations.\n\n9. `setCreatedByAgent` fixture\n- agent linked to created sets/collections.\n\n10. `conceptInfluencedByAgent` fixture\n- agent linked to concept creation influence chains.\n\n---\n\n## Round 76 Addendum — Search Relations: Place\n\nSource section basis:\n\n- Linked Art API relation docs (Place-focused search links with SPARQL patterns)\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Documented place-centric search relations include:\n  - `activityTookPlaceAtPlace`\n  - `agentActiveAtPlace`\n  - `agentBornOrFormedAtPlace`\n  - `agentDiedOrDissolvedAtPlace`\n  - `agentResidentAtPlace`\n  - `conceptInfluencedByPlace`\n  - `groupActiveAtPlace`\n  - `groupDissolvedAtPlace`\n  - `groupFormedAtPlace`\n  - `objectCurrentPlace`\n  - `objectEncounteredAtPlace`\n  - `objectProducedAtPlace`\n  - `objectProductionInfluencedByPlace`\n  - `personActiveAtPlace`\n  - `personBornAtPlace`\n  - `personDiedAtPlace`\n  - `placePartOfPlace`\n  - `setCreatedAtPlace`\n  - `workAboutOrRepresentsPlace`\n  - `workAboutPlace`\n  - `workCreatedAtPlace`\n  - `workPublishedAtPlace`\n  - `workRepresentsPlace`\n- Relation details define:\n  - source class (`Place`)\n  - return class family (`Event/Activity`, `Agent`, `Group`, `Person`, `HumanMadeObject`, `Place`, `Set`, `Work`, `Concept`)\n  - semantic edge basis (`tookPlaceAt`, `bornAt`, `diedAt`, `formedAt`, `dissolvedAt`, `about`, `represents`, `createdAt`, etc.)\n- Provided SPARQL snippets establish expected inverse traversal behavior and should guide semantic correctness tests.\n\n### Implementation Mapping — Place Search Relations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Relation-name publication\n- Publish stable HAL relation links for the documented place-centric relation set.\n\n2. Result-class fidelity\n- Ensure each relation returns the documented class family (including union-style families where specified).\n\n3. Temporal/lifecycle edge fidelity\n- Preserve birth/death/formation/dissolution/activity location semantics distinctly across relation handlers.\n\n4. Production/publication/location path fidelity\n- Preserve multi-hop path semantics for produced/created/published relations as indicated by model/SPARQL patterns.\n\n5. About-vs-represents separation\n- Preserve distinction between `about`, `represents`, and combined `aboutOrRepresents` relation results.\n\n6. Search-page compliance\n- Relation targets must return valid Search API `OrderedCollectionPage` responses.\n\n7. Empty-result omission\n- Omit HAL relation links when no matching records exist.\n\n### TDD Additions — Place Search Relations\n\nAdd failing-first tests for place-relation conformance:\n\nContract-level:\n\n- validates each listed place relation is either present with valid HAL link shape or omitted when empty\n- validates followable relation targets return schema-valid search pages\n\nRoute-level:\n\n- validates `orderedItems[].type` matches documented return class family per relation\n- validates combined relations (`workAboutOrRepresentsPlace`, agent born/formed, died/dissolved) preserve union semantics\n\nIntegration-level:\n\n- graph fixtures verify inverse discovery for:\n  - activities/events at place\n  - agents active/resident/born/formed/died/dissolved at place\n  - groups formed/dissolved/active at place\n  - objects currently at, encountered at, produced at, production-influenced by place\n  - sets created at place\n  - places part-of place\n  - works about/representing/created/published at place\n  - concepts influenced by place\n\nRegression:\n\n- relation naming and source/return class mappings remain stable across adapters/backends\n- SPARQL-equivalence assertions detect path-semantics drift in query implementations\n\n### Fixture Anchors — Place Search Relations Examples\n\nUse these relation patterns as fixture seeds:\n\n1. `activityTookPlaceAtPlace` fixture\n- place linked to event/activity records via `took_place_at`.\n\n2. Lifecycle-at-place fixtures\n- `personBornAtPlace`, `personDiedAtPlace`, `groupFormedAtPlace`, `groupDissolvedAtPlace`.\n\n3. Agent-at-place fixtures\n- `agentActiveAtPlace`, `agentResidentAtPlace`, plus combined born/formed and died/dissolved relations.\n\n4. Object-at-place fixtures\n- current location, encountered-at, produced-at, and production-influenced-by place relations.\n\n5. Place hierarchy fixture\n- `placePartOfPlace` inverse discovery.\n\n6. Set-at-place fixture\n- `setCreatedAtPlace` via creation activities.\n\n7. Work-at-place fixtures\n- `workAboutPlace`, `workRepresentsPlace`, combined `workAboutOrRepresentsPlace`, `workCreatedAtPlace`, `workPublishedAtPlace`.\n\n8. Concept-influence fixture\n- `conceptInfluencedByPlace` relation from place to concept records.\n\n---\n\n## Round 77 Addendum — Search Relations: Concept\n\nSource section basis:\n\n- Linked Art API relation docs (Concept-focused search links, including Language/Material specializations)\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Documented concept-centric search relations include:\n  - `activityClassifiedAsConcept`\n  - `agentClassifiedAsConcept`\n  - `conceptBroaderConcept`\n  - `conceptClassifiedAsConcept`\n  - `conceptInfluencedByConcept`\n  - `objectClassifiedAsConcept`\n  - `objectMadeOfMaterial`\n  - `objectProductionTechniqueConcept`\n  - `placeClassifiedAsConcept`\n  - `setClassifiedAsConcept`\n  - `workAboutConcept`\n  - `workAboutOrRepresentsConcept`\n  - `workClassifiedAsConcept`\n  - `workCreationTechniqueConcept`\n  - `workLanguageLanguage`\n  - `workRepresentsConcept`\n- Relation definitions specify:\n  - source class (`Concept`, plus special-source subclasses such as `Language` and `Material`)\n  - return class family (`Temporal`, `Agent`, `Concept`, `HumanMadeObject`, `Place`, `Set`, `Work`, `LinguisticObject`)\n  - semantic edge (`classifiedAs`, `broader`, `influencedBy`, `madeOf`, `productionTechnique`, `about`, `represents`, `creationTechnique`, `language`)\n- Provided SPARQL references act as semantic oracle for inverse traversal correctness.\n\n### Implementation Mapping — Concept Search Relations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Relation-name publication\n- Publish stable HAL relation links for the documented concept-centric relation set.\n\n2. Source-class specialization\n- Enforce source-class-specific relations:\n  - `objectMadeOfMaterial` expects material-class source semantics\n  - `workLanguageLanguage` expects language-class source semantics\n\n3. Result-class fidelity\n- Ensure each relation returns the documented class family (including broader “Temporal” or “Work” family aliases where used).\n\n4. Classification-vs-technique-vs-about semantics\n- Keep `classifiedAs`, `production/creationTechnique`, `about`, and `represents` semantics separated in relation handlers.\n\n5. Hierarchy and influence semantics\n- Preserve `broader` inverse/narrower behavior and concept influence chains distinctly.\n\n6. Search-page compliance\n- Relation targets must return valid Search API `OrderedCollectionPage` responses.\n\n7. Empty-result omission\n- Omit relation links when no matching referring records exist.\n\n### TDD Additions — Concept Search Relations\n\nAdd failing-first tests for concept-relation conformance:\n\nContract-level:\n\n- validates each listed relation is either present with valid HAL link shape or omitted when empty\n- validates followable relation targets return schema-valid search pages\n\nRoute-level:\n\n- validates `orderedItems[].type` matches documented return class family per relation\n- validates source-class-specific relations are only emitted for compatible concept subclasses\n\nIntegration-level:\n\n- graph fixtures verify inverse discovery for:\n  - entities classified as concept (activity/agent/object/place/set/work/concept)\n  - concept hierarchy (`broader`) and influence relations\n  - material-based object queries\n  - concept-as-technique queries for object production and work creation\n  - work about / represents concept and combined about-or-represents\n  - linguistic works by language concept\n\nRegression:\n\n- relation naming and source/return mappings remain stable across adapters/backends\n- classifier-vs-depiction semantics do not collapse into generic “related concepts” results\n\n### Fixture Anchors — Concept Search Relations Examples\n\nUse these relation patterns as fixture seeds:\n\n1. `objectClassifiedAsConcept` fixture\n- concept returns objects classified with that concept.\n\n2. `agentClassifiedAsConcept` fixture\n- concept returns people/groups classified with that concept.\n\n3. `conceptBroaderConcept` fixture\n- broader/narrower concept hierarchy inverse traversal.\n\n4. `objectMadeOfMaterial` fixture\n- material concept returns objects made of it.\n\n5. `objectProductionTechniqueConcept` fixture\n- concept returns objects whose production uses that technique.\n\n6. `workCreationTechniqueConcept` fixture\n- concept returns works whose creation uses that technique.\n\n7. `workLanguageLanguage` fixture\n- language concept returns linguistic works in that language.\n\n8. `workAboutConcept` / `workRepresentsConcept` fixture\n- works about concept vs works depicting concept, plus combined relation.\n\n9. `setClassifiedAsConcept` / `placeClassifiedAsConcept` fixture\n- concept returns classified sets and places.\n\n10. `activityClassifiedAsConcept` fixture\n- concept returns temporal/activity records classified as concept.\n\n---\n\n## Round 78 Addendum — Search Relations: Temporal / Event / Activity\n\nSource section basis:\n\n- Linked Art API relation docs (Temporal/Event/Activity-focused search links)\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Documented temporal/activity-centric search relations include:\n  - `activityCausedByActivity`\n  - `activityPartOfActivity`\n  - `conceptCreationCausedByActivity`\n  - `conceptInfluencedByActivity`\n  - `objectDestructionCausedByActivity`\n  - `objectProductionCausedByActivity`\n  - `personDeathCausedByActivity`\n  - `setCreationCausedByActivity`\n  - `workAboutActivity`\n  - `workAboutOrRepresentsActivity`\n  - `workCreationCausedByActivity`\n  - `workRepresentsActivity`\n- Relation definitions specify:\n  - source class family (`Event`, `Activity`, or broader `Temporal`)\n  - return class family (`Temporal`, `Concept`, `HumanMadeObject`, `Person`, `Set`, `Work`)\n  - causal, partitive, aboutness, and depiction inverse semantics\n- Provided examples emphasize:\n  - causality chains (event/activity causing creation, destruction, death)\n  - temporal containment (`partOf`)\n  - works about/representing temporal entities\n\n### Implementation Mapping — Temporal/Activity Search Relations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Relation-name publication\n- Publish stable HAL relation links for the documented temporal/event/activity relation set.\n\n2. Source-class family gating\n- Enforce source compatibility for `Event`/`Activity`-specific vs broader `Temporal` relations.\n\n3. Result-class fidelity\n- Ensure relation result item classes match documented return families.\n\n4. Causality semantics preservation\n- Preserve explicit caused-by inverse semantics for production/destruction/creation/death related relations.\n\n5. Part-of temporal hierarchy semantics\n- Preserve temporal part/whole traversal semantics for period/event/activity nesting.\n\n6. About-vs-represents separation\n- Preserve distinction between `about`, `represents`, and combined about-or-represents relation behavior.\n\n7. Search-page compliance\n- Relation targets must return valid Search API `OrderedCollectionPage` responses.\n\n8. Empty-result omission\n- Omit relation links when no matching records exist.\n\n### TDD Additions — Temporal/Activity Search Relations\n\nAdd failing-first tests for temporal/activity relation conformance:\n\nContract-level:\n\n- validates each listed relation is either present with valid HAL link shape or omitted when empty\n- validates followable relation targets return schema-valid search pages\n\nRoute-level:\n\n- validates `orderedItems[].type` against documented return class family per relation\n- validates source-family-incompatible relations are not emitted\n\nIntegration-level:\n\n- graph fixtures verify inverse discovery for:\n  - activities caused by source event/activity\n  - temporal part-of hierarchies\n  - concepts created/ influenced by temporal entities\n  - objects whose production/destruction is causally linked\n  - persons whose death is causally linked\n  - sets created due to event/activity\n  - works about/representing temporal entities\n  - works created due to event/activity\n\nRegression:\n\n- relation naming and class mapping remain stable across adapters/backends\n- causality and partitive semantics do not collapse into generic related-item queries\n\n### Fixture Anchors — Temporal/Activity Search Relations Examples\n\nUse these relation patterns as fixture seeds:\n\n1. `activityCausedByActivity` fixture\n- event/activity returning downstream caused activities.\n\n2. `activityPartOfActivity` fixture\n- period/event/activity with nested temporal components.\n\n3. `objectProductionCausedByActivity` fixture\n- causal activity returning produced object records.\n\n4. `objectDestructionCausedByActivity` fixture\n- destructive event returning destroyed object records.\n\n5. `personDeathCausedByActivity` fixture\n- event/activity returning persons with causally linked deaths.\n\n6. `conceptInfluencedByActivity` fixture\n- temporal source returning influenced concept records.\n\n7. `workAboutActivity` / `workRepresentsActivity` fixture\n- separated about vs represents work sets.\n\n8. `workAboutOrRepresentsActivity` fixture\n- combined about-or-represents work set behavior.\n\n9. `workCreationCausedByActivity` fixture\n- event/activity returning works created as causal outcome.\n\n10. `setCreationCausedByActivity` fixture\n- event/activity returning sets created due to source activity.\n\n---\n\n## Round 79 Addendum — Search Relations: Set\n\nSource section basis:\n\n- Linked Art API relation docs (Set-focused search links)\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Documented set-centric search relations include:\n  - `activityUsedSet`\n  - `conceptInfluencedBySet`\n  - `conceptMemberOfSet`\n  - `entityMemberOfSet`\n  - `objectMemberOfSet`\n  - `placeMemberOfSet`\n  - `setMemberOfSet`\n  - `temporalMemberOfSet`\n  - `workAboutOrRepresentsSet`\n  - `workAboutSet`\n  - `workMemberOfSet`\n  - `workRepresentsSet`\n- Relation definitions specify:\n  - source class (`Set`)\n  - return class family (`Activity`, `Concept`, `Entity`, `HumanMadeObject`, `Place`, `Set`, `Temporal`, `Work`)\n  - semantic basis (`used`, `influencedBy`, `memberOf`, `about`, `represents`)\n- These relations extend set discoverability without requiring full member embedding in set records.\n\n### Implementation Mapping — Set Search Relations\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Relation-name publication\n- Publish stable HAL relation links for the documented set-centric relations.\n\n2. Membership-matrix fidelity\n- Preserve distinct membership relation views by target class (`entity`, `object`, `place`, `set`, `temporal`, `work`, `concept`).\n\n3. Generic-vs-specialized relation coherence\n- Ensure `entityMemberOfSet` remains a superset-compatible view while specialized member relations return filtered class families.\n\n4. About-vs-represents semantics\n- Preserve distinct `workAboutSet`, `workRepresentsSet`, and combined `workAboutOrRepresentsSet` relation behavior.\n\n5. Activity/influence semantics\n- Preserve `activityUsedSet` and `conceptInfluencedBySet` edges without collapsing into generic related-item sets.\n\n6. Search-page compliance\n- Relation targets must return valid Search API `OrderedCollectionPage` responses.\n\n7. Empty-result omission\n- Omit relation links when no matching records exist.\n\n### TDD Additions — Set Search Relations\n\nAdd failing-first tests for set-relation conformance:\n\nContract-level:\n\n- validates each listed set relation is either present with valid HAL link shape or omitted when empty\n- validates followable relation targets return schema-valid search pages\n\nRoute-level:\n\n- validates `orderedItems[].type` matches documented return class family per relation\n- validates specialized member relations enforce class-specific filtering\n\nIntegration-level:\n\n- graph fixtures verify inverse discovery for:\n  - activities using set\n  - concepts influenced by set\n  - concepts/entities/objects/places/sets/temporals/works that are members of set\n  - works about set\n  - works representing set\n  - combined about-or-represents set relation\n\nRegression:\n\n- relation naming and class-return mappings remain stable across providers/backends\n- specialized relations do not regress into only generic `entityMemberOfSet` behavior\n\n### Fixture Anchors — Set Search Relations Examples\n\nUse these relation patterns as fixture seeds:\n\n1. `activityUsedSet` fixture\n- set linked to one or more activities using it.\n\n2. `entityMemberOfSet` fixture\n- set with mixed-member classes returned in generic member relation.\n\n3. Specialized membership fixtures\n- `objectMemberOfSet`, `placeMemberOfSet`, `setMemberOfSet`, `temporalMemberOfSet`, `workMemberOfSet`, `conceptMemberOfSet`.\n\n4. `conceptInfluencedBySet` fixture\n- set linked to concept(s) influenced by set context.\n\n5. `workAboutSet` fixture\n- works about set.\n\n6. `workRepresentsSet` fixture\n- visual works depicting set.\n\n7. `workAboutOrRepresentsSet` fixture\n- combined result set of about-or-represents relations.\n\n---\n\n## Round 80 Addendum — Data Discovery\n\nSource section basis:\n\n- Linked Art API 1.0: Data Discovery\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Linked Art records should be discoverable from non-Linked-Art entrypoints, especially HTML pages.\n- Discovery/signposting requirements:\n  - HTML `<head>` link with `rel=\"describedby\"` to Linked Art JSON-LD record is required.\n  - HTTP `Link` header with `rel=\"describedby\"` is recommended where possible.\n  - exactly one linked-art `describedby` target per page to avoid client ambiguity.\n  - media type should declare Linked Art JSON-LD profile:\n    - `application/ld+json;profile='https://linked.art/ns/v1/linked-art.json'`\n- This aligns with FAIR Signposting profile behavior.\n- Harvesting/synchronization guidance:\n  - use IIIF Change Discovery API for cross-collection aggregation and sync.\n  - include Linked Art record-type extension context:\n    - `https://linked.art/ns/v1/record-types.json`\n    - alongside IIIF discovery context\n  - enables change stream entries to carry Linked Art record `type` values (for example `HumanMadeObject`).\n\n### Implementation Mapping — Data Discovery\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. HTML signposting requirement\n- Ensure HTML views include exactly one `<link rel=\"describedby\" ...>` to canonical Linked Art record.\n\n2. HTTP link-header support\n- Emit `Link: <...>; rel=\"describedby\"; type=\"application/ld+json;profile='...'\"` when transport/runtime allows.\n\n3. Canonical record binding\n- Keep describedby target stable, canonical, and one-to-one with rendered page entity.\n\n4. Change-discovery integration\n- Expose or integrate IIIF Change Discovery endpoints for harvesting/sync workflows.\n\n5. Context extension compliance\n- Ensure IIIF change stream contexts include both Linked Art record-types context and IIIF discovery context.\n\n6. Type propagation in change events\n- Preserve Linked Art record types in change event `object.type` fields.\n\n### TDD Additions — Data Discovery\n\nAdd failing-first tests for discovery conformance:\n\nContract-level:\n\n- validates HTML responses include exactly one valid describedby link in `<head>`\n- validates describedby link MIME/profile declaration format\n- validates optional HTTP `Link` header format when enabled\n\nRoute-level:\n\n- HTML view route and JSON-LD data route stay correctly paired by describedby URI\n- duplicate/missing describedby link scenarios fail checks\n\nIntegration-level:\n\n- IIIF change stream includes required dual contexts (`record-types` + IIIF discovery)\n- change events include Linked Art record `id` and `type` values\n\nRegression:\n\n- page template updates cannot remove or duplicate describedby signposts\n- harvesting stream changes cannot drop Linked Art record type extension context\n\n### Fixture Anchors — Data Discovery Examples\n\nUse these discovery patterns as fixture seeds:\n\n1. HTML head signpost fixture\n- one `<link rel=\"describedby\" ...>` to canonical Linked Art JSON-LD URI.\n\n2. HTTP header signpost fixture\n- response with correct `Link` header profile/media type.\n\n3. Duplicate-link negative fixture\n- page with multiple describedby links fails validation.\n\n4. IIIF context fixture\n- change discovery payload with both required contexts in proper order.\n\n5. Change event type fixture\n- update event object with Linked Art `id` and `type` (for example `HumanMadeObject`).\n\n---\n\n## Round 81 Addendum — API Design Principles and Practical Requirements\n\nSource section basis:\n\n- Linked Art API: Design Principles + Requirements and Design Specifics\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Core design principles (IIIF-inspired) emphasize:\n  1. scope via shared use cases\n  2. internationalization support\n  3. as simple as possible (progressive complexity)\n  4. avoid stack lock-in\n  5. REST/web compatibility and cacheability\n  6. JSON-LD-first while following LOD principles\n  7. standards/best-practice reuse when practical\n  8. define success-not-failure for extensibility\n  9. network-aware design\n  10. solve at the correct layer (API vs model)\n- Practical requirements reinforce:\n  - trivial implementation possible via static files\n  - hand-authorable JSON should remain possible\n  - response count/size should stay minimal while consistent\n  - each statement should appear in one response where possible\n  - if a resource has many incoming references, it should be its own response\n  - inverse relationships should be resolved via dedicated APIs rather than duplicate assertions\n  - partition/part relationships generally flow from many -> one\n  - embed 1:1 dependent constructs where separate dereference is unnecessary\n  - URIs should remain opaque; no required URI structure assumptions\n\n### Implementation Mapping — API Design Requirements\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. File-first operability\n- Ensure core read-paths can run from static JSON artifacts without requiring dynamic query infrastructure.\n\n2. Single-assertion direction policy\n- Encode relationships once in canonical direction; provide inverse-discovery via search/HAL links.\n\n3. Many-to-one partitioning discipline\n- Prefer child-to-parent links for partition-heavy domains (for example page -> book, part -> whole).\n\n4. Minimal redundancy guardrail\n- Avoid duplicating the same fact across multiple payloads unless explicitly justified as performance exception.\n\n5. 1:1 embed policy\n- Embed dependent 1:1 structures (names, dimensions, timespans, etc.) unless separate dereference is needed.\n\n6. URI opacity\n- Avoid route/client logic that depends on URI path-shape assumptions beyond dereferenceability.\n\n7. Layer-correct solutions\n- Put data-description problems in model contracts; interaction/navigation problems in API/HAL/search layers.\n\n### TDD Additions — API Design Requirements\n\nAdd failing-first tests for architecture conformance:\n\nContract-level:\n\n- validates no duplicated canonical assertions across designated record pairs where single-direction policy applies\n- validates embedded 1:1 structures follow shared-structure contracts\n\nRoute-level:\n\n- validates inverse relationship discoverability through search/HAL links rather than duplicated forward+inverse fields\n- validates URI consumers treat IDs as opaque strings, not path-pattern parsed keys\n\nIntegration-level:\n\n- static-file fixture mode produces equivalent read responses to dynamic mode for core endpoints\n- partition fixtures confirm many->one link direction and inverse discovery behavior\n\nRegression:\n\n- optimization changes cannot silently introduce broad statement duplication\n- backend swaps cannot break file-first minimum implementation mode\n\n### Fixture Anchors — API Design Requirements Examples\n\nUse these architecture patterns as fixture seeds:\n\n1. Static-mode parity fixture\n- endpoint responses from static artifacts match dynamic pipeline outputs.\n\n2. Single-direction relationship fixture\n- fact appears once; inverse discovered via search link.\n\n3. Partition direction fixture\n- child records reference parent; parent inverse list discovered via search API.\n\n4. Opaque URI fixture\n- consumer utilities handle arbitrary URI structures without path-shape coupling.\n\n5. 1:1 embed fixture\n- embedded dependent structures (name/dimension/timespan) validate without separate dereference requirement.\n\n---\n\n## Round 82 Addendum — JSON-LD and Context Design\n\nSource section basis:\n\n- Linked Art API: JSON-LD serialization + context design rules\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Canonical Linked Art context:\n  - `https://linked.art/ns/v1/linked-art.json`\n- Canonical media type/profile:\n  - `application/ld+json;profile=\"https://linked.art/ns/v1/linked-art.json\"`\n- Core serialization constraints:\n  - terms are case-sensitive (for example `Type` vs `type`)\n  - JSON properties cannot be repeated; multi-values use arrays\n  - Linked Art avoids RDF ordered list structures and relies on array order\n- Other RDF/graph serializations may exist but are optional and must not be assumed.\n- Context design goals:\n  - valid JSON-LD + LOD semantics\n  - developer-friendly JSON shapes\n  - cross-language implementation usability\n- Context transformation strategy from CRM terms includes:\n  - namespace/prefix cleanup\n  - number/punctuation simplification\n  - class naming to UpperCamelCase\n  - property naming to lower_snake_case\n  - collision resolution and inconsistency normalization\n- Context uses JSON-LD 1.1 scoped contexts and set containers:\n  - `@container: @set` for properties that may have multiple values\n  - mapped partition relationships to consistent `part` / `part_of` keys\n\n### Implementation Mapping — JSON-LD Context Design\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Context/media-type correctness\n- Always emit canonical Linked Art context and correct JSON-LD profile media type on API responses.\n\n2. Case-sensitive key discipline\n- Enforce key casing exactly per context definitions in serializers and validators.\n\n3. Array-normalization rule\n- Emit array form for potentially multi-valued properties, even when only one value is present.\n\n4. Context-driven naming consistency\n- Use context-resolved canonical keys (including normalized collision-resolved keys) consistently across all routes.\n\n5. Scoped-context behavior preservation\n- Preserve `part` / `part_of` unified readability while keeping underlying semantic precision.\n\n6. Optional format tolerance\n- Support alternate serializations where offered, but do not require them for conformance.\n\n7. Collision-map stability\n- Treat documented collision/inconsistency remappings as stable API contract behavior, not implementation details.\n\n### TDD Additions — JSON-LD Context Design\n\nAdd failing-first tests for JSON-LD/context conformance:\n\nContract-level:\n\n- validates root `@context` matches canonical Linked Art context URI\n- validates case-sensitive keys and rejection of incorrect-cased alternatives\n- validates single-or-many fields are serialized as arrays where context requires set behavior\n\nRoute-level:\n\n- validates `Content-Type` profile string for JSON-LD responses\n- validates partition relationships serialize consistently as `part` / `part_of` where scoped context applies\n\nIntegration-level:\n\n- round-trip tests verify JSON-LD expansions preserve expected RDF semantics\n- context collision-remap keys stay stable across endpoint families\n\nRegression:\n\n- serializer changes cannot reintroduce CRM raw-term inconsistencies into payload keys\n- profile/media-type drift is caught by response-header contract tests\n\n### Fixture Anchors — JSON-LD Context Design Examples\n\nUse these JSON-LD patterns as fixture seeds:\n\n1. Canonical context fixture\n- payload with exact linked-art context URI and profile media type.\n\n2. Case-sensitivity negative fixture\n- incorrect-cased term keys fail validation.\n\n3. Array-singleton fixture\n- potentially multi-valued property serialized as single-entry array.\n\n4. Partition key fixture\n- scoped-context mapped `part` / `part_of` relations with expected semantics.\n\n5. Collision-key stability fixture\n- payload uses normalized context keys (not raw CRM-numbered property names).\n\n6. Expansion integrity fixture\n- JSON-LD expansion check confirming preserved predicate mapping.\n\n---\n\n## Round 83 Addendum — Protocol (HTTP/REST)\n\nSource section basis:\n\n- Linked Art API: Protocol\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- Linked Art protocol profile is REST/resource-centric over HTTP.\n- Transport/security/version guidance:\n  - HTTPS strongly recommended\n  - servers must support HTTP/1.1\n  - servers should support HTTP/2+\n- Operation support:\n  - publishers must support `GET` and `OPTIONS`\n  - publishers should support `HEAD`\n  - clients must not rely on `HEAD` support\n- Content negotiation:\n  - request `Accept: application/ld+json;profile=\"https://linked.art/ns/v1/linked-art.json\"`\n  - response `Content-Type: application/ld+json;profile=\"https://linked.art/ns/v1/linked-art.json\"`\n  - alternate serializations may be supported, but discovery mechanism is not standardized by Linked Art\n- CORS requirements:\n  - responses must include `Access-Control-Allow-Origin: *`\n  - `OPTIONS` preflight responses must include CORS headers as well\n- URI policy:\n  - no strict URI structure requirements (URIs remain opaque)\n  - preferred shape: `scheme://hostname/prefix/endpoint/identifier`\n  - preferred endpoint path names:\n    - `concept`, `digital`, `event`, `group`, `object`, `person`, `place`, `provenance`, `set`, `text`, `visual`\n\n### Implementation Mapping — Protocol\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Method support compliance\n- Ensure all public API routes support `GET` and `OPTIONS`; optionally support `HEAD` without client dependency.\n\n2. JSON-LD conneg compliance\n- Enforce Accept/Content-Type profile handling for Linked Art JSON-LD responses.\n\n3. CORS baseline compliance\n- Emit `Access-Control-Allow-Origin: *` on both normal and preflight responses for API resources.\n\n4. HTTP-version readiness\n- Maintain HTTP/1.1 compatibility; prefer HTTP/2+ deployment where available.\n\n5. URI opacity discipline\n- Treat all URIs as opaque in client/server logic; never depend on URI path parsing for semantics.\n\n6. URI good-practice alignment\n- Where controllable, align endpoint naming and URI patterns with preferred conventions for maintainability.\n\n### TDD Additions — Protocol\n\nAdd failing-first tests for protocol conformance:\n\nContract-level:\n\n- validates response `Content-Type` includes Linked Art JSON-LD profile\n- validates preflight and normal responses include required CORS header\n\nRoute-level:\n\n- validates `GET` and `OPTIONS` are supported for endpoint families\n- validates unsupported methods return controlled/consistent status behavior\n\nIntegration-level:\n\n- validates conneg behavior for profile-accepting requests\n- validates route behavior remains stable regardless of URI shape assumptions\n\nRegression:\n\n- deployment/config changes cannot drop CORS headers or content-profile headers\n- router changes cannot break preferred endpoint namespace mapping where implemented\n\n### Fixture Anchors — Protocol Examples\n\nUse these protocol patterns as fixture seeds:\n\n1. GET success fixture\n- endpoint returns JSON-LD payload with canonical Content-Type profile.\n\n2. OPTIONS preflight fixture\n- preflight response includes `Access-Control-Allow-Origin: *`.\n\n3. HEAD optional-support fixture\n- if implemented, returns headers-only response; client tests remain non-dependent.\n\n4. Conneg fixture\n- request with Linked Art Accept profile returns matching profile Content-Type.\n\n5. URI opacity fixture\n- alternative URI path patterns still resolve correctly without parser assumptions.\n\n6. Endpoint-name mapping fixture\n- canonical endpoint paths (`object`, `person`, etc.) map to expected serializers.\n\n---\n\n## Round 84 Addendum — Code and Tools Ecosystem\n\nSource section basis:\n\n- Linked Art: Code and Tools references\n- Captured for this addendum on: May 30, 2026\n\nOfficial-model takeaways captured for implementation:\n\n- This section is ecosystem guidance rather than normative API contract rules.\n- Referenced software/library/platform categories include:\n  - Libraries:\n    - Crom (Python)\n    - LinkedArt.js (JavaScript)\n    - Linked.Art.Net (C#/.NET)\n  - Platforms:\n    - LUX (open-source cross-collection discovery implementation)\n    - Arches\n    - Ogee Arches package (Linked Art model + vocabulary support)\n  - Documentation/pattern tooling:\n    - Zellij (semantic pattern library representation)\n  - Validators:\n    - JSON validator service based on Linked Art schemas\n  - Other resources:\n    - data-model visualization tools\n    - Mermaid Live Editor\n    - OpenRefine for collections data cleanup/handling\n\n### Implementation Mapping — Code and Tools\n\nApply these requirements to adapters, normalization, and route outputs:\n\n1. Non-normative dependency policy\n- Treat tooling references as implementation accelerators, not as conformance requirements.\n\n2. Toolchain selection criteria\n- Prefer tools that preserve Linked Art schema/context fidelity and integrate with existing test/validation workflows.\n\n3. Validator integration\n- Keep JSON Schema validation in automated pipelines regardless of chosen library/platform stack.\n\n4. Pattern documentation integration\n- Use pattern libraries/visualization tools to strengthen onboarding, mapping clarity, and query/template generation.\n\n5. Data hygiene workflow support\n- Integrate data-cleaning tooling (for example OpenRefine-compatible flows) upstream of ingestion where helpful.\n\n### TDD Additions — Code and Tools\n\nAdd failing-first tests for toolchain reliability expectations:\n\nContract-level:\n\n- validate core payloads with schema validators independent of runtime language/library\n\nIntegration-level:\n\n- smoke tests confirm chosen serializer/parser libraries preserve canonical context and key semantics\n- import/cleanup workflows retain required Linked Art fields after transformation\n\nRegression:\n\n- library/platform upgrades do not alter canonical payload shape or break schema conformance\n- toolchain swaps maintain identical API-facing contracts\n\n### Fixture Anchors — Code and Tools Examples\n\nUse these ecosystem-oriented patterns as fixture seeds:\n\n1. Cross-library parity fixture\n- same record serialized/parsed through selected library paths yields equivalent canonical JSON-LD.\n\n2. Validator parity fixture\n- local CI schema validation and external validator results agree on pass/fail.\n\n3. Data-cleaning fixture\n- pre/post-cleaning payloads retain required Linked Art semantics and identifiers.\n\n4. Visualization/documentation fixture\n- model pattern artifacts generated from fixture graph remain consistent with schema contracts.\n\n---\n\n## Round 1 Open Items For Next Docs Drop\n\nPlease add official material in future rounds for:\n\n- detailed basic pattern examples\n- required vs recommended vs optional terminology specifics\n- concrete JSON-LD examples for activities, provenance, exhibitions, conservation, and object production/destruction\n- model versioning rules and upgrade guidance\n- specific assertions and archival hierarchy examples\n\nWhen those arrive, we should extend this file with explicit fixture-driven test plans.\n","sections":[{"level":2,"heading":"Purpose","anchor":"purpose"},{"level":2,"heading":"Canonical Model Summary","anchor":"canonical-model-summary"},{"level":2,"heading":"Model Coverage Areas (from official structure)","anchor":"model-coverage-areas-from-official-structure"},{"level":2,"heading":"Design Principles To Preserve","anchor":"design-principles-to-preserve"},{"level":2,"heading":"Scope Boundaries (Important)","anchor":"scope-boundaries-important"},{"level":2,"heading":"Meta Museum Implementation Mapping (Round 1)","anchor":"meta-museum-implementation-mapping-round-1"},{"level":2,"heading":"TDD Guidance Derived From Linked Art 1.0","anchor":"tdd-guidance-derived-from-linked-art-1-0"},{"level":3,"heading":"Contract-level tests","anchor":"contract-level-tests"},{"level":3,"heading":"Adapter-level tests","anchor":"adapter-level-tests"},{"level":3,"heading":"Route-level tests","anchor":"route-level-tests"},{"level":3,"heading":"Regression tests","anchor":"regression-tests"},{"level":2,"heading":"Roadmap Hooks (What this reference should drive)","anchor":"roadmap-hooks-what-this-reference-should-drive"},{"level":2,"heading":"Round 2 Addendum — Objects (Physical Object Modeling)","anchor":"round-2-addendum-objects-physical-object-modeling"},{"level":3,"heading":"Implementation Mapping — Objects","anchor":"implementation-mapping-objects"},{"level":3,"heading":"TDD Additions — Objects","anchor":"tdd-additions-objects"},{"level":2,"heading":"Round 3 Addendum — Digital Content","anchor":"round-3-addendum-digital-content"},{"level":3,"heading":"Implementation Mapping — Digital Content","anchor":"implementation-mapping-digital-content"},{"level":3,"heading":"TDD Additions — Digital Content","anchor":"tdd-additions-digital-content"},{"level":3,"heading":"Fixture Anchors — Digital Content Examples","anchor":"fixture-anchors-digital-content-examples"},{"level":2,"heading":"Round 4 Addendum — Collections and Sets","anchor":"round-4-addendum-collections-and-sets"},{"level":3,"heading":"Implementation Mapping — Collections/Sets","anchor":"implementation-mapping-collections-sets"},{"level":3,"heading":"TDD Additions — Collections/Sets","anchor":"tdd-additions-collections-sets"},{"level":3,"heading":"Fixture Anchors — Collections/Sets Examples","anchor":"fixture-anchors-collections-sets-examples"},{"level":2,"heading":"Round 5 Addendum — Object Provenance","anchor":"round-5-addendum-object-provenance"},{"level":3,"heading":"Implementation Mapping — Provenance","anchor":"implementation-mapping-provenance"},{"level":3,"heading":"TDD Additions — Provenance","anchor":"tdd-additions-provenance"},{"level":3,"heading":"Fixture Anchors — Provenance Examples","anchor":"fixture-anchors-provenance-examples"},{"level":2,"heading":"Round 6 Addendum — Acquisitions and Loans","anchor":"round-6-addendum-acquisitions-and-loans"},{"level":3,"heading":"Implementation Mapping — Acquisitions/Payments","anchor":"implementation-mapping-acquisitions-payments"},{"level":3,"heading":"TDD Additions — Acquisitions/Payments","anchor":"tdd-additions-acquisitions-payments"},{"level":3,"heading":"Fixture Anchors — Acquisitions/Payments Examples","anchor":"fixture-anchors-acquisitions-payments-examples"},{"level":2,"heading":"Round 7 Addendum — Auctions","anchor":"round-7-addendum-auctions"},{"level":3,"heading":"Implementation Mapping — Auctions","anchor":"implementation-mapping-auctions"},{"level":3,"heading":"TDD Additions — Auctions","anchor":"tdd-additions-auctions"},{"level":3,"heading":"Fixture Anchors — Auctions Examples","anchor":"fixture-anchors-auctions-examples"},{"level":2,"heading":"Round 8 Addendum — Changes of Custody","anchor":"round-8-addendum-changes-of-custody"},{"level":3,"heading":"Implementation Mapping — Custody","anchor":"implementation-mapping-custody"},{"level":3,"heading":"TDD Additions — Custody","anchor":"tdd-additions-custody"},{"level":3,"heading":"Fixture Anchors — Custody Examples","anchor":"fixture-anchors-custody-examples"},{"level":2,"heading":"Round 9 Addendum — Exhibitions","anchor":"round-9-addendum-exhibitions"},{"level":3,"heading":"Implementation Mapping — Exhibitions","anchor":"implementation-mapping-exhibitions"},{"level":3,"heading":"TDD Additions — Exhibitions","anchor":"tdd-additions-exhibitions"},{"level":3,"heading":"Fixture Anchors — Exhibitions Examples","anchor":"fixture-anchors-exhibitions-examples"},{"level":2,"heading":"Round 10 Addendum — Encounters with Objects","anchor":"round-10-addendum-encounters-with-objects"},{"level":3,"heading":"Implementation Mapping — Encounters","anchor":"implementation-mapping-encounters"},{"level":3,"heading":"TDD Additions — Encounters","anchor":"tdd-additions-encounters"},{"level":3,"heading":"Fixture Anchors — Encounters Examples","anchor":"fixture-anchors-encounters-examples"},{"level":2,"heading":"Round 11 Addendum — Location and Movement","anchor":"round-11-addendum-location-and-movement"},{"level":3,"heading":"Implementation Mapping — Movement","anchor":"implementation-mapping-movement"},{"level":3,"heading":"TDD Additions — Movement","anchor":"tdd-additions-movement"},{"level":3,"heading":"Fixture Anchors — Movement Examples","anchor":"fixture-anchors-movement-examples"},{"level":2,"heading":"Round 12 Addendum — Promised Activities","anchor":"round-12-addendum-promised-activities"},{"level":3,"heading":"Implementation Mapping — Promises","anchor":"implementation-mapping-promises"},{"level":3,"heading":"TDD Additions — Promised Activities","anchor":"tdd-additions-promised-activities"},{"level":3,"heading":"Fixture Anchors — Promised Activities Examples","anchor":"fixture-anchors-promised-activities-examples"},{"level":2,"heading":"Round 13 Addendum — Transfer of Rights","anchor":"round-13-addendum-transfer-of-rights"},{"level":3,"heading":"Implementation Mapping — Rights","anchor":"implementation-mapping-rights"},{"level":3,"heading":"TDD Additions — Rights","anchor":"tdd-additions-rights"},{"level":3,"heading":"Fixture Anchors — Rights Examples","anchor":"fixture-anchors-rights-examples"},{"level":2,"heading":"Round 14 Addendum — Unknown Transfers","anchor":"round-14-addendum-unknown-transfers"},{"level":3,"heading":"Implementation Mapping — Unknown Transfers","anchor":"implementation-mapping-unknown-transfers"},{"level":3,"heading":"TDD Additions — Unknown Transfers","anchor":"tdd-additions-unknown-transfers"},{"level":3,"heading":"Fixture Anchors — Unknown Transfers Examples","anchor":"fixture-anchors-unknown-transfers-examples"},{"level":2,"heading":"Round 15 Addendum — Conservation","anchor":"round-15-addendum-conservation"},{"level":3,"heading":"Implementation Mapping — Conservation","anchor":"implementation-mapping-conservation"},{"level":3,"heading":"TDD Additions — Conservation","anchor":"tdd-additions-conservation"},{"level":3,"heading":"Fixture Anchors — Conservation Examples","anchor":"fixture-anchors-conservation-examples"},{"level":2,"heading":"Round 16 Addendum — People and Organizations","anchor":"round-16-addendum-people-and-organizations"},{"level":3,"heading":"Implementation Mapping — People/Organizations","anchor":"implementation-mapping-people-organizations"},{"level":3,"heading":"TDD Additions — People/Organizations","anchor":"tdd-additions-people-organizations"},{"level":3,"heading":"Fixture Anchors — People/Organizations Examples","anchor":"fixture-anchors-people-organizations-examples"},{"level":2,"heading":"Round 17 Addendum — Places","anchor":"round-17-addendum-places"},{"level":3,"heading":"Implementation Mapping — Places","anchor":"implementation-mapping-places"},{"level":3,"heading":"TDD Additions — Places","anchor":"tdd-additions-places"},{"level":3,"heading":"Fixture Anchors — Places Examples","anchor":"fixture-anchors-places-examples"},{"level":2,"heading":"Round 18 Addendum — Concepts","anchor":"round-18-addendum-concepts"},{"level":3,"heading":"Implementation Mapping — Concepts","anchor":"implementation-mapping-concepts"},{"level":3,"heading":"TDD Additions — Concepts","anchor":"tdd-additions-concepts"},{"level":3,"heading":"Fixture Anchors — Concepts Examples","anchor":"fixture-anchors-concepts-examples"},{"level":2,"heading":"Round 19 Addendum — Events","anchor":"round-19-addendum-events"},{"level":3,"heading":"Implementation Mapping — Events","anchor":"implementation-mapping-events"},{"level":3,"heading":"TDD Additions — Events","anchor":"tdd-additions-events"},{"level":3,"heading":"Fixture Anchors — Events Examples","anchor":"fixture-anchors-events-examples"},{"level":2,"heading":"Round 20 Addendum — About Vocabulary Terms","anchor":"round-20-addendum-about-vocabulary-terms"},{"level":3,"heading":"Implementation Mapping — Vocabulary Terms","anchor":"implementation-mapping-vocabulary-terms"},{"level":3,"heading":"TDD Additions — Vocabulary Terms","anchor":"tdd-additions-vocabulary-terms"},{"level":3,"heading":"Fixture Anchors — Vocabulary Terms Examples","anchor":"fixture-anchors-vocabulary-terms-examples"},{"level":2,"heading":"Round 21 Addendum — Required Terms","anchor":"round-21-addendum-required-terms"},{"level":3,"heading":"Implementation Mapping — Required Terms","anchor":"implementation-mapping-required-terms"},{"level":3,"heading":"TDD Additions — Required Terms","anchor":"tdd-additions-required-terms"},{"level":3,"heading":"Fixture Anchors — Required Terms Examples","anchor":"fixture-anchors-required-terms-examples"},{"level":2,"heading":"Round 22 Addendum — Recommended Terms","anchor":"round-22-addendum-recommended-terms"},{"level":3,"heading":"Implementation Mapping — Recommended Terms","anchor":"implementation-mapping-recommended-terms"},{"level":3,"heading":"TDD Additions — Recommended Terms","anchor":"tdd-additions-recommended-terms"},{"level":3,"heading":"Fixture Anchors — Recommended Terms Examples","anchor":"fixture-anchors-recommended-terms-examples"},{"level":2,"heading":"Round 23 Addendum — Optional Terms","anchor":"round-23-addendum-optional-terms"},{"level":3,"heading":"Implementation Mapping — Optional Terms","anchor":"implementation-mapping-optional-terms"},{"level":3,"heading":"TDD Additions — Optional Terms","anchor":"tdd-additions-optional-terms"},{"level":3,"heading":"Fixture Anchors — Optional Terms Examples","anchor":"fixture-anchors-optional-terms-examples"},{"level":2,"heading":"Round 24 Addendum — Textual Documents","anchor":"round-24-addendum-textual-documents"},{"level":3,"heading":"Implementation Mapping — Textual Documents","anchor":"implementation-mapping-textual-documents"},{"level":3,"heading":"TDD Additions — Textual Documents","anchor":"tdd-additions-textual-documents"},{"level":3,"heading":"Fixture Anchors — Textual Documents Examples","anchor":"fixture-anchors-textual-documents-examples"},{"level":2,"heading":"Round 25 Addendum — Archival Hierarchies","anchor":"round-25-addendum-archival-hierarchies"},{"level":3,"heading":"Implementation Mapping — Archival Hierarchies","anchor":"implementation-mapping-archival-hierarchies"},{"level":3,"heading":"TDD Additions — Archival Hierarchies","anchor":"tdd-additions-archival-hierarchies"},{"level":3,"heading":"Fixture Anchors — Archival Hierarchies Examples","anchor":"fixture-anchors-archival-hierarchies-examples"},{"level":2,"heading":"Round 26 Addendum — Specific Assertions","anchor":"round-26-addendum-specific-assertions"},{"level":3,"heading":"Implementation Mapping — Specific Assertions","anchor":"implementation-mapping-specific-assertions"},{"level":3,"heading":"TDD Additions — Specific Assertions","anchor":"tdd-additions-specific-assertions"},{"level":3,"heading":"Fixture Anchors — Specific Assertions Examples","anchor":"fixture-anchors-specific-assertions-examples"},{"level":2,"heading":"Round 27 Addendum — Profile","anchor":"round-27-addendum-profile"},{"level":3,"heading":"Implementation Mapping — Profile","anchor":"implementation-mapping-profile"},{"level":3,"heading":"TDD Additions — Profile","anchor":"tdd-additions-profile"},{"level":3,"heading":"Fixture Anchors — Profile Examples","anchor":"fixture-anchors-profile-examples"},{"level":2,"heading":"Round 28 Addendum — Linked Art Terms Ontology (RDF Extensions)","anchor":"round-28-addendum-linked-art-terms-ontology-rdf-extensions"},{"level":3,"heading":"Implementation Mapping — Terms Ontology","anchor":"implementation-mapping-terms-ontology"},{"level":3,"heading":"TDD Additions — Terms Ontology","anchor":"tdd-additions-terms-ontology"},{"level":3,"heading":"Fixture Anchors — Terms Ontology Examples","anchor":"fixture-anchors-terms-ontology-examples"},{"level":2,"heading":"Round 29 Addendum — CIDOC-CRM Class Analysis (Practical Utility Profile)","anchor":"round-29-addendum-cidoc-crm-class-analysis-practical-utility-profile"},{"level":3,"heading":"Implementation Mapping — Class Analysis","anchor":"implementation-mapping-class-analysis"},{"level":3,"heading":"TDD Additions — Class Analysis","anchor":"tdd-additions-class-analysis"},{"level":3,"heading":"Fixture Anchors — Class Analysis Examples","anchor":"fixture-anchors-class-analysis-examples"},{"level":2,"heading":"Round 30 Addendum — Linked Art API 1.0 Foundations","anchor":"round-30-addendum-linked-art-api-1-0-foundations"},{"level":3,"heading":"Implementation Mapping — API Foundations","anchor":"implementation-mapping-api-foundations"},{"level":3,"heading":"TDD Additions — API Foundations","anchor":"tdd-additions-api-foundations"},{"level":3,"heading":"Fixture Anchors — API Foundations Examples","anchor":"fixture-anchors-api-foundations-examples"},{"level":2,"heading":"Round 31 Addendum — About Endpoints (Entity Endpoint Taxonomy)","anchor":"round-31-addendum-about-endpoints-entity-endpoint-taxonomy"},{"level":3,"heading":"Implementation Mapping — Endpoint Taxonomy","anchor":"implementation-mapping-endpoint-taxonomy"},{"level":3,"heading":"TDD Additions — Endpoint Taxonomy","anchor":"tdd-additions-endpoint-taxonomy"},{"level":3,"heading":"Fixture Anchors — Endpoint Taxonomy Examples","anchor":"fixture-anchors-endpoint-taxonomy-examples"},{"level":2,"heading":"Round 32 Addendum — Abstract Works Endpoint","anchor":"round-32-addendum-abstract-works-endpoint"},{"level":3,"heading":"Implementation Mapping — Abstract Works Endpoint","anchor":"implementation-mapping-abstract-works-endpoint"},{"level":3,"heading":"TDD Additions — Abstract Works Endpoint","anchor":"tdd-additions-abstract-works-endpoint"},{"level":3,"heading":"Fixture Anchors — Abstract Works Endpoint Examples","anchor":"fixture-anchors-abstract-works-endpoint-examples"},{"level":2,"heading":"Round 33 Addendum — Concepts Endpoint","anchor":"round-33-addendum-concepts-endpoint"},{"level":3,"heading":"Implementation Mapping — Concepts Endpoint","anchor":"implementation-mapping-concepts-endpoint"},{"level":3,"heading":"TDD Additions — Concepts Endpoint","anchor":"tdd-additions-concepts-endpoint"},{"level":3,"heading":"Fixture Anchors — Concepts Endpoint Examples","anchor":"fixture-anchors-concepts-endpoint-examples"},{"level":2,"heading":"Round 34 Addendum — Digital Objects Endpoint","anchor":"round-34-addendum-digital-objects-endpoint"},{"level":3,"heading":"Implementation Mapping — Digital Objects Endpoint","anchor":"implementation-mapping-digital-objects-endpoint"},{"level":3,"heading":"TDD Additions — Digital Objects Endpoint","anchor":"tdd-additions-digital-objects-endpoint"},{"level":3,"heading":"Fixture Anchors — Digital Objects Endpoint Examples","anchor":"fixture-anchors-digital-objects-endpoint-examples"},{"level":2,"heading":"Round 35 Addendum — Events Endpoint","anchor":"round-35-addendum-events-endpoint"},{"level":3,"heading":"Implementation Mapping — Events Endpoint","anchor":"implementation-mapping-events-endpoint"},{"level":3,"heading":"TDD Additions — Events Endpoint","anchor":"tdd-additions-events-endpoint"},{"level":3,"heading":"Fixture Anchors — Events Endpoint Examples","anchor":"fixture-anchors-events-endpoint-examples"},{"level":2,"heading":"Round 36 Addendum — Groups Endpoint","anchor":"round-36-addendum-groups-endpoint"},{"level":3,"heading":"Implementation Mapping — Groups Endpoint","anchor":"implementation-mapping-groups-endpoint"},{"level":3,"heading":"TDD Additions — Groups Endpoint","anchor":"tdd-additions-groups-endpoint"},{"level":3,"heading":"Fixture Anchors — Groups Endpoint Examples","anchor":"fixture-anchors-groups-endpoint-examples"},{"level":2,"heading":"Round 37 Addendum — People Endpoint","anchor":"round-37-addendum-people-endpoint"},{"level":3,"heading":"Implementation Mapping — People Endpoint","anchor":"implementation-mapping-people-endpoint"},{"level":3,"heading":"TDD Additions — People Endpoint","anchor":"tdd-additions-people-endpoint"},{"level":3,"heading":"Fixture Anchors — People Endpoint Examples","anchor":"fixture-anchors-people-endpoint-examples"},{"level":2,"heading":"Round 38 Addendum — Physical Objects Endpoint","anchor":"round-38-addendum-physical-objects-endpoint"},{"level":3,"heading":"Implementation Mapping — Physical Objects Endpoint","anchor":"implementation-mapping-physical-objects-endpoint"},{"level":3,"heading":"TDD Additions — Physical Objects Endpoint","anchor":"tdd-additions-physical-objects-endpoint"},{"level":3,"heading":"Fixture Anchors — Physical Objects Endpoint Examples","anchor":"fixture-anchors-physical-objects-endpoint-examples"},{"level":2,"heading":"Round 39 Addendum — Places Endpoint","anchor":"round-39-addendum-places-endpoint"},{"level":3,"heading":"Implementation Mapping — Places Endpoint","anchor":"implementation-mapping-places-endpoint"},{"level":3,"heading":"TDD Additions — Places Endpoint","anchor":"tdd-additions-places-endpoint"},{"level":3,"heading":"Fixture Anchors — Places Endpoint Examples","anchor":"fixture-anchors-places-endpoint-examples"},{"level":2,"heading":"Round 40 Addendum — Provenance Activities Endpoint","anchor":"round-40-addendum-provenance-activities-endpoint"},{"level":3,"heading":"Implementation Mapping — Provenance Activities Endpoint","anchor":"implementation-mapping-provenance-activities-endpoint"},{"level":3,"heading":"TDD Additions — Provenance Activities Endpoint","anchor":"tdd-additions-provenance-activities-endpoint"},{"level":3,"heading":"Fixture Anchors — Provenance Activities Endpoint Examples","anchor":"fixture-anchors-provenance-activities-endpoint-examples"},{"level":2,"heading":"Round 41 Addendum — Sets Endpoint","anchor":"round-41-addendum-sets-endpoint"},{"level":3,"heading":"Implementation Mapping — Sets Endpoint","anchor":"implementation-mapping-sets-endpoint"},{"level":3,"heading":"TDD Additions — Sets Endpoint","anchor":"tdd-additions-sets-endpoint"},{"level":3,"heading":"Fixture Anchors — Sets Endpoint Examples","anchor":"fixture-anchors-sets-endpoint-examples"},{"level":2,"heading":"Round 42 Addendum — Textual Works Endpoint","anchor":"round-42-addendum-textual-works-endpoint"},{"level":3,"heading":"Implementation Mapping — Textual Works Endpoint","anchor":"implementation-mapping-textual-works-endpoint"},{"level":3,"heading":"TDD Additions — Textual Works Endpoint","anchor":"tdd-additions-textual-works-endpoint"},{"level":3,"heading":"Fixture Anchors — Textual Works Endpoint Examples","anchor":"fixture-anchors-textual-works-endpoint-examples"},{"level":2,"heading":"Round 43 Addendum — Visual Works Endpoint","anchor":"round-43-addendum-visual-works-endpoint"},{"level":3,"heading":"Implementation Mapping — Visual Works Endpoint","anchor":"implementation-mapping-visual-works-endpoint"},{"level":3,"heading":"TDD Additions — Visual Works Endpoint","anchor":"tdd-additions-visual-works-endpoint"},{"level":3,"heading":"Fixture Anchors — Visual Works Endpoint Examples","anchor":"fixture-anchors-visual-works-endpoint-examples"},{"level":2,"heading":"Round 44 Addendum — Shared Structures","anchor":"round-44-addendum-shared-structures"},{"level":3,"heading":"Implementation Mapping — Shared Structures","anchor":"implementation-mapping-shared-structures"},{"level":3,"heading":"TDD Additions — Shared Structures","anchor":"tdd-additions-shared-structures"},{"level":3,"heading":"Fixture Anchors — Shared Structures Examples","anchor":"fixture-anchors-shared-structures-examples"},{"level":2,"heading":"Round 45 Addendum — Shared Structure: Activities","anchor":"round-45-addendum-shared-structure-activities"},{"level":3,"heading":"Implementation Mapping — Shared Activities","anchor":"implementation-mapping-shared-activities"},{"level":3,"heading":"TDD Additions — Shared Activities","anchor":"tdd-additions-shared-activities"},{"level":3,"heading":"Fixture Anchors — Shared Activities Examples","anchor":"fixture-anchors-shared-activities-examples"},{"level":2,"heading":"Round 46 Addendum — Shared Structure: Digital Links","anchor":"round-46-addendum-shared-structure-digital-links"},{"level":3,"heading":"Implementation Mapping — Shared Digital Links","anchor":"implementation-mapping-shared-digital-links"},{"level":3,"heading":"TDD Additions — Shared Digital Links","anchor":"tdd-additions-shared-digital-links"},{"level":3,"heading":"Fixture Anchors — Shared Digital Links Examples","anchor":"fixture-anchors-shared-digital-links-examples"},{"level":2,"heading":"Round 47 Addendum — Shared Structure: Activities (Reconfirmation)","anchor":"round-47-addendum-shared-structure-activities-reconfirmation"},{"level":3,"heading":"Implementation Mapping — Shared Activities (Reconfirmation)","anchor":"implementation-mapping-shared-activities-reconfirmation"},{"level":3,"heading":"TDD Additions — Shared Activities (Reconfirmation)","anchor":"tdd-additions-shared-activities-reconfirmation"},{"level":3,"heading":"Fixture Anchors — Shared Activities (Reconfirmation)","anchor":"fixture-anchors-shared-activities-reconfirmation"},{"level":2,"heading":"Round 48 Addendum — Shared Structure: Dimensions","anchor":"round-48-addendum-shared-structure-dimensions"},{"level":3,"heading":"Implementation Mapping — Shared Dimensions","anchor":"implementation-mapping-shared-dimensions"},{"level":3,"heading":"TDD Additions — Shared Dimensions","anchor":"tdd-additions-shared-dimensions"},{"level":3,"heading":"Fixture Anchors — Shared Dimensions Examples","anchor":"fixture-anchors-shared-dimensions-examples"},{"level":2,"heading":"Round 49 Addendum — Shared Structure: Concept References","anchor":"round-49-addendum-shared-structure-concept-references"},{"level":3,"heading":"Implementation Mapping — Shared Concept References","anchor":"implementation-mapping-shared-concept-references"},{"level":3,"heading":"TDD Additions — Shared Concept References","anchor":"tdd-additions-shared-concept-references"},{"level":3,"heading":"Fixture Anchors — Shared Concept References Examples","anchor":"fixture-anchors-shared-concept-references-examples"},{"level":2,"heading":"Round 50 Addendum — Shared Structure: Identifiers","anchor":"round-50-addendum-shared-structure-identifiers"},{"level":3,"heading":"Implementation Mapping — Shared Identifiers","anchor":"implementation-mapping-shared-identifiers"},{"level":3,"heading":"TDD Additions — Shared Identifiers","anchor":"tdd-additions-shared-identifiers"},{"level":3,"heading":"Fixture Anchors — Shared Identifiers Examples","anchor":"fixture-anchors-shared-identifiers-examples"},{"level":2,"heading":"Round 51 Addendum — Shared Structure: Monetary Amounts","anchor":"round-51-addendum-shared-structure-monetary-amounts"},{"level":3,"heading":"Implementation Mapping — Shared Monetary Amounts","anchor":"implementation-mapping-shared-monetary-amounts"},{"level":3,"heading":"TDD Additions — Shared Monetary Amounts","anchor":"tdd-additions-shared-monetary-amounts"},{"level":3,"heading":"Fixture Anchors — Shared Monetary Amounts Examples","anchor":"fixture-anchors-shared-monetary-amounts-examples"},{"level":2,"heading":"Round 52 Addendum — Shared Structure: Names","anchor":"round-52-addendum-shared-structure-names"},{"level":3,"heading":"Implementation Mapping — Shared Names","anchor":"implementation-mapping-shared-names"},{"level":3,"heading":"TDD Additions — Shared Names","anchor":"tdd-additions-shared-names"},{"level":3,"heading":"Fixture Anchors — Shared Names Examples","anchor":"fixture-anchors-shared-names-examples"},{"level":2,"heading":"Round 53 Addendum — Shared Structure: Rights","anchor":"round-53-addendum-shared-structure-rights"},{"level":3,"heading":"Implementation Mapping — Shared Rights","anchor":"implementation-mapping-shared-rights"},{"level":3,"heading":"TDD Additions — Shared Rights","anchor":"tdd-additions-shared-rights"},{"level":3,"heading":"Fixture Anchors — Shared Rights Examples","anchor":"fixture-anchors-shared-rights-examples"},{"level":2,"heading":"Round 54 Addendum — Shared Structure: References","anchor":"round-54-addendum-shared-structure-references"},{"level":3,"heading":"Implementation Mapping — Shared References","anchor":"implementation-mapping-shared-references"},{"level":3,"heading":"TDD Additions — Shared References","anchor":"tdd-additions-shared-references"},{"level":3,"heading":"Fixture Anchors — Shared References Examples","anchor":"fixture-anchors-shared-references-examples"},{"level":2,"heading":"Round 55 Addendum — Shared Structure: Statements","anchor":"round-55-addendum-shared-structure-statements"},{"level":3,"heading":"Implementation Mapping — Shared Statements","anchor":"implementation-mapping-shared-statements"},{"level":3,"heading":"TDD Additions — Shared Statements","anchor":"tdd-additions-shared-statements"},{"level":3,"heading":"Fixture Anchors — Shared Statements Examples","anchor":"fixture-anchors-shared-statements-examples"},{"level":2,"heading":"Round 56 Addendum — Shared Structure: TimeSpans","anchor":"round-56-addendum-shared-structure-timespans"},{"level":3,"heading":"Implementation Mapping — Shared TimeSpans","anchor":"implementation-mapping-shared-timespans"},{"level":3,"heading":"TDD Additions — Shared TimeSpans","anchor":"tdd-additions-shared-timespans"},{"level":3,"heading":"Fixture Anchors — Shared TimeSpans Examples","anchor":"fixture-anchors-shared-timespans-examples"},{"level":2,"heading":"Round 57 Addendum — Shared Structure: Relationships (AttributeAssignment)","anchor":"round-57-addendum-shared-structure-relationships-attributeassignment"},{"level":3,"heading":"Implementation Mapping — Shared Relationships","anchor":"implementation-mapping-shared-relationships"},{"level":3,"heading":"TDD Additions — Shared Relationships","anchor":"tdd-additions-shared-relationships"},{"level":3,"heading":"Fixture Anchors — Shared Relationships Examples","anchor":"fixture-anchors-shared-relationships-examples"},{"level":2,"heading":"Round 58 Addendum — About Schemas","anchor":"round-58-addendum-about-schemas"},{"level":3,"heading":"Implementation Mapping — Schemas","anchor":"implementation-mapping-schemas"},{"level":3,"heading":"TDD Additions — Schemas","anchor":"tdd-additions-schemas"},{"level":3,"heading":"Fixture Anchors — Schemas Examples","anchor":"fixture-anchors-schemas-examples"},{"level":2,"heading":"Round 59 Addendum — Abstract Work Schema","anchor":"round-59-addendum-abstract-work-schema"},{"level":3,"heading":"Implementation Mapping — Abstract Work Schema","anchor":"implementation-mapping-abstract-work-schema"},{"level":3,"heading":"TDD Additions — Abstract Work Schema","anchor":"tdd-additions-abstract-work-schema"},{"level":3,"heading":"Fixture Anchors — Abstract Work Schema Examples","anchor":"fixture-anchors-abstract-work-schema-examples"},{"level":2,"heading":"Round 60 Addendum — Concept Schema","anchor":"round-60-addendum-concept-schema"},{"level":3,"heading":"Implementation Mapping — Concept Schema","anchor":"implementation-mapping-concept-schema"},{"level":3,"heading":"TDD Additions — Concept Schema","anchor":"tdd-additions-concept-schema"},{"level":3,"heading":"Fixture Anchors — Concept Schema Examples","anchor":"fixture-anchors-concept-schema-examples"},{"level":2,"heading":"Round 61 Addendum — Digital Object Schema","anchor":"round-61-addendum-digital-object-schema"},{"level":3,"heading":"Implementation Mapping — Digital Object Schema","anchor":"implementation-mapping-digital-object-schema"},{"level":3,"heading":"TDD Additions — Digital Object Schema","anchor":"tdd-additions-digital-object-schema"},{"level":3,"heading":"Fixture Anchors — Digital Object Schema Examples","anchor":"fixture-anchors-digital-object-schema-examples"},{"level":2,"heading":"Round 62 Addendum — Event Schema","anchor":"round-62-addendum-event-schema"},{"level":3,"heading":"Implementation Mapping — Event Schema","anchor":"implementation-mapping-event-schema"},{"level":3,"heading":"TDD Additions — Event Schema","anchor":"tdd-additions-event-schema"},{"level":3,"heading":"Fixture Anchors — Event Schema Examples","anchor":"fixture-anchors-event-schema-examples"},{"level":2,"heading":"Round 63 Addendum — Group Schema","anchor":"round-63-addendum-group-schema"},{"level":3,"heading":"Implementation Mapping — Group Schema","anchor":"implementation-mapping-group-schema"},{"level":3,"heading":"TDD Additions — Group Schema","anchor":"tdd-additions-group-schema"},{"level":3,"heading":"Fixture Anchors — Group Schema Examples","anchor":"fixture-anchors-group-schema-examples"},{"level":2,"heading":"Round 64 Addendum — Person Schema","anchor":"round-64-addendum-person-schema"},{"level":3,"heading":"Implementation Mapping — Person Schema","anchor":"implementation-mapping-person-schema"},{"level":3,"heading":"TDD Additions — Person Schema","anchor":"tdd-additions-person-schema"},{"level":3,"heading":"Fixture Anchors — Person Schema Examples","anchor":"fixture-anchors-person-schema-examples"},{"level":2,"heading":"Round 65 Addendum — Human-Made Object Schema","anchor":"round-65-addendum-human-made-object-schema"},{"level":3,"heading":"Implementation Mapping — Human-Made Object Schema","anchor":"implementation-mapping-human-made-object-schema"},{"level":3,"heading":"TDD Additions — Human-Made Object Schema","anchor":"tdd-additions-human-made-object-schema"},{"level":3,"heading":"Fixture Anchors — Human-Made Object Schema Examples","anchor":"fixture-anchors-human-made-object-schema-examples"},{"level":2,"heading":"Round 66 Addendum — Place Schema","anchor":"round-66-addendum-place-schema"},{"level":3,"heading":"Implementation Mapping — Place Schema","anchor":"implementation-mapping-place-schema"},{"level":3,"heading":"TDD Additions — Place Schema","anchor":"tdd-additions-place-schema"},{"level":3,"heading":"Fixture Anchors — Place Schema Examples","anchor":"fixture-anchors-place-schema-examples"},{"level":2,"heading":"Round 67 Addendum — Provenance Activity Schema","anchor":"round-67-addendum-provenance-activity-schema"},{"level":3,"heading":"Implementation Mapping — Provenance Activity Schema","anchor":"implementation-mapping-provenance-activity-schema"},{"level":3,"heading":"TDD Additions — Provenance Activity Schema","anchor":"tdd-additions-provenance-activity-schema"},{"level":3,"heading":"Fixture Anchors — Provenance Activity Schema Examples","anchor":"fixture-anchors-provenance-activity-schema-examples"},{"level":2,"heading":"Round 68 Addendum — Collection (Set) Schema","anchor":"round-68-addendum-collection-set-schema"},{"level":3,"heading":"Implementation Mapping — Collection (Set) Schema","anchor":"implementation-mapping-collection-set-schema"},{"level":3,"heading":"TDD Additions — Collection (Set) Schema","anchor":"tdd-additions-collection-set-schema"},{"level":3,"heading":"Fixture Anchors — Collection (Set) Schema Examples","anchor":"fixture-anchors-collection-set-schema-examples"},{"level":2,"heading":"Round 69 Addendum — Text Schema","anchor":"round-69-addendum-text-schema"},{"level":3,"heading":"Implementation Mapping — Text Schema","anchor":"implementation-mapping-text-schema"},{"level":3,"heading":"TDD Additions — Text Schema","anchor":"tdd-additions-text-schema"},{"level":3,"heading":"Fixture Anchors — Text Schema Examples","anchor":"fixture-anchors-text-schema-examples"},{"level":2,"heading":"Round 70 Addendum — Visual Content Schema","anchor":"round-70-addendum-visual-content-schema"},{"level":3,"heading":"Implementation Mapping — Visual Content Schema","anchor":"implementation-mapping-visual-content-schema"},{"level":3,"heading":"TDD Additions — Visual Content Schema","anchor":"tdd-additions-visual-content-schema"},{"level":3,"heading":"Fixture Anchors — Visual Content Schema Examples","anchor":"fixture-anchors-visual-content-schema-examples"},{"level":2,"heading":"Round 71 Addendum — Search API","anchor":"round-71-addendum-search-api"},{"level":3,"heading":"Implementation Mapping — Search API","anchor":"implementation-mapping-search-api"},{"level":3,"heading":"TDD Additions — Search API","anchor":"tdd-additions-search-api"},{"level":3,"heading":"Fixture Anchors — Search API Examples","anchor":"fixture-anchors-search-api-examples"},{"level":2,"heading":"Round 72 Addendum — About HAL","anchor":"round-72-addendum-about-hal"},{"level":3,"heading":"Implementation Mapping — HAL","anchor":"implementation-mapping-hal"},{"level":3,"heading":"TDD Additions — HAL","anchor":"tdd-additions-hal"},{"level":3,"heading":"Fixture Anchors — HAL Examples","anchor":"fixture-anchors-hal-examples"},{"level":2,"heading":"Round 73 Addendum — Search Relations: HumanMadeObject","anchor":"round-73-addendum-search-relations-humanmadeobject"},{"level":3,"heading":"Implementation Mapping — HumanMadeObject Search Relations","anchor":"implementation-mapping-humanmadeobject-search-relations"},{"level":3,"heading":"TDD Additions — HumanMadeObject Search Relations","anchor":"tdd-additions-humanmadeobject-search-relations"},{"level":3,"heading":"Fixture Anchors — HumanMadeObject Search Relations Examples","anchor":"fixture-anchors-humanmadeobject-search-relations-examples"},{"level":2,"heading":"Round 74 Addendum — Search Relations: Work","anchor":"round-74-addendum-search-relations-work"},{"level":3,"heading":"Implementation Mapping — Work Search Relations","anchor":"implementation-mapping-work-search-relations"},{"level":3,"heading":"TDD Additions — Work Search Relations","anchor":"tdd-additions-work-search-relations"},{"level":3,"heading":"Fixture Anchors — Work Search Relations Examples","anchor":"fixture-anchors-work-search-relations-examples"},{"level":2,"heading":"Round 75 Addendum — Search Relations: Agent","anchor":"round-75-addendum-search-relations-agent"},{"level":3,"heading":"Implementation Mapping — Agent Search Relations","anchor":"implementation-mapping-agent-search-relations"},{"level":3,"heading":"TDD Additions — Agent Search Relations","anchor":"tdd-additions-agent-search-relations"},{"level":3,"heading":"Fixture Anchors — Agent Search Relations Examples","anchor":"fixture-anchors-agent-search-relations-examples"},{"level":2,"heading":"Round 76 Addendum — Search Relations: Place","anchor":"round-76-addendum-search-relations-place"},{"level":3,"heading":"Implementation Mapping — Place Search Relations","anchor":"implementation-mapping-place-search-relations"},{"level":3,"heading":"TDD Additions — Place Search Relations","anchor":"tdd-additions-place-search-relations"},{"level":3,"heading":"Fixture Anchors — Place Search Relations Examples","anchor":"fixture-anchors-place-search-relations-examples"},{"level":2,"heading":"Round 77 Addendum — Search Relations: Concept","anchor":"round-77-addendum-search-relations-concept"},{"level":3,"heading":"Implementation Mapping — Concept Search Relations","anchor":"implementation-mapping-concept-search-relations"},{"level":3,"heading":"TDD Additions — Concept Search Relations","anchor":"tdd-additions-concept-search-relations"},{"level":3,"heading":"Fixture Anchors — Concept Search Relations Examples","anchor":"fixture-anchors-concept-search-relations-examples"},{"level":2,"heading":"Round 78 Addendum — Search Relations: Temporal / Event / Activity","anchor":"round-78-addendum-search-relations-temporal-event-activity"},{"level":3,"heading":"Implementation Mapping — Temporal/Activity Search Relations","anchor":"implementation-mapping-temporal-activity-search-relations"},{"level":3,"heading":"TDD Additions — Temporal/Activity Search Relations","anchor":"tdd-additions-temporal-activity-search-relations"},{"level":3,"heading":"Fixture Anchors — Temporal/Activity Search Relations Examples","anchor":"fixture-anchors-temporal-activity-search-relations-examples"},{"level":2,"heading":"Round 79 Addendum — Search Relations: Set","anchor":"round-79-addendum-search-relations-set"},{"level":3,"heading":"Implementation Mapping — Set Search Relations","anchor":"implementation-mapping-set-search-relations"},{"level":3,"heading":"TDD Additions — Set Search Relations","anchor":"tdd-additions-set-search-relations"},{"level":3,"heading":"Fixture Anchors — Set Search Relations Examples","anchor":"fixture-anchors-set-search-relations-examples"},{"level":2,"heading":"Round 80 Addendum — Data Discovery","anchor":"round-80-addendum-data-discovery"},{"level":3,"heading":"Implementation Mapping — Data Discovery","anchor":"implementation-mapping-data-discovery"},{"level":3,"heading":"TDD Additions — Data Discovery","anchor":"tdd-additions-data-discovery"},{"level":3,"heading":"Fixture Anchors — Data Discovery Examples","anchor":"fixture-anchors-data-discovery-examples"},{"level":2,"heading":"Round 81 Addendum — API Design Principles and Practical Requirements","anchor":"round-81-addendum-api-design-principles-and-practical-requirements"},{"level":3,"heading":"Implementation Mapping — API Design Requirements","anchor":"implementation-mapping-api-design-requirements"},{"level":3,"heading":"TDD Additions — API Design Requirements","anchor":"tdd-additions-api-design-requirements"},{"level":3,"heading":"Fixture Anchors — API Design Requirements Examples","anchor":"fixture-anchors-api-design-requirements-examples"},{"level":2,"heading":"Round 82 Addendum — JSON-LD and Context Design","anchor":"round-82-addendum-json-ld-and-context-design"},{"level":3,"heading":"Implementation Mapping — JSON-LD Context Design","anchor":"implementation-mapping-json-ld-context-design"},{"level":3,"heading":"TDD Additions — JSON-LD Context Design","anchor":"tdd-additions-json-ld-context-design"},{"level":3,"heading":"Fixture Anchors — JSON-LD Context Design Examples","anchor":"fixture-anchors-json-ld-context-design-examples"},{"level":2,"heading":"Round 83 Addendum — Protocol (HTTP/REST)","anchor":"round-83-addendum-protocol-http-rest"},{"level":3,"heading":"Implementation Mapping — Protocol","anchor":"implementation-mapping-protocol"},{"level":3,"heading":"TDD Additions — Protocol","anchor":"tdd-additions-protocol"},{"level":3,"heading":"Fixture Anchors — Protocol Examples","anchor":"fixture-anchors-protocol-examples"},{"level":2,"heading":"Round 84 Addendum — Code and Tools Ecosystem","anchor":"round-84-addendum-code-and-tools-ecosystem"},{"level":3,"heading":"Implementation Mapping — Code and Tools","anchor":"implementation-mapping-code-and-tools"},{"level":3,"heading":"TDD Additions — Code and Tools","anchor":"tdd-additions-code-and-tools"},{"level":3,"heading":"Fixture Anchors — Code and Tools Examples","anchor":"fixture-anchors-code-and-tools-examples"},{"level":2,"heading":"Round 1 Open Items For Next Docs Drop","anchor":"round-1-open-items-for-next-docs-drop"}],"html":"<h1 id=\"linked-art-model-1-0-reference-round-1\">Linked Art Model 1.0 Reference (Round 1)</h1>\n<p>Status: Working reference for Meta Museum engineering and TDD alignment  </p>\n<p>Source: &lt;https://linked.art/&gt;  </p>\n<p>Source document basis: Linked Art Model 1.0 (`1.0.0`)  </p>\n<p>License note from source: Linked Art Data Model is published under CC BY 4.0  </p>\n<p>Captured for this reference on: May 30, 2026</p>\n<p>---</p>\n<h2 id=\"purpose\">Purpose</h2>\n<p>This file turns official Linked Art model guidance into project-ready engineering notes for Meta Museum.  </p>\n<p>It is designed to support:</p>\n<ul><li>implementation decisions in adapters, contracts, routes, and UI</li><li>roadmap updates across Era B and Era C</li><li>test-driven development (TDD) with explicit behavior checks</li></ul>\n<p>This is a living reference. Future rounds append additional official sections and examples.</p>\n<p>---</p>\n<h2 id=\"canonical-model-summary\">Canonical Model Summary</h2>\n<p>Linked Art 1.0 is an application profile for describing cultural heritage resources, especially artworks and museum-oriented activities.</p>\n<p>Core characteristics:</p>\n<ul><li>event-centric modeling grounded in CIDOC-CRM</li><li>streamlined subset of CIDOC-CRM 7.1.3 for practical interoperability</li><li>JSON-LD 1.1 as core serialization format</li><li>vocabulary and term discipline to keep data interoperable across institutions</li></ul>\n<p>The model is finalized at version `1.0.0`, with future evolution expected through community process.</p>\n<p>---</p>\n<h2 id=\"model-coverage-areas-from-official-structure\">Model Coverage Areas (from official structure)</h2>\n<p>The model documentation includes guidance for:</p>\n<ul><li>basic patterns used throughout</li><li>artworks and other physical objects</li><li>digital content about/depicting objects</li><li>sets and collections</li><li>provenance</li><li>exhibitions</li><li>conservation</li><li>related people, organizations, places, concepts, events</li><li>cultural context</li><li>textual documents</li><li>archival hierarchies</li><li>specific assertions</li></ul>\n<p>Implementation note for Meta Museum:</p>\n<ul><li>these areas should map to explicit contract and validation coverage, not implicit adapter behavior</li></ul>\n<p>---</p>\n<h2 id=\"design-principles-to-preserve\">Design Principles To Preserve</h2>\n<p>Linked Art model development emphasizes:</p>\n<ul><li>iterative improvement</li><li>responsive change from feedback</li><li>responsible complexity management</li><li>collaborative evolution</li></ul>\n<p>For this codebase, this means:</p>\n<ul><li>prioritize clear contract boundaries over one-off transforms</li><li>prefer additive schema/version migration over breaking storage changes</li><li>keep provider-specific logic isolated in adapters</li></ul>\n<p>---</p>\n<h2 id=\"scope-boundaries-important\">Scope Boundaries (Important)</h2>\n<p>From the official scope limitations:</p>\n<ul><li>goal is interoperability across systems, not perfect modeling of every local institutional detail</li><li>complete bibliographic/archival description is intentionally out of scope for Linked Art alone</li><li>detailed provenance of the data-recording process itself is out of scope at this stage</li><li>quantification of uncertainty/belief is valuable but intentionally deferred due to complexity</li></ul>\n<p>Engineering implication:</p>\n<ul><li>avoid over-modeling unsupported certainty/provenance semantics until explicitly scoped in roadmap</li><li>keep import outputs interoperable-first and standards-aligned</li></ul>\n<p>---</p>\n<h2 id=\"meta-museum-implementation-mapping-round-1\">Meta Museum Implementation Mapping (Round 1)</h2>\n<p>Use this as a standards checklist when adding/changing features:</p>\n<ol><li>Canonical layer</li></ol>\n<ul><li>Stored records remain Linked Art JSON-LD centric (`SourceRecord` + `_source.raw` preservation).</li></ul>\n<ol><li>Event-centric modeling</li></ol>\n<ul><li>Do not flatten event semantics (production/acquisition/exhibition/conservation) into untyped strings when structured activity is available.</li></ul>\n<ol><li>Serialization discipline</li></ol>\n<ul><li>APIs and adapters should preserve JSON-LD compatibility and context handling.</li></ul>\n<ol><li>Vocabulary discipline</li></ol>\n<ul><li>Keep required/recommended/optional term usage explicit where feasible in contracts and validation.</li></ul>\n<ol><li>Interoperability over local convenience</li></ol>\n<ul><li>Route and UI DTOs can simplify for UX, but source-level structures must stay standards-safe.</li></ul>\n<p>---</p>\n<h2 id=\"tdd-guidance-derived-from-linked-art-1-0\">TDD Guidance Derived From Linked Art 1.0</h2>\n<p>When implementing any new provider, route, or transform, test first against these minimum behaviors.</p>\n<h3 id=\"contract-level-tests\">Contract-level tests</h3>\n<ul><li>rejects malformed Linked Art top-level shape</li><li>preserves core identity fields (`id`, `type`, `_label` when present)</li><li>preserves structured event/activity nodes</li><li>preserves controlled-term links/classifications when present</li></ul>\n<h3 id=\"adapter-level-tests\">Adapter-level tests</h3>\n<ul><li>transforms provider payloads into Linked Art-compatible structures</li><li>does not discard important relationships (people/place/concept/event)</li><li>keeps source provenance fields for citation and audit surfaces</li><li>handles sparse data conservatively (warnings instead of silent loss)</li></ul>\n<h3 id=\"route-level-tests\">Route-level tests</h3>\n<ul><li>inspect/resolve/import routes validate request boundaries</li><li>import routes return standards-safe normalized output and stable error shapes</li><li>provider routes do not leak provider-specific quirks into shared contracts</li></ul>\n<h3 id=\"regression-tests\">Regression tests</h3>\n<ul><li>adding a provider does not break existing provider adapters</li><li>DTO simplification never mutates canonical stored source data</li></ul>\n<p>---</p>\n<h2 id=\"roadmap-hooks-what-this-reference-should-drive\">Roadmap Hooks (What this reference should drive)</h2>\n<p>This reference directly supports:</p>\n<ul><li>Era B1/B2: schema mirrors + formal validation alignment</li><li>Era B5: provider expansion with consistent Linked Art boundary behavior</li><li>Era B6: authority strategy and controlled vocabulary consistency</li><li>Era C: richer model coverage (documents, archival hierarchies, assertions) without breaking core interoperability</li></ul>\n<p>Recommended follow-up after each documentation round:</p>\n<ul><li>update `docs/roadmap.md` acceptance language where needed</li><li>add or tighten failing tests before feature code</li><li>record gaps between source docs and current contracts in a tracked checklist</li></ul>\n<p>---</p>\n<h2 id=\"round-2-addendum-objects-physical-object-modeling\">Round 2 Addendum — Objects (Physical Object Modeling)</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Objects</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>`HumanMadeObject` is the core class for art objects and other physical objects with social/cultural value.</li><li>Even minimally altered natural objects (for example, a shell) are still modeled as `HumanMadeObject` when value is socially conferred.</li><li>This simplifies interoperability and avoids ambiguous thresholds for &quot;how modified is modified enough&quot;.</li><li>Shared/basic patterns and digital integration patterns still apply to object records.</li><li>Object-specific documentation focus areas:</li><li>production and destruction</li><li>physical characteristics</li><li>aboutness</li><li>ownership</li><li>rights information (non-ownership rights)</li><li>digital representation linkage</li><li>immovable objects handled through place-oriented modeling</li></ul>\n<h3 id=\"implementation-mapping-objects\">Implementation Mapping — Objects</h3>\n<p>Apply these requirements to adapters, normalization, and stored source records:</p>\n<ol><li>Object typing</li></ol>\n<ul><li>Default culturally valued physical works to `HumanMadeObject` unless there is explicit evidence for a different canonical class.</li></ul>\n<ol><li>Event modeling</li></ol>\n<ul><li>Production and destruction must remain activity/event-shaped when present; do not flatten into untyped date/label strings only.</li></ul>\n<ol><li>Physical characteristics</li></ol>\n<ul><li>Preserve structured dimensions/materials/parts where provided; avoid collapsing to display-only text.</li></ul>\n<ol><li>Aboutness and descriptive statements</li></ol>\n<ul><li>Keep descriptive content in structured statement fields; do not discard language-tagged or classified descriptions.</li></ul>\n<ol><li>Ownership and location</li></ol>\n<ul><li>Keep ownership/location assertions distinct from general rights statements.</li></ul>\n<ol><li>Rights split</li></ol>\n<ul><li>Distinguish ownership from usage/reproduction rights in normalization and UI summaries.</li></ul>\n<ol><li>Digital linkage</li></ol>\n<ul><li>Keep physical object and digital surrogates distinct, linked through representation/documentation patterns.</li></ul>\n<ol><li>Immovable handling</li></ol>\n<ul><li>For immovable works, prefer place-connected modeling patterns instead of forcing moveable-object assumptions.</li></ul>\n<h3 id=\"tdd-additions-objects\">TDD Additions — Objects</h3>\n<p>Add failing-first tests for object workflows:</p>\n<p>Contract-level:</p>\n<ul><li>accepts `HumanMadeObject` as canonical object class for valued physical objects</li><li>preserves event structures for production/destruction when present</li><li>preserves dimensions/materials/parts structures without forced flattening</li></ul>\n<p>Adapter-level:</p>\n<ul><li>normalizes provider object payloads into `HumanMadeObject`-compatible output</li><li>keeps ownership/location and rights information separated in normalized output</li><li>preserves links to digital surrogates without collapsing physical and digital identities</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import paths retain object event + physical-characteristics structure after normalization</li><li>responses include stable rights/ownership-safe summaries without mutating canonical source fields</li></ul>\n<p>Regression:</p>\n<ul><li>immovable/place-centric records remain standards-safe and are not coerced into moveable-only assumptions</li></ul>\n<p>---</p>\n<h2 id=\"round-3-addendum-digital-content\">Round 3 Addendum — Digital Content</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Digital Content</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>`DigitalObject` is a carrier of information, not the information itself.</li><li>Information/content should remain modeled as `LinguisticObject` or `VisualItem`, with digital/physical carriers linked to that same content.</li><li>Digital object core properties include:</li><li>`access_point` for file/resource URLs</li><li>`format` for media type (MIME)</li><li>`conforms_to` for standards/specifications</li><li>`dimension` for digital characteristics (for example, file size, pixels)</li><li>`created_by` using `Creation` activity pattern</li><li>Digital erasure/deletion is not yet modeled in Linked Art 1.0 and should not be invented ad hoc.</li><li>Digital surrogates should be distinguished from generic depictions:</li><li>physical object `shows` a `VisualItem`</li><li>digital surrogate `digitally_shows` the same `VisualItem`</li><li>Embedded representation pattern is valid when the digital image is auxiliary to the main entity.</li><li>Web pages about entities should be linked via `subject_of` with intermediary `LinguisticObject`, then `digitally_carried_by` a `DigitalObject` classified as web page.</li><li>IIIF Presentation manifests:</li><li>treat as `DigitalObject` in `subject_of` pattern</li><li>include `conforms_to` = `http://iiif.io/api/presentation/`</li><li>use presentation media type in `format`</li><li>IIIF Image API:</li><li>model service as `DigitalService` under `digitally_available_via`</li><li>service (not the image file itself) carries `conforms_to` = `http://iiif.io/api/image/`</li><li>service `format` refers to `info.json` media type profile</li></ul>\n<h3 id=\"implementation-mapping-digital-content\">Implementation Mapping — Digital Content</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Carrier/content separation</li></ol>\n<ul><li>Never collapse `DigitalObject` and information content into a single semantic layer.</li></ul>\n<ol><li>URL and media handling</li></ol>\n<ul><li>Preserve canonical access URLs in `access_point`; preserve MIME/media-type detail in `format`.</li></ul>\n<ol><li>Standards linkage</li></ol>\n<ul><li>Use `conforms_to` for protocol/spec alignment (IIIF, HTML spec, etc.), not broad topical classification.</li></ul>\n<ol><li>Creation semantics</li></ol>\n<ul><li>Use `Creation` for digital-object creation events, not `Production`.</li></ul>\n<ol><li>Surrogate clarity</li></ol>\n<ul><li>Preserve shared `VisualItem` linkage between physical `shows` and digital `digitally_shows` when surrogate semantics are present.</li></ul>\n<ol><li>Embedded digital references</li></ol>\n<ul><li>Allow embedded digital representation objects in records where that improves interoperability and UI usability.</li></ul>\n<ol><li>IIIF compatibility</li></ol>\n<ul><li>Preserve both direct image access points and service endpoints when both are available.</li></ul>\n<ol><li>Deletion semantics guardrail</li></ol>\n<ul><li>Do not synthesize unsupported digital deletion/erasure events in 1.0 workflows.</li></ul>\n<h3 id=\"tdd-additions-digital-content\">TDD Additions — Digital Content</h3>\n<p>Add failing-first tests for digital-content workflows:</p>\n<p>Contract-level:</p>\n<ul><li>preserves `DigitalObject` records with `access_point`, `format`, and optional `conforms_to`</li><li>preserves `Creation` event shape on digital objects where present</li><li>rejects or flags malformed digital access points/media shapes</li></ul>\n<p>Adapter-level:</p>\n<ul><li>keeps content-carrier separation (`DigitalObject` vs `LinguisticObject`/`VisualItem`)</li><li>preserves surrogate linkage where physical and digital records point at the same `VisualItem`</li><li>preserves `subject_of` → `LinguisticObject` → `digitally_carried_by` web-page pattern</li><li>preserves IIIF manifest and IIIF image service structures (`digitally_available_via` with `DigitalService`)</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs preserve digital fields without flattening to plain strings only</li><li>resolve/import routes keep IIIF `conforms_to` and `format` metadata when present</li><li>API DTO simplification does not mutate canonical `_source.raw` digital structure</li></ul>\n<p>Regression:</p>\n<ul><li>existing physical-object workflows remain stable when digital enrichment is added</li><li>adapter updates do not regress rights/provenance fields while adding digital metadata</li></ul>\n<h3 id=\"fixture-anchors-digital-content-examples\">Fixture Anchors — Digital Content Examples</h3>\n<p>Use these official-example patterns as fixture seeds for contract and route tests:</p>\n<ol><li>Web publication as first-class `DigitalObject`</li></ol>\n<ul><li>`type: DigitalObject`</li><li>`classified_as` includes web page (`aat:300264578`) when applicable</li><li>`access_point` contains the direct human/web resource URL</li><li>`format` preserves media type such as `text/html`</li><li>`conforms_to` can point to relevant standards (for example, HTML)</li><li>`created_by.type` is `Creation`</li><li>`digitally_carries` links the content entity (`LinguisticObject`)</li></ul>\n<ol><li>Digital surrogate parity pattern</li></ol>\n<ul><li>Physical object `shows` a `VisualItem`</li><li>Digital surrogate `digitally_shows` the same `VisualItem` identifier</li><li>Tests should verify shared visual-content identity across carriers</li></ul>\n<ol><li>Embedded representation image pattern</li></ol>\n<ul><li>Entity `representation[]` includes `VisualItem`</li><li>`digitally_shown_by[]` contains a `DigitalObject`</li><li>digital image keeps `format` and image `access_point`</li></ul>\n<ol><li>Web page about an object pattern</li></ol>\n<ul><li>Object `subject_of[]` contains `LinguisticObject`</li><li>`digitally_carried_by[]` contains a `DigitalObject`</li><li>web page classification and `text/html` format remain intact</li></ul>\n<ol><li>IIIF Presentation manifest pattern</li></ol>\n<ul><li>linked through `subject_of -&gt; LinguisticObject -&gt; digitally_carried_by`</li><li>`conforms_to` includes `http://iiif.io/api/presentation/`</li><li>`format` preserves profile media type (Presentation 3 context)</li></ul>\n<ol><li>IIIF Image API service pattern</li></ol>\n<ul><li>digital image may include both `access_point` and `digitally_available_via`</li><li>`digitally_available_via[].type` is `DigitalService`</li><li>service `conforms_to` includes `http://iiif.io/api/image/`</li><li>service `format` preserves profile media type (Image 3 context / `info.json`)</li></ul>\n<p>---</p>\n<h2 id=\"round-4-addendum-collections-and-sets\">Round 4 Addendum — Collections and Sets</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Collections</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Use `Set` for conceptual groupings across many use cases (collections, exhibition sets, auction lots, archival sets, conceptual/person sets).</li><li>`Set` is a Linked Art class introduced outside base CIDOC-CRM to support consistent multi-type grouping semantics.</li><li>Sets are conceptual, not physical aggregations:</li><li>created via `Creation`, not `Production`</li><li>cannot be destroyed in this model</li><li>may have zero members and still exist</li><li>Membership is asserted on the member entity via `member_of` pointing to the set.</li><li>Linked Art API expectations focus membership on core record-capable entities.</li><li>Ordered sets use sort value identifiers (for example, AAT sort value typing) on members, optionally contextualized with `AttributeAssignment` influenced by a specific `Set`.</li><li>Prototypical member description uses `members_exemplified_by` embedded in the `Set`.</li><li>Collection membership should not be conflated with ownership or custody; objects can be members of multiple sets simultaneously.</li><li>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).</li></ul>\n<h3 id=\"implementation-mapping-collections-sets\">Implementation Mapping — Collections/Sets</h3>\n<p>Apply these requirements to adapters, normalization, contracts, and route outputs:</p>\n<ol><li>Set identity and lifecycle</li></ol>\n<ul><li>Preserve `Set` as first-class record type with stable `id`, `type`, names, statements, and optional classification.</li><li>Model set creation with `created_by.type = Creation` where known.</li></ul>\n<ol><li>Membership directionality</li></ol>\n<ul><li>Preserve `member_of` on member entities; do not require inverse `member` materialization on sets in API responses.</li></ul>\n<ol><li>Collection-context separation</li></ol>\n<ul><li>Keep collection membership separate from ownership/custody semantics.</li></ul>\n<ol><li>Ordering semantics</li></ol>\n<ul><li>Preserve sort-value identifiers and contextual assignment patterns when present; do not flatten away set-specific ordering signals.</li></ul>\n<ol><li>Prototypical member semantics</li></ol>\n<ul><li>Preserve `members_exemplified_by` as descriptive prototype, not as highlighted members or strict universal constraints.</li></ul>\n<ol><li>Nested set structures</li></ol>\n<ul><li>Preserve set-to-set `member_of` relations for institutional and departmental collection hierarchies.</li></ul>\n<ol><li>Group compatibility</li></ol>\n<ul><li>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.</li></ul>\n<h3 id=\"tdd-additions-collections-sets\">TDD Additions — Collections/Sets</h3>\n<p>Add failing-first tests for set and collection workflows:</p>\n<p>Contract-level:</p>\n<ul><li>accepts `Set` with core identity fields and optional statements/classifications</li><li>preserves `created_by` creation semantics for sets</li><li>rejects malformed `member_of` and `members_exemplified_by` structures</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves `member_of` links on imported member entities</li><li>does not collapse membership into inferred ownership/custody</li><li>preserves set ordering metadata (`Identifier` sort value + optional assignment context)</li><li>preserves `members_exemplified_by` without converting it into concrete membership</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs preserve set structures and membership links</li><li>collection and entity endpoints return memberships without mutating `_source.raw`</li><li>set-related DTO projections remain additive and do not erase canonical set semantics</li></ul>\n<p>Regression:</p>\n<ul><li>object and digital-content workflows remain stable when set membership metadata is introduced</li><li>multi-set membership for a single entity remains supported</li></ul>\n<h3 id=\"fixture-anchors-collections-sets-examples\">Fixture Anchors — Collections/Sets Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Exhibition object set</li></ol>\n<ul><li>`Set` with primary name, description statement, and `created_by` `Creation`.</li></ul>\n<ol><li>Member entity linkage</li></ol>\n<ul><li>`HumanMadeObject` with `member_of` pointing to exhibition set.</li></ul>\n<ol><li>Ordered membership context</li></ol>\n<ul><li>member `Identifier` classified as sort value with optional `AttributeAssignment` influenced by the target set.</li></ul>\n<ol><li>Prototypical member pattern</li></ol>\n<ul><li>`Set.members_exemplified_by` embedding a prototype entity and typical characteristics.</li></ul>\n<ol><li>Institutional + departmental collections</li></ol>\n<ul><li>institutional collection `Set`</li><li>departmental collection `Set` as `member_of` institutional set</li><li>departmental curation context modeled via `used_for` activity.</li></ul>\n<ol><li>Member in curated set</li></ol>\n<ul><li>object with `member_of` departmental collection.</li></ul>\n<p>---</p>\n<h2 id=\"round-5-addendum-object-provenance\">Round 5 Addendum — Object Provenance</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Object Provenance</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Provenance is modeled as a chain of activities across an object&#39;s lifecycle.</li><li>A provenance entry is often a wrapper `Activity` (&quot;Provenance Event&quot;) that groups multiple granular parts.</li><li>Typical `part` activities can include:</li><li>`Acquisition` (ownership transfer)</li><li>`Payment` (monetary exchange)</li><li>other legal/physical/contextual activities as needed</li><li>Production and destruction are lifecycle boundaries but are modeled using object lifecycle patterns, not the same pattern as wrapper provenance events.</li><li>Provenance event classification is important (for example, provenance activity, gift, purchase-like variants).</li><li>Unknown/approximate chronology can be represented with relative ordering:</li><li>`after`: current event starts after referenced event ends</li><li>`before`: current event ends before referenced event starts</li><li>Provenance can include events beyond ownership transfer:</li><li>custody transfer</li><li>encountering/rediscovery</li><li>rights acquisition</li><li>promises/auction commitments</li><li>movement</li><li>unknown transfer type when evidence is incomplete</li></ul>\n<h3 id=\"implementation-mapping-provenance\">Implementation Mapping — Provenance</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Wrapper-event pattern</li></ol>\n<ul><li>Preserve provenance entries as top-level `Activity` wrappers with classifications and optional timespans.</li></ul>\n<ol><li>Part decomposition</li></ol>\n<ul><li>Preserve granular `part` activities (`Acquisition`, `Payment`, etc.) rather than flattening to narrative strings.</li></ul>\n<ol><li>Actor/object role integrity</li></ol>\n<ul><li>Preserve explicit transfer/payment roles (`transferred_title_from`, `transferred_title_to`, `paid_from`, `paid_to`, `transferred_title_of`).</li></ul>\n<ol><li>Monetary structure integrity</li></ol>\n<ul><li>Preserve `MonetaryAmount` + `currency` structures for payment parts when present.</li></ul>\n<ol><li>Relative-time support</li></ol>\n<ul><li>Preserve `after`/`before` references for events with uncertain absolute dating.</li></ul>\n<ol><li>Classification precision</li></ol>\n<ul><li>Preserve both broad provenance classification and specific transaction-type classifications.</li></ul>\n<ol><li>Uncertain transfer handling</li></ol>\n<ul><li>Do not force uncertain evidence into overly specific ownership/custody/movement types; preserve uncertainty safely.</li></ul>\n<h3 id=\"tdd-additions-provenance\">TDD Additions — Provenance</h3>\n<p>Add failing-first tests for provenance workflows:</p>\n<p>Contract-level:</p>\n<ul><li>accepts wrapper provenance `Activity` with `classified_as` and optional `timespan`</li><li>preserves valid `part` arrays with `Acquisition`/`Payment` structures</li><li>rejects malformed transfer-role structures and malformed monetary/currency payloads</li></ul>\n<p>Adapter-level:</p>\n<ul><li>normalizes provider provenance entries into wrapper activity + granular part structure</li><li>preserves transfer and payment roles without role collapse</li><li>preserves specific provenance classification terms (for example, gift)</li><li>preserves `after`/`before` relations when explicit dates are absent</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs preserve provenance wrapper + part structures</li><li>provenance-rich records remain queryable without losing role-specific fields</li><li>DTO simplification does not mutate canonical provenance structure in `_source.raw`</li></ul>\n<p>Regression:</p>\n<ul><li>object lifecycle activity fields (production/destruction) are not overwritten by provenance-wrapper logic</li><li>uncertain/unknown transfer records remain represented as uncertain, not force-cast to a specific event type</li></ul>\n<h3 id=\"fixture-anchors-provenance-examples\">Fixture Anchors — Provenance Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Purchase provenance event with payment</li></ol>\n<ul><li>wrapper `Activity` classified as provenance activity</li><li>`part[]` includes:</li><li>`Acquisition` with title transfer roles and object</li><li>`Payment` with `MonetaryAmount` and currency</li></ul>\n<ol><li>Gift provenance event</li></ol>\n<ul><li>wrapper `Activity` classified as provenance activity + gift</li><li>`part[]` includes `Acquisition` transfer from donor to receiving group/institution</li></ul>\n<ol><li>Relative-time-only provenance event</li></ol>\n<ul><li>wrapper `Activity` with `after` and/or `before` references</li><li>no requirement for explicit absolute timespan</li></ul>\n<ol><li>Unknown transfer scenarios</li></ol>\n<ul><li>fixtures where textual evidence is ambiguous; tests assert preservation of uncertainty and non-overstatement of event type.</li></ul>\n<p>---</p>\n<h2 id=\"round-6-addendum-acquisitions-and-loans\">Round 6 Addendum — Acquisitions and Loans</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Acquisitions and Loans</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Most provenance events involve ownership transfer and are modeled via `Acquisition` parts inside a wrapper provenance `Activity`.</li><li>&quot;Seller&quot; and &quot;buyer&quot; are role labels for transfer clarity, not strictly cash-sale semantics.</li><li>`Acquisition` encodes title transfer:</li><li>`transferred_title_of` (object)</li><li>`transferred_title_from` (relinquishing owner)</li><li>`transferred_title_to` (gaining owner)</li><li>Unknown seller or buyer can be omitted when evidence is incomplete.</li><li>A single provenance event can contain multiple `Acquisition` parts (for example, multiple objects in one transaction).</li><li>Simultaneous co-ownership can be represented by multiple `transferred_title_to` (or `transferred_title_from`) entries when split details are unknown/even.</li><li>If legal ownership is held by a consortium, model consortium as `Group` and use that group as owner.</li><li>Agents can be modeled via `carried_out_by` on acquisition activity; model does not distinguish seller-agent vs buyer-agent semantics.</li><li>Exchanges can be represented by multiple acquisitions with inverse transfer directions.</li><li>Purchases include `Payment` parts with:</li><li>`paid_from`</li><li>`paid_to`</li><li>`paid_amount` (`MonetaryAmount` with `value` + `currency`)</li><li>Separate monetary flows (seller price, commissions, service payments) should be separate `Payment` instances.</li><li>Monetary amounts are face-value constructs; diachronic comparison requires time context of referencing events.</li><li>Loan/custody-centric transfer scenarios are related but documented in custody-specific patterns; do not force custody into ownership transfer semantics.</li></ul>\n<h3 id=\"implementation-mapping-acquisitions-payments\">Implementation Mapping — Acquisitions/Payments</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Ownership transfer fidelity</li></ol>\n<ul><li>Preserve acquisition role edges explicitly; do not collapse into a generic &quot;changed owner&quot; string.</li></ul>\n<ol><li>Multi-object and multi-party support</li></ol>\n<ul><li>Support arrays in transfer fields to preserve multi-object transactions and co-owner/co-seller patterns.</li></ul>\n<ol><li>Agent representation</li></ol>\n<ul><li>Preserve acquisition-level `carried_out_by` agents when present.</li></ul>\n<ol><li>Exchange modeling</li></ol>\n<ul><li>Preserve multi-acquisition exchange structures rather than flattening to one ambiguous transfer.</li></ul>\n<ol><li>Payment decomposition</li></ol>\n<ul><li>Preserve each payment as a distinct part activity, especially where commissions/services are known.</li></ul>\n<ol><li>Monetary structure preservation</li></ol>\n<ul><li>Preserve `MonetaryAmount` + `currency` (+ optional notation/classification) without type degradation.</li></ul>\n<ol><li>Uncertainty discipline</li></ol>\n<ul><li>Where seller/buyer detail is unknown, preserve partial role assertions without speculative completion.</li></ul>\n<ol><li>Ownership vs custody guardrail</li></ol>\n<ul><li>Do not encode loans/custody movements as title transfers unless evidence explicitly indicates ownership transfer.</li></ul>\n<h3 id=\"tdd-additions-acquisitions-payments\">TDD Additions — Acquisitions/Payments</h3>\n<p>Add failing-first tests for acquisition and payment workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `Acquisition` role structure with object/from/to fields when provided</li><li>allows omitted transfer-role fields for uncertain historical evidence</li><li>validates `Payment` structure with `paid_from`, `paid_to`, and `MonetaryAmount` currency/value</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves multi-acquisition provenance events for bundled transactions</li><li>preserves multi-party ownership transfer arrays without collapsing to a single actor</li><li>preserves `carried_out_by` agents on acquisition parts</li><li>preserves multiple payment parts (object price + commission/service) as separate events</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs preserve acquisition/payment part granularity and actor roles</li><li>routes do not synthesize missing seller/buyer values when source evidence is incomplete</li><li>DTO projections preserve canonical `_source.raw` transaction structure</li></ul>\n<p>Regression:</p>\n<ul><li>exchange-of-objects scenarios continue to round-trip without role inversion bugs</li><li>commission/service payments do not overwrite or merge with primary seller payment</li></ul>\n<h3 id=\"fixture-anchors-acquisitions-payments-examples\">Fixture Anchors — Acquisitions/Payments Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Simple acquisition</li></ol>\n<ul><li>wrapper provenance `Activity` with one `Acquisition` transferring one object from seller to buyer.</li></ul>\n<ol><li>Joint acquisition / multiple owners</li></ol>\n<ul><li>acquisition with multiple `transferred_title_to` entries for co-ownership.</li></ul>\n<ol><li>Agent-mediated acquisition</li></ol>\n<ul><li>acquisition with `carried_out_by` agent plus explicit seller and buyer.</li></ul>\n<ol><li>Exchange transaction</li></ol>\n<ul><li>wrapper event with multiple `Acquisition` parts modeling reciprocal transfers.</li></ul>\n<ol><li>Purchase + payment</li></ol>\n<ul><li>acquisition part plus separate payment part with `MonetaryAmount`.</li></ul>\n<ol><li>Service/commission payments</li></ol>\n<ul><li>multiple payment parts distinguishing seller payment from commission payment.</li></ul>\n<p>---</p>\n<h2 id=\"round-7-addendum-auctions\">Round 7 Addendum — Auctions</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Auctions</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Auction modeling separates several entities/activities:</li><li>overall auction event (`Activity`, auction-event classification)</li><li>auction of a single lot (`Activity`, auction-of-lot classification)</li><li>lot itself as a `Set` of objects</li><li>resulting provenance purchase activity (if sale completes)</li><li>Key vocabulary anchors include:</li><li>Auction Activity (`aat:300054751`)</li><li>Auction of Lot Activity (`aat:300420001`)</li><li>Auction House Organization (`aat:300417515`)</li><li>Auction House Premises (`aat:300005234`)</li><li>Auction Lot (`aat:300411307`)</li><li>Lot Number (`aat:300404628`)</li><li>Auction Catalog (`aat:300026068`)</li><li>Auction event (`Activity`):</li><li>`carried_out_by` auction house `Group`</li><li>`took_place_at` auction house premises `Place`</li><li>timespan/name/classification as regular activity metadata</li><li>Auction of lot (`Activity`):</li><li>`part_of` overall auction event</li><li>references lot set via `used_specific_object`</li><li>may cause provenance purchase event if reserve conditions are met</li><li>Lot modeled as `Set`:</li><li>classified as auction lot</li><li>includes lot number identifier</li><li>membership expressed on member objects via `member_of`</li><li>Pre-set prices (starting/reserve/estimated) are modeled on lot set as monetary dimensions, independent of sale completion.</li><li>Purchase of lot:</li><li>provenance event references set via `used_specific_object`</li><li>has per-object `Acquisition` parts and payment part(s)</li><li>may include agent via `carried_out_by`</li><li>can link back to auction-of-lot via `part_of`</li><li>Auction catalogs are `LinguisticObject` records classified as auction catalogs and can reference auction event via `about`.</li><li>Non-sale outcomes must be represented explicitly without over-asserting ownership transfers:</li><li>lot withdrawn (catalog + lot set, but no auction-of-lot activity)</li><li>object withdrawn from multi-object lot</li><li>reserve not met / bought in</li><li>owner buys own lot</li><li>winner unable to pay</li></ul>\n<h3 id=\"implementation-mapping-auctions\">Implementation Mapping — Auctions</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Layer separation</li></ol>\n<ul><li>Preserve distinction between auction event, lot-auction activity, lot set, and resulting provenance purchase.</li></ul>\n<ol><li>Lot membership directionality</li></ol>\n<ul><li>Preserve lot membership on objects (`member_of`) rather than synthesizing set-owned member lists in canonical data.</li></ul>\n<ol><li>Event linkage integrity</li></ol>\n<ul><li>Preserve `part_of` links (lot-auction -&gt; auction event, purchase provenance -&gt; lot-auction when known).</li></ul>\n<ol><li>Price semantics</li></ol>\n<ul><li>Preserve pre-set lot prices as lot-level monetary dimensions, separate from realized payment amounts.</li></ul>\n<ol><li>Auction-house context</li></ol>\n<ul><li>Preserve place and organization context for auction event (`took_place_at`, `carried_out_by`) with classifications when present.</li></ul>\n<ol><li>Catalog evidence</li></ol>\n<ul><li>Preserve auction-catalog documents as evidence entities linked through `about`.</li></ul>\n<ol><li>Outcome discipline</li></ol>\n<ul><li>Do not infer ownership transfer when outcomes indicate no completed sale.</li><li>Preserve custody/commission/bid context separately when available.</li></ul>\n<ol><li>Multi-object lots</li></ol>\n<ul><li>Preserve per-object acquisition granularity even when one payment covers the lot.</li></ul>\n<h3 id=\"tdd-additions-auctions\">TDD Additions — Auctions</h3>\n<p>Add failing-first tests for auction workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates auction event and auction-of-lot activity shapes with correct linkage fields</li><li>validates lot set structures with lot number and classification</li><li>validates pre-set price monetary dimensions on lot sets</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves auction-event vs lot-auction vs purchase-provenance boundaries</li><li>preserves lot membership on member objects via `member_of`</li><li>preserves lot-level estimated/reserve/starting price metadata without merging into sale price</li><li>preserves auction catalog modeling as `LinguisticObject` evidence</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs preserve auction chain linkage (`part_of`, `used_specific_object`) when present</li><li>purchase-provenance imports preserve per-object acquisition + payment decomposition for lot sales</li><li>non-sale scenarios do not fabricate transfer-of-title events</li></ul>\n<p>Regression:</p>\n<ul><li>adding auction metadata does not overwrite existing provenance transfer roles</li><li>multi-lot and multi-object scenarios preserve object-level membership and acquisition details</li></ul>\n<h3 id=\"fixture-anchors-auctions-examples\">Fixture Anchors — Auctions Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Auction event</li></ol>\n<ul><li>auction `Activity` with timespan, auction-house place, and auction-house organization.</li></ul>\n<ol><li>Auction of lot</li></ol>\n<ul><li>lot-auction `Activity` with auction-of-lot classification, `used_specific_object` set, and `part_of` auction event.</li></ul>\n<ol><li>Lot set + member object</li></ol>\n<ul><li>lot `Set` with lot-number identifier and object `member_of` link.</li></ul>\n<ol><li>Pre-set estimated price</li></ol>\n<ul><li>lot `Set` with `dimension` `MonetaryAmount` classified as estimated price.</li></ul>\n<ol><li>Purchase of lot</li></ol>\n<ul><li>provenance `Activity` referencing lot set, with acquisition part(s) plus payment and `part_of` lot-auction.</li></ul>\n<ol><li>Auction catalog</li></ol>\n<ul><li>catalog `LinguisticObject` classified as auction catalog and `about` auction event.</li></ul>\n<ol><li>No-sale outcomes</li></ol>\n<ul><li>fixtures for withdrawn lot, reserve not met, owner buy-back, and winner unable to pay that preserve uncertainty and avoid false ownership-transfer assertions.</li></ul>\n<p>---</p>\n<h2 id=\"round-8-addendum-changes-of-custody\">Round 8 Addendum — Changes of Custody</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Changes of Custody</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Custody transfer is distinct from ownership transfer.</li><li>Temporary possession changes (loan, return, theft, loss, recovery) are modeled as custody changes, not title changes.</li><li>Custody uses `TransferOfCustody` (not `Acquisition`) with equivalent role fields:</li><li>`transferred_custody_of`</li><li>`transferred_custody_from`</li><li>`transferred_custody_to`</li><li>Loan lifecycle is typically modeled as paired custody transfers (outbound + return), potentially open-ended for active long-term loans.</li><li>Institutional ownership can co-exist with departmental custody:</li><li>institution as owner</li><li>department as current keeper/custodian</li><li>Theft/looting are illegal custody transfers; ownership remains unchanged.</li><li>Lost-object scenarios can omit recipient custodian where unknown.</li><li>Sale of stolen goods should be modeled as custody transfer + payment, not ownership acquisition.</li></ul>\n<h3 id=\"implementation-mapping-custody\">Implementation Mapping — Custody</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Ownership/custody separation</li></ol>\n<ul><li>Do not translate `TransferOfCustody` into `Acquisition` unless evidence explicitly indicates title transfer.</li></ul>\n<ol><li>Custody role fidelity</li></ol>\n<ul><li>Preserve custody role edges and allow partial role assertions for unknown recipients.</li></ul>\n<ol><li>Loan pairing semantics</li></ol>\n<ul><li>Preserve paired transfer patterns when present without forcing synthetic return events.</li></ul>\n<ol><li>Departmental custody</li></ol>\n<ul><li>Preserve departmental custodian context without altering institutional ownership assertions.</li></ul>\n<ol><li>Theft/loss semantics</li></ol>\n<ul><li>Preserve theft/loss classifications as custody events and avoid ownership mutations.</li></ul>\n<ol><li>Stolen-sale handling</li></ol>\n<ul><li>Preserve custody-transfer + payment decomposition in stolen-sale scenarios.</li></ul>\n<h3 id=\"tdd-additions-custody\">TDD Additions — Custody</h3>\n<p>Add failing-first tests for custody workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `TransferOfCustody` structures with custody role fields</li><li>allows omitted `transferred_custody_to` in loss/unknown-recipient scenarios</li><li>preserves classification for loan/return/theft/sale-of-stolen-goods cases</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves distinction between `Acquisition` and `TransferOfCustody`</li><li>preserves departmental custody part in mixed acquisition+custody provenance events</li><li>preserves stolen-sale pattern as custody transfer plus payment</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs preserve custody part structures and role edges</li><li>routes do not fabricate ownership transfer events from custody-only evidence</li><li>canonical `_source.raw` retains original custody semantics</li></ul>\n<p>Regression:</p>\n<ul><li>ownership summaries remain stable when custody events are added</li><li>exhibition-related custody chains do not regress into ownership chains</li></ul>\n<h3 id=\"fixture-anchors-custody-examples\">Fixture Anchors — Custody Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Loan out</li></ol>\n<ul><li>provenance `Activity` with `TransferOfCustody` classified as loan.</li></ul>\n<ol><li>Return of loan</li></ol>\n<ul><li>subsequent `TransferOfCustody` reversing from/to custodians.</li></ul>\n<ol><li>Mixed acquisition and departmental custody</li></ol>\n<ul><li>single provenance event with both `Acquisition` and `TransferOfCustody` parts.</li></ul>\n<ol><li>Theft event</li></ol>\n<ul><li>`TransferOfCustody` classified as theft.</li></ul>\n<ol><li>Sale of stolen goods</li></ol>\n<ul><li>custody transfer classified as stolen-goods sale plus payment part.</li></ul>\n<p>---</p>\n<h2 id=\"round-9-addendum-exhibitions\">Round 9 Addendum — Exhibitions</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Exhibitions</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Exhibition modeling separates:</li><li>exhibition activity (`Activity`) at place/time with organizers</li><li>exhibition concept (`PropositionalObject`) representing the abstract idea/theme</li><li>Exhibition activity:</li><li>classify as exhibiting (`aat:300054766`)</li><li>include `timespan`, `took_place_at`, `carried_out_by`</li><li>link exhibited-object set via `used_specific_object`</li><li>link conceptual work via `influenced_by`</li><li>Exhibition concept:</li><li>`PropositionalObject` classified as exhibition (`aat:300417531`)</li><li>can include `about` subjects and `created_by` creators</li><li>can model known artist influence when specific exhibited objects are unknown</li><li>Multi-venue exhibitions:</li><li>each venue is its own exhibition activity</li><li>venue activities may be `part_of` a broader travelling exhibition activity (`aat:300054773`)</li><li>top-level travelling activity should not duplicate venue-specific place/org details</li><li>Exhibition object membership:</li><li>represented through exhibition `Set` and object `member_of`</li><li>venue-specific sets should be used where object lists differ materially</li><li>Provenance integration:</li><li>exhibition-linked custody transfers can be `part_of` exhibition activity</li><li>if owning institution exhibits its own object, movement may apply instead of custody transfer</li></ul>\n<h3 id=\"implementation-mapping-exhibitions\">Implementation Mapping — Exhibitions</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Activity/concept split</li></ol>\n<ul><li>Preserve separate records/structures for exhibition activity and exhibition concept.</li></ul>\n<ol><li>Venue fidelity</li></ol>\n<ul><li>Preserve per-venue exhibition activities and avoid collapsing multi-venue runs into one venue-level event.</li></ul>\n<ol><li>Concept linkage</li></ol>\n<ul><li>Preserve `influenced_by` linkage from exhibition activities to concept records.</li></ul>\n<ol><li>Object-set linkage</li></ol>\n<ul><li>Preserve `used_specific_object` set references and object-side `member_of` membership.</li></ul>\n<ol><li>Artist-known/object-unknown scenario</li></ol>\n<ul><li>Preserve artist relation on exhibition concept (`about` or concept-creation influence) rather than forcing fake object assertions.</li></ul>\n<ol><li>Travel hierarchy</li></ol>\n<ul><li>Preserve `part_of` links to travelling exhibition umbrella activities.</li></ul>\n<ol><li>Provenance integration</li></ol>\n<ul><li>Preserve exhibition-related custody provenance and avoid over-converting to ownership change.</li></ul>\n<h3 id=\"tdd-additions-exhibitions\">TDD Additions — Exhibitions</h3>\n<p>Add failing-first tests for exhibition workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates exhibition activity and exhibition concept as distinct entity types</li><li>validates `used_specific_object` linkage to set and object `member_of` membership pattern</li><li>validates travelling exhibition classification and `part_of` structure</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves venue-specific activity details (time/place/organizer) and concept linkage</li><li>preserves concept-side subject/influence assertions for artist-known/object-unknown data</li><li>preserves venue-specific object sets when input indicates different object lists by venue</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs keep exhibition activity/concept separation intact</li><li>entity and artwork projections preserve exhibition membership without mutating canonical source</li><li>provenance endpoints/surfaces preserve exhibition custody links where present</li></ul>\n<p>Regression:</p>\n<ul><li>exhibitions do not collapse into generic events without exhibition classification</li><li>multi-venue hierarchies remain navigable after import/normalization</li></ul>\n<h3 id=\"fixture-anchors-exhibitions-examples\">Fixture Anchors — Exhibitions Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Single-venue exhibition activity</li></ol>\n<ul><li>exhibiting `Activity` with timespan/place/organizer, used object set, and concept influence.</li></ul>\n<ol><li>Exhibition concept</li></ol>\n<ul><li>`PropositionalObject` classified as exhibition with `about` and `created_by`.</li></ul>\n<ol><li>Artist-known/object-unknown concept variant</li></ol>\n<ul><li>concept creation influenced by artist without asserting specific exhibited object list.</li></ul>\n<ol><li>Multi-venue exhibition</li></ol>\n<ul><li>venue activity with `part_of` broader travelling exhibition activity.</li></ul>\n<ol><li>Travelling exhibition umbrella</li></ol>\n<ul><li>top-level multi-location activity with broader timespan and concept influence.</li></ul>\n<ol><li>Exhibition object set + member object</li></ol>\n<ul><li>exhibition `Set` plus `HumanMadeObject` with `member_of`.</li></ul>\n<ol><li>Exhibition custody provenance linkage</li></ol>\n<ul><li>custody transfer provenance entries linked `part_of` exhibition activity when applicable.</li></ul>\n<p>---</p>\n<h2 id=\"round-10-addendum-encounters-with-objects\">Round 10 Addendum — Encounters with Objects</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Encounters with Objects</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Encounter events model rediscovery/find scenarios in provenance chains, especially where objects re-enter documented knowledge long after production.</li><li>An object may have multiple encounters over time (encountered, lost, rediscovered).</li><li>Encounter is modeled as `Encounter` activity part within a provenance wrapper `Activity`.</li><li>`Encounter` has dedicated object linkage via `encountered` to distinguish found object(s) from other objects used in related activities.</li><li>Encounter actors are linked via `carried_out_by` on the encounter activity.</li><li>Ownership/custody consequences are not implicit:</li><li>ownership transfer should be modeled explicitly (for example, adjacent `Acquisition` part)</li><li>custody-only outcomes should remain custody semantics</li><li>Encounter can be modeled directly in object descriptions in simpler scenarios, even without full ownership transfer logic.</li></ul>\n<h3 id=\"implementation-mapping-encounters\">Implementation Mapping — Encounters</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Encounter activity preservation</li></ol>\n<ul><li>Preserve `Encounter` as an explicit activity type; do not flatten into narrative notes.</li></ul>\n<ol><li>Dedicated encountered linkage</li></ol>\n<ul><li>Preserve `encountered` object relations distinctly from `used_specific_object` or transfer-role fields.</li></ul>\n<ol><li>Actor/event integrity</li></ol>\n<ul><li>Preserve encounter actors in `carried_out_by` and keep encounter-specific metadata on the encounter part.</li></ul>\n<ol><li>Ownership/custody explicitness</li></ol>\n<ul><li>Do not infer title transfer from encounter alone.</li><li>Preserve explicit ownership (`Acquisition`) or custody (`TransferOfCustody`) parts when present in the same provenance event.</li></ul>\n<ol><li>Multi-encounter support</li></ol>\n<ul><li>Support repeated encounters in chains without overwriting prior encounter history.</li></ul>\n<ol><li>Archaeological uncertainty guardrail</li></ol>\n<ul><li>Preserve partial/uncertain encounter context without inventing missing chronology or legal outcomes.</li></ul>\n<h3 id=\"tdd-additions-encounters\">TDD Additions — Encounters</h3>\n<p>Add failing-first tests for encounter workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `Encounter` parts with `encountered` linkage and optional `carried_out_by`</li><li>rejects malformed encounter object references</li><li>permits encounter events with or without adjacent acquisition/custody parts</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves encounter parts in normalized provenance chains</li><li>preserves combined encounter + acquisition pattern when source indicates ownership transfer on discovery</li><li>preserves encounter-only cases without fabricating ownership changes</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs preserve encounter activity structure and object references</li><li>route responses maintain explicit distinction between encounter, acquisition, and custody parts</li><li>canonical `_source.raw` encounter content remains unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>existing acquisition/custody logic remains stable when encounter parts are introduced</li><li>multi-encounter histories do not collapse into a single event</li></ul>\n<h3 id=\"fixture-anchors-encounters-examples\">Fixture Anchors — Encounters Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Encounter with ownership transfer</li></ol>\n<ul><li>wrapper provenance `Activity` containing:</li><li>`Encounter` part (`carried_out_by` + `encountered`)</li><li>`Acquisition` part transferring title to discoverer entity.</li></ul>\n<ol><li>Encounter without explicit ownership transfer</li></ol>\n<ul><li>encounter part present, no acquisition part; tests assert no inferred title transfer.</li></ul>\n<ol><li>Encounter chain continuity</li></ol>\n<ul><li>multiple encounter events across time with distinct IDs and preserved ordering/links.</li></ul>\n<p>---</p>\n<h2 id=\"round-11-addendum-location-and-movement\">Round 11 Addendum — Location and Movement</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Location and Movement</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Object location is, in principle, derivable from movement history; many CH systems only track selected movement events.</li><li>Movement tracking is especially useful for:</li><li>display/storage transitions</li><li>exhibition display where ownership/custody might not change</li><li>moves between facilities (storage, conservation, galleries)</li><li>scenarios coupled with departmental custody transfer</li><li>Movement is modeled with `Move` activity parts within provenance/event wrappers.</li><li>`Move` captures:</li><li>`moved` (object)</li><li>`moved_from` (origin place)</li><li>`moved_to` (destination place)</li><li>Movement is semantically separate from ownership (`Acquisition`) and custody (`TransferOfCustody`), though they may co-occur in the same broader event chain.</li></ul>\n<h3 id=\"implementation-mapping-movement\">Implementation Mapping — Movement</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Movement activity preservation</li></ol>\n<ul><li>Preserve `Move` as explicit activity structure; do not collapse to plain location strings.</li></ul>\n<ol><li>Origin/destination integrity</li></ol>\n<ul><li>Preserve both `moved_from` and `moved_to` place nodes when known.</li></ul>\n<ol><li>Movement/object linkage</li></ol>\n<ul><li>Preserve `moved` object references distinctly from ownership/custody role edges.</li></ul>\n<ol><li>Co-occurring event separation</li></ol>\n<ul><li>When movement and custody changes co-occur, preserve each as separate parts in the same wrapper activity/event chain.</li></ul>\n<ol><li>Display/exhibition movement support</li></ol>\n<ul><li>Preserve movement-only exhibition/display scenarios without forcing ownership or custody transfer.</li></ul>\n<ol><li>Current-location inference guardrail</li></ol>\n<ul><li>Do not overwrite canonical history with inferred present location; keep derived views separate from source event history.</li></ul>\n<h3 id=\"tdd-additions-movement\">TDD Additions — Movement</h3>\n<p>Add failing-first tests for movement workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `Move` parts with `moved`, `moved_from`, and `moved_to` structures</li><li>rejects malformed place/object references in movement parts</li><li>allows movement events without acquisition/custody parts</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves movement events as structured `Move` parts during normalization</li><li>preserves co-occurring movement + custody structures without semantic merging</li><li>preserves movement-only exhibition/internal-transfer scenarios</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain movement part structure and place references</li><li>routes do not synthesize ownership changes from movement-only evidence</li><li>canonical `_source.raw` movement history remains unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>existing ownership/custody summaries remain stable when movement events are added</li><li>derived location views do not erase historical movement events</li></ul>\n<h3 id=\"fixture-anchors-movement-examples\">Fixture Anchors — Movement Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Routine move between two galleries</li></ol>\n<ul><li>wrapper provenance `Activity` with one `Move` part:</li><li>`moved` object</li><li>`moved_from` place</li><li>`moved_to` place</li></ul>\n<ol><li>Movement with departmental handoff</li></ol>\n<ul><li>event chain where movement and custody transfer are both present as separate parts.</li></ul>\n<ol><li>Exhibition-owned-object move</li></ol>\n<ul><li>movement event for institution-owned object used in exhibition context without custody transfer.</li></ul>\n<p>---</p>\n<h2 id=\"round-12-addendum-promised-activities\">Round 12 Addendum — Promised Activities</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Promised Activities</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Promises model planned future actions (gift, sale, exchange, commission-related obligations) that may precede final ownership transfer.</li><li>Promise uses activity classification with the required vocabulary term:</li><li>Promise (`aat:300435599`)</li><li>Current model does not fully model the future planned event object directly; promise context is expressed via:</li><li>`participant` (promised party/counterparty)</li><li>`used_specific_object` (promised object when known)</li><li>descriptive note (`referred_to_by`) for contract/terms details</li><li>Promised gift pattern:</li><li>promise activity carried out by promisor</li><li>participant references intended recipient</li><li>object referenced via `used_specific_object`</li><li>Commissioning pattern can include paired promises:</li><li>commissioner promise to pay</li><li>artist promise to produce</li><li>Later production, title transfer, and payment settlement remain separate lifecycle/provenance events using their standard patterns.</li></ul>\n<h3 id=\"implementation-mapping-promises\">Implementation Mapping — Promises</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Promise classification integrity</li></ol>\n<ul><li>Preserve promise activities as `Activity` parts classified as `Promise` (`aat:300435599`).</li></ul>\n<ol><li>Obligation context preservation</li></ol>\n<ul><li>Preserve promisor (`carried_out_by`), participant/counterparty, and promised object links where present.</li></ul>\n<ol><li>Contract/terms evidence</li></ol>\n<ul><li>Preserve descriptive statements on promise activities for legal/contractual context.</li></ul>\n<ol><li>Future-event separation</li></ol>\n<ul><li>Do not collapse promises into completed acquisitions/payments/productions.</li><li>Keep promise events separate from eventual fulfillment events.</li></ul>\n<ol><li>Commission pair modeling</li></ol>\n<ul><li>Preserve dual-obligation structures in commission scenarios when both sides are known.</li></ul>\n<ol><li>Unfulfilled/open promise support</li></ol>\n<ul><li>Preserve open promise state without fabricating completion events.</li></ul>\n<h3 id=\"tdd-additions-promised-activities\">TDD Additions — Promised Activities</h3>\n<p>Add failing-first tests for promised-activity workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates promise activity parts with required promise classification</li><li>validates optional `participant`, `used_specific_object`, and descriptive note structures</li><li>rejects malformed promise activity payloads and role/link fields</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves promised-gift pattern (promisor + object + recipient) without converting to acquisition</li><li>preserves commissioning paired promises (pay obligation + produce obligation) as separate parts</li><li>preserves commission/provenance classifications when present</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain promise activity parts and contract-note descriptions</li><li>routes do not synthesize title transfer or payment completion from promise-only evidence</li><li>canonical `_source.raw` promise structures remain unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>existing acquisition/payment/production chains remain stable when promise events are introduced</li><li>later fulfillment events can co-exist without overwriting original promise records</li></ul>\n<h3 id=\"fixture-anchors-promised-activities-examples\">Fixture Anchors — Promised Activities Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Promised gift</li></ol>\n<ul><li>wrapper provenance `Activity` containing promise-classified part with:</li><li>promisor (`carried_out_by`)</li><li>promised object (`used_specific_object`)</li><li>recipient (`participant`)</li><li>descriptive note for promise context</li></ul>\n<ol><li>Commissioning pair</li></ol>\n<ul><li>wrapper provenance `Activity` classified as commissioning with two promise parts:</li><li>obligation to pay artist</li><li>obligation to produce artwork</li></ul>\n<ol><li>Promise without fulfillment</li></ol>\n<ul><li>promise record with no immediate acquisition/payment/production part; tests assert no inferred completion.</li></ul>\n<p>---</p>\n<h2 id=\"round-13-addendum-transfer-of-rights\">Round 13 Addendum — Transfer of Rights</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Transfer of Rights</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Some provenance scenarios require explicit modeling of rights rather than only title-transfer shorthand.</li><li>`Acquisition` is concise for standard ownership transfer, but explicit `Right` modeling is needed for complex right states (partial shares, IP rights, etc.).</li><li>Rights are conceptual entities with key properties:</li><li>`possessed_by` (holder)</li><li>`applies_to` (thing the right concerns)</li><li>Rights transitions are modeled with `RightAcquisition` activity parts using:</li><li>`establishes` (newly established right instances)</li><li>`invalidates` (rights superseded/terminated by the change)</li><li>It is valid (but often redundant) to include both `Acquisition` and `RightAcquisition` in the same provenance entry.</li><li>Shared ownership with uneven stakes:</li><li>partition ownership right into component rights (`part`)</li><li>represent proportions using `Dimension` with percent unit</li><li>Subsequent share transfers should model the new resulting state directly (establish new rights, invalidate prior rights).</li><li>Intellectual property and other non-physical rights can be modeled with the same `RightAcquisition` pattern.</li></ul>\n<h3 id=\"implementation-mapping-rights\">Implementation Mapping — Rights</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Right model activation</li></ol>\n<ul><li>Use explicit `Right` + `RightAcquisition` when acquisition shorthand would lose legal/state detail.</li></ul>\n<ol><li>Right-holder/object linkage</li></ol>\n<ul><li>Preserve `possessed_by` and `applies_to` links for every explicit right record.</li></ul>\n<ol><li>State-transition integrity</li></ol>\n<ul><li>Preserve `establishes`/`invalidates` pairs as explicit state transitions, not implicit deltas.</li></ul>\n<ol><li>Share partitioning</li></ol>\n<ul><li>Preserve ownership-share partitions as child rights with quantitative dimensions.</li></ul>\n<ol><li>Result-state modeling</li></ol>\n<ul><li>For share trades, represent the post-transaction right state explicitly; do not rely on inferred arithmetic-only deltas.</li></ul>\n<ol><li>Acquisition coexistence</li></ol>\n<ul><li>Where both acquisition and right transitions are present, preserve both without forcing deduplication.</li></ul>\n<ol><li>IP-right support</li></ol>\n<ul><li>Preserve copyright/performance/right-type classifications independent of physical carrier transfers.</li></ul>\n<h3 id=\"tdd-additions-rights\">TDD Additions — Rights</h3>\n<p>Add failing-first tests for rights workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `Right` structures with `possessed_by` and `applies_to`</li><li>validates `RightAcquisition` with `establishes` and optional `invalidates`</li><li>validates share dimensions and measurement units for partitioned ownership rights</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves explicit rights transitions when source includes complex ownership/legal data</li><li>preserves partitioned ownership rights and per-holder percentages</li><li>preserves invalidation of superseded rights in share-transfer scenarios</li><li>preserves IP-right acquisitions without conflating with physical ownership transfer</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain `RightAcquisition` transitions and right partitions</li><li>routes do not collapse explicit rights models into flat acquisition-only summaries</li><li>canonical `_source.raw` rights structures remain unchanged by DTO projections</li></ul>\n<p>Regression:</p>\n<ul><li>simple acquisition paths remain stable and concise where explicit rights are unnecessary</li><li>mixed records (acquisition + rights + payments) maintain cross-part consistency</li></ul>\n<h3 id=\"fixture-anchors-rights-examples\">Fixture Anchors — Rights Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Basic right establishment alongside acquisition</li></ol>\n<ul><li>provenance wrapper with `Acquisition` plus `RightAcquisition.establishes` ownership right.</li></ul>\n<ol><li>Uneven shared ownership</li></ol>\n<ul><li>total ownership right partitioned into component rights with percent dimensions per holder.</li></ul>\n<ol><li>Share transfer between existing owners</li></ol>\n<ul><li>rights transition where new shares are established and prior shares invalidated.</li></ul>\n<ol><li>Intellectual property right acquisition</li></ol>\n<ul><li>`RightAcquisition` establishing copyright-like right held by organization and applied to artwork.</li></ul>\n<p>---</p>\n<h2 id=\"round-14-addendum-unknown-transfers\">Round 14 Addendum — Unknown Transfers</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Unknown Transfers</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Historical evidence can be insufficient to determine whether a transfer was ownership, custody, loan, or another mechanism.</li><li>To avoid false precision, model ambiguous exchanges with `Transfer` rather than forcing `Acquisition`, `TransferOfCustody`, or right-transfer semantics.</li><li>`Transfer` has dedicated role properties:</li><li>`transferred` (object(s))</li><li>`transferred_from` (source actor(s))</li><li>`transferred_to` (destination actor(s))</li><li>This mirrors other transfer-like activity parts while preserving indeterminacy.</li></ul>\n<h3 id=\"implementation-mapping-unknown-transfers\">Implementation Mapping — Unknown Transfers</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Uncertainty-first modeling</li></ol>\n<ul><li>Use `Transfer` when source evidence is ambiguous about legal/physical semantics.</li></ul>\n<ol><li>No forced disambiguation</li></ol>\n<ul><li>Do not auto-convert ambiguous transfers to acquisition, custody, move, or rights transfer.</li></ul>\n<ol><li>Role fidelity</li></ol>\n<ul><li>Preserve `transferred`, `transferred_from`, and `transferred_to` structures as provided.</li></ul>\n<ol><li>Future refinement safety</li></ol>\n<ul><li>Allow later evidence to supersede/augment ambiguous transfer entries without destructive rewrites.</li></ul>\n<ol><li>Provenance-chain continuity</li></ol>\n<ul><li>Keep unknown transfers in chronology so event ordering remains intact even when semantics are partial.</li></ul>\n<h3 id=\"tdd-additions-unknown-transfers\">TDD Additions — Unknown Transfers</h3>\n<p>Add failing-first tests for unknown-transfer workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `Transfer` parts with `transferred`, `transferred_from`, `transferred_to`</li><li>rejects malformed transfer role structures</li><li>supports transfer entries with sparse contextual metadata when evidence is limited</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves ambiguous source records as `Transfer` instead of over-classifying</li><li>preserves actor/object role edges without semantic coercion</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain `Transfer` part type and fields unchanged</li><li>routes do not fabricate ownership/custody outcomes from ambiguous transfer records</li><li>canonical `_source.raw` uncertainty semantics remain unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>known acquisition/custody/move workflows remain unaffected when `Transfer` parts are introduced</li><li>future enrichment paths can add precise events without deleting prior uncertain records</li></ul>\n<h3 id=\"fixture-anchors-unknown-transfers-examples\">Fixture Anchors — Unknown Transfers Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Ambiguous person-to-person transfer</li></ol>\n<ul><li>wrapper provenance `Activity` with one `Transfer` part:</li><li>`transferred` object</li><li>`transferred_from` person/group</li><li>`transferred_to` person/group</li><li>no assertion of ownership, custody, or permanence.</li></ul>\n<p>---</p>\n<h2 id=\"round-15-addendum-conservation\">Round 15 Addendum — Conservation</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Conservation</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Conservation modeling includes:</li><li>condition assessment (state/damage identification)</li><li>conservation intervention activities (physical modifications)</li><li>conservation projects as wrapper activities</li><li>Condition assessment pattern:</li><li>represented via `AttributeAssignment` on the object (`attributed_by`)</li><li>uses `assigned_property` (for example `classified_as`) and `assigned` condition types</li><li>can include description, timespan, actor, and `part_of` project linkage</li><li>Conservation intervention pattern:</li><li>represented via `Modification` on object (`modified_by`)</li><li>can include technique, description, timespan, actor, and `part_of` project linkage</li><li>Conservation project pattern:</li><li>top-level wrapper `Activity` with conservation classification</li><li>regular activity metadata (name, description, timespan, actors) describing overall context</li><li>Conservation links to other model areas:</li><li>statements for object state and conservation context</li><li>sampling/production-by-removal patterns in object production sections</li></ul>\n<h3 id=\"implementation-mapping-conservation\">Implementation Mapping — Conservation</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Assessment/intervention separation</li></ol>\n<ul><li>Preserve condition assessments (`AttributeAssignment`) separately from intervention work (`Modification`).</li></ul>\n<ol><li>Assignment semantics</li></ol>\n<ul><li>Preserve `assigned_property` and `assigned` condition types without collapsing into plain narrative text.</li></ul>\n<ol><li>Intervention detail preservation</li></ol>\n<ul><li>Preserve `technique`, actor, timespan, and descriptions on modification activities.</li></ul>\n<ol><li>Project wrapper integrity</li></ol>\n<ul><li>Preserve conservation project wrapper `Activity` and `part_of` links from assessments/modifications.</li></ul>\n<ol><li>Multi-object project support</li></ol>\n<ul><li>Allow one project to contextualize many object-level assessments/modifications without duplicating project metadata per object.</li></ul>\n<ol><li>No provenance-role coercion</li></ol>\n<ul><li>Do not coerce conservation activities into ownership/custody transfer semantics.</li></ul>\n<h3 id=\"tdd-additions-conservation\">TDD Additions — Conservation</h3>\n<p>Add failing-first tests for conservation workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates object-level `attributed_by` condition-assessment structures</li><li>validates object-level `modified_by` conservation-modification structures</li><li>validates project-level conservation activity structures and classification</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves condition assignment structure (`assigned_property`, `assigned`) during normalization</li><li>preserves modification technique + temporal/actor metadata</li><li>preserves `part_of` links tying granular events to conservation project wrapper</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain conservation assessment and modification structures without flattening</li><li>routes preserve project wrappers and links across object and event views</li><li>canonical `_source.raw` conservation data remains unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>conservation metadata does not overwrite core classification/title fields</li><li>adding project context does not remove object-level condition/intervention details</li></ul>\n<h3 id=\"fixture-anchors-conservation-examples\">Fixture Anchors — Conservation Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Condition assessment on object</li></ol>\n<ul><li>`HumanMadeObject` with `attributed_by` `AttributeAssignment`:</li><li>condition assignment via `assigned_property` + `assigned`</li><li>description/timespan/actor</li><li>`part_of` conservation project</li></ul>\n<ol><li>Conservation intervention on object</li></ol>\n<ul><li>`HumanMadeObject` with `modified_by` `Modification`:</li><li>conservation description</li><li>technique classification</li><li>timespan/actor</li><li>`part_of` conservation project</li></ul>\n<ol><li>Conservation project wrapper</li></ol>\n<ul><li>conservation `Activity` with name/description/timespan and multiple actors.</li></ul>\n<p>---</p>\n<h2 id=\"round-16-addendum-people-and-organizations\">Round 16 Addendum — People and Organizations</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: People and Organizations</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Actors in Linked Art are modeled as:</li><li>`Person` (human individual)</li><li>`Group` (collective of humans, including organizations and other defined sets)</li><li>If actor type is uncertain between person/group, `Group` is the safer default.</li><li>Core actor modeling goals are disambiguation and historical role clarity, not exhaustive biography/social-graph capture.</li><li>Identity and equivalence patterns:</li><li>names via `identified_by` (`Name`, optionally partitioned into typed parts)</li><li>external alignment via `equivalent`</li><li>Contact and residence:</li><li>contact details via `contact_point` (`Identifier`-based, not `Name`)</li><li>place-based residence via `residence` (`Place`)</li><li>Actor lifecycle and activity context:</li><li>person events: `born`, `died`</li><li>group events: `formed_by`, `dissolved_by`</li><li>active professional period via embedded `carried_out` activity classified as professional activities</li><li>participation-only events via `participated_in` when actor is participant, not responsible agent</li><li>Classification patterns for actor descriptors:</li><li>nationality as typed classification</li><li>ethnicity/culture as typed classification</li><li>gender as typed classification</li><li>occupation as typed classification</li><li>Organizational membership:</li><li>member relation asserted via `member_of` from member person/group to parent group.</li></ul>\n<h3 id=\"implementation-mapping-people-organizations\">Implementation Mapping — People/Organizations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Actor-type discipline</li></ol>\n<ul><li>Preserve `Person` vs `Group` distinctions; use `Group` fallback for ambiguous actor references.</li></ul>\n<ol><li>Name modeling depth</li></ol>\n<ul><li>Preserve primary names and typed name parts when available; do not flatten multi-part names into a single untyped label only.</li></ul>\n<ol><li>External reconciliation safety</li></ol>\n<ul><li>Preserve `equivalent` links to authority records without collapsing local record identity.</li></ul>\n<ol><li>Contact/residence separation</li></ol>\n<ul><li>Keep `contact_point` identifier semantics separate from `residence` place semantics.</li></ul>\n<ol><li>Lifecycle event correctness</li></ol>\n<ul><li>Preserve birth/death for persons and formation/dissolution for groups with event/timespan/place context.</li></ul>\n<ol><li>Responsibility vs participation</li></ol>\n<ul><li>Preserve distinction between activities the actor carried out (`carried_out`) and events they participated in (`participated_in`).</li></ul>\n<ol><li>Descriptor classifications</li></ol>\n<ul><li>Preserve meta-classified actor descriptors (nationality, ethnicity, gender, occupation) without coercing them into group membership constructs.</li></ul>\n<ol><li>Membership directionality</li></ol>\n<ul><li>Preserve `member_of` from member records; do not require synthetic inverse membership arrays in canonical records.</li></ul>\n<h3 id=\"tdd-additions-people-organizations\">TDD Additions — People/Organizations</h3>\n<p>Add failing-first tests for actor workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `Person`/`Group` identity structures with names/classifications</li><li>validates lifecycle event structures (`born`/`died`, `formed_by`/`dissolved_by`)</li><li>validates `contact_point`, `residence`, and `equivalent` structures</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves typed name parts and actor descriptor classifications</li><li>preserves actor activity distinctions (`carried_out` vs `participated_in`)</li><li>preserves uncertain actor references as `Group` when person/group ambiguity is unresolved</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain actor identity, descriptor, and lifecycle event structures</li><li>entity profile projections preserve membership and descriptor metadata without mutating `_source.raw`</li><li>routes do not convert contact identifiers into name statements or place records incorrectly</li></ul>\n<p>Regression:</p>\n<ul><li>actor enrichment does not break provenance role links (`carried_out_by`, transfer parties, etc.)</li><li>external-equivalent reconciliation does not overwrite local actor IDs</li></ul>\n<h3 id=\"fixture-anchors-people-organizations-examples\">Fixture Anchors — People/Organizations Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Person as group member</li></ol>\n<ul><li>`Person` with `member_of` `Group`.</li></ul>\n<ol><li>Primary and partitioned names</li></ol>\n<ul><li>primary name with typed parts (given/middle/family).</li></ul>\n<ol><li>External equivalent alignment</li></ol>\n<ul><li>actor with `equivalent` link to authority URI.</li></ul>\n<ol><li>Contact and residence</li></ol>\n<ul><li>actor with multiple `contact_point` identifiers and separate `residence` place.</li></ul>\n<ol><li>Lifecycle events</li></ol>\n<ul><li>person birth/death and group formation examples.</li></ul>\n<ol><li>Active professional period</li></ol>\n<ul><li>`carried_out` activity classified as professional activities with timespan.</li></ul>\n<ol><li>Participation event</li></ol>\n<ul><li>`participated_in` burial-style activity with time/place.</li></ul>\n<ol><li>Descriptor classifications</li></ol>\n<ul><li>nationality, ethnicity, gender, and occupation typed classifications.</li></ul>\n<p>---</p>\n<h2 id=\"round-17-addendum-places\">Round 17 Addendum — Places</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Places</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>`Place` is foundational for activity location, object location context, and actor residence/association.</li><li>Places are spatial extents independent of time and independent of what currently occupies that space.</li><li>Place model supports:</li><li>core identity metadata (names, identifiers, statements, classifications, equivalents)</li><li>spatial hierarchy via `part_of`</li><li>geospatial geometry via `defined_by` (WKT string)</li><li>Geospatial data can range from detailed polygons to approximations/bounding proxies.</li><li>Approximate location can be represented as a more specific place `part_of` a broader known place.</li><li>Buildings and other &quot;immovable&quot; works remain `HumanMadeObject` records with location references; activities occur at `Place`, not at the object itself.</li></ul>\n<h3 id=\"implementation-mapping-places\">Implementation Mapping — Places</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Place identity preservation</li></ol>\n<ul><li>Preserve place core metadata and classifications without collapsing into plain location strings.</li></ul>\n<ol><li>Hierarchy integrity</li></ol>\n<ul><li>Preserve `part_of` place hierarchy links to support spatial navigation and context.</li></ul>\n<ol><li>Geometry fidelity</li></ol>\n<ul><li>Preserve `defined_by` WKT geometry exactly when supplied.</li></ul>\n<ol><li>Approximation semantics</li></ol>\n<ul><li>Preserve approximate/specific place modeling via `part_of` rather than forcing uncertain coordinates.</li></ul>\n<ol><li>Place vs object separation</li></ol>\n<ul><li>Keep built works as objects (`HumanMadeObject`) and their spatial context as `Place`.</li></ul>\n<ol><li>Activity location discipline</li></ol>\n<ul><li>Preserve event/activity location references as `Place` nodes, not building objects.</li></ul>\n<ol><li>Immovable-object handling</li></ol>\n<ul><li>Support large/fixed-seeming works as movable-or-locatable objects with `current_location` place references when modeled that way.</li></ul>\n<h3 id=\"tdd-additions-places\">TDD Additions — Places</h3>\n<p>Add failing-first tests for place workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `Place` entities with core identity metadata and classifications</li><li>validates `defined_by` string preservation for WKT geometry values</li><li>validates hierarchical `part_of` place references</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves place hierarchy and descriptive statements during normalization</li><li>preserves WKT geometry and does not coerce it to unsupported formats</li><li>preserves approximation patterns (specific place within broader place)</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain place hierarchy and geometry fields</li><li>routes do not convert place references into object references for activity locations</li><li>canonical `_source.raw` place data remains unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>immovable-object records remain objects with place references rather than being converted into place entities</li><li>map-oriented fields remain stable across provider imports</li></ul>\n<h3 id=\"fixture-anchors-places-examples\">Fixture Anchors — Places Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Place with hierarchy and description</li></ol>\n<ul><li>city `Place` with classification, name/description, and `part_of` nation.</li></ul>\n<ol><li>Place with WKT geometry</li></ol>\n<ul><li>nation `Place` with polygon in `defined_by`.</li></ul>\n<ol><li>Approximate sub-location</li></ol>\n<ul><li>specific location place with `part_of` broader city place.</li></ul>\n<ol><li>Building as object + place location</li></ol>\n<ul><li>building `HumanMadeObject` classified as building with `current_location` place.</li></ul>\n<p>---</p>\n<h2 id=\"round-18-addendum-concepts\">Round 18 Addendum — Concepts</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Concepts</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Concepts represent units of thought used for classification and semantic alignment.</li><li>Linked Art typically reuses external vocabularies (especially AAT), with local concept records allowed when needed.</li><li>Core concept classes:</li><li>`Type` (general concept class)</li><li>`Currency`</li><li>`Language`</li><li>`Material`</li><li>`MeasurementUnit`</li><li>Class specificity should be preserved where known (do not default everything to generic `Type` unnecessarily).</li><li>`equivalent` links are critical for interoperability when local concept records mirror or extend external concepts.</li><li>Concept relationships have distinct semantics:</li><li>`broader` for hierarchical/generalization relationships</li><li>`classified_as` for meta-type/category relationships</li><li>`member_of` for concept-scheme/set grouping (orthogonal to hierarchy and meta-typing)</li><li>Coordinated concepts involving non-concept entities are modeled via `created_by.influenced_by` (for example, concept + place).</li><li>Model is aligned with SKOS patterns; concept schemes map well to `Set`.</li></ul>\n<h3 id=\"implementation-mapping-concepts\">Implementation Mapping — Concepts</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Concept class fidelity</li></ol>\n<ul><li>Preserve specific concept subclasses (`Currency`, `Language`, `Material`, `MeasurementUnit`) when present.</li></ul>\n<ol><li>Interoperability equivalence</li></ol>\n<ul><li>Preserve `equivalent` links on local concept records and concept references to maintain cross-system semantics.</li></ul>\n<ol><li>Hierarchy vs meta-type distinction</li></ol>\n<ul><li>Preserve `broader` and `classified_as` as distinct relations; do not conflate them.</li></ul>\n<ol><li>Scheme/set grouping</li></ol>\n<ul><li>Preserve `member_of` concept scheme/set links independently of hierarchy and classification.</li></ul>\n<ol><li>Coordinated concept creation</li></ol>\n<ul><li>Preserve `created_by.influenced_by` links for concept coordination involving non-concept entities.</li></ul>\n<ol><li>Local concept safety</li></ol>\n<ul><li>Allow local concept records to carry additional metadata while keeping explicit external equivalence anchors.</li></ul>\n<ol><li>SKOS compatibility guardrail</li></ol>\n<ul><li>Keep concept structures transform-friendly for SKOS-style mappings (labels/notes/broader/scheme).</li></ul>\n<h3 id=\"tdd-additions-concepts\">TDD Additions — Concepts</h3>\n<p>Add failing-first tests for concept workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates concept class records (`Type` and specialized subclasses) with core identity metadata</li><li>validates `equivalent`, `broader`, `classified_as`, and `member_of` structures</li><li>rejects malformed concept hierarchy and equivalence payloads</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves local concept records with external equivalence links</li><li>preserves distinction between broader hierarchy and meta-type classification</li><li>preserves concept-scheme memberships without rewriting as hierarchy links</li><li>preserves coordinated concept influences including non-concept entities</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain concept class/relationship semantics</li><li>routes do not collapse concept links to plain labels only</li><li>canonical `_source.raw` concept structures remain unmutated by DTO projection</li></ul>\n<p>Regression:</p>\n<ul><li>object/person/place classification references remain stable when concept records are normalized locally</li><li>concept enrichments do not break rights/material/language/unit references across records</li></ul>\n<h3 id=\"fixture-anchors-concepts-examples\">Fixture Anchors — Concepts Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Minimal concept record</li></ol>\n<ul><li>basic `Type` concept with ID and label.</li></ul>\n<ol><li>Local concept with external equivalent</li></ol>\n<ul><li>local concept primary name plus `equivalent` AAT concept.</li></ul>\n<ol><li>Concept reference with embedded equivalent</li></ol>\n<ul><li>object classification referencing local concept with explicit external equivalent.</li></ul>\n<ol><li>Broader + meta-type distinction</li></ol>\n<ul><li>concept with both `broader` and `classified_as` relationships.</li></ul>\n<ol><li>Concept scheme membership</li></ol>\n<ul><li>concept `member_of` concept-scheme `Set`.</li></ul>\n<ol><li>Coordinated concept creation influence</li></ol>\n<ul><li>concept `created_by.influenced_by` including both concept and place entities.</li></ul>\n<p>---</p>\n<h2 id=\"round-19-addendum-events\">Round 19 Addendum — Events</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Events</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Temporal entities include:</li><li>`Period` (time span construct, often conventionally bounded)</li><li>`Event` (occurrence that changes state, not necessarily intentional)</li><li>`Activity` (intentional human-carried occurrence)</li><li>These temporal records are often contextual entities separate from specific object lifecycle/provenance/exhibition models.</li><li>Causality:</li><li>events/activities can reference preceding causes via `caused_by`</li><li>causal events should be first-class records when shared across objects/works/events</li><li>Event relationship semantics must remain distinct:</li><li>`part_of`: strict partition hierarchy</li><li>`during`: inclusion/context without partition semantics</li><li>Relative ordering for uncertain chronology:</li><li>`before`</li><li>`after`</li><li>Relative ordering is especially useful where absolute dates are unknown but sequence is known.</li></ul>\n<h3 id=\"implementation-mapping-events\">Implementation Mapping — Events</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Temporal class fidelity</li></ol>\n<ul><li>Preserve `Period`/`Event`/`Activity` distinctions without collapsing to generic activity types.</li></ul>\n<ol><li>Causal-link preservation</li></ol>\n<ul><li>Preserve `caused_by` links as explicit references to causal entities.</li></ul>\n<ol><li>Partition vs inclusion discipline</li></ol>\n<ul><li>Preserve `part_of` and `during` with their distinct semantics; do not interchange automatically.</li></ul>\n<ol><li>Relative chronology support</li></ol>\n<ul><li>Preserve `before`/`after` relations for uncertain or partially ordered timelines.</li></ul>\n<ol><li>Shared-context entity reuse</li></ol>\n<ul><li>Reuse canonical event IDs in references so multiple records can point to the same contextual event.</li></ul>\n<ol><li>Temporal metadata integrity</li></ol>\n<ul><li>Preserve timespan and place metadata on temporal entities without flattening to display-only labels.</li></ul>\n<h3 id=\"tdd-additions-events\">TDD Additions — Events</h3>\n<p>Add failing-first tests for event workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `Period`, `Event`, and `Activity` structures with core identity/timespan fields</li><li>validates `caused_by`, `part_of`, `during`, `before`, and `after` relationship structures</li><li>rejects malformed temporal relation payloads</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves causal chains without role inversion</li><li>preserves `part_of` vs `during` distinction in normalized timelines</li><li>preserves relative ordering fields when no absolute timespan exists</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain temporal class and relation semantics</li><li>routes do not fabricate exact dates from relative ordering alone</li><li>canonical `_source.raw` temporal relationships remain unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>provenance/exhibition timelines remain stable with added contextual period/event references</li><li>causal event references remain reusable across multiple object/activity records</li></ul>\n<h3 id=\"fixture-anchors-events-examples\">Fixture Anchors — Events Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Period with bounded timespan</li></ol>\n<ul><li>period record (for example, century) with explicit begin/end bounds.</li></ul>\n<ol><li>Causal event chain</li></ol>\n<ul><li>event record (for example, eruption) referenced as `caused_by` from a destruction/lifecycle event.</li></ul>\n<ol><li>`part_of` hierarchy</li></ol>\n<ul><li>sub-period/activity linked to a broader parent period/activity via `part_of`.</li></ul>\n<ol><li>`during` inclusion</li></ol>\n<ul><li>event/activity linked as occurring `during` a period.</li></ul>\n<ol><li>Relative ordering without exact date</li></ol>\n<ul><li>production or activity with `before`/`after` relation to another event.</li></ul>\n<p>---</p>\n<h2 id=\"round-20-addendum-about-vocabulary-terms\">Round 20 Addendum — About Vocabulary Terms</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: About Vocabulary Terms</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Linked Art relies on vocabulary reuse for semantic interoperability across broad classes.</li><li>Class-level interoperability alone is insufficient; classification-term interoperability is required for comparable analytics and UX.</li><li>Vocabulary requirement classes:</li><li>required terms: mandatory for Linked Art conformance</li><li>recommended terms: expected unless a concrete reason prevents use</li><li>optional terms: available but not compulsory</li><li>Acceptable vocabulary-linking patterns for conformance:</li><li>direct vocabulary URI in `id`</li><li>local/intermediary concept in `id` with external vocabulary URI in `equivalent`</li><li>Vocabulary list change policy:</li><li>required list: changed/removed only in major versions; additions may arrive in minor versions</li><li>recommended list: may change in minor versions</li><li>optional list: informational, can change anytime</li></ul>\n<h3 id=\"implementation-mapping-vocabulary-terms\">Implementation Mapping — Vocabulary Terms</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Requirement-class awareness</li></ol>\n<ul><li>Treat required terms as conformance-critical in validation and import checks.</li></ul>\n<ol><li>Stable mapping strategy</li></ol>\n<ul><li>Support both direct-`id` and `equivalent`-bridged vocabulary linking without semantic loss.</li></ul>\n<ol><li>Local concept interoperability</li></ol>\n<ul><li>When local concepts are used, preserve explicit `equivalent` links to canonical external terms.</li></ul>\n<ol><li>Non-destructive normalization</li></ol>\n<ul><li>Do not rewrite local concept IDs to external IDs if local records carry additional context; preserve both layers.</li></ul>\n<ol><li>Version-aware validation</li></ol>\n<ul><li>Design validators to handle evolving recommended/optional lists without breaking prior data unnecessarily.</li></ul>\n<ol><li>Classifier consistency</li></ol>\n<ul><li>Preserve `classified_as` arrays in source order and content; avoid silent dropping of unknown-yet-valid terms.</li></ul>\n<h3 id=\"tdd-additions-vocabulary-terms\">TDD Additions — Vocabulary Terms</h3>\n<p>Add failing-first tests for vocabulary conformance workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates required-term usage for constrained fields where Linked Art mandates specific terms</li><li>validates `classified_as` references with direct vocabulary URIs</li><li>validates local term records with `equivalent` references to canonical vocab terms</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves both vocabulary-link patterns (`id` direct vs `equivalent` bridge)</li><li>preserves local concept metadata while retaining external semantic anchors</li><li>does not downgrade required/recommended classification references during normalization</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain vocabulary semantics and do not collapse intermediary concepts</li><li>validation responses clearly distinguish required-term failures from recommended-term advisories</li><li>canonical `_source.raw` vocabulary links remain unchanged</li></ul>\n<p>Regression:</p>\n<ul><li>introducing new recommended terms does not break existing records that remain conformant</li><li>analytics/classification faceting still resolves equivalent-linked local concepts correctly</li></ul>\n<h3 id=\"fixture-anchors-vocabulary-terms-examples\">Fixture Anchors — Vocabulary Terms Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Direct vocabulary ID usage</li></ol>\n<ul><li>object classification where `classified_as[].id` is canonical external vocabulary URI.</li></ul>\n<ol><li>Local term with equivalent mapping</li></ol>\n<ul><li>object classification where local concept `id` includes `equivalent` to canonical external vocabulary URI.</li></ul>\n<ol><li>Mixed dataset compatibility</li></ol>\n<ul><li>dataset fixtures containing both patterns; tests assert consistent downstream classification behavior.</li></ul>\n<p>---</p>\n<h2 id=\"round-21-addendum-required-terms\">Round 21 Addendum — Required Terms</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Required Terms</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Required terms are conformance-critical: when the concept is present, the required URI must be used.</li><li>Not every record must contain every required term; requirement applies when the modeled concept exists.</li><li>Full URI form must be used in data payloads.</li><li>Required term coverage includes:</li><li>Name/identifier control terms (primary name, display name, sort name, sort value)</li><li>Meta-type control terms (statement, type of work, style, shape, occupation, nationality)</li><li>Color classification on `Dimension`</li><li>Activity flags (exhibition, provenance, professional, publication, promise)</li><li>Broad item flags (collection item, artwork)</li><li>Required term link style can be either:</li><li>direct vocabulary URI in `id`</li><li>intermediary/local term with canonical URI in `equivalent`</li><li>Term-list version policy differs by requirement class; required list is stricter and changes more conservatively.</li></ul>\n<h3 id=\"implementation-mapping-required-terms\">Implementation Mapping — Required Terms</h3>\n<p>Apply these requirements to adapters, normalization, validation, and route outputs:</p>\n<ol><li>Required-term enforcement</li></ol>\n<ul><li>Validate required URI usage whenever corresponding concepts are asserted in records.</li></ul>\n<ol><li>URI canonicalization policy</li></ol>\n<ul><li>Preserve full canonical URIs in stored/served data; avoid namespace shorthand in canonical JSON-LD payloads.</li></ul>\n<ol><li>Equivalent-bridge acceptance</li></ol>\n<ul><li>Accept intermediary/local term IDs when canonical required term appears in `equivalent`.</li></ul>\n<ol><li>Name term semantics</li></ol>\n<ul><li>Preserve:</li><li>primary names for core display identity</li><li>display names for UI labeling</li><li>sort name/sort value for ordering logic</li><li>Enforce uniqueness constraints where modeled (for example, one sort value per entity).</li></ul>\n<ol><li>Meta-type correctness</li></ol>\n<ul><li>Preserve meta-type classifications that disambiguate statement/type-of-work/style/shape/nationality/occupation semantics.</li></ul>\n<ol><li>Activity flag correctness</li></ol>\n<ul><li>Preserve required activity classifications for exhibition/provenance/professional/publication/promise contexts.</li></ul>\n<ol><li>Color-dimension rule</li></ol>\n<ul><li>Preserve required color classification on `Dimension` when color is modeled.</li></ul>\n<ol><li>Item-flag preservation</li></ol>\n<ul><li>Preserve collection-item/artwork flags where explicitly present; do not infer silently without evidence.</li></ul>\n<h3 id=\"tdd-additions-required-terms\">TDD Additions — Required Terms</h3>\n<p>Add failing-first tests for required-term conformance workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates required term URIs on:</li><li>primary/display/sort names and sort identifiers</li><li>required activity classifications</li><li>required meta-type classifications</li><li>color dimensions and collection/artwork flags when present</li><li>validates intermediary+equivalent pattern as conformant alternative to direct URI IDs</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves required-term classifications through normalization</li><li>preserves sort-name/sort-value semantics and cardinality expectations</li><li>does not remap required terms to non-canonical alternatives</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import validation distinguishes:</li><li>required-term failures (hard errors)</li><li>recommended/optional advisories (non-blocking)</li><li>outputs retain required-term URIs and equivalent bridges unchanged</li><li>canonical `_source.raw` is not rewritten destructively during term normalization</li></ul>\n<p>Regression:</p>\n<ul><li>evolving recommended/optional term lists do not break required-term validations</li><li>faceting/search keyed on required terms remains stable across providers</li></ul>\n<h3 id=\"fixture-anchors-required-terms-examples\">Fixture Anchors — Required Terms Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Primary name + language</li></ol>\n<ul><li>entity with `Name` classified as primary name and language notation.</li></ul>\n<ol><li>Display name on statement/timespan</li></ol>\n<ul><li>display-name classification used as UI label for statement or timespan.</li></ul>\n<ol><li>Sort name and sort value</li></ol>\n<ul><li>separate fixtures for linguistic sort name and non-linguistic sort value.</li></ul>\n<ol><li>Meta-type disambiguation</li></ol>\n<ul><li>statement/type-of-work/style/shape/nationality/occupation classifications.</li></ul>\n<ol><li>Color dimension</li></ol>\n<ul><li>`Dimension` with required color classification and optional numeric/unit payload.</li></ul>\n<ol><li>Activity flags</li></ol>\n<ul><li>exhibition/provenance/publication/professional/promise activity classifications.</li></ul>\n<ol><li>Collection and artwork flags</li></ol>\n<ul><li>object-level required flags for collection-item/artwork categorization.</li></ul>\n<ol><li>Equivalent-bridge conformance</li></ol>\n<ul><li>intermediary local term with canonical required URI in `equivalent`.</li></ul>\n<p>---</p>\n<h2 id=\"round-22-addendum-recommended-terms\">Round 22 Addendum — Recommended Terms</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Recommended Terms</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Recommended terms are strongly advised for interoperability but are not strict conformance blockers.</li><li>Diverging from recommended terms remains valid Linked Art, but should be deliberate and documented.</li><li>Recommended term clusters include:</li><li>name types (alternate/given/middle/family/former)</li><li>identifier types (accession/local/system/call numbers)</li><li>statement types (note/description/materials/provenance/rights/etc.) with statement meta-type usage</li><li>object/place/group/digital/set/dimension type vocabularies</li><li>common instances (languages, units, materials, currencies, nationalities, occupations, shapes)</li><li>Many recommended entries rely on meta-type patterns (for example, nationality/occupation/shape).</li><li>Bias and domain skew may exist in current recommended lists; extension and feedback are expected parts of ecosystem evolution.</li></ul>\n<h3 id=\"implementation-mapping-recommended-terms\">Implementation Mapping — Recommended Terms</h3>\n<p>Apply these requirements to adapters, normalization, validation, and route outputs:</p>\n<ol><li>Advisory-term support</li></ol>\n<ul><li>Prefer recommended terms when mapping known source semantics, unless source fidelity requires an alternate concept.</li></ul>\n<ol><li>Non-blocking validation behavior</li></ol>\n<ul><li>Treat recommended-term deviations as advisories/warnings, not hard conformance failures.</li></ul>\n<ol><li>Meta-type preservation</li></ol>\n<ul><li>Preserve recommended meta-type structures when present (statement/object/shape/nationality/occupation families).</li></ul>\n<ol><li>Controlled fallback strategy</li></ol>\n<ul><li>When exact recommended terms are unavailable, preserve source concept + include `equivalent` anchors where possible.</li></ul>\n<ol><li>Domain-set consistency</li></ol>\n<ul><li>Maintain stable mappings for commonly recurring domains:</li><li>language</li><li>units</li><li>materials</li><li>currencies</li><li>nationalities</li><li>occupations</li><li>shapes</li></ul>\n<ol><li>Explainable mapping</li></ol>\n<ul><li>Capture mapping rationale in adapter tests/docs when intentionally choosing non-recommended terms.</li></ul>\n<ol><li>Upgrade resilience</li></ol>\n<ul><li>Keep recommended-term checks version-tolerant so list updates do not create unnecessary breakages.</li></ul>\n<h3 id=\"tdd-additions-recommended-terms\">TDD Additions — Recommended Terms</h3>\n<p>Add failing-first tests for recommended-term interoperability workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates structure of recommended-term classifications where used</li><li>validates statement meta-type patterns for statement categories</li><li>permits alternative non-recommended concepts while emitting advisory results</li></ul>\n<p>Adapter-level:</p>\n<ul><li>maps common provider terms to recommended vocabulary when high-confidence matches exist</li><li>preserves alternate/local terms with equivalence links instead of destructive remapping</li><li>preserves recommended domain-instance references (language/unit/material/currency, etc.) when source provides them</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs include recommended-term advisories when alternatives are used</li><li>routes distinguish required failures from recommended-term warnings clearly</li><li>canonical `_source.raw` remains unchanged by advisory remapping logic</li></ul>\n<p>Regression:</p>\n<ul><li>introducing new recommended mappings does not break older records</li><li>classification facets remain stable for both recommended and equivalent-linked local terms</li></ul>\n<h3 id=\"fixture-anchors-recommended-terms-examples\">Fixture Anchors — Recommended Terms Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Name-type variants</li></ol>\n<ul><li>records with alternate/given/middle/family/sort-like name patterns.</li></ul>\n<ol><li>Identifier-type variants</li></ol>\n<ul><li>records with accession/local/system/call identifiers.</li></ul>\n<ol><li>Statement-type families</li></ol>\n<ul><li>statement records covering materials/provenance/rights/description/etc. using statement meta-type pattern.</li></ul>\n<ol><li>Object/place/group/digital/set/dimension recommended types</li></ol>\n<ul><li>typed examples across each family for normalization/faceting tests.</li></ul>\n<ol><li>Common instance vocabularies</li></ol>\n<ul><li>fixtures for language/unit/material/currency/nationality/occupation/shape references.</li></ul>\n<ol><li>Intentional non-recommended alternative</li></ol>\n<ul><li>fixture proving advisory behavior with no hard validation failure.</li></ul>\n<p>---</p>\n<h2 id=\"round-23-addendum-optional-terms\">Round 23 Addendum — Optional Terms</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Optional Terms</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Optional terms are interoperability helpers, not conformance requirements.</li><li>They are useful defaults and discovery aids for mapping, but alternatives are fully acceptable.</li><li>Optional-term lists may evolve ad hoc and are suitable for extension, including bias-mitigation additions.</li><li>Optional term families include:</li><li>name types (translated title, subtitle, alias, pseudonym)</li><li>identifier/contact types (auction lot number, DOI/ISBN/ISSN, email/street/phone/fax)</li><li>statement/document/object/place/group/part/dimension type vocabularies</li><li>Optional terms should improve cross-dataset usability when adopted consistently, but must not become hidden hard requirements.</li></ul>\n<h3 id=\"implementation-mapping-optional-terms\">Implementation Mapping — Optional Terms</h3>\n<p>Apply these requirements to adapters, normalization, validation, and route outputs:</p>\n<ol><li>Strictly non-blocking semantics</li></ol>\n<ul><li>Treat optional-term mismatches or absences as informational only, never as hard validation failures.</li></ul>\n<ol><li>Interop-first preference</li></ol>\n<ul><li>Prefer optional terms when there is no better source-specific mapping requirement.</li></ul>\n<ol><li>Transparent alternatives</li></ol>\n<ul><li>Preserve alternate local/external terms without forced substitution; include equivalence links where feasible.</li></ul>\n<ol><li>Family-level consistency</li></ol>\n<ul><li>Keep optional term use consistent within each domain family (for example, document types, object part types, contact identifiers).</li></ul>\n<ol><li>Mapping explainability</li></ol>\n<ul><li>Document adapter mapping rationale when intentionally diverging from optional-term suggestions.</li></ul>\n<ol><li>Future-list tolerance</li></ol>\n<ul><li>Keep optional-term handling resilient to list additions/removals without schema breakages.</li></ul>\n<h3 id=\"tdd-additions-optional-terms\">TDD Additions — Optional Terms</h3>\n<p>Add failing-first tests for optional-term interoperability workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates optional-term structures when present</li><li>confirms missing optional terms do not fail validation</li><li>confirms alternate terms can coexist with valid optional-term usage</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves optional term classifications when source provides them</li><li>preserves non-optional alternatives without data loss or invalid coercion</li><li>preserves contact/document/part/dimension optional type semantics where provided</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs expose optional-term advisories as informational hints only</li><li>routes do not escalate optional-term differences into blocking errors</li><li>canonical `_source.raw` remains unchanged by optional-term normalization suggestions</li></ul>\n<p>Regression:</p>\n<ul><li>adopting new optional mappings does not alter existing required/recommended validation outcomes</li><li>faceting/classification logic remains stable across mixed optional-term adoption patterns</li></ul>\n<h3 id=\"fixture-anchors-optional-terms-examples\">Fixture Anchors — Optional Terms Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Optional name types</li></ol>\n<ul><li>translated title/sub-title/alias/pseudonym name-classification examples.</li></ul>\n<ol><li>Optional identifier and contact types</li></ol>\n<ul><li>DOI/ISBN/ISSN/lot number plus email/street/telephone/fax contact identifiers.</li></ul>\n<ol><li>Optional statement and document types</li></ol>\n<ul><li>representative statement classes and document-classification examples.</li></ul>\n<ol><li>Optional place/group/object/part/dimension types</li></ol>\n<ul><li>typed examples across these families for advisory mapping behavior tests.</li></ul>\n<ol><li>Alternative-term coexistence</li></ol>\n<ul><li>fixture with non-optional alternative term proving non-blocking validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-24-addendum-textual-documents\">Round 24 Addendum — Textual Documents</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Textual Documents</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Text modeling distinguishes:</li><li>physical/digital carriers (`HumanMadeObject`/`DigitalObject`)</li><li>textual content (`LinguisticObject`)</li><li>A single `LinguisticObject` can be carried by many carriers (`carries` / `digitally_carried_by` patterns).</li><li>Scope target is pragmatic bibliographic interoperability, not full FRBR/LRM/BibFrame complexity.</li><li>Common text features include:</li><li>type/classification of textual work</li><li>names and identifiers</li><li>language</li><li>descriptive statements</li><li>Text lifecycle often includes:</li><li>`created_by` for authorship/creation</li><li>publishing activity in `used_for` with required publication activity classification</li><li>Textual structure uses partitioning:</li><li>chapter/article/issue/volume hierarchies via `part_of`</li><li>Pagination/foliation can be represented:</li><li>as statements (human-readable ranges)</li><li>as structured dimension counts (computable)</li><li>Texts can be `about` other core entities (objects, people, places, etc.).</li><li>Abstract-work alignment:</li><li>textual content can be linked to higher-level conceptual abstraction (`PropositionalObject`) via `part_of`.</li></ul>\n<h3 id=\"implementation-mapping-textual-documents\">Implementation Mapping — Textual Documents</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Carrier/content separation</li></ol>\n<ul><li>Preserve distinction between text carriers and textual content entities.</li></ul>\n<ol><li>Shared-content linkage</li></ol>\n<ul><li>Preserve links from multiple carriers to shared `LinguisticObject` content records.</li></ul>\n<ol><li>Bibliographic identity</li></ol>\n<ul><li>Preserve textual names/identifiers/language and work-type classifications.</li></ul>\n<ol><li>Creation vs publication split</li></ol>\n<ul><li>Preserve authorship creation (`created_by`) separately from publishing activities (`used_for`).</li></ul>\n<ol><li>Structural hierarchy</li></ol>\n<ul><li>Preserve chapter/article/issue/volume partitioning via `part_of` where available.</li></ul>\n<ol><li>Pagination dual pattern</li></ol>\n<ul><li>Preserve both statement-style pagination and structured page-count dimensions when provided.</li></ul>\n<ol><li>Aboutness integrity</li></ol>\n<ul><li>Preserve `about` links to core entities without substituting with string-only references.</li></ul>\n<ol><li>Abstract-work linkage</li></ol>\n<ul><li>Preserve conceptual `part_of` links from `LinguisticObject` to `PropositionalObject` where modeled.</li></ul>\n<h3 id=\"tdd-additions-textual-documents\">TDD Additions — Textual Documents</h3>\n<p>Add failing-first tests for textual-document workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `LinguisticObject` identity/classification/name/identifier/language structures</li><li>validates carrier-to-content links (`carries` and/or digital carry patterns)</li><li>validates publication activity embedding in `used_for` and creation activity in `created_by`</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves carrier/content separation and shared-content linkage</li><li>preserves textual structure (`part_of`) for sub-documents</li><li>preserves pagination statement and count-dimension structures</li><li>preserves `about` links and abstract-work part-of references</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain textual-document modeling patterns without flattening</li><li>routes do not collapse conceptual/abstract links into plain labels</li><li>canonical `_source.raw` text structures remain unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>text modeling enhancements do not break digital-object modeling or concept mappings</li><li>object-centric views continue to resolve related textual references correctly</li></ul>\n<h3 id=\"fixture-anchors-textual-documents-examples\">Fixture Anchors — Textual Documents Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Physical carrier with textual content link</li></ol>\n<ul><li>`HumanMadeObject` book record carrying a `LinguisticObject`.</li></ul>\n<ol><li>Linguistic content core record</li></ol>\n<ul><li>monograph-classified `LinguisticObject` with names, identifiers, and language.</li></ul>\n<ol><li>Authorship + publication</li></ol>\n<ul><li>`created_by` authorship activity plus publishing `used_for` activity.</li></ul>\n<ol><li>Document structure</li></ol>\n<ul><li>chapter `LinguisticObject` `part_of` larger textual work.</li></ul>\n<ol><li>Pagination and page count</li></ol>\n<ul><li>pagination statement plus computable page-count dimension.</li></ul>\n<ol><li>Aboutness</li></ol>\n<ul><li>`LinguisticObject` `about` linked core entity.</li></ul>\n<ol><li>Abstract-work link</li></ol>\n<ul><li>textual content `part_of` conceptual `PropositionalObject`.</li></ul>\n<p>---</p>\n<h2 id=\"round-25-addendum-archival-hierarchies\">Round 25 Addendum — Archival Hierarchies</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Archival Hierarchies</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Archives are modeled primarily as conceptual hierarchies of `Set` entities.</li><li>Archival intellectual arrangement is distinct from physical containment.</li><li>Conceptual hierarchy pattern:</li><li>archival items (typically `HumanMadeObject`/`DigitalObject`) are `member_of` archival sets</li><li>archival sets can be `member_of` broader archival sets (sub-series -&gt; series -&gt; fonds ...)</li><li>no fixed depth limit; graph allows multi-membership across hierarchies</li><li>Physical containment alignment pattern:</li><li>archival set -&gt; `members_contained_by` -&gt; physical container object</li><li>individual item -&gt; `held_or_supported_by` -&gt; physical container object</li><li>Ordering of members follows the same set-ordering patterns as other `Set` use cases.</li><li>Shared/member-common description can use `members_exemplified_by`; textual statements remain acceptable for many archival descriptions.</li></ul>\n<h3 id=\"implementation-mapping-archival-hierarchies\">Implementation Mapping — Archival Hierarchies</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Conceptual/physical split</li></ol>\n<ul><li>Preserve conceptual membership (`member_of` set hierarchy) separately from physical containment (`members_contained_by`, `held_or_supported_by`).</li></ul>\n<ol><li>Hierarchy depth support</li></ol>\n<ul><li>Preserve arbitrary-depth set-to-set hierarchies without flattening.</li></ul>\n<ol><li>Multi-membership support</li></ol>\n<ul><li>Allow items/sets to participate in multiple conceptual archival sets when source data indicates this.</li></ul>\n<ol><li>Container linkage fidelity</li></ol>\n<ul><li>Preserve links between archival sets and container objects, and between items and physical containers.</li></ul>\n<ol><li>Archival type preservation</li></ol>\n<ul><li>Preserve archival grouping/sub-grouping classifications on sets when present.</li></ul>\n<ol><li>Description strategy compatibility</li></ol>\n<ul><li>Preserve both structured collective descriptors (`members_exemplified_by`) and statement-based archival notes.</li></ul>\n<ol><li>Ordering compatibility</li></ol>\n<ul><li>Preserve sort-value and ordering metadata for archival members where provided.</li></ul>\n<h3 id=\"tdd-additions-archival-hierarchies\">TDD Additions — Archival Hierarchies</h3>\n<p>Add failing-first tests for archival workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates archival set hierarchy structures (`Set` + `member_of`)</li><li>validates physical-alignment properties (`members_contained_by`, `held_or_supported_by`)</li><li>validates archival grouping classifications when present</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves conceptual hierarchy depth and item membership</li><li>preserves physical container links without collapsing into conceptual hierarchy</li><li>preserves collective member descriptors and/or statements</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain both conceptual and physical hierarchy structures</li><li>routes do not infer conceptual membership solely from physical containment</li><li>canonical `_source.raw` archival hierarchy data remains unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>collection/set features (ordering, prototypes) remain compatible with archival sets</li><li>object-centric views still resolve both archival set membership and container placement</li></ul>\n<h3 id=\"fixture-anchors-archival-hierarchies-examples\">Fixture Anchors — Archival Hierarchies Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Archival item membership</li></ol>\n<ul><li>item `HumanMadeObject` `member_of` archival sub-series set.</li></ul>\n<ol><li>Sub-series to series linkage</li></ol>\n<ul><li>archival sub-grouping `Set` `member_of` archival grouping set.</li></ul>\n<ol><li>Physical alignment at set level</li></ol>\n<ul><li>archival set with `members_contained_by` archival box object.</li></ul>\n<ol><li>Physical alignment at item level</li></ol>\n<ul><li>archival item with `held_or_supported_by` same archival box object.</li></ul>\n<ol><li>Mixed conceptual + physical graph</li></ol>\n<ul><li>fixture where conceptual set hierarchy and physical container hierarchy coexist and must not be conflated.</li></ul>\n<p>---</p>\n<h2 id=\"round-26-addendum-specific-assertions\">Round 26 Addendum — Specific Assertions</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Specific Assertions</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>`AttributeAssignment` is used for historically contingent, uncertain, context-specific, or otherwise non-primary assertions.</li><li>Keep use minimal because assertion reification adds complexity and query burden.</li><li>Core assignment pattern (`attributed_by` on subject):</li><li>subject entity has `attributed_by` -&gt; `AttributeAssignment`</li><li>assignment carries `assigned_property` (predicate)</li><li>assignment carries `assigned` (object/value entity)</li><li>Inverse/value-centered pattern (`assigned_by` on value):</li><li>useful for value entities such as identifiers/dimensions</li><li>helps encode who assigned a specific value (for example, institution-specific accession numbers)</li><li>Source-of-knowledge pattern:</li><li>assignment references authority witness via `used_specific_object` (entity reference, not plain citation string)</li><li>Embedded statement provenance/rights:</li><li>statements may carry `created_by`, `technique`, timespan, and `subject_to` rights</li><li>AI-origin metadata can be represented via statement/creation classifications/techniques</li><li>Uncertain/former assertions:</li><li>can target embedded production/activity nodes for &quot;possibly by&quot;/former-attribution scenarios</li><li>Context-specific assertions:</li><li>exhibition- or project-specific names/identifiers/descriptions should use `AttributeAssignment`</li><li>`caused_by` can bind assignment to contextual activity (for example, exhibition)</li><li>Unknown or unmodeled relationships:</li><li>`AttributeAssignment` can express relationship presence when precise model relation is unknown or unavailable</li><li>should be last resort after attempting explicit model properties</li></ul>\n<h3 id=\"implementation-mapping-specific-assertions\">Implementation Mapping — Specific Assertions</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Minimal-use policy</li></ol>\n<ul><li>Prefer direct model properties first; use `AttributeAssignment` only when direct expression is inadequate or historically/contextually incorrect.</li></ul>\n<ol><li>Subject/value direction correctness</li></ol>\n<ul><li>Preserve correct directionality for `attributed_by` vs `assigned_by` patterns depending on assertion use case.</li></ul>\n<ol><li>Triple integrity</li></ol>\n<ul><li>Preserve subject (`attributed_by` host), predicate (`assigned_property`), object (`assigned`) semantics explicitly.</li></ul>\n<ol><li>Context linkage</li></ol>\n<ul><li>Preserve `caused_by` and `part_of` links for context-bounded assertions.</li></ul>\n<ol><li>Source provenance fidelity</li></ol>\n<ul><li>Preserve `used_specific_object` references as source evidence entities.</li></ul>\n<ol><li>AI/rights annotation safety</li></ol>\n<ul><li>Preserve statement-level creation technique/time and rights markings without collapsing into global record-level assumptions.</li></ul>\n<ol><li>Uncertainty preservation</li></ol>\n<ul><li>Preserve uncertain/former assignments as assertions; do not auto-promote into canonical fact fields.</li></ul>\n<ol><li>Relationship-fallback restraint</li></ol>\n<ul><li>Use related-entity assertion patterns only when explicit relationship predicates are unavailable.</li></ul>\n<h3 id=\"tdd-additions-specific-assertions\">TDD Additions — Specific Assertions</h3>\n<p>Add failing-first tests for specific-assertion workflows:</p>\n<p>Contract-level:</p>\n<ul><li>validates `AttributeAssignment` structures for both subject-side and value-side patterns</li><li>validates `assigned_property`, `assigned`, `used_specific_object`, and contextual links when present</li><li>rejects malformed assertion triples and invalid assignment payloads</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves assertion directionality and context/source links</li><li>preserves exhibition-specific and uncertainty-specific assertions without canonical overwrite</li><li>preserves AI/rights statement metadata attached to embedded linguistic content</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain assertion structures and relation context</li><li>routes do not flatten assertions into canonical direct properties unless explicitly instructed by migration logic</li><li>canonical `_source.raw` assertion history remains unmutated</li></ul>\n<p>Regression:</p>\n<ul><li>assertion enrichment does not break baseline property queries for current state</li><li>related-entity fallback assertions do not replace explicit relationships when those are present</li></ul>\n<h3 id=\"fixture-anchors-specific-assertions-examples\">Fixture Anchors — Specific Assertions Examples</h3>\n<p>Use these official-example patterns as fixture seeds:</p>\n<ol><li>Subject-side assignment triple</li></ol>\n<ul><li>entity `attributed_by` assignment with `assigned_property` + `assigned` value.</li></ul>\n<ol><li>Value-side assignment provenance</li></ol>\n<ul><li>identifier with `assigned_by` assignment pointing to assigning institution/actor.</li></ul>\n<ol><li>Source-backed name assertion</li></ol>\n<ul><li>name with `assigned_by.used_specific_object` referencing source text entity.</li></ul>\n<ol><li>AI-generated embedded statement</li></ol>\n<ul><li>statement with AI-related classification/technique, creation timestamp, and statement-level rights.</li></ul>\n<ol><li>Uncertain production attribution</li></ol>\n<ul><li>production node with attributed assignment carrying &quot;possibly by&quot; classification and assigned production part.</li></ul>\n<ol><li>Context-specific exhibition identifier</li></ol>\n<ul><li>object-level assertion assigning exhibition-specific identifier with `caused_by` exhibition activity.</li></ul>\n<ol><li>Related/unmodeled entity fallback</li></ol>\n<ul><li>attribute assignment used for &quot;related object&quot; / social relationship fallback when explicit model predicate is unavailable.</li></ul>\n<p>---</p>\n<h2 id=\"round-27-addendum-profile\">Round 27 Addendum — Profile</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Profile</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ol><li>Scope through shared use cases and real world data.</li></ol>\n<ol><li>Select solutions that are as simple as possible and no simpler.</li></ol>\n<ol><li>Intelligently manage addition of complexity.</li></ol>\n<ol><li>Avoid dependency on specific technologies.</li></ol>\n<ol><li>Follow linked-data principles and best practices.</li></ol>\n<ol><li>Design for JSON-LD first.</li></ol>\n<ol><li>Define success, not failure.</li></ol>\n<ul><li>Linked Art is an intentionally reduced application profile of CIDOC-CRM:</li><li>targeted practical coverage for most real-world museum use cases</li><li>reduced ontology complexity to improve implementation and interoperability</li><li>Core mission emphasizes:</li><li>event-based cultural heritage publication for research and general developers</li><li>shared models plus shared software patterns to lower producer/consumer burden</li><li>Design posture is explicitly:</li><li>iterative</li><li>responsive</li><li>responsible</li><li>collaborative</li><li>Seven profile design principles govern modeling decisions:</li><li>Practical implications for implementers:</li><li>no class/property without concrete use case data</li><li>strong preference for reuse over new terms/extensions</li><li>avoid unnecessary multiple instantiation complexity</li><li>support simple &quot;minimum viable&quot; publishing first, with optional expansions</li><li>remain transformable between JSON-LD and RDF triples without information loss</li><li>avoid CIDOC-CRM features that conflict with core linked-data practice</li></ul>\n<h3 id=\"implementation-mapping-profile\">Implementation Mapping — Profile</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Use-case-first modeling gate</li></ol>\n<ul><li>New provider mappings must tie each non-trivial class/property to a documented museum use case and sample payload.</li></ul>\n<ol><li>Simplicity-first adapter behavior</li></ol>\n<ul><li>Prefer direct baseline Linked Art patterns in normalized output.</li><li>Add complex expansions only when required by explicit source evidence.</li></ul>\n<ol><li>Reuse-before-extension rule</li></ol>\n<ul><li>Reuse Linked Art and existing CRM-aligned structures before adding local extension fields.</li><li>Any local extension must be documented in contracts and roadmap with rationale.</li></ul>\n<ol><li>JSON-LD-first output contract</li></ol>\n<ul><li>Canonical route payloads must remain valid JSON-LD oriented structures first, while still enabling RDF materialization.</li></ul>\n<ol><li>Technology-neutral core</li></ol>\n<ul><li>Source adapters must avoid coupling business logic to a single graph store or query technology.</li><li>Model semantics remain stable regardless of storage backend (files/Postgres/graph layer).</li></ul>\n<ol><li>Expansion layering discipline</li></ol>\n<ul><li>Keep &quot;current/baseline fact&quot; fields straightforward.</li><li>Hang uncertainty/history/context in additive expansions without forcing all clients to parse them.</li></ul>\n<ol><li>Success-pattern conformance</li></ol>\n<ul><li>Treat official profile patterns as positive conformance targets; non-profile source fields may be preserved under `_source.raw` without breaking canonical model output.</li></ul>\n<h3 id=\"tdd-additions-profile\">TDD Additions — Profile</h3>\n<p>Add failing-first tests for profile-conformance guardrails:</p>\n<p>Contract-level:</p>\n<ul><li>validates canonical JSON-LD structure for normalized entities against profile-aligned contracts</li><li>validates that extension fields are namespaced and documented when present</li><li>rejects unsupported &quot;invented&quot; relationship fields in canonical model zone</li></ul>\n<p>Adapter-level:</p>\n<ul><li>verifies baseline/simple pattern output exists for each supported provider slice</li><li>verifies optional expansions do not overwrite or obscure baseline fields</li><li>verifies round-trip integrity from source -&gt; normalized JSON-LD -&gt; RDF transform path (shape-level/no-loss checks)</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import responses expose canonical profile-first shape with optional expansion blocks</li><li>routes preserve raw provider payloads under `_source.raw` for audit/debug without polluting canonical fields</li><li>unsupported source constructs degrade gracefully into raw/annotation zones rather than malformed canonical nodes</li></ul>\n<p>Regression:</p>\n<ul><li>introducing a new provider does not regress existing Linked Art conformance fixtures</li><li>conformance suite blocks accidental drift into over-complex local ontology fragments</li></ul>\n<h3 id=\"fixture-anchors-profile-examples\">Fixture Anchors — Profile Examples</h3>\n<p>Use these official-profile principles as fixture seeds:</p>\n<ol><li>Shared use case evidence fixture</li></ol>\n<ul><li>each advanced mapping test references an explicit use case ID + real sample payload.</li></ul>\n<ol><li>Simplicity baseline fixture</li></ol>\n<ul><li>same source record emits a simple canonical representation with optional expansion kept separate.</li></ul>\n<ol><li>Reuse over extension fixture</li></ol>\n<ul><li>provider-specific nuance modeled via existing Linked Art/CRM patterns, not ad hoc canonical fields.</li></ul>\n<ol><li>JSON-LD first fixture</li></ol>\n<ul><li>normalized output validates as JSON-LD object graph and remains transformable to triples.</li></ul>\n<ol><li>Technology-independence fixture</li></ol>\n<ul><li>identical normalized semantics pass with file-backed and Postgres-backed storage implementations.</li></ul>\n<ol><li>Success-not-failure fixture</li></ol>\n<ul><li>out-of-scope source details retained in `_source.raw`, while canonical profile section remains valid.</li></ul>\n<p>---</p>\n<h2 id=\"round-28-addendum-linked-art-terms-ontology-rdf-extensions\">Round 28 Addendum — Linked Art Terms Ontology (RDF Extensions)</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art terms ontology serialization (`https://linked.art/ns/terms/`) as RDF/XML excerpt</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>The RDF terms file defines practical Linked Art extensions and profile conveniences over base CIDOC-CRM.</li><li>Confirmed active terms/classes include:</li><li>assertion support: `property_classified_as` (for dot-one style semantics via `AttributeAssignment`)</li><li>custody convenience: `current_permanent_custodian` and inverse</li><li>identity equivalence: `equivalent` (explicitly avoiding `skos:exactMatch` inference side effects)</li><li>generalized transfer model:</li><li>class `Transfer` with `transferred`, `transferred_from`, `transferred_to`</li><li>subclasses include `Acquisition`, `Move`, `Transfer_of_Custody`</li><li>payment specialization via `Payment` + `paid_amount` / `paid_from` / `paid_to`</li><li>set and membership model:</li><li>class `Set`, membership relations (`has_member`, `member_of`)</li><li>exemplar/containment helpers (`members_exemplified_by`, `members_contained_by`, `contains_members_of`)</li><li>lifecycle activities: `Addition`/`Removal` with directional member and set links</li><li>digital object relations:</li><li>`digitally_carries`, `digitally_shows`</li><li>`access_point`</li><li>`DigitalService` + `digitally_available_via` / `digitally_makes_available`</li><li>rights transfer:</li><li>`RightAcquisition`</li><li>`establishes`/`established_by`, `invalidates`/`invalidated_by`</li><li>The excerpt also contains a commented `Phase` model block marked as not currently used in profile and therefore non-normative for current conformance.</li></ul>\n<h3 id=\"implementation-mapping-terms-ontology\">Implementation Mapping — Terms Ontology</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Active-terms allowlist</li></ol>\n<ul><li>Treat the listed active classes/properties as permitted canonical vocabulary in normalized Linked Art output.</li></ul>\n<ol><li>Inverse-aware graph handling</li></ol>\n<ul><li>Preserve inverse-capable relationship semantics in canonical storage/query layers without forcing both directions into payloads.</li></ul>\n<ol><li>Transfer abstraction discipline</li></ol>\n<ul><li>Support `Transfer` as a first-class unknown/abstract exchange pattern; avoid coercing ambiguous transfers into acquisition/custody/move when evidence is insufficient.</li></ul>\n<ol><li>Set lifecycle fidelity</li></ol>\n<ul><li>Preserve `Addition`/`Removal` events and directional membership properties to model collection/list evolution over time.</li></ul>\n<ol><li>Digital relation fidelity</li></ol>\n<ul><li>Preserve separation between digital carrier/content/display/service/access-point semantics for IIIF and other provider integrations.</li></ul>\n<ol><li>Rights transition semantics</li></ol>\n<ul><li>Preserve rights establishment and invalidation as explicit activity-driven state changes.</li></ul>\n<ol><li>Non-normative block protection</li></ol>\n<ul><li>Do not implement commented `Phase` terms as required behavior in current provider slices unless roadmap explicitly activates that scope.</li></ul>\n<h3 id=\"tdd-additions-terms-ontology\">TDD Additions — Terms Ontology</h3>\n<p>Add failing-first tests for ontology-term conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates acceptance of active `la:` terms in canonical contract schemas</li><li>validates inverse-capable properties as semantically paired where applicable</li><li>rejects/flags non-profile commented terms as required fields</li></ul>\n<p>Adapter-level:</p>\n<ul><li>preserves ambiguous exchange as `Transfer` when subtype is unknown</li><li>preserves set membership change events (`Addition`/`Removal`) and directional links</li><li>preserves digital relations (`digitally_carries` vs `digitally_shows` vs `digitally_available_via`) without collapsing semantics</li><li>preserves rights transitions via `RightAcquisition` establish/invalidate pairs</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import outputs retain canonical `la:` term usage and source fidelity</li><li>routes do not flatten transfer, set-lifecycle, or rights-lifecycle structures into static snapshots only</li><li>canonical `_source.raw` retains original provider modeling where richer than canonical projection</li></ul>\n<p>Regression:</p>\n<ul><li>previously accepted object/provenance/digital fixtures continue passing with `la:` term allowlist enabled</li><li>no accidental introduction of inactive/commented ontology sections into required conformance gates</li></ul>\n<h3 id=\"fixture-anchors-terms-ontology-examples\">Fixture Anchors — Terms Ontology Examples</h3>\n<p>Use these ontology-backed patterns as fixture seeds:</p>\n<ol><li>Attribute-assignment property typing</li></ol>\n<ul><li>`AttributeAssignment` with `property_classified_as` term annotation.</li></ul>\n<ol><li>Permanent custodian snapshot</li></ol>\n<ul><li>object with `current_permanent_custodian` actor and inverse query check.</li></ul>\n<ol><li>Equivalent identity link</li></ol>\n<ul><li>entity pair linked with `equivalent` (non-SKOS inference-safe mapping).</li></ul>\n<ol><li>Abstract transfer</li></ol>\n<ul><li>ambiguous provenance handoff modeled as `Transfer` + transferred/from/to.</li></ul>\n<ol><li>Payment transfer part</li></ol>\n<ul><li>payment with amount/from/to linked under transfer activity context.</li></ul>\n<ol><li>Set membership lifecycle</li></ol>\n<ul><li>`Addition` adds member to set; `Removal` removes member from set; both directional relations asserted.</li></ul>\n<ol><li>Digital service publication</li></ol>\n<ul><li>digital object with `access_point`, `digitally_shows` visual item, and `digitally_available_via` digital service.</li></ul>\n<ol><li>Rights lifecycle</li></ol>\n<ul><li>`RightAcquisition` that `establishes` one right and `invalidates` another in transition scenario.</li></ul>\n<p>---</p>\n<h2 id=\"round-29-addendum-cidoc-crm-class-analysis-practical-utility-profile\">Round 29 Addendum — CIDOC-CRM Class Analysis (Practical Utility Profile)</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art Model 1.0: Class Analysis</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Class usage should be driven by practical interoperability and real dataset utility, not full ontology breadth.</li><li>Explicit classes-to-ignore guidance includes:</li><li>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`)</li><li>CRM datatype classes (`E59`, `E60`, `E61`, `E62`, `E94`, `E95`) in favor of RDF/XSD/native representations</li><li>overly specific/redundant classes best replaced with parent class + `P2_has_type` and external vocab</li><li>Strong simplification recommendations:</li><li>prefer `E13 Attribute Assignment` patterns over its narrow reification subclasses</li><li>prefer `Name` / `E33_E41 Linguistic Appellation` patterns for names/titles; keep `E42 Identifier` for identifiers</li><li>prefer `E36 Visual Item` for visual content; avoid deprecated/redundant visual subclasses</li><li>prefer Linked Art `Set` model for aggregations over controversial collection-specific CRM distinctions</li><li>Useful class set is explicitly identified and should anchor mapping priorities (for objects, provenance, activities, actors, places, dimensions, money, etc.).</li><li>Optional/not-currently-required classes can remain unsupported unless a concrete source use case appears.</li><li>`E30 Right` is treated as problematic in base CRM semantics; Linked Art’s practical right-acquisition/invalidation patterns are preferred for operational modeling.</li></ul>\n<h3 id=\"implementation-mapping-class-analysis\">Implementation Mapping — Class Analysis</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Canonical class allowlist</li></ol>\n<ul><li>Maintain a practical class allowlist aligned to the &quot;useful classes&quot; set and existing Linked Art profile terms.</li></ul>\n<ol><li>Ignore/redirect policy</li></ol>\n<ul><li>If source data carries ignored/overly specific classes, normalize to the recommended parent/pattern and preserve original typing in `_source.raw`.</li></ul>\n<ol><li>Datatype normalization</li></ol>\n<ul><li>Normalize CRM datatype-class usage into concrete literals (`xsd:string`, numeric/date types, etc.) and external geometry vocab when required.</li></ul>\n<ol><li>Set-first aggregation modeling</li></ol>\n<ul><li>Model collection-like groupings via Linked Art `Set` + type classification rather than forcing curated-holding subclasses.</li></ul>\n<ol><li>Visual/text distinction discipline</li></ol>\n<ul><li>Route visual manifestations to `VisualItem` patterns and inscriptions/text to linguistic-object patterns when evidence supports that split.</li></ul>\n<ol><li>Rights modeling guardrail</li></ol>\n<ul><li>For rights change semantics, prefer Linked Art right-acquisition lifecycle patterns over naive static-right assertions.</li></ul>\n<ol><li>Evidence-based expansion</li></ol>\n<ul><li>Support currently optional classes only when provider evidence and use-case docs justify them.</li></ul>\n<h3 id=\"tdd-additions-class-analysis\">TDD Additions — Class Analysis</h3>\n<p>Add failing-first tests for practical class-profile conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates canonical outputs only emit class types from the active practical allowlist</li><li>rejects direct emission of ignored abstract/datatype CRM classes in canonical projection</li><li>validates class remapping paths for known overly specific/deprecated source classes</li></ul>\n<p>Adapter-level:</p>\n<ul><li>source class variants normalize to profile-preferred classes without data loss</li><li>identifiers remain distinct from names/titles in normalized output</li><li>visual vs linguistic content splits are preserved according to source evidence</li><li>set aggregation outputs use `Set` semantics with typed classification</li></ul>\n<p>Route-level:</p>\n<ul><li>inspect/import responses include canonical remapped class model plus `_source.raw` for provenance</li><li>routes do not leak ignored/deprecated classes into top-level canonical payloads</li><li>rights-related provider data maps to right-lifecycle activity patterns where applicable</li></ul>\n<p>Regression:</p>\n<ul><li>existing provenance, digital, and vocabulary fixtures continue to pass under class allowlist enforcement</li><li>legacy fixtures with deprecated/over-specific typing remain ingestible via remap shims</li></ul>\n<h3 id=\"fixture-anchors-class-analysis-examples\">Fixture Anchors — Class Analysis Examples</h3>\n<p>Use these analysis-derived patterns as fixture seeds:</p>\n<ol><li>Datatype class replacement</li></ol>\n<ul><li>source payload using CRM datatype-class semantics normalized to concrete typed literals.</li></ul>\n<ol><li>Over-specific appellation collapse</li></ol>\n<ul><li>legacy title/name subclass mapped into `Name`/linguistic-appellation pattern; identifiers remain `Identifier`.</li></ul>\n<ol><li>Visual class collapse</li></ol>\n<ul><li>image/mark/inscription edge cases mapped to `VisualItem` or `LinguisticObject` per evidence.</li></ul>\n<ol><li>Set normalization</li></ol>\n<ul><li>curated-holding-like source mapped to Linked Art `Set` with vocabulary type.</li></ul>\n<ol><li>Abstract class suppression</li></ol>\n<ul><li>source carrying abstract hierarchy classes ingests successfully but canonical payload omits direct abstract class emissions.</li></ul>\n<ol><li>Rights lifecycle mapping</li></ol>\n<ul><li>source rights change represented via right-acquisition/invalidates pattern rather than static timeless right-only node.</li></ul>\n<p>---</p>\n<h2 id=\"round-30-addendum-linked-art-api-1-0-foundations\">Round 30 Addendum — Linked Art API 1.0 Foundations</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Introduction and API design fundamentals overview</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>The Linked Art model/profile is transport-agnostic; API conformance is a separate web interaction layer.</li><li>Core API expectation:</li><li>entity descriptions serialized as JSON-LD using Linked Art context</li><li>non-semantic HAL block for navigational/API affordance links</li><li>API surface areas called out:</li><li>Entity Description endpoints</li><li>Shared Data Structures</li><li>JSON Schema</li><li>HAL links for versions/cross-format/searches</li><li>Search API response format (query language intentionally unspecified)</li><li>Data discovery/harvest/synchronization APIs</li><li>Search interoperability stance:</li><li>standardized search response shape</li><li>implementation-specific query languages are allowed (SPARQL/GraphQL/Cypher/ES/Solr/etc.)</li><li>clients should discover named searches via HAL links rather than hard-coding query grammar</li><li>Versioning policy:</li><li>semantic versioning `Major.Minor.Patch`</li><li>minor = backwards-compatible feature/clarification</li><li>patch = documentation-only changes</li><li>major = backwards-incompatible changes</li></ul>\n<h3 id=\"implementation-mapping-api-foundations\">Implementation Mapping — API Foundations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>JSON-LD + HAL dual-layer response contract</li></ol>\n<ul><li>Keep canonical entity payload JSON-LD compliant while exposing API navigation in HAL-style metadata blocks.</li></ul>\n<ol><li>Endpoint consistency</li></ol>\n<ul><li>Ensure route handlers expose consistent entity envelope patterns across objects, people, places, concepts, events, and shared structures.</li></ul>\n<ol><li>Search-format stability</li></ol>\n<ul><li>Standardize search response structure independent of backend query implementation.</li><li>Allow internal query engine changes without breaking client-facing response shape.</li></ul>\n<ol><li>Discovery-first integration</li></ol>\n<ul><li>Expose machine-followable links for:</li><li>named searches</li><li>format variants</li><li>version endpoints</li><li>synchronization/discovery feeds where available</li></ul>\n<ol><li>Schema-governed contracts</li></ol>\n<ul><li>Keep response and request contracts aligned with JSON Schema/Zod boundary checks as implementation guardrails.</li></ul>\n<ol><li>Versioned compatibility guarantees</li></ol>\n<ul><li>Treat API-breaking response-shape changes as major-version work items only.</li><li>Record minor/patch behavior in changelog/roadmap notes for provider-slice PRs.</li></ul>\n<h3 id=\"tdd-additions-api-foundations\">TDD Additions — API Foundations</h3>\n<p>Add failing-first tests for API conformance behavior:</p>\n<p>Contract-level:</p>\n<ul><li>validates entity responses as JSON-LD using expected context semantics</li><li>validates HAL block shape and required link relations</li><li>validates search response envelope stability independent of query backend</li></ul>\n<p>Route-level:</p>\n<ul><li>entity endpoints return consistent envelope and link conventions</li><li>search endpoints return standardized response shape with discovered query links</li><li>discovery endpoints/links provide harvest/sync affordances when configured</li></ul>\n<p>Versioning-level:</p>\n<ul><li>tests enforce non-breaking minor changes for existing response contracts</li><li>tests detect breaking shape changes and require explicit version-bump workflow</li></ul>\n<p>Regression:</p>\n<ul><li>provider additions do not alter existing entity/search envelope contracts</li><li>backend query engine swaps do not change public search response schema</li></ul>\n<h3 id=\"fixture-anchors-api-foundations-examples\">Fixture Anchors — API Foundations Examples</h3>\n<p>Use these API-level patterns as fixture seeds:</p>\n<ol><li>Entity response fixture</li></ol>\n<ul><li>JSON-LD entity record with HAL links for self/version/related/search.</li></ul>\n<ol><li>Search response fixture</li></ol>\n<ul><li>standardized result list with pagination/meta independent of query syntax.</li></ul>\n<ol><li>HAL named-search link fixture</li></ol>\n<ul><li>entity exposing discoverable named searches via stable relation names.</li></ul>\n<ol><li>Multi-format link fixture</li></ol>\n<ul><li>entity exposing alternate format/version links through HAL metadata.</li></ul>\n<ol><li>Version-compat fixture</li></ol>\n<ul><li>snapshot tests proving minor update compatibility for entity and search responses.</li></ul>\n<p>---</p>\n<h2 id=\"round-31-addendum-about-endpoints-entity-endpoint-taxonomy\">Round 31 Addendum — About Endpoints (Entity Endpoint Taxonomy)</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: About Endpoints</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Linked Art API is organized as endpoint families, each with defined response structure aligned to model classes.</li><li>Endpoint families called out:</li><li>Abstract Works</li><li>Concepts</li><li>Digital Objects</li><li>Events</li><li>Groups</li><li>People</li><li>Physical Objects</li><li>Places</li><li>Provenance Activities</li><li>Sets</li><li>Textual Works</li><li>Visual Works</li><li>Endpoints are class-oriented and should remain predictable for consumers regardless of internal storage/query implementation.</li></ul>\n<h3 id=\"implementation-mapping-endpoint-taxonomy\">Implementation Mapping — Endpoint Taxonomy</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Endpoint family coverage matrix</li></ol>\n<ul><li>Maintain an explicit map of project routes to Linked Art endpoint families (implemented, partial, planned).</li></ul>\n<ol><li>Family-specific envelope consistency</li></ol>\n<ul><li>Keep consistent JSON-LD + HAL envelope conventions across all family endpoints while allowing family-specific payload fields.</li></ul>\n<ol><li>Cross-entity linking discipline</li></ol>\n<ul><li>Ensure records link across families through stable identifiers (for example object -&gt; provenance activity -&gt; people/groups/places/concepts).</li></ul>\n<ol><li>Provenance vs event separation</li></ol>\n<ul><li>Keep provenance activities as a dedicated event family and avoid collapsing them into generic events when provenance semantics are present.</li></ul>\n<ol><li>Work/entity distinction</li></ol>\n<ul><li>Keep abstract/textual/visual work endpoints distinct from physical object endpoints to avoid conflating conceptual and physical layers.</li></ul>\n<ol><li>Set modeling consistency</li></ol>\n<ul><li>Route set-like resources through set semantics, including collections and exhibition sets, without forcing physical-object semantics.</li></ul>\n<h3 id=\"tdd-additions-endpoint-taxonomy\">TDD Additions — Endpoint Taxonomy</h3>\n<p>Add failing-first tests for endpoint-family conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates each endpoint family response against its expected entity-class contract profile</li><li>validates shared envelope requirements are consistent across families</li><li>validates family-specific required links/fields are present when applicable</li></ul>\n<p>Route-level:</p>\n<ul><li>smoke tests for each supported family endpoint return expected entity type(s)</li><li>unknown family records fail gracefully with clear not-supported/not-found behavior</li><li>provenance-family endpoints retain transfer/acquisition/custody/move semantics</li></ul>\n<p>Integration-level:</p>\n<ul><li>cross-family traversal tests (object -&gt; production/provenance -&gt; actor/place/concept)</li><li>set endpoints correctly resolve membership and member entity references</li><li>digital object endpoints correctly resolve access points/services and visual/textual links</li></ul>\n<p>Regression:</p>\n<ul><li>adding new provider slices does not alter existing family envelope conventions</li><li>family-specific fixtures remain stable when storage backend changes</li></ul>\n<h3 id=\"fixture-anchors-endpoint-taxonomy-examples\">Fixture Anchors — Endpoint Taxonomy Examples</h3>\n<p>Use these endpoint-family patterns as fixture seeds:</p>\n<ol><li>Physical object fixture</li></ol>\n<ul><li>object record with links to production, provenance, identifiers, and digital representations.</li></ul>\n<ol><li>Provenance activity fixture</li></ol>\n<ul><li>transfer/acquisition activity linked to object + actors + timespan/place.</li></ul>\n<ol><li>People/groups fixture</li></ol>\n<ul><li>person and group records linked via participation roles in activities.</li></ul>\n<ol><li>Place fixture</li></ol>\n<ul><li>place linked from object ownership/location and activity occurrence.</li></ul>\n<ol><li>Concept fixture</li></ol>\n<ul><li>type/material/language concept records resolved as first-class endpoint entities.</li></ul>\n<ol><li>Set fixture</li></ol>\n<ul><li>collection/exhibition set with members and membership lifecycle references.</li></ul>\n<ol><li>Work layer fixtures</li></ol>\n<ul><li>abstract work, textual work, and visual work each represented independently and linked to carrying/showing entities.</li></ul>\n<ol><li>Digital object fixture</li></ol>\n<ul><li>digital object with access point/service and linked visual/textual content.</li></ul>\n<p>---</p>\n<h2 id=\"round-32-addendum-abstract-works-endpoint\">Round 32 Addendum — Abstract Works Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Abstract Works endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Abstract Works endpoint describes conceptual works, especially those instantiated by activities (for example exhibition concepts, performance concepts).</li><li>Endpoint is less common but important for linking multiple concrete realizations to one conceptual work.</li><li>Required core response properties:</li><li>`@context` must include Linked Art context URI (`https://linked.art/ns/v1/linked-art.json`)</li><li>`id` must be dereferenceable HTTP(S) URI</li><li>`type` must be `PropositionalObject`</li><li>Recommended properties:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by` (Name and/or Identifier patterns)</li><li>Optional properties include:</li><li>`referred_to_by`, `equivalent`, `subject_of`, `representation`, `member_of`</li><li>`attributed_by`, `dimension`, `conceptually_part_of`, `about`, `subject_to`, `created_by`</li><li>Incoming reference patterns called out:</li><li>`about` from Textual Works</li><li>`influenced_by` from Activities</li></ul>\n<h3 id=\"implementation-mapping-abstract-works-endpoint\">Implementation Mapping — Abstract Works Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Abstract Work endpoint payloads must emit canonical `type: &quot;PropositionalObject&quot;` for top-level records.</li></ul>\n<ol><li>Context and URI discipline</li></ol>\n<ul><li>Enforce valid Linked Art context placement and stable dereferenceable `id` values.</li></ul>\n<ol><li>Conceptual-vs-physical separation</li></ol>\n<ul><li>Keep abstract work records distinct from physical/textual/visual instantiations and link them via references.</li></ul>\n<ol><li>Relationship fidelity</li></ol>\n<ul><li>Preserve `about`, `conceptually_part_of`, `representation`, and `subject_of` links without flattening into local-only text fields.</li></ul>\n<ol><li>Creation and assertion support</li></ol>\n<ul><li>Preserve `created_by` and `attributed_by` blocks where provided as first-class modeled structures.</li></ul>\n<ol><li>Set participation</li></ol>\n<ul><li>Preserve optional `member_of` links so abstract works can participate in sets (for example curatorial concept groupings).</li></ul>\n<h3 id=\"tdd-additions-abstract-works-endpoint\">TDD Additions — Abstract Works Endpoint</h3>\n<p>Add failing-first tests for abstract-work endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required properties: `@context`, `id`, `type=PropositionalObject`</li><li>validates recommended structures (`classified_as`, `identified_by`) when present</li><li>validates optional relation fields against shared reference patterns</li></ul>\n<p>Route-level:</p>\n<ul><li>abstract-work endpoint returns single-entity JSON-LD envelope with HAL-compatible link layer</li><li>unknown/non-abstract IDs fail gracefully with clear status and error shape</li><li>route preserves `created_by` and `about` relation structures end-to-end</li></ul>\n<p>Integration-level:</p>\n<ul><li>textual-work records can reference abstract works via `about`</li><li>activity records can reference abstract works via `influenced_by`</li><li>conceptual hierarchy traversal via `conceptually_part_of` remains stable</li></ul>\n<p>Regression:</p>\n<ul><li>abstract-work ingestion does not regress physical object or visual/textual work endpoint schemas</li><li>optional abstract-work fields remain additive and do not break minimal valid responses</li></ul>\n<h3 id=\"fixture-anchors-abstract-works-endpoint-examples\">Fixture Anchors — Abstract Works Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid abstract work</li></ol>\n<ul><li>required-only payload with context, HTTP(S) id, and `type: PropositionalObject`.</li></ul>\n<ol><li>Exhibition concept fixture</li></ol>\n<ul><li>abstract work classified as exhibition with name and brief descriptive statement.</li></ul>\n<ol><li>About-link fixture</li></ol>\n<ul><li>abstract work `about` a person/concept/entity with stable external URI reference.</li></ul>\n<ol><li>Creation fixture</li></ol>\n<ul><li>abstract work with `created_by` creation activity and `carried_out_by` person/group.</li></ul>\n<ol><li>Conceptual hierarchy fixture</li></ol>\n<ul><li>abstract work linked via `conceptually_part_of` to a broader abstract work.</li></ul>\n<ol><li>Cross-endpoint incoming fixture</li></ol>\n<ul><li>textual work `about` abstract work and activity `influenced_by` same abstract work.</li></ul>\n<p>---</p>\n<h2 id=\"round-33-addendum-concepts-endpoint\">Round 33 Addendum — Concepts Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Concepts endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Concepts endpoint provides full concept records (not embedded references) for:</li><li>`Type`</li><li>`Material`</li><li>`Language`</li><li>`Currency`</li><li>`MeasurementUnit`</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is one of the allowed concept classes above</li><li>Recommended properties:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by` (Name and/or Identifier structures)</li><li>Optional properties:</li><li>`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`</li><li>`attributed_by`, `broader`, `created_by`</li><li>Key incoming links across model:</li><li>`classified_as` (all entities)</li><li>`technique` / `influenced_by` (activities)</li><li>`about` (textual/visual works)</li><li>`assigned` (attribute assignments)</li><li>`language` (linguistic objects)</li><li>`currency` (monetary amounts)</li><li>`unit` (dimensions)</li><li>`made_of` (human-made objects)</li></ul>\n<h3 id=\"implementation-mapping-concepts-endpoint\">Implementation Mapping — Concepts Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type allowlist enforcement</li></ol>\n<ul><li>Concepts endpoint must enforce top-level `type` to allowed concept classes only.</li></ul>\n<ol><li>Full-record vs embedded-reference separation</li></ol>\n<ul><li>Keep concept endpoint records richer than embedded type stubs while preserving shared identity URIs.</li></ul>\n<ol><li>Hierarchy fidelity</li></ol>\n<ul><li>Preserve `broader` links for concept navigation without flattening into label-only taxonomies.</li></ul>\n<ol><li>Cross-domain linkage stability</li></ol>\n<ul><li>Preserve concept usage links from activities, linguistic content, monetary amounts, dimensions, and materials.</li></ul>\n<ol><li>Creation/attribution traceability</li></ol>\n<ul><li>Preserve `created_by` and `attributed_by` structures when concept provenance is provided.</li></ul>\n<ol><li>Equivalence integrity</li></ol>\n<ul><li>Keep `equivalent` links as identity mappings without overwriting local canonical URI identity.</li></ul>\n<h3 id=\"tdd-additions-concepts-endpoint\">TDD Additions — Concepts Endpoint</h3>\n<p>Add failing-first tests for concept endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, and allowed concept `type` values</li><li>validates recommended structures (`identified_by`, `classified_as`) when present</li><li>validates optional relation fields (`broader`, `equivalent`, `member_of`, etc.) against shared reference schemas</li></ul>\n<p>Route-level:</p>\n<ul><li>concept endpoint returns full concept records with stable JSON-LD + HAL envelope conventions</li><li>invalid concept `type` values are rejected with clear error responses</li><li>missing or unknown concept IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>activities can resolve linked concept records for `technique` and `influenced_by`</li><li>dimensions resolve `unit` concepts; monetary amounts resolve `currency` concepts</li><li>linguistic objects resolve `language`; objects resolve `made_of` material concepts</li></ul>\n<p>Regression:</p>\n<ul><li>concept endpoint changes do not break embedded concept references in other entity endpoints</li><li>broader/equivalent graph traversal remains stable after provider adapter updates</li></ul>\n<h3 id=\"fixture-anchors-concepts-endpoint-examples\">Fixture Anchors — Concepts Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid concept</li></ol>\n<ul><li>required-only record with `type` in concept allowlist.</li></ul>\n<ol><li>Hierarchical type concept</li></ol>\n<ul><li>`Type` with `broader` link and primary name.</li></ul>\n<ol><li>Language concept</li></ol>\n<ul><li>`Language` record used by linguistic object `language` linkage tests.</li></ul>\n<ol><li>Measurement unit concept</li></ol>\n<ul><li>`MeasurementUnit` record consumed by dimension `unit` tests.</li></ul>\n<ol><li>Currency concept</li></ol>\n<ul><li>`Currency` record consumed by monetary amount `currency` tests.</li></ul>\n<ol><li>Material concept</li></ol>\n<ul><li>`Material` record consumed by object `made_of` tests.</li></ul>\n<ol><li>Concept provenance fixture</li></ol>\n<ul><li>concept with `created_by.influenced_by` links and optional `attributed_by`.</li></ul>\n<p>---</p>\n<h2 id=\"round-34-addendum-digital-objects-endpoint\">Round 34 Addendum — Digital Objects Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Digital Objects endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Digital Objects endpoint describes digital content metadata (images, documents, other media) independent of whether bytes are directly accessible.</li><li>`access_point` is the locator mechanism for retrievable file/service representations.</li><li>Required top-level Digital Object properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `DigitalObject`</li><li>Recommended properties:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by` (Name and/or Identifier)</li><li>Optional Digital Object properties include:</li><li>common linked-art fields (`referred_to_by`, `equivalent`, `member_of`, `subject_of`, `representation`, `attributed_by`)</li><li>digital-specific fields: `dimension`, `part_of`, `format`, `conforms_to`, `digitally_carries`, `digitally_shows`, `digitally_available_via`, `access_point`, `created_by`, `used_for`</li><li>Digital Service sub-structure is first-class with required:</li><li>`@context`, `id`, `type: DigitalService`</li><li>optional `access_point`, `conforms_to`, and common descriptive fields</li><li>Incoming links highlighted:</li><li>`digitally_carried_by` from Textual Works</li><li>`digitally_shown_by` from Visual Works</li></ul>\n<h3 id=\"implementation-mapping-digital-objects-endpoint\">Implementation Mapping — Digital Objects Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Digital object endpoint payloads must emit top-level `type: &quot;DigitalObject&quot;` only for this family.</li></ul>\n<ol><li>Metadata-vs-binary separation</li></ol>\n<ul><li>Preserve distinction between metadata records and retrievable content endpoints via `access_point`.</li></ul>\n<ol><li>Service modeling fidelity</li></ol>\n<ul><li>Preserve `digitally_available_via` as Digital Service objects with their own access/specification links.</li></ul>\n<ol><li>Content relationship clarity</li></ol>\n<ul><li>Keep `digitally_carries` (textual content) and `digitally_shows` (visual content) semantically separate.</li></ul>\n<ol><li>Technical conformance capture</li></ol>\n<ul><li>Preserve `format` and `conforms_to` to support IIIF and other technical interoperability checks.</li></ul>\n<ol><li>Structural linkage</li></ol>\n<ul><li>Preserve `part_of` relations (for example image part of manifest/package object).</li></ul>\n<ol><li>Creation provenance</li></ol>\n<ul><li>Preserve `created_by` plus `used_specific_object` where digitization provenance is provided.</li></ul>\n<h3 id=\"tdd-additions-digital-objects-endpoint\">TDD Additions — Digital Objects Endpoint</h3>\n<p>Add failing-first tests for digital-object endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, `type=DigitalObject`</li><li>validates digital-service nested structure with `type=DigitalService` and valid access/specification references</li><li>validates optional digital-specific fields (`format`, `conforms_to`, `digitally_*`, `access_point`, `part_of`) against schema</li></ul>\n<p>Route-level:</p>\n<ul><li>digital endpoint returns consistent JSON-LD + HAL envelope for digital records</li><li>invalid `type` or malformed service/access blocks return clear validation errors</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>visual/textual work endpoints can resolve reciprocal digital links (`digitally_shown_by`, `digitally_carried_by`)</li><li>IIIF-style fixtures resolve service and access-point chains without semantic loss</li><li>dimensions on digital objects retain numeric/unit fidelity (for example pixel height/width)</li></ul>\n<p>Regression:</p>\n<ul><li>digital endpoint updates do not regress physical object or visual/textual endpoint contracts</li><li>ingestion from multiple providers preserves both canonical digital semantics and `_source.raw`</li></ul>\n<h3 id=\"fixture-anchors-digital-objects-endpoint-examples\">Fixture Anchors — Digital Objects Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid digital object</li></ol>\n<ul><li>required-only digital object with context/id/type.</li></ul>\n<ol><li>Image object with dimensions</li></ol>\n<ul><li>digital image with pixel `Dimension` entries and `MeasurementUnit`.</li></ul>\n<ol><li>Access point fixture</li></ol>\n<ul><li>digital object with retrievable file URI in `access_point`.</li></ul>\n<ol><li>Service fixture</li></ol>\n<ul><li>`DigitalService` with IIIF `conforms_to` and service `access_point`.</li></ul>\n<ol><li>Visual linkage fixture</li></ol>\n<ul><li>digital object `digitally_shows` visual work with reciprocal visual endpoint linkage checks.</li></ul>\n<ol><li>Text linkage fixture</li></ol>\n<ul><li>digital object `digitally_carries` textual work with reciprocal textual endpoint linkage checks.</li></ul>\n<ol><li>Part-of fixture</li></ol>\n<ul><li>derivative file/asset linked via `part_of` to a manifest/package digital object.</li></ul>\n<ol><li>Digitization provenance fixture</li></ol>\n<ul><li>`created_by` activity with `carried_out_by` agent and `used_specific_object` physical source.</li></ul>\n<p>---</p>\n<h2 id=\"round-35-addendum-events-endpoint\">Round 35 Addendum — Events Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Events endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Events endpoint groups `Period`, `Event`, and `Activity` records that are notable but not provenance/exhibition-specific endpoint families.</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` must be one of: `Period`, `Event`, `Activity`</li><li>Recommended:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by`</li><li>`timespan` (recommended in endpoint table)</li><li>Optional common links:</li><li>`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`, `part_of`</li><li>Optional temporal/spatial ordering:</li><li>`during`, `before`, `after`, `took_place_at`</li><li>Type-conditional properties:</li><li>`caused_by` only for `Event`/`Activity`</li><li>`influenced_by` only for `Activity`</li><li>`carried_out_by` only for `Activity`</li><li>`participant` for `Event`/`Activity`</li><li>`used_specific_object` and `technique` only for `Activity`</li><li>Incoming pattern highlighted:</li><li>`part_of` from any event/activity family to broader periods/events/activities</li></ul>\n<h3 id=\"implementation-mapping-events-endpoint\">Implementation Mapping — Events Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type allowlist + conditional validation</li></ol>\n<ul><li>Enforce event `type` allowlist and gate conditional fields by type at validation boundary.</li></ul>\n<ol><li>Time modeling discipline</li></ol>\n<ul><li>Preserve `timespan` structures with explicit bounds/display names when present.</li></ul>\n<ol><li>Temporal ordering fidelity</li></ol>\n<ul><li>Preserve `during` / `before` / `after` relationships without flattening to plain-date-only approximations.</li></ul>\n<ol><li>Causality and influence semantics</li></ol>\n<ul><li>Keep `caused_by` and `influenced_by` distinct and type-correct.</li></ul>\n<ol><li>Participation role clarity</li></ol>\n<ul><li>Distinguish `carried_out_by` (agentive execution) from `participant` (participation without execution).</li></ul>\n<ol><li>Activity instrumentation</li></ol>\n<ul><li>Preserve `used_specific_object` and `technique` for activity explainability and reproducibility.</li></ul>\n<ol><li>Cross-endpoint composition</li></ol>\n<ul><li>Preserve `part_of` composition links between events and broader periods for timeline traversal.</li></ul>\n<h3 id=\"tdd-additions-events-endpoint\">TDD Additions — Events Endpoint</h3>\n<p>Add failing-first tests for event endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, and `type in {Period, Event, Activity}`</li><li>validates recommended `timespan` structure when present</li><li>rejects type-disallowed fields (for example `carried_out_by` on `Period`)</li></ul>\n<p>Route-level:</p>\n<ul><li>event endpoint returns stable JSON-LD + HAL envelope</li><li>invalid type/field combinations return clear boundary validation errors</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>`part_of` links resolve across event families and preserve hierarchy constraints</li><li>`during`/`before`/`after` ordering chains remain traversable</li><li>`took_place_at` links resolve to place endpoint records</li></ul>\n<p>Regression:</p>\n<ul><li>event endpoint updates do not regress provenance-specific or exhibition-specific workflows</li><li>existing activity fixtures keep role semantics (`carried_out_by` vs `participant`) intact</li></ul>\n<h3 id=\"fixture-anchors-events-endpoint-examples\">Fixture Anchors — Events Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal period fixture</li></ol>\n<ul><li>`type: Period` with valid timespan and no activity-only fields.</li></ul>\n<ol><li>Generic event fixture</li></ol>\n<ul><li>`type: Event` with participant and causality links.</li></ul>\n<ol><li>Activity fixture</li></ol>\n<ul><li>`type: Activity` with `carried_out_by`, `used_specific_object`, `technique`.</li></ul>\n<ol><li>Temporal bounds fixture</li></ol>\n<ul><li>timespan with `begin_of_the_begin` and `end_of_the_end` plus display title name.</li></ul>\n<ol><li>Ordering fixture</li></ol>\n<ul><li>`before`/`after` links across multiple events with deterministic traversal.</li></ul>\n<ol><li>Part-of hierarchy fixture</li></ol>\n<ul><li>event/activity as `part_of` broader period and inherited timeline navigation checks.</li></ul>\n<ol><li>Place linkage fixture</li></ol>\n<ul><li>event `took_place_at` stable place reference resolution.</li></ul>\n<p>---</p>\n<h2 id=\"round-36-addendum-groups-endpoint\">Round 36 Addendum — Groups Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Groups endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Groups endpoint provides records for sets of actors (families, organizations, companies, departments, etc.).</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `Group`</li><li>Recommended:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by`</li><li>Optional:</li><li>`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`</li><li>`contact_point`, `residence`</li><li>`carried_out`, `participated_in`</li><li>lifecycle events: `formed_by`, `dissolved_by`</li><li>Incoming links highlighted include:</li><li>actor participation/carrying out activity</li><li>object ownership/custody/permanent custody</li><li>provenance transfer/payment role links</li><li>textual/visual references (`about`, `represents`)</li></ul>\n<h3 id=\"implementation-mapping-groups-endpoint\">Implementation Mapping — Groups Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Group endpoint payloads must emit top-level `type: &quot;Group&quot;` only.</li></ul>\n<ol><li>Actor-role differentiation</li></ol>\n<ul><li>Preserve distinction between `carried_out` (responsible actor) and `participated_in` (non-responsible participant).</li></ul>\n<ol><li>Lifecycle event integrity</li></ol>\n<ul><li>Preserve `formed_by` and `dissolved_by` as structured activity nodes with timespan/place when available.</li></ul>\n<ol><li>Membership hierarchy support</li></ol>\n<ul><li>Preserve `member_of` links for nested group structures without flattening hierarchy to labels.</li></ul>\n<ol><li>Custody/ownership interoperability</li></ol>\n<ul><li>Keep group identities stable across ownership, custody, and provenance transfer/payment role edges.</li></ul>\n<ol><li>Contact/residence fidelity</li></ol>\n<ul><li>Preserve optional `contact_point` and `residence` semantics without conflating with identifiers or labels.</li></ul>\n<ol><li>Assertion support</li></ol>\n<ul><li>Preserve `attributed_by` relationship assignments for contextual group relationships.</li></ul>\n<h3 id=\"tdd-additions-groups-endpoint\">TDD Additions — Groups Endpoint</h3>\n<p>Add failing-first tests for group endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, `type=Group`</li><li>validates optional lifecycle fields (`formed_by`, `dissolved_by`) against activity/time/place structures</li><li>validates actor-role arrays (`carried_out`, `participated_in`) with correct reference typing</li></ul>\n<p>Route-level:</p>\n<ul><li>group endpoint returns stable JSON-LD + HAL envelope</li><li>malformed lifecycle or actor-role payloads fail boundary validation with clear errors</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>provenance routes resolve group edges for title/custody transfer and payment roles</li><li>object routes resolve group edges for owner/custodian/permanent custodian roles</li><li>textual/visual routes resolve `about`/`represents` references to group records</li></ul>\n<p>Regression:</p>\n<ul><li>group endpoint changes do not regress person endpoint actor semantics</li><li>membership and lifecycle fixtures stay stable across provider adapter updates</li></ul>\n<h3 id=\"fixture-anchors-groups-endpoint-examples\">Fixture Anchors — Groups Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid group</li></ol>\n<ul><li>required-only group record with context/id/type.</li></ul>\n<ol><li>Classified + named group</li></ol>\n<ul><li>group with primary name, nationality/type classifications.</li></ul>\n<ol><li>Lifecycle fixture</li></ol>\n<ul><li>group with `formed_by` and `dissolved_by` including timespan and place.</li></ul>\n<ol><li>Activity role fixture</li></ol>\n<ul><li>group with both `carried_out` and `participated_in` references.</li></ul>\n<ol><li>Residence/contact fixture</li></ol>\n<ul><li>group with `residence` place and `contact_point` identifier.</li></ul>\n<ol><li>Provenance-role fixture</li></ol>\n<ul><li>group as transfer/payment recipient/source across provenance activities.</li></ul>\n<ol><li>Membership hierarchy fixture</li></ol>\n<ul><li>subgroup linked via `member_of` to parent group.</li></ul>\n<ol><li>Assertion fixture</li></ol>\n<ul><li>`attributed_by` assignment connecting related groups contextually.</li></ul>\n<p>---</p>\n<h2 id=\"round-37-addendum-people-endpoint\">Round 37 Addendum — People Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: People endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>People endpoint provides records for persons (artists, collectors, museum staff, and others).</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `Person`</li><li>Recommended:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by`</li><li>Optional:</li><li>`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`</li><li>`contact_point`, `residence`</li><li>`carried_out`, `participated_in`</li><li>lifecycle events: `born`, `died`</li><li>Incoming links highlighted include:</li><li>activity execution roles (`carried_out_by`)</li><li>object ownership/custody/permanent custody roles</li><li>provenance transfer/payment role links</li><li>textual/visual references (`about`, `represents`)</li></ul>\n<h3 id=\"implementation-mapping-people-endpoint\">Implementation Mapping — People Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>People endpoint payloads must emit top-level `type: &quot;Person&quot;` only.</li></ul>\n<ol><li>Lifecycle event fidelity</li></ol>\n<ul><li>Preserve `born` and `died` as structured event nodes with timespan/place semantics.</li></ul>\n<ol><li>Role differentiation</li></ol>\n<ul><li>Preserve distinction between `carried_out` (responsible activity) and `participated_in` (participatory role).</li></ul>\n<ol><li>Identity semantics</li></ol>\n<ul><li>Keep `identified_by` name/identifier patterns distinct; preserve `equivalent` for external identity links.</li></ul>\n<ol><li>Residence/contact semantics</li></ol>\n<ul><li>Preserve `residence` as place links and `contact_point` as identifier-like contact/address structures.</li></ul>\n<ol><li>Group membership integrity</li></ol>\n<ul><li>Preserve `member_of` relationships to groups for social/professional context.</li></ul>\n<ol><li>Assertion compatibility</li></ol>\n<ul><li>Preserve `attributed_by` relationship assignments for contextual or uncertain links.</li></ul>\n<h3 id=\"tdd-additions-people-endpoint\">TDD Additions — People Endpoint</h3>\n<p>Add failing-first tests for people endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, `type=Person`</li><li>validates lifecycle structures for `born` and `died` when present</li><li>validates optional role arrays and reference typing (`member_of`, `carried_out`, `participated_in`)</li></ul>\n<p>Route-level:</p>\n<ul><li>people endpoint returns stable JSON-LD + HAL envelope</li><li>malformed lifecycle/role/contact fields fail boundary validation with clear errors</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>activity/provenance routes resolve person edges for execution, transfer, and payment roles</li><li>object routes resolve person edges for owner/custodian/permanent custodian roles</li><li>textual/visual routes resolve `about`/`represents` references to people records</li></ul>\n<p>Regression:</p>\n<ul><li>people endpoint changes do not regress groups endpoint actor-role semantics</li><li>person lifecycle and identity fixtures remain stable across provider adapter updates</li></ul>\n<h3 id=\"fixture-anchors-people-endpoint-examples\">Fixture Anchors — People Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid person</li></ol>\n<ul><li>required-only person record with context/id/type.</li></ul>\n<ol><li>Classified + named person</li></ol>\n<ul><li>person with gender/nationality classifications and primary name.</li></ul>\n<ol><li>Birth/death lifecycle fixture</li></ol>\n<ul><li>person with structured `born` and `died` events including timespan/place.</li></ul>\n<ol><li>Activity role fixture</li></ol>\n<ul><li>person with `carried_out` and `participated_in` edges.</li></ul>\n<ol><li>Residence/contact fixture</li></ol>\n<ul><li>person with place `residence` and street-address `contact_point`.</li></ul>\n<ol><li>Provenance-role fixture</li></ol>\n<ul><li>person as source/target in title/custody transfer and payment activities.</li></ul>\n<ol><li>Group-membership fixture</li></ol>\n<ul><li>person linked via `member_of` to one or more group records.</li></ul>\n<ol><li>External identity fixture</li></ol>\n<ul><li>person with `equivalent` URI to authority source (for example ULAN).</li></ul>\n<p>---</p>\n<h2 id=\"round-38-addendum-physical-objects-endpoint\">Round 38 Addendum — Physical Objects Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Physical Objects endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Physical Objects endpoint is a core endpoint for tangible artworks/resources.</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `HumanMadeObject`</li><li>Recommended:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by`</li><li>Optional object-centric fields include:</li><li>descriptive and linking fields (`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`, `part_of`)</li><li>physical fields (`dimension`, `made_of`, `held_or_supported_by`)</li><li>rights/ownership/location (`current_owner`, `current_custodian`, `current_permanent_custodian`, `current_location`, `current_permanent_location`)</li><li>content linkage (`carries`, `shows`)</li><li>lifecycle/activity linkage (`used_for`, `produced_by`, `destroyed_by`, `removed_by`, `modified_by`, `encountered_by`, `changed_ownership_through`)</li><li>Acquisition objects inside `changed_ownership_through` may include:</li><li>`transferred_title_from`</li><li>`transferred_title_to`</li><li>Incoming links highlighted:</li><li>`used_specific_object`, `influenced_by`</li><li>provenance transfer/move/rights links</li><li>textual `carried_by` and visual `shown_by`</li></ul>\n<h3 id=\"implementation-mapping-physical-objects-endpoint\">Implementation Mapping — Physical Objects Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Physical object endpoint payloads must emit top-level `type: &quot;HumanMadeObject&quot;` only.</li></ul>\n<ol><li>Physical/conceptual separation</li></ol>\n<ul><li>Keep object-carried/shown relationships (`carries`, `shows`) distinct from textual/visual work records.</li></ul>\n<ol><li>Ownership/custody/location semantics</li></ol>\n<ul><li>Preserve current vs permanent owner/custodian/location distinctions without collapsing into single status fields.</li></ul>\n<ol><li>Material and dimension fidelity</li></ol>\n<ul><li>Preserve `made_of` references and dimensional values/units with full numeric precision.</li></ul>\n<ol><li>Lifecycle provenance integrity</li></ol>\n<ul><li>Preserve production/destruction/modification/removal/encounter/acquisition chains as structured event nodes.</li></ul>\n<ol><li>Support relationships</li></ol>\n<ul><li>Preserve `held_or_supported_by` and `part_of` relations for containment/structural modeling.</li></ul>\n<ol><li>Acquisition detail preservation</li></ol>\n<ul><li>Preserve `transferred_title_from`/`transferred_title_to` within ownership-change activities.</li></ul>\n<h3 id=\"tdd-additions-physical-objects-endpoint\">TDD Additions — Physical Objects Endpoint</h3>\n<p>Add failing-first tests for physical-object endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, `type=HumanMadeObject`</li><li>validates object fields for dimensions/materials/location/custody/ownership structures</li><li>validates lifecycle and acquisition nested activity schemas</li></ul>\n<p>Route-level:</p>\n<ul><li>physical object endpoint returns stable JSON-LD + HAL envelope</li><li>malformed ownership/custody/location or lifecycle blocks fail boundary validation with clear errors</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>provenance endpoints resolve object links across transfer/custody/move/rights activities</li><li>textual and visual endpoints resolve reciprocal `carried_by`/`shown_by` links</li><li>people/groups/places endpoints resolve owner/custodian/location references</li></ul>\n<p>Regression:</p>\n<ul><li>object endpoint updates do not regress digital object or abstract work schemas</li><li>fixture coverage prevents flattening of current/permanent and owner/custodian distinctions</li></ul>\n<h3 id=\"fixture-anchors-physical-objects-endpoint-examples\">Fixture Anchors — Physical Objects Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid physical object</li></ol>\n<ul><li>required-only record with context/id/type.</li></ul>\n<ol><li>Multi-name + identifier fixture</li></ol>\n<ul><li>multilingual names plus accession identifier classifications.</li></ul>\n<ol><li>Dimension + material fixture</li></ol>\n<ul><li>height/width dimensions with units and multiple `made_of` materials.</li></ul>\n<ol><li>Ownership/custody/location fixture</li></ol>\n<ul><li>current vs permanent owner/custodian/location separation.</li></ul>\n<ol><li>Production fixture</li></ol>\n<ul><li>`produced_by` with timespan/place/actor.</li></ul>\n<ol><li>Lifecycle chain fixture</li></ol>\n<ul><li>object with `modified_by`, `removed_by`, `encountered_by`, `destroyed_by`.</li></ul>\n<ol><li>Ownership-transfer fixture</li></ol>\n<ul><li>`changed_ownership_through` acquisition with `transferred_title_from` and `transferred_title_to`.</li></ul>\n<ol><li>Support/containment fixture</li></ol>\n<ul><li>object `part_of` and `held_or_supported_by` another physical object.</li></ul>\n<p>---</p>\n<h2 id=\"round-39-addendum-places-endpoint\">Round 39 Addendum — Places Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Places endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Places are spatial extents (independent of time and object presence) used as context for activities and locations.</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `Place`</li><li>Recommended:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by`</li><li>Optional:</li><li>`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`</li><li>`part_of` (place hierarchy)</li><li>`defined_by` (WKT geometry string)</li><li>Incoming links highlighted:</li><li>`took_place_at` from events/activities</li><li>object `current_location` / `current_permanent_location`</li><li>provenance `moved_from` / `moved_to`</li><li>person/group `residence`</li></ul>\n<h3 id=\"implementation-mapping-places-endpoint\">Implementation Mapping — Places Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Places endpoint payloads must emit top-level `type: &quot;Place&quot;` only.</li></ul>\n<ol><li>Geometry fidelity</li></ol>\n<ul><li>Preserve `defined_by` WKT as canonical geometry representation when provided.</li></ul>\n<ol><li>Place hierarchy integrity</li></ol>\n<ul><li>Preserve `part_of` relations for nested place modeling (gallery -&gt; museum -&gt; city -&gt; region).</li></ul>\n<ol><li>Spatial-role separation</li></ol>\n<ul><li>Keep place identity separate from group/organization identity (for example museum institution vs museum building/place).</li></ul>\n<ol><li>Cross-endpoint location semantics</li></ol>\n<ul><li>Preserve inbound location roles distinctly (`took_place_at`, `current_location`, `moved_from`, `residence`, etc.).</li></ul>\n<ol><li>Identity and equivalence</li></ol>\n<ul><li>Preserve stable local IDs and `equivalent` external place authorities (for example TGN/GeoNames).</li></ul>\n<h3 id=\"tdd-additions-places-endpoint\">TDD Additions — Places Endpoint</h3>\n<p>Add failing-first tests for places endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, `type=Place`</li><li>validates optional `defined_by` WKT as string payload and reference fields as place-typed links</li><li>validates `part_of` place hierarchy references</li></ul>\n<p>Route-level:</p>\n<ul><li>places endpoint returns stable JSON-LD + HAL envelope</li><li>malformed WKT or invalid place reference shapes fail boundary validation clearly</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>object endpoints resolve `current_location` and `current_permanent_location` place references</li><li>event/activity/provenance endpoints resolve `took_place_at`, `moved_from`, `moved_to`</li><li>people/groups endpoints resolve `residence` place references</li></ul>\n<p>Regression:</p>\n<ul><li>place endpoint updates do not regress object/event provenance workflows</li><li>hierarchy and geometry fixtures remain stable across provider adapter updates</li></ul>\n<h3 id=\"fixture-anchors-places-endpoint-examples\">Fixture Anchors — Places Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid place</li></ol>\n<ul><li>required-only place record with context/id/type.</li></ul>\n<ol><li>Classified + named place</li></ol>\n<ul><li>place with city/region type classification and primary name/identifier.</li></ul>\n<ol><li>Geometry fixture</li></ol>\n<ul><li>place with valid `defined_by` WKT polygon.</li></ul>\n<ol><li>Hierarchy fixture</li></ol>\n<ul><li>place `part_of` parent place chain (gallery -&gt; city -&gt; state/country).</li></ul>\n<ol><li>Incoming object-location fixture</li></ol>\n<ul><li>physical object with `current_location` referencing place endpoint record.</li></ul>\n<ol><li>Incoming activity-location fixture</li></ol>\n<ul><li>event/activity `took_place_at` place reference resolution.</li></ul>\n<ol><li>Move provenance fixture</li></ol>\n<ul><li>provenance `moved_from`/`moved_to` between two place records.</li></ul>\n<ol><li>Residence fixture</li></ol>\n<ul><li>person/group with `residence` place links.</li></ul>\n<p>---</p>\n<h2 id=\"round-40-addendum-provenance-activities-endpoint\">Round 40 Addendum — Provenance Activities Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Provenance Activities endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Provenance Activities endpoint is a higher-complexity event/activity endpoint with required structured `part` activities.</li><li>Top-level required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `Event` or `Activity`</li><li>`classified_as` is required and must include Provenance Activity classification</li><li>`part` array is required</li><li>Required provenance classification discriminator:</li><li>one `classified_as.id` must be `http://vocab.getty.edu/aat/300055863`</li><li>Top-level optional/recommended event features include:</li><li>`identified_by`, `timespan`, `took_place_at`, `caused_by`, `influenced_by`, `carried_out_by`, `participant`, `used_specific_object`, temporal ordering and contextual links</li><li>Every `part` entry has shared activity fields and a required `type`, plus type-specific rules:</li><li>`Acquisition`: requires `transferred_title_of`, optional `transferred_title_from` / `transferred_title_to`</li><li>`Payment`: optional `paid_amount`, `paid_from`, `paid_to`</li><li>`TransferOfCustody`: requires `transferred_custody_of`, optional `transferred_custody_from` / `transferred_custody_to`</li><li>`Encounter`: requires `encountered`</li><li>`RightAcquisition`: requires `establishes`, optional `invalidates`</li><li>`Move`: requires `moved`, optional `moved_from` / `moved_to`</li><li>`Promise`: modeled as `type: Activity` with required classification containing `aat:300435599`</li><li>`Transfer`: requires `transferred`, optional `transferred_from` / `transferred_to`</li><li>Rights sub-structure is formally defined (`type: Right`) with identity/classification/applicability/possession dimensions and optional nesting via `part`.</li></ul>\n<h3 id=\"implementation-mapping-provenance-activities-endpoint\">Implementation Mapping — Provenance Activities Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Provenance discriminator enforcement</li></ol>\n<ul><li>Treat provenance endpoint entries as valid only when `classified_as` includes `aat:300055863`.</li></ul>\n<ol><li>Top-level/part separation discipline</li></ol>\n<ul><li>Preserve top-level provenance context and keep transactional details in explicit `part` entries, not flattened fields.</li></ul>\n<ol><li>Part-type contract enforcement</li></ol>\n<ul><li>Validate each part by its declared type-specific required fields before persistence or response emission.</li></ul>\n<ol><li>Promise typing rule</li></ol>\n<ul><li>Enforce promise parts as `type: Activity` plus required classification `aat:300435599`.</li></ul>\n<ol><li>Rights lifecycle fidelity</li></ol>\n<ul><li>Preserve `RightAcquisition` establish/invalidate semantics with explicit `Right` structures.</li></ul>\n<ol><li>Monetary fidelity</li></ol>\n<ul><li>Preserve `Payment.paid_amount` numeric/currency semantics and multi-party flows (`paid_from`/`paid_to`).</li></ul>\n<ol><li>Transfer ambiguity preservation</li></ol>\n<ul><li>Preserve ambiguous transfers as `Transfer` when evidence is insufficient for specific acquisition/custody/move typing.</li></ul>\n<h3 id=\"tdd-additions-provenance-activities-endpoint\">TDD Additions — Provenance Activities Endpoint</h3>\n<p>Add failing-first tests for provenance endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required top-level fields including provenance classification discriminator and required `part` array</li><li>validates each `part` by subtype required fields</li><li>validates rights sub-structures and promise classification rule</li></ul>\n<p>Route-level:</p>\n<ul><li>provenance endpoint returns stable JSON-LD + HAL envelope with structured parts</li><li>malformed part payloads fail boundary validation with clear subtype-specific errors</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>object endpoints resolve provenance edges (ownership/custody/move/rights/payment relationships)</li><li>people/groups endpoints resolve transfer and payment roles consistently</li><li>place endpoints resolve move/took_place_at references for provenance activities</li></ul>\n<p>Regression:</p>\n<ul><li>provenance endpoint changes do not regress generic events endpoint behavior</li><li>part-type fixtures prevent flattening of transactional semantics into lossy summaries</li></ul>\n<h3 id=\"fixture-anchors-provenance-activities-endpoint-examples\">Fixture Anchors — Provenance Activities Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid provenance activity</li></ol>\n<ul><li>top-level activity with required provenance classification and non-empty `part`.</li></ul>\n<ol><li>Acquisition + payment bundle</li></ol>\n<ul><li>single provenance entry with `Acquisition` and `Payment` parts sharing actors/object.</li></ul>\n<ol><li>Transfer of custody fixture</li></ol>\n<ul><li>`TransferOfCustody` with required transferred object and from/to custodians.</li></ul>\n<ol><li>Move fixture</li></ol>\n<ul><li>`Move` with moved objects and origin/destination places.</li></ul>\n<ol><li>Encounter fixture</li></ol>\n<ul><li>`Encounter` part with discovered object and participating actor.</li></ul>\n<ol><li>Right acquisition fixture</li></ol>\n<ul><li>`RightAcquisition` that establishes one right and invalidates another.</li></ul>\n<ol><li>Promise fixture</li></ol>\n<ul><li>`type: Activity` part classified with `aat:300435599`.</li></ul>\n<ol><li>Ambiguous transfer fixture</li></ol>\n<ul><li>`Transfer` part used when ownership-vs-custody evidence is indeterminate.</li></ul>\n<p>---</p>\n<h2 id=\"round-41-addendum-sets-endpoint\">Round 41 Addendum — Sets Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Sets endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Sets endpoint describes collections/aggregations across entity types (especially objects, texts, and images).</li><li>Important modeling constraint:</li><li>Set records do not list full members directly; membership is primarily expressed on member entities (`member_of`) or through discovery APIs.</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `Set`</li><li>Recommended:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by`</li><li>Optional:</li><li>common fields (`referred_to_by`, `equivalent`, `representation`, `member_of`, `subject_of`, `attributed_by`)</li><li>set-specific fields: `dimension`, `about`, `members_exemplified_by`, `members_contained_by`, `created_by`, `used_for`</li><li>Validation caveat:</li><li>`members_exemplified_by` can only be minimally validated because values may be embedded structures of many endpoint shapes or references.</li><li>Incoming links highlighted:</li><li>`member_of` from most non-person/non-group entities</li><li>`used_specific_object` from events/activities (for example exhibition object sets, auction lots)</li></ul>\n<h3 id=\"implementation-mapping-sets-endpoint\">Implementation Mapping — Sets Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Sets endpoint payloads must emit top-level `type: &quot;Set&quot;` only.</li></ul>\n<ol><li>Membership modeling discipline</li></ol>\n<ul><li>Do not force exhaustive inline member lists in set records; preserve membership edges on member entities and discovery/search layers.</li></ul>\n<ol><li>Exemplification vs containment semantics</li></ol>\n<ul><li>Preserve `members_exemplified_by` (representative examples) distinctly from `members_contained_by` (physical containment context).</li></ul>\n<ol><li>Set-aboutness and curation context</li></ol>\n<ul><li>Preserve `about`, `used_for`, and `created_by` to represent thematic and publication/exhibition intent.</li></ul>\n<ol><li>Dimension semantics for aggregates</li></ol>\n<ul><li>Preserve aggregate dimensions (for example member counts) using proper dimension structures.</li></ul>\n<ol><li>Cross-endpoint set reuse</li></ol>\n<ul><li>Keep set identifiers stable for use by events/provenance/object workflows (lots, exhibitions, institutional holdings).</li></ul>\n<h3 id=\"tdd-additions-sets-endpoint\">TDD Additions — Sets Endpoint</h3>\n<p>Add failing-first tests for set endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, `type=Set`</li><li>validates optional set-specific fields and shared reference structures</li><li>allows minimally validated `members_exemplified_by` while still enforcing basic object/reference safety</li></ul>\n<p>Route-level:</p>\n<ul><li>sets endpoint returns stable JSON-LD + HAL envelope</li><li>malformed set-specific payloads fail boundary validation clearly</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>member entities across endpoints resolve `member_of` links to set records</li><li>events/provenance can reference sets via `used_specific_object` (for example auction lot sets)</li><li>physical container linkage through `members_contained_by` resolves to object endpoint records</li></ul>\n<p>Regression:</p>\n<ul><li>set endpoint changes do not regress group membership semantics (people/groups remain group-membership domain)</li><li>discovery/search pipelines remain the mechanism for expanding full set membership</li></ul>\n<h3 id=\"fixture-anchors-sets-endpoint-examples\">Fixture Anchors — Sets Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid set</li></ol>\n<ul><li>required-only set record with context/id/type.</li></ul>\n<ol><li>Classified collection fixture</li></ol>\n<ul><li>set classified as collection with primary name and description statement.</li></ul>\n<ol><li>Creation fixture</li></ol>\n<ul><li>set with `created_by` creation activity and precise timespan.</li></ul>\n<ol><li>Aboutness fixture</li></ol>\n<ul><li>thematic set with `about` links to concept/person/place/object.</li></ul>\n<ol><li>Exemplified-members fixture</li></ol>\n<ul><li>set with mixed embedded/reference `members_exemplified_by` samples.</li></ul>\n<ol><li>Contained-members fixture</li></ol>\n<ul><li>set with `members_contained_by` physical object reference.</li></ul>\n<ol><li>Event linkage fixture</li></ol>\n<ul><li>event/provenance `used_specific_object` references set (exhibition selection or auction lot).</li></ul>\n<ol><li>Member-of traversal fixture</li></ol>\n<ul><li>object/text/visual records referencing set via `member_of`, verified through traversal tests.</li></ul>\n<p>---</p>\n<h2 id=\"round-42-addendum-textual-works-endpoint\">Round 42 Addendum — Textual Works Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Textual Works endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Textual Works endpoint describes linguistic content as first-class entities.</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `LinguisticObject`</li><li>Recommended:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by`</li><li>Optional fields include:</li><li>`referred_to_by`, `equivalent`, `subject_of`, `representation`, `member_of`, `attributed_by`</li><li>`language`, `dimension`, `part_of`, `conceptually_part_of`</li><li>`content`, `format`, `about`, `subject_to`, `created_by`, `used_for`</li><li>Incoming links highlighted:</li><li>`subject_of` from any endpoint entity</li><li>`carries` from Physical Objects</li><li>`digitally_carries` from Digital Objects</li></ul>\n<h3 id=\"implementation-mapping-textual-works-endpoint\">Implementation Mapping — Textual Works Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Textual endpoint payloads must emit top-level `type: &quot;LinguisticObject&quot;` only.</li></ul>\n<ol><li>Text/content representation separation</li></ol>\n<ul><li>Preserve distinction between textual entity metadata and optional inline `content` serialization.</li></ul>\n<ol><li>Language fidelity</li></ol>\n<ul><li>Preserve `language` references (and notations when present) for multilingual content behavior.</li></ul>\n<ol><li>Intellectual structure links</li></ol>\n<ul><li>Preserve `part_of`, `conceptually_part_of`, and `about` relationships for composition and subject modeling.</li></ul>\n<ol><li>Carrier relationship integrity</li></ol>\n<ul><li>Preserve inbound/outbound linkage with physical and digital carriers (`carries`, `digitally_carries`) without conflating with text identity.</li></ul>\n<ol><li>Rights and publication provenance</li></ol>\n<ul><li>Preserve `subject_to`, `created_by`, and `used_for` structures for rights and publishing context.</li></ul>\n<h3 id=\"tdd-additions-textual-works-endpoint\">TDD Additions — Textual Works Endpoint</h3>\n<p>Add failing-first tests for textual endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, `type=LinguisticObject`</li><li>validates optional textual fields (`language`, `content`, `format`, `about`, rights/provenance links)</li><li>validates composition links to textual/visual/abstract work references</li></ul>\n<p>Route-level:</p>\n<ul><li>textual endpoint returns stable JSON-LD + HAL envelope</li><li>malformed language/content/format or link structures fail boundary validation clearly</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>physical object routes resolve `carries` links to textual works</li><li>digital object routes resolve `digitally_carries` links to textual works</li><li>cross-endpoint `subject_of` traversal remains stable for all core entity families</li></ul>\n<p>Regression:</p>\n<ul><li>textual endpoint updates do not regress abstract/visual work endpoint contracts</li><li>multilingual and identifier fixtures remain stable across provider adapter updates</li></ul>\n<h3 id=\"fixture-anchors-textual-works-endpoint-examples\">Fixture Anchors — Textual Works Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid textual work</li></ol>\n<ul><li>required-only record with context/id/type.</li></ul>\n<ol><li>Named + identified textual work</li></ol>\n<ul><li>text with primary name and identifier (for example ISBN classification).</li></ul>\n<ol><li>Language + content fixture</li></ol>\n<ul><li>text with language references and optional `content`/`format`.</li></ul>\n<ol><li>Subject/about fixture</li></ol>\n<ul><li>text `about` person/object/concept and reciprocal `subject_of` links.</li></ul>\n<ol><li>Composition fixture</li></ol>\n<ul><li>text `part_of` larger text/visual container and `conceptually_part_of` abstract work.</li></ul>\n<ol><li>Publication provenance fixture</li></ol>\n<ul><li>`used_for` publishing activity with timespan/place/actor plus `created_by`.</li></ul>\n<ol><li>Carrier linkage fixture</li></ol>\n<ul><li>text referenced by both physical `carries` and digital `digitally_carries`.</li></ul>\n<ol><li>Rights fixture</li></ol>\n<ul><li>text with `subject_to` rights block and classification.</li></ul>\n<p>---</p>\n<h2 id=\"round-43-addendum-visual-works-endpoint\">Round 43 Addendum — Visual Works Endpoint</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Visual Works endpoint</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Visual Works endpoint describes image/appearance content as first-class entities.</li><li>Required properties:</li><li>`@context` includes Linked Art context URI</li><li>`id` is dereferenceable HTTP(S) URI</li><li>`type` is `VisualItem`</li><li>Recommended:</li><li>`_label`</li><li>`classified_as`</li><li>`identified_by`</li><li>Optional fields include:</li><li>common fields (`referred_to_by`, `equivalent`, `member_of`, `subject_of`, `attributed_by`)</li><li>structure/context fields (`dimension`, `part_of`, `conceptually_part_of`, `about`)</li><li>depiction fields (`represents`, `represents_instance_of_type`)</li><li>rights/provenance/publication (`subject_to`, `created_by`, `used_for`)</li><li>Incoming links highlighted:</li><li>`representation` from all endpoint families</li><li>`shows` from Physical Objects</li><li>`digitally_shows` from Digital Objects</li></ul>\n<h3 id=\"implementation-mapping-visual-works-endpoint\">Implementation Mapping — Visual Works Endpoint</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Visual endpoint payloads must emit top-level `type: &quot;VisualItem&quot;` only.</li></ul>\n<ol><li>Depiction semantics separation</li></ol>\n<ul><li>Preserve `represents` (known entity) separately from `represents_instance_of_type` (unknown individual of known type).</li></ul>\n<ol><li>Work-layer boundaries</li></ol>\n<ul><li>Keep visual works distinct from physical/digital carriers while preserving `shows`/`digitally_shows` linkage.</li></ul>\n<ol><li>Conceptual and structural links</li></ol>\n<ul><li>Preserve `part_of` and `conceptually_part_of` for compositional and conceptual hierarchy navigation.</li></ul>\n<ol><li>Style/aboutness fidelity</li></ol>\n<ul><li>Preserve classification/style and aboutness links without collapsing to plain textual tags.</li></ul>\n<ol><li>Rights and creation provenance</li></ol>\n<ul><li>Preserve `subject_to`, `created_by`, and `used_for` structures for governance and publishing context.</li></ul>\n<h3 id=\"tdd-additions-visual-works-endpoint\">TDD Additions — Visual Works Endpoint</h3>\n<p>Add failing-first tests for visual endpoint conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`, `id`, `type=VisualItem`</li><li>validates depiction fields (`represents`, `represents_instance_of_type`) with correct reference/type constraints</li><li>validates optional conceptual/rights/provenance fields against shared contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>visual endpoint returns stable JSON-LD + HAL envelope</li><li>malformed depiction or link structures fail boundary validation clearly</li><li>unknown IDs return consistent not-found behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>physical object routes resolve `shows` links to visual work records</li><li>digital object routes resolve `digitally_shows` links to visual work records</li><li>cross-endpoint `representation` traversal remains stable for entities referencing visual works</li></ul>\n<p>Regression:</p>\n<ul><li>visual endpoint changes do not regress textual/abstract work endpoint contracts</li><li>depiction semantics fixtures prevent conflating concrete represented entities with generic represented types</li></ul>\n<h3 id=\"fixture-anchors-visual-works-endpoint-examples\">Fixture Anchors — Visual Works Endpoint Examples</h3>\n<p>Use these endpoint-specific patterns as fixture seeds:</p>\n<ol><li>Minimal valid visual work</li></ol>\n<ul><li>required-only record with context/id/type.</li></ul>\n<ol><li>Style-classified visual work</li></ol>\n<ul><li>visual work with style/type classification and primary name.</li></ul>\n<ol><li>Represents-entity fixture</li></ol>\n<ul><li>visual work `represents` known entity (for example place/person/object).</li></ul>\n<ol><li>Represents-instance-of-type fixture</li></ol>\n<ul><li>visual work with unknown depicted individual expressed via `represents_instance_of_type`.</li></ul>\n<ol><li>Carrier linkage fixture</li></ol>\n<ul><li>reciprocal links from physical `shows` and digital `digitally_shows`.</li></ul>\n<ol><li>Conceptual hierarchy fixture</li></ol>\n<ul><li>visual work `part_of` and `conceptually_part_of` references.</li></ul>\n<ol><li>Creation provenance fixture</li></ol>\n<ul><li>`created_by` creation activity with timespan/actor.</li></ul>\n<ol><li>Rights/publication fixture</li></ol>\n<ul><li>visual work with `subject_to` rights and `used_for` publication activity.</li></ul>\n<p>---</p>\n<h2 id=\"round-44-addendum-shared-structures\">Round 44 Addendum — Shared Structures</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: About Shared Structures</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Shared structures reused across endpoints include:</li><li>Activities</li><li>Digital Links</li><li>Dimensions</li><li>Identifiers</li><li>Monetary Amounts</li><li>Names</li><li>Rights</li><li>References</li><li>Statements</li><li>TimeSpans</li><li>Types/Concepts</li><li>Relationships</li><li>Embedded shared structures inherit the parent record `@context` and should not repeat `@context` inline.</li><li>If a usually-embedded structure (for example `Name`, `Dimension`) has its own dereferenceable `id` with richer remote data, embedded instance must include `_complete: false`.</li><li>Without `_complete: false`, consumers should assume the embedded structure is complete and URI is informational.</li></ul>\n<h3 id=\"implementation-mapping-shared-structures\">Implementation Mapping — Shared Structures</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Context inheritance rule</li></ol>\n<ul><li>Do not emit nested `@context` for embedded shared structures inside endpoint payloads.</li></ul>\n<ol><li>Standalone structure rule</li></ol>\n<ul><li>If shared structures are published as standalone Linked Art resources, include root `@context`.</li></ul>\n<ol><li>Partial-embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` when embedding structures that have richer canonical detail at their own `id`.</li></ul>\n<ol><li>Contract consistency</li></ol>\n<ul><li>Reuse one shared contract layer for Names/Identifiers/Dimensions/TimeSpans/etc. across all endpoints.</li></ul>\n<ol><li>Reference integrity</li></ol>\n<ul><li>Preserve stable `id` references in embedded structures to enable deferred retrieval and graph joins.</li></ul>\n<h3 id=\"tdd-additions-shared-structures\">TDD Additions — Shared Structures</h3>\n<p>Add failing-first tests for shared-structure conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates embedded shared structures do not include nested `@context`</li><li>validates standalone shared-structure documents include required root `@context`</li><li>validates `_complete: false` requirement for partial embedded structures with dereferenceable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>endpoint responses consistently apply shared structure schemas across entity families</li><li>malformed shared structures fail boundary validation with clear structure-specific errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>consumers can resolve referenced shared-structure `id` values for richer retrieval flows</li><li>mixed complete/partial embeddings behave predictably across provider adapters</li></ul>\n<p>Regression:</p>\n<ul><li>adding provider slices does not fork shared structure semantics by endpoint</li><li>`_complete` signaling remains stable in snapshots for names/dimensions/identifiers</li></ul>\n<h3 id=\"fixture-anchors-shared-structures-examples\">Fixture Anchors — Shared Structures Examples</h3>\n<p>Use these shared-structure patterns as fixture seeds:</p>\n<ol><li>Embedded name (complete) fixture</li></ol>\n<ul><li>embedded `Name` with no nested `@context`, no `_complete` flag.</li></ul>\n<ol><li>Embedded name (partial) fixture</li></ol>\n<ul><li>embedded `Name` with dereferenceable `id` and `_complete: false`.</li></ul>\n<ol><li>Embedded dimension fixture</li></ol>\n<ul><li>dimension with value/unit and no nested `@context`.</li></ul>\n<ol><li>Embedded timespan fixture</li></ol>\n<ul><li>`TimeSpan` with fuzzy bounds and display label.</li></ul>\n<ol><li>Standalone shared-structure fixture</li></ol>\n<ul><li>standalone shared structure resource with root `@context`.</li></ul>\n<ol><li>Relationship assignment fixture</li></ol>\n<ul><li>embedded relationship structure with reference integrity and shared schema compliance.</li></ul>\n<p>---</p>\n<h2 id=\"round-45-addendum-shared-structure-activities\">Round 45 Addendum — Shared Structure: Activities</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Shared structure for Activities</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Activities are often embedded inside entity records for lifecycle and usage context.</li><li>Core usage covers:</li><li>beginnings (`Production`, `Creation`, `Formation`, `Birth`)</li><li>endings (`Destruction`, `Dissolution`, `Death`)</li><li>other activity context (`Modification`, `Encounter`, generic `Activity`, etc.)</li><li>Shared activity structure:</li><li>required `type`</li><li>optional `id` with `_complete: false` when embedded form is partial and richer data exists remotely</li><li>common contextual fields: `identified_by`, `classified_as`, `referred_to_by`, `took_place_at`, `timespan`, temporal ordering, causal/influence, participants, `used_specific_object`, `technique`, `part`</li><li>Type-conditional restriction:</li><li>`Birth`/`Death` do not use `carried_out_by`, `influenced_by`, `used_specific_object`, `technique`, or `part`</li><li>`PartRemoval` adds `diminished` reference semantics.</li><li>Activity classes vary by endpoint family (for example `Person` uses `Birth`/`Death`, `Physical Object` uses `Production`/`Destruction` plus others, etc.).</li></ul>\n<h3 id=\"implementation-mapping-shared-activities\">Implementation Mapping — Shared Activities</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Shared activity contract reuse</li></ol>\n<ul><li>Use one activity schema layer across all endpoint families, then apply endpoint/type-specific constraints.</li></ul>\n<ol><li>Partial embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for embedded activity nodes with dereferenceable IDs when embedded payload is incomplete.</li></ul>\n<ol><li>Type-conditional guards</li></ol>\n<ul><li>Enforce forbidden fields for `Birth`/`Death` activity types at validation boundary.</li></ul>\n<ol><li>Lifecycle event precision</li></ol>\n<ul><li>Preserve beginning/end activity distinctions rather than flattening into single status/date fields.</li></ul>\n<ol><li>Participation semantics</li></ol>\n<ul><li>Preserve role differences (`carried_out_by` vs other participation/context fields) where applicable.</li></ul>\n<ol><li>Temporal ordering fidelity</li></ol>\n<ul><li>Preserve `timespan`, `during`, `before`, `after`, and `caused_by` without lossy date-only collapse.</li></ul>\n<ol><li>Nested activity support</li></ol>\n<ul><li>Preserve `part` sub-activities for complex activities except where type restrictions prohibit it.</li></ul>\n<h3 id=\"tdd-additions-shared-activities\">TDD Additions — Shared Activities</h3>\n<p>Add failing-first tests for shared activity structure conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type` and shared optional field schemas across embedded activity nodes</li><li>validates `_complete: false` requirement for partial embedded activities with resolvable IDs</li><li>rejects forbidden fields on `Birth`/`Death`</li></ul>\n<p>Route-level:</p>\n<ul><li>endpoints emitting embedded activities conform to shared activity schema + endpoint-specific type allowlists</li><li>malformed activity nodes fail boundary validation with explicit field/type diagnostics</li></ul>\n<p>Integration-level:</p>\n<ul><li>lifecycle links (`produced_by`, `created_by`, `born`, `died`, `destroyed_by`, etc.) resolve consistently across endpoints</li><li>`used_for`, `carried_out`, and `participated_in` activity traversals preserve actor-role semantics</li></ul>\n<p>Regression:</p>\n<ul><li>activity schema updates do not diverge by endpoint family</li><li>nested-part and temporal-ordering fixtures remain stable across provider adapter updates</li></ul>\n<h3 id=\"fixture-anchors-shared-activities-examples\">Fixture Anchors — Shared Activities Examples</h3>\n<p>Use these shared-activity patterns as fixture seeds:</p>\n<ol><li>Minimal embedded activity</li></ol>\n<ul><li>embedded activity with required `type` and basic timespan/place.</li></ul>\n<ol><li>Partial embedded activity fixture</li></ol>\n<ul><li>activity with `id` and `_complete: false` indicating richer standalone representation.</li></ul>\n<ol><li>Birth/death restriction fixture</li></ol>\n<ul><li>invalid payloads proving forbidden fields are rejected for `Birth`/`Death`.</li></ul>\n<ol><li>Production activity fixture</li></ol>\n<ul><li>production with technique, timespan, place, actor, and influence links.</li></ul>\n<ol><li>PartRemoval fixture</li></ol>\n<ul><li>`PartRemoval` activity with `diminished` object reference.</li></ul>\n<ol><li>Nested part fixture</li></ol>\n<ul><li>complex activity with `part` sub-activities for non-restricted types.</li></ul>\n<ol><li>Temporal ordering fixture</li></ol>\n<ul><li>activity with `during`, `before`, `after`, `caused_by` chain.</li></ul>\n<ol><li>Actor role fixture</li></ol>\n<ul><li>distinguishes `carried_out_by` vs participation context across related activities.</li></ul>\n<p>---</p>\n<h2 id=\"round-46-addendum-shared-structure-digital-links\">Round 46 Addendum — Shared Structure: Digital Links</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Shared structure for Digital Links</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Digital Links provide an embedding shortcut for external digital resources (for example web pages/images) within core entity records.</li><li>Structure is nested:</li><li>embedded work (`VisualItem` or `LinguisticObject`)</li><li>embedded `DigitalObject` inside that work</li><li>Embedded work constraints:</li><li>`type` required and must be `VisualItem` or `LinguisticObject`</li><li>exactly one of:</li><li>`digitally_shown_by` (for `VisualItem`)</li><li>`digitally_carried_by` (for `LinguisticObject`)</li><li>optional `_complete: false` when `id` exists and richer remote representation is available</li><li>Embedded digital object constraints:</li><li>`type` required and must be `DigitalObject`</li><li>optional `access_point` entries must each contain required `{ id, type: &quot;DigitalObject&quot; }`</li><li>optional `_complete: false` signaling for partial embedded form</li><li>optional digital metadata (`digitally_available_via`, `format`, `conforms_to`, etc.)</li><li>Incoming usage:</li><li>`representation` when embedded work is visual</li><li>`subject_of` when embedded work is linguistic</li></ul>\n<h3 id=\"implementation-mapping-shared-digital-links\">Implementation Mapping — Shared Digital Links</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Nested one-of enforcement</li></ol>\n<ul><li>Enforce class-dependent exclusive linkage:</li><li>`VisualItem` -&gt; must include `digitally_shown_by` only</li><li>`LinguisticObject` -&gt; must include `digitally_carried_by` only</li></ul>\n<ol><li>Embedded partiality signaling</li></ol>\n<ul><li>Require `_complete: false` when embedded work/digital object includes dereferenceable `id` but is not fully represented inline.</li></ul>\n<ol><li>Access point strictness</li></ol>\n<ul><li>Enforce `access_point` entry shape (`id` + `type: DigitalObject`) and treat as retrieval locators, not identity replacements.</li></ul>\n<ol><li>Work-vs-carriership separation</li></ol>\n<ul><li>Preserve distinction between work semantics (visual/textual content) and carrier/delivery semantics (digital objects/services).</li></ul>\n<ol><li>Shared-contract reuse</li></ol>\n<ul><li>Reuse Name/Type/Statement/Language shared structures inside embedded work and digital object nodes.</li></ul>\n<h3 id=\"tdd-additions-shared-digital-links\">TDD Additions — Shared Digital Links</h3>\n<p>Add failing-first tests for digital-link structure conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates embedded work `type` allowlist (`VisualItem` | `LinguisticObject`)</li><li>validates exclusive/class-appropriate presence of `digitally_shown_by` vs `digitally_carried_by`</li><li>validates embedded digital object `type=DigitalObject` and access-point child shape</li><li>validates `_complete: false` requirement for partial embedded nodes with dereferenceable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>entity endpoints embedding digital links conform to nested shared structure contracts</li><li>malformed nested work/digital object payloads fail boundary validation with explicit path-level errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>`representation` traversals resolve visual embedded links and downstream digital object access points</li><li>`subject_of` traversals resolve linguistic embedded links and downstream digital object access points</li><li>standalone digital object endpoints remain consistent with embedded digital link nodes</li></ul>\n<p>Regression:</p>\n<ul><li>updates to embedded digital-link logic do not regress full digital object endpoint semantics</li><li>one-of constraint fixtures prevent ambiguous or dual-mode linkage in one embedded work node</li></ul>\n<h3 id=\"fixture-anchors-shared-digital-links-examples\">Fixture Anchors — Shared Digital Links Examples</h3>\n<p>Use these shared digital-link patterns as fixture seeds:</p>\n<ol><li>Visual embedding fixture</li></ol>\n<ul><li>embedded `VisualItem` with required `digitally_shown_by` and no `digitally_carried_by`.</li></ul>\n<ol><li>Linguistic embedding fixture</li></ol>\n<ul><li>embedded `LinguisticObject` with required `digitally_carried_by` and language metadata.</li></ul>\n<ol><li>Nested digital object fixture</li></ol>\n<ul><li>embedded `DigitalObject` with classification/name and valid `access_point`.</li></ul>\n<ol><li>Partial embedded node fixture</li></ol>\n<ul><li>embedded work/digital object with `id` and `_complete: false`.</li></ul>\n<ol><li>Access-point validation fixture</li></ol>\n<ul><li>invalid/missing `id` or incorrect `type` in `access_point` is rejected.</li></ul>\n<ol><li>Service linkage fixture</li></ol>\n<ul><li>embedded digital object with `digitally_available_via` and `conforms_to` spec link.</li></ul>\n<p>---</p>\n<h2 id=\"round-47-addendum-shared-structure-activities-reconfirmation\">Round 47 Addendum — Shared Structure: Activities (Reconfirmation)</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Shared structure for Activities (repeat ingestion)</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>This round reconfirms the same activity-shared-structure rules already captured in Round 45.</li><li>No net-new schema fields, type rules, or endpoint-specific constraints were introduced beyond Round 45.</li><li>Reconfirmed constraints include:</li><li>shared embedded activity structure with required `type`</li><li>partial embed signaling via `_complete: false`</li><li>`Birth`/`Death` field restrictions</li><li>endpoint-family mapping of beginning/ending/other activity classes</li><li>`PartRemoval.diminished` usage</li></ul>\n<h3 id=\"implementation-mapping-shared-activities-reconfirmation\">Implementation Mapping — Shared Activities (Reconfirmation)</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>No new implementation scope</li></ol>\n<ul><li>Keep Round 45 implementation mapping as canonical; no additional code-path requirements from this round.</li></ul>\n<ol><li>Stability expectation</li></ol>\n<ul><li>Treat this repeated docs drop as a consistency checkpoint for existing activity boundary validation and serializers.</li></ul>\n<h3 id=\"tdd-additions-shared-activities-reconfirmation\">TDD Additions — Shared Activities (Reconfirmation)</h3>\n<p>Add/retain failing-first tests for stability:</p>\n<p>Contract-level:</p>\n<ul><li>keep Round 45 activity conformance suite as authoritative and unchanged</li></ul>\n<p>Regression:</p>\n<ul><li>add/retain a snapshot guard that duplicate spec ingestion does not change schemas or route payload shapes</li><li>ensure `Birth`/`Death` forbidden-field checks remain active</li></ul>\n<h3 id=\"fixture-anchors-shared-activities-reconfirmation\">Fixture Anchors — Shared Activities (Reconfirmation)</h3>\n<p>Use existing Round 45 fixtures as anchors:</p>\n<ol><li>Partial activity embed fixture with `_complete: false`.</li></ol>\n<ol><li>Birth/death restricted-field negative fixture.</li></ol>\n<ol><li>Production activity with timespan/place/technique/actor.</li></ol>\n<ol><li>Nested `part` fixture for non-restricted activity types.</li></ol>\n<p>---</p>\n<h2 id=\"round-48-addendum-shared-structure-dimensions\">Round 48 Addendum — Shared Structure: Dimensions</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Shared structure for Dimensions</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>A Dimension combines:</li><li>numeric `value`</li><li>required `unit` (`MeasurementUnit`)</li><li>classification of what is being measured</li><li>Core requirements:</li><li>`type` required and must be `Dimension`</li><li>`value` required (number)</li><li>`unit` required (MeasurementUnit reference/object)</li><li>Optional semantics:</li><li>uncertainty/range bounds: `upper_value_limit`, `lower_value_limit`</li><li>textual rendering via `identified_by` (Name)</li><li>provenance of measurement via `assigned_by` (AttributeAssignment/measurement activity)</li><li>`_complete: false` when embedded dimension has dereferenceable `id` with richer remote data</li><li>Incoming usage:</li><li>`dimension` across many endpoints (especially physical/digital objects)</li><li>`duration` on `TimeSpan` as dimensionalized temporal length</li></ul>\n<h3 id=\"implementation-mapping-shared-dimensions\">Implementation Mapping — Shared Dimensions</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Required-field strictness</li></ol>\n<ul><li>Enforce `type=Dimension`, numeric `value`, and required `unit` at boundary validation.</li></ul>\n<ol><li>Unit integrity</li></ol>\n<ul><li>Require `unit.type = MeasurementUnit` and preserve unit identifiers/labels for interoperability.</li></ul>\n<ol><li>Uncertainty modeling</li></ol>\n<ul><li>Preserve `upper_value_limit` and `lower_value_limit` as explicit uncertainty bounds, not inferred from display strings.</li></ul>\n<ol><li>Display-text separation</li></ol>\n<ul><li>Preserve human-readable dimensional strings in `identified_by` without replacing canonical numeric/value/unit fields.</li></ul>\n<ol><li>Measurement provenance</li></ol>\n<ul><li>Preserve `assigned_by` as explicit measurement activity/provenance trace when available.</li></ul>\n<ol><li>Partial-embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for partial embedded dimension nodes with richer dereferenceable representations.</li></ul>\n<h3 id=\"tdd-additions-shared-dimensions\">TDD Additions — Shared Dimensions</h3>\n<p>Add failing-first tests for dimension structure conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type=Dimension`, numeric `value`, and required `unit` object/reference</li><li>validates optional uncertainty bounds as numbers when present</li><li>validates `assigned_by` activity structure and `identified_by` name shape</li><li>validates `_complete: false` requirement for partial embedded dimensions with resolvable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>entity endpoints embedding dimensions conform to shared dimension schema</li><li>malformed dimension/unit/bound payloads fail boundary validation with explicit field-path errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>object/text/digital/person/group endpoints preserve dimensional semantics consistently</li><li>timespan duration dimensions interoperate with time modeling without type ambiguity</li></ul>\n<p>Regression:</p>\n<ul><li>dimension serializer changes do not collapse bounds into strings or lose unit typing</li><li>provider adapter updates preserve measurement provenance in `assigned_by`</li></ul>\n<h3 id=\"fixture-anchors-shared-dimensions-examples\">Fixture Anchors — Shared Dimensions Examples</h3>\n<p>Use these shared-dimension patterns as fixture seeds:</p>\n<ol><li>Minimal valid dimension</li></ol>\n<ul><li>`type`, numeric `value`, and valid `MeasurementUnit`.</li></ul>\n<ol><li>Uncertain dimension fixture</li></ol>\n<ul><li>dimension with `lower_value_limit` and `upper_value_limit`.</li></ul>\n<ol><li>Display-name fixture</li></ol>\n<ul><li>`identified_by` name expressing human-readable measurement string.</li></ul>\n<ol><li>Measurement provenance fixture</li></ol>\n<ul><li>`assigned_by` measurement activity with classifier and measuring actor.</li></ul>\n<ol><li>Partial dimension fixture</li></ol>\n<ul><li>embedded dimension with dereferenceable `id` and `_complete: false`.</li></ul>\n<ol><li>Duration dimension fixture</li></ol>\n<ul><li>`TimeSpan` duration represented as a dimension with unit and numeric value.</li></ul>\n<p>---</p>\n<h2 id=\"round-49-addendum-shared-structure-concept-references\">Round 49 Addendum — Shared Structure: Concept References</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Concept References</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Concept references (Types) are core embedded structures across almost all entities.</li><li>Required fields for embedded concept reference:</li><li>`id` (URI)</li><li>`type` in allowlist: `Type`, `Currency`, `Language`, `Material`, `MeasurementUnit`</li><li>Recommended:</li><li>`_label`</li><li>Optional:</li><li>`equivalent`</li><li>`notation` (commonly used especially for `Language` tags)</li><li>`classified_as` (meta-classification of concept)</li><li>Specialized concept-reference classes:</li><li>`Language` for human language</li><li>`Material` for physical composition</li><li>`Currency` for monetary amounts</li><li>`MeasurementUnit` for dimensions</li><li>Full standalone concept records are handled by the Concept endpoint; this shared structure is for embedded references.</li></ul>\n<h3 id=\"implementation-mapping-shared-concept-references\">Implementation Mapping — Shared Concept References</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Concept type allowlist enforcement</li></ol>\n<ul><li>Enforce strict embedded concept-reference `type` allowlist at validation boundary.</li></ul>\n<ol><li>URI-first identity</li></ol>\n<ul><li>Preserve canonical concept `id` URIs as authoritative identity keys for cross-dataset interoperability.</li></ul>\n<ol><li>Meta-classification preservation</li></ol>\n<ul><li>Preserve `classified_as` on concept references to support meta-typing (for example “Painting” classified as “Type of Work”).</li></ul>\n<ol><li>Notation handling</li></ol>\n<ul><li>Preserve `notation` values, especially for language tags/codes, without replacing URI identity semantics.</li></ul>\n<ol><li>Embedded-vs-full-record separation</li></ol>\n<ul><li>Keep embedded concept references lightweight; use Concept endpoint for full concept expansion.</li></ul>\n<h3 id=\"tdd-additions-shared-concept-references\">TDD Additions — Shared Concept References</h3>\n<p>Add failing-first tests for concept-reference conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `id` + `type` for embedded concept references</li><li>validates `type` is in allowed concept-reference class set</li><li>validates optional `notation`, `equivalent`, and nested `classified_as` structures</li></ul>\n<p>Route-level:</p>\n<ul><li>all endpoint payloads embedding concepts conform to shared concept-reference schema</li><li>malformed concept references fail boundary validation with explicit path-level errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>concept references resolve consistently across:</li><li>`classified_as` (all entities)</li><li>`technique` / `influenced_by` (activities)</li><li>`about` (textual/visual works)</li><li>`language` (linguistic objects)</li><li>`currency` (monetary amounts)</li><li>`unit` (dimensions)</li><li>`made_of` (objects/material composition)</li></ul>\n<p>Regression:</p>\n<ul><li>provider adapter updates do not drift concept reference typing or URI identity behavior</li><li>meta-classification fixtures remain stable across endpoint families</li></ul>\n<h3 id=\"fixture-anchors-shared-concept-references-examples\">Fixture Anchors — Shared Concept References Examples</h3>\n<p>Use these concept-reference patterns as fixture seeds:</p>\n<ol><li>Minimal type reference</li></ol>\n<ul><li>embedded `Type` with required URI `id` and `type`.</li></ul>\n<ol><li>Meta-typed concept fixture</li></ol>\n<ul><li>concept with nested `classified_as` meta-type (for example work type hierarchy).</li></ul>\n<ol><li>Language reference fixture</li></ol>\n<ul><li>`Language` with notation tag/code plus label.</li></ul>\n<ol><li>Currency reference fixture</li></ol>\n<ul><li>`Currency` used in monetary amount structure.</li></ul>\n<ol><li>Measurement unit fixture</li></ol>\n<ul><li>`MeasurementUnit` used in dimension structure.</li></ul>\n<ol><li>Material reference fixture</li></ol>\n<ul><li>`Material` used in object `made_of` array.</li></ul>\n<p>---</p>\n<h2 id=\"round-50-addendum-shared-structure-identifiers\">Round 50 Addendum — Shared Structure: Identifiers</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Identifiers</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Identifiers are non-natural-language codes assigned to resources in context.</li><li>Shared identifier structure is separate from Names:</li><li>no `language`</li><li>no translation/alternative-form semantics like names</li><li>Required fields:</li><li>`type` must be `Identifier`</li><li>`content` must be string</li><li>Optional/recommended:</li><li>`id`, `_label`, `_complete`</li><li>`classified_as`, `identified_by` (display name for identifier), `referred_to_by`, `assigned_by`</li><li>`_complete: false` is required when embedded identifier with dereferenceable `id` is partial and richer remote form exists.</li><li>Incoming usage:</li><li>`identified_by` across all endpoints</li><li>`contact_point` for Person/Group endpoints</li></ul>\n<h3 id=\"implementation-mapping-shared-identifiers\">Implementation Mapping — Shared Identifiers</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type/content strictness</li></ol>\n<ul><li>Enforce `type=Identifier` and required string `content` at boundary validation.</li></ul>\n<ol><li>Identifier-vs-name separation</li></ol>\n<ul><li>Keep identifier semantics distinct from Name semantics (no language/translation assumptions).</li></ul>\n<ol><li>Classification fidelity</li></ol>\n<ul><li>Preserve identifier type classifications (for example accession number, ISBN) via `classified_as`.</li></ul>\n<ol><li>Assignment provenance</li></ol>\n<ul><li>Preserve `assigned_by` assignment activities with timespan/actor context where available.</li></ul>\n<ol><li>Partial embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for embedded identifiers with dereferenceable IDs and incomplete inline payload.</li></ul>\n<ol><li>Contact point reuse</li></ol>\n<ul><li>Reuse Identifier shared contract for `contact_point` fields on Person/Group endpoints.</li></ul>\n<h3 id=\"tdd-additions-shared-identifiers\">TDD Additions — Shared Identifiers</h3>\n<p>Add failing-first tests for identifier structure conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type=Identifier` + string `content`</li><li>rejects identifier payloads with invalid/non-string content</li><li>validates optional classification/display-name/assignment fields</li><li>validates `_complete: false` requirement for partial embedded identifiers with resolvable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>all endpoint payloads embedding identifiers conform to shared identifier schema</li><li>malformed identifier/classification/assignment blocks fail boundary validation with explicit path-level errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>identifier structures resolve consistently through `identified_by` across endpoint families</li><li>person/group `contact_point` fields validate and serialize as identifiers</li></ul>\n<p>Regression:</p>\n<ul><li>provider adapter updates do not collapse identifiers into names or lose assignment provenance</li><li>classification fixtures (accession/ISBN/etc.) remain stable across endpoints</li></ul>\n<h3 id=\"fixture-anchors-shared-identifiers-examples\">Fixture Anchors — Shared Identifiers Examples</h3>\n<p>Use these shared-identifier patterns as fixture seeds:</p>\n<ol><li>Minimal valid identifier</li></ol>\n<ul><li>`type: Identifier` with required string `content`.</li></ul>\n<ol><li>Classified identifier fixture</li></ol>\n<ul><li>identifier classified as accession/ISBN style concept.</li></ul>\n<ol><li>Display-name fixture</li></ol>\n<ul><li>identifier with `identified_by` name for UI display semantics.</li></ul>\n<ol><li>Assignment provenance fixture</li></ol>\n<ul><li>identifier with `assigned_by` activity including timespan and assigning group/person.</li></ul>\n<ol><li>Partial identifier fixture</li></ol>\n<ul><li>embedded identifier with dereferenceable `id` and `_complete: false`.</li></ul>\n<ol><li>Contact-point fixture</li></ol>\n<ul><li>person/group `contact_point` modeled and validated as identifier structure.</li></ul>\n<p>---</p>\n<h2 id=\"round-51-addendum-shared-structure-monetary-amounts\">Round 51 Addendum — Shared Structure: Monetary Amounts</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Monetary Amounts</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Monetary Amounts parallel Dimensions but use `currency` instead of `unit`.</li><li>Required fields:</li><li>`type` must be `MonetaryAmount`</li><li>numeric `value`</li><li>required `currency` (must follow Currency concept-reference rules)</li><li>Optional/recommended:</li><li>`id`, `_label`, `_complete`</li><li>`classified_as`, `identified_by`, `upper_value_limit`, `lower_value_limit`, `referred_to_by`</li><li>`_complete: false` is required when embedded amount has dereferenceable `id` and richer remote representation exists.</li><li>Primary usage in Linked Art model/API:</li><li>`paid_amount` within Provenance `Payment` parts</li><li>also usable as `dimension` in other contexts (for example set-level pricing/valuation signals)</li></ul>\n<h3 id=\"implementation-mapping-shared-monetary-amounts\">Implementation Mapping — Shared Monetary Amounts</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type/value/currency strictness</li></ol>\n<ul><li>Enforce `type=MonetaryAmount`, numeric `value`, and required `currency` at boundary validation.</li></ul>\n<ol><li>Currency integrity</li></ol>\n<ul><li>Require `currency.type=Currency` and preserve authoritative concept URI/notation (for example ISO code notation).</li></ul>\n<ol><li>Uncertainty bounds support</li></ol>\n<ul><li>Preserve optional `upper_value_limit` and `lower_value_limit` for uncertain/estimated amounts.</li></ul>\n<ol><li>Display-text separation</li></ol>\n<ul><li>Preserve `identified_by` display text without replacing canonical numeric+currency representation.</li></ul>\n<ol><li>Provenance payment wiring</li></ol>\n<ul><li>Preserve `paid_amount` semantics inside provenance `Payment` parts without flattening into generic note fields.</li></ul>\n<ol><li>Partial embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for embedded partial monetary amount nodes with dereferenceable IDs.</li></ul>\n<h3 id=\"tdd-additions-shared-monetary-amounts\">TDD Additions — Shared Monetary Amounts</h3>\n<p>Add failing-first tests for monetary amount conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type=MonetaryAmount`, numeric `value`, and `currency` reference structure</li><li>validates optional bounds (`upper_value_limit`, `lower_value_limit`) as numeric</li><li>validates optional classification/display/reference fields</li><li>validates `_complete: false` requirement for partial embedded monetary amounts with resolvable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>provenance/payment payloads embedding `paid_amount` conform to shared monetary schema</li><li>malformed value/currency/bounds payloads fail boundary validation with explicit path-level errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>provenance `Payment` parts preserve paid amount and currency semantics end-to-end</li><li>set/object dimension contexts using monetary amounts remain compatible with shared dimension pipelines</li></ul>\n<p>Regression:</p>\n<ul><li>serializer updates do not collapse monetary amounts into raw strings</li><li>currency URI and notation handling remain stable across provider adapters</li></ul>\n<h3 id=\"fixture-anchors-shared-monetary-amounts-examples\">Fixture Anchors — Shared Monetary Amounts Examples</h3>\n<p>Use these shared monetary patterns as fixture seeds:</p>\n<ol><li>Minimal valid monetary amount</li></ol>\n<ul><li>required `type`, numeric `value`, and `currency`.</li></ul>\n<ol><li>Classified amount fixture</li></ol>\n<ul><li>amount classified as starting price/estimate/hammer price.</li></ul>\n<ol><li>Display-title fixture</li></ol>\n<ul><li>amount with `identified_by` display name text.</li></ul>\n<ol><li>Uncertainty fixture</li></ol>\n<ul><li>amount with lower/upper value bounds.</li></ul>\n<ol><li>Payment integration fixture</li></ol>\n<ul><li>provenance `Payment.paid_amount` with payer/payee links.</li></ul>\n<ol><li>Partial amount fixture</li></ol>\n<ul><li>embedded amount with dereferenceable `id` and `_complete: false`.</li></ul>\n<p>---</p>\n<h2 id=\"round-52-addendum-shared-structure-names\">Round 52 Addendum — Shared Structure: Names</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Names</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Names are linguistic labels for entities and are shared across all endpoints.</li><li>Required fields:</li><li>`type` must be `Name`</li><li>`content` must be string</li><li>Recommended/optional:</li><li>`classified_as`, `language` (recommended)</li><li>`id`, `_label`, `_complete`, `part`, `identified_by`, `referred_to_by`, `assigned_by`</li><li>`_complete: false` is required when embedded name has dereferenceable `id` and richer remote representation exists.</li><li>Names can be decomposed via recursive `part` structures (for example subtitle component).</li><li>Unlike Identifiers, Names are linguistic and language-tag-aware.</li></ul>\n<h3 id=\"implementation-mapping-shared-names\">Implementation Mapping — Shared Names</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type/content strictness</li></ol>\n<ul><li>Enforce `type=Name` and required string `content` at boundary validation.</li></ul>\n<ol><li>Name-vs-identifier separation</li></ol>\n<ul><li>Keep Name semantics linguistic (with optional language) and separate from Identifier code semantics.</li></ul>\n<ol><li>Language fidelity</li></ol>\n<ul><li>Preserve one or more `language` references/notations for multilingual name handling.</li></ul>\n<ol><li>Recursive name-part support</li></ol>\n<ul><li>Preserve `part` arrays as nested Name structures for compound/appellative names.</li></ul>\n<ol><li>Classification fidelity</li></ol>\n<ul><li>Preserve `classified_as` distinctions (primary name, subtitle, display title, etc.).</li></ul>\n<ol><li>Partial embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for embedded partial name nodes with dereferenceable IDs.</li></ul>\n<ol><li>Assignment readiness</li></ol>\n<ul><li>Support optional `assigned_by` structure even if use cases are currently limited.</li></ul>\n<h3 id=\"tdd-additions-shared-names\">TDD Additions — Shared Names</h3>\n<p>Add failing-first tests for name structure conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type=Name` + string `content`</li><li>validates optional language/classification/referred_to_by/identified_by fields</li><li>validates recursive `part` structures as Name-only nested nodes</li><li>validates `_complete: false` requirement for partial embedded names with resolvable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>endpoint payloads embedding names conform to shared name schema</li><li>malformed name/language/part payloads fail boundary validation with explicit path-level errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>multilingual names remain stable across object/person/group/place/textual/visual endpoints</li><li>display-name patterns (`identified_by` on names) remain consistent for UI surfaces</li></ul>\n<p>Regression:</p>\n<ul><li>updates do not collapse linguistic names into identifier semantics</li><li>nested-name part fixtures remain stable across provider adapter updates</li></ul>\n<h3 id=\"fixture-anchors-shared-names-examples\">Fixture Anchors — Shared Names Examples</h3>\n<p>Use these shared-name patterns as fixture seeds:</p>\n<ol><li>Minimal valid name</li></ol>\n<ul><li>`type: Name` with required `content`.</li></ul>\n<ol><li>Classified primary name fixture</li></ol>\n<ul><li>name classified as primary name.</li></ul>\n<ol><li>Multilingual name fixture</li></ol>\n<ul><li>single name with multiple language references/notations.</li></ul>\n<ol><li>Nested part fixture</li></ol>\n<ul><li>compound name with subtitle `part` node.</li></ul>\n<ol><li>Display-title fixture</li></ol>\n<ul><li>name `identified_by` another name classified as display title.</li></ul>\n<ol><li>Partial name fixture</li></ol>\n<ul><li>embedded name with dereferenceable `id` and `_complete: false`.</li></ul>\n<p>---</p>\n<h2 id=\"round-53-addendum-shared-structure-rights\">Round 53 Addendum — Shared Structure: Rights</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Rights</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Rights structure represents machine-comparable rights assertions for intellectual works.</li><li>Required fields:</li><li>`type` must be `Right`</li><li>Recommended/optional:</li><li>`identified_by`, `classified_as` (recommended)</li><li>`id`, `_label`, `_complete`, `referred_to_by`, `possessed_by`</li><li>Rights class/type semantics are conveyed through `classified_as` concept references (for example CC URIs).</li><li>`_complete: false` required when embedded right has dereferenceable `id` and richer remote representation exists.</li><li>Incoming usage emphasized:</li><li>`subject_to` on intellectual resources (Textual Work, Visual Work, Abstract Work, Statement)</li></ul>\n<h3 id=\"implementation-mapping-shared-rights\">Implementation Mapping — Shared Rights</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Enforce `type=Right` at boundary validation for all embedded rights structures.</li></ul>\n<ol><li>Rights-classification fidelity</li></ol>\n<ul><li>Preserve `classified_as` URIs as canonical machine-comparable rights descriptors.</li></ul>\n<ol><li>Human-readable display support</li></ol>\n<ul><li>Preserve `identified_by` names (for example “Public Domain”) for UI and downstream reporting.</li></ul>\n<ol><li>Holder modeling</li></ol>\n<ul><li>Preserve optional `possessed_by` actor references where right-holder context is provided.</li></ul>\n<ol><li>Partial embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for partial embedded rights nodes with dereferenceable IDs.</li></ul>\n<ol><li>Subject linkage integrity</li></ol>\n<ul><li>Preserve `subject_to` edges on intellectual works without flattening rights into unstructured string fields.</li></ul>\n<h3 id=\"tdd-additions-shared-rights\">TDD Additions — Shared Rights</h3>\n<p>Add failing-first tests for rights structure conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type=Right`</li><li>validates recommended `classified_as` and `identified_by` structures when present</li><li>validates optional `possessed_by` actor references</li><li>validates `_complete: false` requirement for partial embedded rights with resolvable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>endpoint payloads embedding rights through `subject_to` conform to shared rights schema</li><li>malformed rights/classification/holder payloads fail boundary validation with explicit path-level errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>textual/visual/abstract/statement endpoints preserve consistent `subject_to` rights modeling</li><li>rights classifications remain interoperable with concept-reference rules and external rights vocab URIs</li></ul>\n<p>Regression:</p>\n<ul><li>provider adapter updates do not collapse structured rights blocks into plain text</li><li>rights display labels and machine-readable URIs remain synchronized in snapshots</li></ul>\n<h3 id=\"fixture-anchors-shared-rights-examples\">Fixture Anchors — Shared Rights Examples</h3>\n<p>Use these shared-rights patterns as fixture seeds:</p>\n<ol><li>Minimal valid right</li></ol>\n<ul><li>embedded right with required `type`.</li></ul>\n<ol><li>Classified rights fixture</li></ol>\n<ul><li>right classified with external rights URI (for example CC0).</li></ul>\n<ol><li>Display title fixture</li></ol>\n<ul><li>right with `identified_by` display title name.</li></ul>\n<ol><li>Holder fixture</li></ol>\n<ul><li>right with `possessed_by` person/group references.</li></ul>\n<ol><li>Subject linkage fixture</li></ol>\n<ul><li>textual/visual/abstract resource linked via `subject_to` to right.</li></ul>\n<ol><li>Partial right fixture</li></ol>\n<ul><li>embedded right with dereferenceable `id` and `_complete: false`.</li></ul>\n<p>---</p>\n<h2 id=\"round-54-addendum-shared-structure-references\">Round 54 Addendum — Shared Structure: References</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: References</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>References are lightweight cross-resource links and must remain clearly distinct from embedded full structures.</li><li>Canonical reference shape:</li><li>required `id` (dereferenceable URI)</li><li>required `type` (must match dereferenced resource type)</li><li>recommended `_label`</li><li>Reference semantics:</li><li>references are inherently incomplete and do not include `_complete`</li><li>dereferencing should yield canonical record with same `id` and `type`</li><li>Allowed optional enrichments on references:</li><li>`equivalent` for external-system identity alignment</li><li>`notation` (especially language tags/codes for language references)</li><li>Types are a special reference case and may include meta-classification to support processing when external vocab resources are not Linked Art-native.</li><li>Client guidance from spec:</li><li>proactively follow references and pre-cache descriptions for responsive UI behavior.</li></ul>\n<h3 id=\"implementation-mapping-shared-references\">Implementation Mapping — Shared References</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict reference envelope</li></ol>\n<ul><li>Treat `id`/`type`/`_label` (+ optional `equivalent`/`notation`) as the only valid reference payload shape.</li></ul>\n<ol><li>No `_complete` on references</li></ol>\n<ul><li>Do not emit `_complete` for references; reserve `_complete` logic for partially embedded shared structures.</li></ul>\n<ol><li>Type identity consistency</li></ol>\n<ul><li>Enforce that reference `type` matches dereferenced record `type` in validation/integration checks.</li></ul>\n<ol><li>Embedded-vs-reference boundary</li></ol>\n<ul><li>Reject hybrid payloads that mix reference-only shape with embedded-structure-only fields.</li></ul>\n<ol><li>External equivalence handling</li></ol>\n<ul><li>Preserve optional `equivalent` links for reconciliation without replacing local canonical IDs.</li></ul>\n<ol><li>Language notation support</li></ol>\n<ul><li>Preserve `notation` when references are language concepts to aid i18n consumers.</li></ul>\n<ol><li>Fetch/caching readiness</li></ol>\n<ul><li>Keep references stable and minimal so clients can dereference/cross-cache deterministically.</li></ul>\n<h3 id=\"tdd-additions-shared-references\">TDD Additions — Shared References</h3>\n<p>Add failing-first tests for reference conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `id` + `type` for all reference nodes</li><li>validates absence of `_complete` on references</li><li>validates optional `_label`, `equivalent`, `notation` fields</li><li>rejects embedded-only fields on reference nodes</li></ul>\n<p>Route-level:</p>\n<ul><li>endpoint payloads emit reference nodes in canonical lightweight shape</li><li>malformed references fail boundary validation with explicit path-level diagnostics</li></ul>\n<p>Integration-level:</p>\n<ul><li>dereferenced records match reference `id` + `type`</li><li>cross-endpoint traversal via references remains stable (object-&gt;owner/place/set/work etc.)</li><li>language reference notations round-trip for i18n usage</li></ul>\n<p>Regression:</p>\n<ul><li>provider updates do not accidentally expand references into inconsistent partial embeds</li><li>reference serializer remains consistent across all endpoint families</li></ul>\n<h3 id=\"fixture-anchors-shared-references-examples\">Fixture Anchors — Shared References Examples</h3>\n<p>Use these shared-reference patterns as fixture seeds:</p>\n<ol><li>Minimal valid reference</li></ol>\n<ul><li>reference with required `id` and `type`.</li></ul>\n<ol><li>Labeled reference fixture</li></ol>\n<ul><li>reference including recommended `_label`.</li></ul>\n<ol><li>Equivalent-link fixture</li></ol>\n<ul><li>local reference with `equivalent` external authority URI.</li></ul>\n<ol><li>Language notation fixture</li></ol>\n<ul><li>language reference with notation tag/code.</li></ul>\n<ol><li>Reference-vs-embed negative fixture</li></ol>\n<ul><li>payload wrongly combining reference shape with embedded-only fields is rejected.</li></ul>\n<ol><li>Dereference consistency fixture</li></ol>\n<ul><li>referenced resource resolves with matching `id` and `type`.</li></ul>\n<p>---</p>\n<h2 id=\"round-55-addendum-shared-structure-statements\">Round 55 Addendum — Shared Structure: Statements</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Statements</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Statements are embedded human-readable textual expressions about entities.</li><li>Required fields:</li><li>`type` must be `LinguisticObject`</li><li>`content` must be string</li><li>Recommended/optional:</li><li>`classified_as`, `language`, `identified_by` (recommended)</li><li>`id`, `_label`, `_complete`, `referred_to_by`, `format`, `assigned_by`, `subject_to`, `created_by`</li><li>`_complete: false` required when embedded statement has dereferenceable `id` and richer remote representation exists.</li><li>Primary incoming usage:</li><li>`referred_to_by` across essentially all endpoint families.</li><li>Statements support both:</li><li>internationalized textual content (`language`)</li><li>structured rights over statement text (`subject_to`)</li></ul>\n<h3 id=\"implementation-mapping-shared-statements\">Implementation Mapping — Shared Statements</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type/content strictness</li></ol>\n<ul><li>Enforce `type=LinguisticObject` and required string `content` for statement nodes.</li></ul>\n<ol><li>Statement-vs-textual-work boundary</li></ol>\n<ul><li>Keep embedded statement semantics distinct from standalone Textual Work endpoint records.</li></ul>\n<ol><li>Classification and language fidelity</li></ol>\n<ul><li>Preserve statement purpose classification (description/note/etc.) and language references/notations.</li></ul>\n<ol><li>Format-aware content handling</li></ol>\n<ul><li>Preserve optional `format` when `content` is non-plain text media.</li></ul>\n<ol><li>Rights and provenance support</li></ol>\n<ul><li>Preserve `subject_to`, `assigned_by`, and `created_by` for statement governance/provenance.</li></ul>\n<ol><li>Nested statement support</li></ol>\n<ul><li>Preserve `referred_to_by` on statements for statement-about-statement use cases.</li></ul>\n<ol><li>Partial embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for partial embedded statements with dereferenceable IDs.</li></ul>\n<h3 id=\"tdd-additions-shared-statements\">TDD Additions — Shared Statements</h3>\n<p>Add failing-first tests for statement structure conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type=LinguisticObject` + string `content`</li><li>validates recommended classification/language/identified_by structures</li><li>validates optional `format`, `subject_to`, `assigned_by`, `created_by`, nested `referred_to_by`</li><li>validates `_complete: false` requirement for partial embedded statements with resolvable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>endpoint payloads embedding statements via `referred_to_by` conform to shared statement schema</li><li>malformed statement/language/rights/format payloads fail boundary validation with explicit path-level errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>statement rights (`subject_to`) interoperate with shared rights structure across endpoint families</li><li>statement language and display-name behavior remains stable in UI-facing payloads</li></ul>\n<p>Regression:</p>\n<ul><li>provider adapter updates do not collapse structured statements into plain strings</li><li>nested statement fixtures remain stable across endpoint serializers</li></ul>\n<h3 id=\"fixture-anchors-shared-statements-examples\">Fixture Anchors — Shared Statements Examples</h3>\n<p>Use these shared-statement patterns as fixture seeds:</p>\n<ol><li>Minimal valid statement</li></ol>\n<ul><li>`type: LinguisticObject` with required `content`.</li></ul>\n<ol><li>Classified description fixture</li></ol>\n<ul><li>statement classified as description/brief text.</li></ul>\n<ol><li>Multilingual statement fixture</li></ol>\n<ul><li>statement with language references and notation.</li></ul>\n<ol><li>Rights-on-statement fixture</li></ol>\n<ul><li>statement with `subject_to` right classification and display name.</li></ul>\n<ol><li>Nested statement fixture</li></ol>\n<ul><li>statement with `referred_to_by` note about provenance/source of statement.</li></ul>\n<ol><li>Partial statement fixture</li></ol>\n<ul><li>embedded statement with dereferenceable `id` and `_complete: false`.</li></ul>\n<p>---</p>\n<h2 id=\"round-56-addendum-shared-structure-timespans\">Round 56 Addendum — Shared Structure: TimeSpans</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: TimeSpans</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>TimeSpans model fuzzy temporal boundaries for events/activities and related temporal entities.</li><li>Required field:</li><li>`type` must be `TimeSpan`</li><li>Recommended/optional fields:</li><li>`identified_by`, `begin_of_the_begin`, `end_of_the_end` (recommended)</li><li>`id`, `_label`, `_complete`, `classified_as`, `end_of_the_begin`, `begin_of_the_end`, `referred_to_by`, `duration`</li><li>Critical minimum-information rule:</li><li>each TimeSpan must include at least one of:</li><li>`identified_by`</li><li>`begin_of_the_begin`</li><li>`end_of_the_end`</li><li>Fuzzy boundary semantics:</li><li>`begin_of_the_begin` = earliest possible start</li><li>`end_of_the_begin` = latest possible start</li><li>`begin_of_the_end` = earliest possible end</li><li>`end_of_the_end` = latest possible end</li><li>`duration` is a Dimension structure describing interval length.</li><li>`_complete: false` required when embedded timespan has dereferenceable `id` and richer remote representation exists.</li></ul>\n<h3 id=\"implementation-mapping-shared-timespans\">Implementation Mapping — Shared TimeSpans</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type strictness</li></ol>\n<ul><li>Enforce `type=TimeSpan` at boundary validation.</li></ul>\n<ol><li>Minimum-information guard</li></ol>\n<ul><li>Enforce “at least one of `identified_by` / `begin_of_the_begin` / `end_of_the_end`” to prevent empty/ambiguous timespan nodes.</li></ul>\n<ol><li>ISO timestamp fidelity</li></ol>\n<ul><li>Preserve timestamp fields as ISO8601 strings without lossy locale/date parsing transforms.</li></ul>\n<ol><li>Fuzzy-bound semantics preservation</li></ol>\n<ul><li>Preserve all four boundary fields distinctly; do not collapse to single start/end fields.</li></ul>\n<ol><li>Duration integration</li></ol>\n<ul><li>Preserve optional `duration` as shared Dimension structure with proper unit typing.</li></ul>\n<ol><li>Partial embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for partial embedded timespans with dereferenceable IDs.</li></ul>\n<h3 id=\"tdd-additions-shared-timespans\">TDD Additions — Shared TimeSpans</h3>\n<p>Add failing-first tests for timespan conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type=TimeSpan`</li><li>validates minimum-information rule (at least one key field present)</li><li>validates optional fuzzy boundary fields as ISO8601 date-time strings</li><li>validates optional `duration` structure via shared Dimension schema</li><li>validates `_complete: false` requirement for partial embedded timespans with resolvable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>endpoint payloads embedding `timespan` conform to shared timespan schema</li><li>malformed/empty timespan nodes fail boundary validation with explicit path-level errors</li></ul>\n<p>Integration-level:</p>\n<ul><li>activity/event/provenance/person/group/object lifecycle time fields remain interoperable via shared timespan rules</li><li>duration dimensions on timespans remain consistent with shared dimension processing</li></ul>\n<p>Regression:</p>\n<ul><li>provider updates do not collapse fuzzy temporal bounds into single-point dates</li><li>snapshot fixtures preserve all boundary semantics and minimum-information behavior</li></ul>\n<h3 id=\"fixture-anchors-shared-timespans-examples\">Fixture Anchors — Shared TimeSpans Examples</h3>\n<p>Use these shared-timespan patterns as fixture seeds:</p>\n<ol><li>Minimal valid timespan (label-only)</li></ol>\n<ul><li>`type=TimeSpan` plus `identified_by` display name.</li></ul>\n<ol><li>Minimal valid timespan (boundary-only)</li></ol>\n<ul><li>`type=TimeSpan` plus `begin_of_the_begin` and/or `end_of_the_end`.</li></ul>\n<ol><li>Full fuzzy-bound fixture</li></ol>\n<ul><li>all four boundary fields populated for uncertainty windows.</li></ul>\n<ol><li>Duration fixture</li></ol>\n<ul><li>timespan with `duration` dimension and measurement unit.</li></ul>\n<ol><li>Descriptive statement fixture</li></ol>\n<ul><li>timespan with `referred_to_by` explanatory statement.</li></ul>\n<ol><li>Partial timespan fixture</li></ol>\n<ul><li>embedded timespan with dereferenceable `id` and `_complete: false`.</li></ul>\n<ol><li>Invalid-empty fixture</li></ol>\n<ul><li>timespan missing `identified_by` + missing both key bounds, expected to fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-57-addendum-shared-structure-relationships-attributeassignment\">Round 57 Addendum — Shared Structure: Relationships (AttributeAssignment)</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Relationships</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Arbitrary/non-semantic or context-specific relationships are modeled via `AttributeAssignment`.</li><li>Required fields:</li><li>`type` must be `AttributeAssignment`</li><li>`assigned` must be present as references to related entities</li><li>Optional/recommended:</li><li>`identified_by`, `classified_as` (recommended)</li><li>`id`, `_label`, `_complete`, `referred_to_by`, `carried_out_by`, `timespan`, temporal ordering/context fields</li><li>`influenced_by`, `caused_by`, `used_specific_object`, `technique`</li><li>`assigned_property` optional URI/curie-like string for explicit relationship predicate</li><li>Modeling note:</li><li>`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).</li><li>Incoming usage:</li><li>`attributed_by` across all endpoints</li><li>`assigned_by` specifically for Dimension/Identifier assignment activities</li></ul>\n<h3 id=\"implementation-mapping-shared-relationships\">Implementation Mapping — Shared Relationships</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Type/assigned strictness</li></ol>\n<ul><li>Enforce `type=AttributeAssignment` and required non-empty `assigned` reference array.</li></ul>\n<ol><li>Predicate capture</li></ol>\n<ul><li>Preserve `assigned_property` when provided to retain explicit predicate semantics.</li></ul>\n<ol><li>Context/provenance fidelity</li></ol>\n<ul><li>Preserve actor/time/cause/influence/object context fields to support explainable relationship provenance.</li></ul>\n<ol><li>Relationship-vs-assignment boundary</li></ol>\n<ul><li>Route Dimension/Identifier assignment scenarios to dedicated assignment pathways rather than generic `assigned` relation modeling.</li></ul>\n<ol><li>Partial embed signaling</li></ol>\n<ul><li>Enforce `_complete: false` for partial embedded assignments with dereferenceable IDs.</li></ul>\n<ol><li>Cross-endpoint consistency</li></ol>\n<ul><li>Keep `attributed_by` handling consistent across all endpoint families.</li></ul>\n<h3 id=\"tdd-additions-shared-relationships\">TDD Additions — Shared Relationships</h3>\n<p>Add failing-first tests for relationship-assignment conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `type=AttributeAssignment` and required `assigned` references</li><li>validates optional `assigned_property` format and context/provenance fields</li><li>rejects malformed/missing assigned target references</li><li>enforces guardrail that Dimension/Identifier assignments are not represented via generic `assigned` misuse</li><li>validates `_complete: false` requirement for partial embedded assignments with resolvable IDs</li></ul>\n<p>Route-level:</p>\n<ul><li>endpoint payloads embedding `attributed_by` conform to shared relationship-assignment schema</li><li>malformed assignment nodes fail boundary validation with explicit path-level diagnostics</li></ul>\n<p>Integration-level:</p>\n<ul><li>`attributed_by` traversals resolve assigned entities consistently across endpoints</li><li>Dimension/Identifier `assigned_by` flows remain distinct and interoperable with their dedicated shared structures</li></ul>\n<p>Regression:</p>\n<ul><li>provider adapter updates do not flatten relationship assignments into untyped “related items” arrays</li><li>explicit `assigned_property` predicates remain stable when present</li></ul>\n<h3 id=\"fixture-anchors-shared-relationships-examples\">Fixture Anchors — Shared Relationships Examples</h3>\n<p>Use these shared-relationship patterns as fixture seeds:</p>\n<ol><li>Minimal valid assignment</li></ol>\n<ul><li>`type=AttributeAssignment` with one `assigned` reference.</li></ul>\n<ol><li>Predicate assignment fixture</li></ol>\n<ul><li>assignment with explicit `assigned_property` URI string.</li></ul>\n<ol><li>Curated recommendation fixture</li></ol>\n<ul><li>assignment classified as recommendation with carried_out_by curator.</li></ul>\n<ol><li>Temporal/provenance fixture</li></ol>\n<ul><li>assignment including timespan, influenced_by, caused_by, used_specific_object.</li></ul>\n<ol><li>Partial assignment fixture</li></ol>\n<ul><li>embedded assignment with dereferenceable `id` and `_complete: false`.</li></ul>\n<ol><li>Guardrail negative fixture</li></ol>\n<ul><li>invalid use of generic `assigned` for identifier/dimension assignment should fail or be remapped.</li></ul>\n<p>---</p>\n<h2 id=\"round-58-addendum-about-schemas\">Round 58 Addendum — About Schemas</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: About Schemas</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Linked Art publishes JSON Schema definitions (plus generated HTML docs) for the core endpoint families:</li><li>Abstract Work</li><li>Concept</li><li>Digital Object</li><li>Event/Activity</li><li>Group</li><li>Person</li><li>Physical Object</li><li>Place</li><li>Provenance Activity</li><li>Set</li><li>Textual Work</li><li>Visual Work</li><li>These schemas are the normative machine-checkable contract layer for endpoint payload conformance.</li></ul>\n<h3 id=\"implementation-mapping-schemas\">Implementation Mapping — Schemas</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Schema-canonical contract policy</li></ol>\n<ul><li>Treat the endpoint schema set as canonical contract references for all route payload validation.</li></ul>\n<ol><li>Endpoint-to-schema matrix</li></ol>\n<ul><li>Maintain explicit mapping from each project API route/serializer to the corresponding Linked Art schema family.</li></ul>\n<ol><li>Shared-structure composition</li></ol>\n<ul><li>Ensure endpoint schemas compose shared structures consistently (names, identifiers, timespans, references, rights, etc.).</li></ul>\n<ol><li>Drift detection</li></ol>\n<ul><li>Add safeguards for schema drift between route handlers, contracts, and fixture expectations.</li></ul>\n<ol><li>Human + machine docs parity</li></ol>\n<ul><li>Keep generated/internal docs aligned with machine validation behavior for dev clarity.</li></ul>\n<h3 id=\"tdd-additions-schemas\">TDD Additions — Schemas</h3>\n<p>Add failing-first tests for schema-governed conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates each endpoint payload against its corresponding Linked Art schema family</li><li>validates shared-structure reuse across endpoint schemas</li></ul>\n<p>Route-level:</p>\n<ul><li>each public endpoint has schema conformance tests for success and failure cases</li><li>boundary validation errors include actionable field paths</li></ul>\n<p>Integration-level:</p>\n<ul><li>cross-endpoint traversals preserve schema-valid reference shapes</li><li>provenance and shared-structure heavy payloads validate under composed schema rules</li></ul>\n<p>Regression:</p>\n<ul><li>snapshot tests detect breaking schema-shape changes</li><li>provider adapter updates cannot bypass schema validation gates</li></ul>\n<h3 id=\"fixture-anchors-schemas-examples\">Fixture Anchors — Schemas Examples</h3>\n<p>Use these schema-level anchors as fixture seeds:</p>\n<ol><li>Per-endpoint golden fixtures</li></ol>\n<ul><li>one canonical valid fixture per endpoint family listed above.</li></ul>\n<ol><li>Negative schema fixtures</li></ol>\n<ul><li>one invalid payload per endpoint proving boundary rejection behavior.</li></ul>\n<ol><li>Shared-structure composition fixtures</li></ol>\n<ul><li>payloads stress-testing nested shared structures inside endpoint records.</li></ul>\n<ol><li>Cross-reference fixtures</li></ol>\n<ul><li>payloads with dense references validating link-shape and type consistency.</li></ul>\n<p>---</p>\n<h2 id=\"round-59-addendum-abstract-work-schema\">Round 59 Addendum — Abstract Work Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Abstract Work Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E89_Propositional_Object`</li><li>purely conceptual work representation</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`dimension`</li><li>`subject_to`</li><li>`about`</li><li>`conceptually_part_of`</li><li>`created_by`</li></ul>\n<h3 id=\"implementation-mapping-abstract-work-schema\">Implementation Mapping — Abstract Work Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for abstract work payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only the listed abstract-work fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Class semantics</li></ol>\n<ul><li>Keep abstract work payloads concept-first (propositional object semantics), not physical-object semantics.</li></ul>\n<h3 id=\"tdd-additions-abstract-work-schema\">TDD Additions — Abstract Work Schema</h3>\n<p>Add failing-first tests for abstract-work schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional allowed properties by shared-structure schemas</li></ul>\n<p>Route-level:</p>\n<ul><li>abstract-work route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>changes to abstract-work serializers cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-abstract-work-schema-examples\">Fixture Anchors — Abstract Work Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid abstract work</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid abstract work</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `about`, `created_by`, `subject_to`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-60-addendum-concept-schema\">Round 60 Addendum — Concept Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Concept Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E55_Type`</li><li>concepts/subjects/categorizations</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`classified_as`</li><li>`identified_by`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`created_by`</li><li>`broader`</li></ul>\n<h3 id=\"implementation-mapping-concept-schema\">Implementation Mapping — Concept Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for concept payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only the listed concept-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Hierarchy semantics</li></ol>\n<ul><li>Preserve `broader` concept links for hierarchical taxonomy navigation.</li></ul>\n<h3 id=\"tdd-additions-concept-schema\">TDD Additions — Concept Schema</h3>\n<p>Add failing-first tests for concept schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional allowed properties (especially `broader`) through shared-structure contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>concept route responses always satisfy schema-required fields</li><li>malformed concept payloads with unknown keys fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>concept serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-concept-schema-examples\">Fixture Anchors — Concept Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid concept</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid concept</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `broader`, `equivalent`, `created_by`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-61-addendum-digital-object-schema\">Round 61 Addendum — Digital Object Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Digital Object Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`dig:D1_Digital_Object`</li><li>digital resources such as web pages/images</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`dimension`</li><li>`part_of`</li><li>`format`</li><li>`conforms_to`</li><li>`access_point`</li><li>`digitally_available_via`</li><li>`digitally_carries`</li><li>`digitally_shows`</li><li>`used_for`</li><li>`created_by`</li></ul>\n<h3 id=\"implementation-mapping-digital-object-schema\">Implementation Mapping — Digital Object Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for digital object payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed digital-object fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Carrier/service/access semantics</li></ol>\n<ul><li>Preserve strict separation of `access_point`, `digitally_available_via`, `digitally_carries`, and `digitally_shows`.</li></ul>\n<ol><li>Technical metadata fidelity</li></ol>\n<ul><li>Preserve `format` and `conforms_to` semantics for media/protocol interoperability.</li></ul>\n<h3 id=\"tdd-additions-digital-object-schema\">TDD Additions — Digital Object Schema</h3>\n<p>Add failing-first tests for digital object schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional allowed fields using shared-structure contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>digital object route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid digital-link fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-digital-object-schema-examples\">Fixture Anchors — Digital Object Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid digital object</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid digital object</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `access_point`, `format`, `digitally_available_via`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-62-addendum-event-schema\">Round 62 Addendum — Event Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Event Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target classes:</li><li>`crm:E4_Period`</li><li>`crm:E6_Event`</li><li>`crm:E7_Activity`</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`took_place_at`</li><li>`timespan`</li><li>`during`</li><li>`after`</li><li>`before`</li><li>`caused_by`</li><li>`carried_out_by`</li><li>`participant`</li><li>`used_specific_object`</li><li>`influenced_by`</li><li>`technique`</li><li>`part_of`</li></ul>\n<h3 id=\"implementation-mapping-event-schema\">Implementation Mapping — Event Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for event payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed event-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Temporal/spatial semantics</li></ol>\n<ul><li>Preserve `timespan`, ordering (`before`/`after`/`during`), and `took_place_at` as first-class structured fields.</li></ul>\n<ol><li>Event/activity role semantics</li></ol>\n<ul><li>Preserve `carried_out_by`, `participant`, `used_specific_object`, and `influenced_by` role/context fields.</li></ul>\n<h3 id=\"tdd-additions-event-schema\">TDD Additions — Event Schema</h3>\n<p>Add failing-first tests for event schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional temporal/spatial/role fields using shared-structure contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>event route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid temporal/role fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-event-schema-examples\">Fixture Anchors — Event Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid event record</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid event record</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `timespan`, `took_place_at`, `carried_out_by`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-63-addendum-group-schema\">Round 63 Addendum — Group Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Group Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E74_Group`</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`carried_out`</li><li>`participated_in`</li><li>`contact_point`</li><li>`residence`</li><li>`formed_by`</li><li>`dissolved_by`</li></ul>\n<h3 id=\"implementation-mapping-group-schema\">Implementation Mapping — Group Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for group payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed group-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Lifecycle/activity semantics</li></ol>\n<ul><li>Preserve `formed_by`, `dissolved_by`, `carried_out`, and `participated_in` as structured activity fields.</li></ul>\n<ol><li>Contact/residence semantics</li></ol>\n<ul><li>Preserve `contact_point` and `residence` as distinct structured fields with shared contracts.</li></ul>\n<h3 id=\"tdd-additions-group-schema\">TDD Additions — Group Schema</h3>\n<p>Add failing-first tests for group schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional activity/contact/residence fields using shared-structure contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>group route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid lifecycle/activity fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-group-schema-examples\">Fixture Anchors — Group Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid group record</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid group record</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `formed_by`, `residence`, `carried_out`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-64-addendum-person-schema\">Round 64 Addendum — Person Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Person Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E21_Person`</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`carried_out`</li><li>`participated_in`</li><li>`contact_point`</li><li>`residence`</li><li>`born`</li><li>`died`</li></ul>\n<h3 id=\"implementation-mapping-person-schema\">Implementation Mapping — Person Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for person payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed person-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Lifecycle/activity semantics</li></ol>\n<ul><li>Preserve `born`, `died`, `carried_out`, and `participated_in` as structured activity fields.</li></ul>\n<ol><li>Contact/residence semantics</li></ol>\n<ul><li>Preserve `contact_point` and `residence` as distinct structured fields with shared contracts.</li></ul>\n<h3 id=\"tdd-additions-person-schema\">TDD Additions — Person Schema</h3>\n<p>Add failing-first tests for person schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional lifecycle/activity/contact/residence fields using shared-structure contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>person route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid lifecycle/activity fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-person-schema-examples\">Fixture Anchors — Person Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid person record</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid person record</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `born`, `died`, `residence`, `carried_out`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-65-addendum-human-made-object-schema\">Round 65 Addendum — Human-Made Object Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Human-Made Object Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E22_Human-Made_Object`</li><li>includes human-made objects, parts, and culturally-valued natural objects</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`dimension`</li><li>`made_of`</li><li>`part_of`</li><li>`current_owner`</li><li>`current_custodian`</li><li>`current_permanent_custodian`</li><li>`current_location`</li><li>`current_permanent_location`</li><li>`held_or_supported_by`</li><li>`used_for`</li><li>`shows`</li><li>`carries`</li><li>`produced_by`</li><li>`destroyed_by`</li><li>`removed_by`</li><li>`encountered_by`</li><li>`modified_by`</li><li>`changed_ownership_through`</li></ul>\n<h3 id=\"implementation-mapping-human-made-object-schema\">Implementation Mapping — Human-Made Object Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for human-made object payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed object-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Ownership/custody/location semantics</li></ol>\n<ul><li>Preserve distinct fields for current vs permanent ownership/custody/location.</li></ul>\n<ol><li>Lifecycle/provenance semantics</li></ol>\n<ul><li>Preserve structured lifecycle/provenance fields (`produced_by`, `destroyed_by`, `removed_by`, `encountered_by`, `modified_by`, `changed_ownership_through`).</li></ul>\n<ol><li>Aboutness/carrier semantics</li></ol>\n<ul><li>Preserve `shows` and `carries` link semantics separately from digital/visual/textual standalone records.</li></ul>\n<h3 id=\"tdd-additions-human-made-object-schema\">TDD Additions — Human-Made Object Schema</h3>\n<p>Add failing-first tests for human-made object schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional lifecycle, provenance, ownership, custody, location, material, and dimension fields via shared contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>object route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid lifecycle/ownership structures fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-human-made-object-schema-examples\">Fixture Anchors — Human-Made Object Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid object record</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid object record</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `made_of`, `dimension`, `current_owner`, `produced_by`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-66-addendum-place-schema\">Round 66 Addendum — Place Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Place Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E53_Place`</li><li>geographic locations where activities occur</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`classified_as`</li><li>`identified_by`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`defined_by`</li><li>`part_of`</li></ul>\n<h3 id=\"implementation-mapping-place-schema\">Implementation Mapping — Place Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for place payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed place-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Geometry/hierarchy semantics</li></ol>\n<ul><li>Preserve `defined_by` geometry payload and `part_of` place hierarchy as first-class structured fields.</li></ul>\n<ol><li>Identity/reference fidelity</li></ol>\n<ul><li>Preserve `equivalent` and classification fields for cross-authority place reconciliation.</li></ul>\n<h3 id=\"tdd-additions-place-schema\">TDD Additions — Place Schema</h3>\n<p>Add failing-first tests for place schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional geometry/hierarchy/reference fields via shared contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>place route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid `defined_by`/`part_of` fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-place-schema-examples\">Fixture Anchors — Place Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid place record</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid place record</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `defined_by`, `part_of`, `equivalent`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-67-addendum-provenance-activity-schema\">Round 67 Addendum — Provenance Activity Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Provenance Activity Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E7_Activity`</li><li>broad activities for ownership/custody/location/rights changes</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>`classified_as`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`during`</li><li>`after`</li><li>`before`</li><li>`took_place_at`</li><li>`timespan`</li><li>`caused_by`</li><li>`carried_out_by`</li><li>`used_specific_object`</li><li>`influenced_by`</li><li>`technique`</li><li>`part_of`</li><li>`part`</li></ul>\n<h3 id=\"implementation-mapping-provenance-activity-schema\">Implementation Mapping — Provenance Activity Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for provenance activity payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, `_label`, and `classified_as` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed provenance-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Classification gate</li></ol>\n<ul><li>Preserve and validate `classified_as` entries required to establish provenance semantics.</li></ul>\n<ol><li>Structured part semantics</li></ol>\n<ul><li>Preserve `part` as first-class structured sub-activity container, not flattened notes.</li></ul>\n<h3 id=\"tdd-additions-provenance-activity-schema\">TDD Additions — Provenance Activity Schema</h3>\n<p>Add failing-first tests for provenance activity schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`/`classified_as`</li><li>validates rejection of additional unknown properties</li><li>validates optional temporal/spatial/role fields and `part` structure via shared contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>provenance route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid `classified_as`/`part` fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `classified_as` and `_label` remain enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-provenance-activity-schema-examples\">Fixture Anchors — Provenance Activity Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid provenance activity</li></ol>\n<ul><li>contains required `@context`, `id`, `type`, `_label`, `classified_as`.</li></ul>\n<ol><li>Extended valid provenance activity</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `timespan`, `took_place_at`, `part`, `used_specific_object`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<ol><li>Missing-classification negative fixture</li></ol>\n<ul><li>omits required `classified_as` and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-68-addendum-collection-set-schema\">Round 68 Addendum — Collection (Set) Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Collection Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`la:Set`</li><li>collection/set of resources</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`dimension`</li><li>`about`</li><li>`members_contained_by`</li><li>`members_exemplified_by`</li><li>`used_for`</li><li>`created_by`</li></ul>\n<h3 id=\"implementation-mapping-collection-set-schema\">Implementation Mapping — Collection (Set) Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for collection/set payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed collection-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Set semantics preservation</li></ol>\n<ul><li>Preserve `members_contained_by` and `members_exemplified_by` distinctions as separate semantics.</li></ul>\n<ol><li>Curatorial/context semantics</li></ol>\n<ul><li>Preserve `about`, `used_for`, and `created_by` as structured contextual fields.</li></ul>\n<h3 id=\"tdd-additions-collection-set-schema\">TDD Additions — Collection (Set) Schema</h3>\n<p>Add failing-first tests for collection/set schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional set-specific fields via shared contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>set route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid set-specific fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-collection-set-schema-examples\">Fixture Anchors — Collection (Set) Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid collection/set record</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid collection/set record</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `about`, `members_exemplified_by`, `created_by`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-69-addendum-text-schema\">Round 69 Addendum — Text Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Text Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E33_Linguistic_Object`</li><li>textual content expressed in one or more human languages</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`representation`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`dimension`</li><li>`subject_to`</li><li>`format`</li><li>`language`</li><li>`about`</li><li>`created_by`</li><li>`used_for`</li><li>`part_of`</li><li>`content`</li></ul>\n<h3 id=\"implementation-mapping-text-schema\">Implementation Mapping — Text Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for text payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed text-schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Linguistic semantics fidelity</li></ol>\n<ul><li>Preserve `language`, `content`, `format`, and `about` as first-class textual semantics.</li></ul>\n<ol><li>Rights/provenance/publication semantics</li></ol>\n<ul><li>Preserve `subject_to`, `created_by`, and `used_for` as structured contextual fields.</li></ul>\n<h3 id=\"tdd-additions-text-schema\">TDD Additions — Text Schema</h3>\n<p>Add failing-first tests for text schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional linguistic/rights/provenance fields via shared contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>text route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid language/content/rights fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-text-schema-examples\">Fixture Anchors — Text Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid text record</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid text record</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `language`, `content`, `subject_to`, `used_for`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-70-addendum-visual-content-schema\">Round 70 Addendum — Visual Content Schema</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Visual Content Schema</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Schema target class:</li><li>`crm:E36_Visual_Item`</li><li>visual content of a work</li><li>Schema form:</li><li>`type: object`</li><li>no additional properties allowed</li><li>Required properties in this schema listing:</li><li>`@context`</li><li>`id`</li><li>`type`</li><li>`_label`</li><li>Additional allowed properties:</li><li>`identified_by`</li><li>`classified_as`</li><li>`referred_to_by`</li><li>`equivalent`</li><li>`member_of`</li><li>`subject_of`</li><li>`attributed_by`</li><li>`dimension`</li><li>`subject_to`</li><li>`part_of`</li><li>`conceptually_part_of`</li><li>`about`</li><li>`created_by`</li><li>`represents`</li><li>`represents_instance_of_type`</li><li>`used_for`</li></ul>\n<h3 id=\"implementation-mapping-visual-content-schema\">Implementation Mapping — Visual Content Schema</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Strict additional-property rule</li></ol>\n<ul><li>Enforce `additionalProperties: false` behavior for visual content payloads.</li></ul>\n<ol><li>Required-field alignment</li></ol>\n<ul><li>Treat `@context`, `id`, `type`, and `_label` as required for schema conformance tests.</li></ul>\n<ol><li>Property allowlist enforcement</li></ol>\n<ul><li>Permit only listed visual-content schema fields; reject unknown keys at boundary validation.</li></ul>\n<ol><li>Depiction semantics fidelity</li></ol>\n<ul><li>Preserve `represents` and `represents_instance_of_type` as distinct semantics in serializers and validators.</li></ul>\n<ol><li>Structural/context semantics</li></ol>\n<ul><li>Preserve `part_of`, `conceptually_part_of`, `about`, and `used_for` as structured contextual fields.</li></ul>\n<h3 id=\"tdd-additions-visual-content-schema\">TDD Additions — Visual Content Schema</h3>\n<p>Add failing-first tests for visual content schema conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates required `@context`/`id`/`type`/`_label`</li><li>validates rejection of additional unknown properties</li><li>validates optional depiction/context/rights fields via shared contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>visual content route responses always satisfy schema-required fields</li><li>malformed payloads with unknown keys or invalid depiction fields fail with clear field-path diagnostics</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot silently introduce non-schema fields</li><li>required `_label` remains enforced in schema conformance suite</li></ul>\n<h3 id=\"fixture-anchors-visual-content-schema-examples\">Fixture Anchors — Visual Content Schema Examples</h3>\n<p>Use these schema-level patterns as fixture seeds:</p>\n<ol><li>Minimal valid visual content record</li></ol>\n<ul><li>contains only required `@context`, `id`, `type`, `_label`.</li></ul>\n<ol><li>Extended valid visual content record</li></ol>\n<ul><li>uses subset of allowed optional fields (for example `represents`, `represents_instance_of_type`, `subject_to`, `created_by`).</li></ul>\n<ol><li>Additional-property negative fixture</li></ol>\n<ul><li>includes unknown key and must fail validation.</li></ul>\n<p>---</p>\n<h2 id=\"round-71-addendum-search-api\">Round 71 Addendum — Search API</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Search API</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Search API solves inverse-relationship discovery without requiring clients to author query grammar.</li><li>Discovery mechanism:</li><li>HAL `_links` on entity records expose named links to referring-record result lists.</li><li>relation naming convention is camelCase by current type + relationship + target type (via `curies` expansion).</li><li>links should be omitted when no matching results exist.</li><li>Search response model:</li><li>based on ActivityStreams `OrderedCollection` / `OrderedCollectionPage`.</li><li>HAL links should target first page URI, not necessarily collection root URI.</li><li>Page requirements (`OrderedCollectionPage`):</li><li>`@context` must be `https://linked.art/ns/v1/search.json`</li><li>required: `id`, `type=&quot;OrderedCollectionPage&quot;`, `partOf`, `orderedItems`</li><li>`next` required unless last page</li><li>`prev` required unless first page</li><li>`startIndex` should be present (0-based index)</li><li>each `orderedItems` entry has exactly `{ id, type }`</li><li>Collection requirements (`OrderedCollection`):</li><li>required: `id`, `type=&quot;OrderedCollection&quot;`, `first`, `last`</li><li>`totalItems` should be present</li><li>`label` and `summary` may be language-map objects</li><li>when embedded in page `partOf`, collection must not repeat `@context`</li><li>if requested separately, collection must include `@context` search context value</li></ul>\n<h3 id=\"implementation-mapping-search-api\">Implementation Mapping — Search API</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>HAL inverse-link publication</li></ol>\n<ul><li>Emit `_links` search relations for supported inverse traversals and omit relations with zero results.</li></ul>\n<ol><li>Relation-name stability</li></ol>\n<ul><li>Keep relation naming deterministic and curies-expandable for client interoperability.</li></ul>\n<ol><li>Page-first retrieval contract</li></ol>\n<ul><li>Ensure relation `href` targets first `OrderedCollectionPage` response with required search context.</li></ul>\n<ol><li>Ordered page structure enforcement</li></ol>\n<ul><li>Preserve strict page contract (`partOf`, `next`/`prev` conditional presence, `orderedItems` id/type shape).</li></ul>\n<ol><li>Embedded collection behavior</li></ol>\n<ul><li>Embed collection metadata in `partOf` without duplicate `@context`; include `@context` only for standalone collection responses.</li></ul>\n<ol><li>Backend-agnostic search execution</li></ol>\n<ul><li>Keep public response shape stable regardless of underlying query engine/indexing strategy.</li></ul>\n<h3 id=\"tdd-additions-search-api\">TDD Additions — Search API</h3>\n<p>Add failing-first tests for search API conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates `OrderedCollectionPage` required fields and search context</li><li>validates `OrderedCollection` required fields and standalone-vs-embedded context rules</li><li>validates `orderedItems` entry shape as exactly id/type references</li></ul>\n<p>Route-level:</p>\n<ul><li>HAL `_links` include only available inverse relationships</li><li>first-page links dereference to valid `OrderedCollectionPage`</li><li>pagination rules enforce `next`/`prev` conditional presence correctly</li></ul>\n<p>Integration-level:</p>\n<ul><li>cross-endpoint inverse discovery works via HAL links without query-language coupling</li><li>`startIndex`, `totalItems`, and page traversal semantics remain consistent across providers/backends</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes do not break search context URI, relation naming, or ordered item shape</li><li>empty-result relationships continue omitting link entries</li></ul>\n<h3 id=\"fixture-anchors-search-api-examples\">Fixture Anchors — Search API Examples</h3>\n<p>Use these search-API patterns as fixture seeds:</p>\n<ol><li>Minimal valid first page</li></ol>\n<ul><li>valid `OrderedCollectionPage` with `partOf`, `next`, and `orderedItems`.</li></ul>\n<ol><li>Middle page fixture</li></ol>\n<ul><li>page with both `prev` and `next` plus correct `startIndex`.</li></ul>\n<ol><li>Last page fixture</li></ol>\n<ul><li>page omitting `next` and retaining `prev`.</li></ul>\n<ol><li>Embedded collection fixture</li></ol>\n<ul><li>`partOf` collection with `first`, `last`, `totalItems`, optional label/summary, and no embedded `@context`.</li></ul>\n<ol><li>Standalone collection fixture</li></ol>\n<ul><li>separate collection response including required search `@context`.</li></ul>\n<ol><li>HAL link omission fixture</li></ol>\n<ul><li>source record where absent inverse relations are not emitted in `_links`.</li></ul>\n<p>---</p>\n<h2 id=\"round-72-addendum-about-hal\">Round 72 Addendum — About HAL</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: About HAL</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Linked Art embeds non-semantic API metadata in JSON responses using HAL via `_links`.</li><li>HAL block is not RDF-semantic and is not preserved through RDF graph round-tripping.</li><li>Core HAL elements:</li><li>`self` link</li><li>`curies` namespace templates for relation semantics (for example `la`)</li><li>namespaced relation links (Linked Art + local extensions)</li><li>Versioning links:</li><li>required: `la:modelVersion`, `la:apiVersion`</li><li>optional: `la:localVersion`</li><li>each version link requires `href` to human docs and `name` in `v{major}.{minor}.{patch}` format</li><li>Version interpretation guidance:</li><li>major/minor are numeric for compatibility logic</li><li>patch is string-sorted and non-functional (awareness/documentation)</li><li>Other representation links:</li><li>`alternate` links for HTML/Turtle/etc. must include correct `type` media type</li><li>`collection` can point to IIIF Change Discovery endpoint</li><li>Search integration:</li><li>HAL links are primary discovery mechanism for related searches (documented in Search API)</li></ul>\n<h3 id=\"implementation-mapping-hal\">Implementation Mapping — HAL</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>HAL envelope consistency</li></ol>\n<ul><li>Emit `_links` consistently on entity responses with valid `self` and curated relation links.</li></ul>\n<ol><li>CURIE namespace discipline</li></ol>\n<ul><li>Emit `curies` entries with templated link semantics for relation documentation expansion.</li></ul>\n<ol><li>Version-link enforcement</li></ol>\n<ul><li>Require `la:modelVersion` and `la:apiVersion`; support optional `la:localVersion` for local extension tracking.</li></ul>\n<ol><li>Version-name parser safety</li></ol>\n<ul><li>Enforce `name` format compatibility and preserve numeric compare behavior for major/minor components.</li></ul>\n<ol><li>Alternate representation correctness</li></ol>\n<ul><li>Ensure `alternate` links include accurate MIME `type` values.</li></ul>\n<ol><li>Discovery link integration</li></ol>\n<ul><li>Support `collection` and search relation links without coupling to backend-specific query syntax.</li></ul>\n<ol><li>Semantic boundary preservation</li></ol>\n<ul><li>Keep HAL metadata separate from semantic JSON-LD graph processing.</li></ul>\n<h3 id=\"tdd-additions-hal\">TDD Additions — HAL</h3>\n<p>Add failing-first tests for HAL conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates `_links` presence and required `self` structure</li><li>validates `curies` templated namespace entries</li><li>validates required version links and `name` format constraints</li><li>validates `alternate` links include correct `type` media types</li></ul>\n<p>Route-level:</p>\n<ul><li>entity responses include consistent HAL links across endpoint families</li><li>malformed/missing required version links fail contract checks</li></ul>\n<p>Integration-level:</p>\n<ul><li>relation links expand via CURIE templates to documentation URIs</li><li>search/discovery links are followable and return schema-valid responses</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes do not drop required HAL version links</li><li>HAL blocks remain non-semantic and do not pollute JSON-LD graph assertions</li></ul>\n<h3 id=\"fixture-anchors-hal-examples\">Fixture Anchors — HAL Examples</h3>\n<p>Use these HAL patterns as fixture seeds:</p>\n<ol><li>Minimal HAL fixture</li></ol>\n<ul><li>`_links.self` + `curies` template entry.</li></ul>\n<ol><li>Versioned HAL fixture</li></ol>\n<ul><li>includes required `la:modelVersion` and `la:apiVersion` plus optional `la:localVersion`.</li></ul>\n<ol><li>Alternate-format fixture</li></ol>\n<ul><li>`alternate` links for HTML and Turtle with valid media types.</li></ul>\n<ol><li>Discovery fixture</li></ol>\n<ul><li>`collection` link to change-discovery endpoint.</li></ul>\n<ol><li>Search-link fixture</li></ol>\n<ul><li>relation links pointing to search result pages.</li></ul>\n<ol><li>Invalid-version-name fixture</li></ol>\n<ul><li>malformed `name` format must fail validation checks.</li></ul>\n<p>---</p>\n<h2 id=\"round-73-addendum-search-relations-humanmadeobject\">Round 73 Addendum — Search Relations: HumanMadeObject</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API relation docs (HumanMadeObject-focused search links)</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Documented search relations for `HumanMadeObject` include:</li><li>`activityUsedObject`</li><li>`conceptInfluencedByObject`</li><li>`objectPartOfObject`</li><li>`objectProductionInfluencedByObject`</li><li>`workAboutObject`</li><li>`workAboutOrRepresentsObject`</li><li>`workRepresentsObject`</li><li>Each relation defines:</li><li>source class (`HumanMadeObject`)</li><li>returned class family (`Activity`, `Concept`, `HumanMadeObject`, `Work`)</li><li>semantic relationship basis (`used`, `influencedBy`, `partOf`, `productionInfluencedBy`, `about`, `represents`)</li><li>These relations are exposed as discoverable HAL/search links and should map to OrderedCollectionPage responses.</li></ul>\n<h3 id=\"implementation-mapping-humanmadeobject-search-relations\">Implementation Mapping — HumanMadeObject Search Relations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Relation-name publication</li></ol>\n<ul><li>Publish stable HAL relation links for the listed HumanMadeObject inverse/discovery relations.</li></ul>\n<ol><li>Result-class fidelity</li></ol>\n<ul><li>Ensure each relation returns the expected entity class family (or documented union) consistently.</li></ul>\n<ol><li>Relationship-semantic fidelity</li></ol>\n<ul><li>Ensure each relation query is grounded in the documented relationship basis:</li><li>`used` -&gt; activities using object</li><li>`influencedBy` -&gt; concepts influenced by object</li><li>`partOf` -&gt; object parts</li><li>`productionInfluencedBy` -&gt; produced objects influenced by source object</li><li>`about` / `represents` combinations for work relations</li></ul>\n<ol><li>Page-format compliance</li></ol>\n<ul><li>Relation targets must return valid Search API `OrderedCollectionPage` shape.</li></ul>\n<ol><li>Empty-result behavior</li></ol>\n<ul><li>Omit relation links when no results exist for a source record (per Search API guidance).</li></ul>\n<h3 id=\"tdd-additions-humanmadeobject-search-relations\">TDD Additions — HumanMadeObject Search Relations</h3>\n<p>Add failing-first tests for relation conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates each listed relation is either:</li><li>present with valid link shape and followable search-page response, or</li><li>omitted when result set is empty</li></ul>\n<p>Route-level:</p>\n<ul><li>validates returned `orderedItems[].type` matches documented class family per relation</li><li>validates each relation endpoint page conforms to search context/page schema</li></ul>\n<p>Integration-level:</p>\n<ul><li>object fixture graph tests verify each relation returns expected linked records:</li><li>activities using object</li><li>concepts influenced by object</li><li>child/part objects</li><li>influenced productions/copies</li><li>about/represents work sets</li></ul>\n<p>Regression:</p>\n<ul><li>relation name stability tests prevent accidental renaming or semantic drift</li><li>relation-specific queries remain consistent across provider adapters/storage backends</li></ul>\n<h3 id=\"fixture-anchors-humanmadeobject-search-relations-examples\">Fixture Anchors — HumanMadeObject Search Relations Examples</h3>\n<p>Use these relation patterns as fixture seeds:</p>\n<ol><li>`activityUsedObject` fixture</li></ol>\n<ul><li>object linked to one or more activity records via usage semantics.</li></ul>\n<ol><li>`conceptInfluencedByObject` fixture</li></ol>\n<ul><li>object linked to concept records via influence semantics.</li></ul>\n<ol><li>`objectPartOfObject` fixture</li></ol>\n<ul><li>parent object with part/frame/subcomponent object records.</li></ul>\n<ol><li>`objectProductionInfluencedByObject` fixture</li></ol>\n<ul><li>source object linked to production of derivative/copy object.</li></ul>\n<ol><li>`workAboutObject` fixture</li></ol>\n<ul><li>textual/visual/abstract works about object.</li></ul>\n<ol><li>`workAboutOrRepresentsObject` fixture</li></ol>\n<ul><li>combined about-or-represents result set.</li></ul>\n<ol><li>`workRepresentsObject` fixture</li></ol>\n<ul><li>visual works depicting object.</li></ul>\n<p>---</p>\n<h2 id=\"round-74-addendum-search-relations-work\">Round 74 Addendum — Search Relations: Work</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API relation docs (Work-focused search links)</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Documented search relations for Work/LinguisticObject/VisualItem contexts include:</li><li>`activityUsedWork`</li><li>`conceptInfluencedByWork`</li><li>`objectCarriesWork`</li><li>`objectProductionInfluencedByWork`</li><li>`objectShowsWork`</li><li>`workAboutOrRepresentsWork`</li><li>`workAboutWork`</li><li>`workPartOfWork`</li><li>`workRepresentsWork`</li><li>Relation details include:</li><li>source class (`Work`, `LinguisticObject`, or `VisualItem` depending on relation)</li><li>returned class family (`Activity`, `Concept`, `HumanMadeObject`, `Work`)</li><li>semantic basis (`used`, `influencedBy`, `carries`, `productionInfluencedBy`, `shows`, `about`, `represents`, `partOf`)</li><li>These relations should be exposed through HAL/search links and return Search API page structures.</li></ul>\n<h3 id=\"implementation-mapping-work-search-relations\">Implementation Mapping — Work Search Relations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Relation-name publication</li></ol>\n<ul><li>Publish stable HAL relation links for the listed Work-family inverse/discovery relations.</li></ul>\n<ol><li>Source-class correctness</li></ol>\n<ul><li>Enforce correct source-class gating per relation (for example `objectCarriesWork` from `LinguisticObject`, `objectShowsWork` from `VisualItem`).</li></ul>\n<ol><li>Result-class fidelity</li></ol>\n<ul><li>Ensure each relation returns the documented class family consistently.</li></ul>\n<ol><li>Relationship-semantic fidelity</li></ol>\n<ul><li>Map each relation to its documented semantic edge:</li><li>`used`</li><li>`influencedBy`</li><li>`carries`</li><li>`productionInfluencedBy`</li><li>`shows`</li><li>`about`</li><li>`represents`</li><li>`partOf`</li></ul>\n<ol><li>Search-page compliance</li></ol>\n<ul><li>Relation targets must return valid `OrderedCollectionPage` responses with correct search context.</li></ul>\n<ol><li>Empty-result link omission</li></ol>\n<ul><li>Omit relation links where no referring records exist.</li></ul>\n<h3 id=\"tdd-additions-work-search-relations\">TDD Additions — Work Search Relations</h3>\n<p>Add failing-first tests for relation conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates listed relations are either present with valid HAL link shape or omitted when empty</li><li>validates link targets return schema-valid search pages</li></ul>\n<p>Route-level:</p>\n<ul><li>validates relation result item `type` matches documented class family</li><li>validates source-class-specific relations are not emitted on incompatible source classes</li></ul>\n<p>Integration-level:</p>\n<ul><li>work graph fixtures verify inverse discovery for:</li><li>activities using work</li><li>concepts influenced by work</li><li>objects carrying linguistic work</li><li>objects showing visual work</li><li>objects produced under work influence</li><li>work-about/work-represents/work-part relations</li></ul>\n<p>Regression:</p>\n<ul><li>relation names remain stable across backend/provider changes</li><li>about-vs-represents-vs-partOf semantics do not collapse into one generic “related works” bucket</li></ul>\n<h3 id=\"fixture-anchors-work-search-relations-examples\">Fixture Anchors — Work Search Relations Examples</h3>\n<p>Use these relation patterns as fixture seeds:</p>\n<ol><li>`activityUsedWork` fixture</li></ol>\n<ul><li>work linked to activity records via usage semantics.</li></ul>\n<ol><li>`conceptInfluencedByWork` fixture</li></ol>\n<ul><li>work linked to concept records via influence semantics.</li></ul>\n<ol><li>`objectCarriesWork` fixture</li></ol>\n<ul><li>linguistic work linked to physical carrier objects.</li></ul>\n<ol><li>`objectShowsWork` fixture</li></ol>\n<ul><li>visual work linked to physical objects that show it.</li></ul>\n<ol><li>`objectProductionInfluencedByWork` fixture</li></ol>\n<ul><li>work linked to objects whose production it influenced.</li></ul>\n<ol><li>`workAboutWork` fixture</li></ol>\n<ul><li>work linked to works about it.</li></ul>\n<ol><li>`workAboutOrRepresentsWork` fixture</li></ol>\n<ul><li>mixed about-or-represents work result set.</li></ul>\n<ol><li>`workPartOfWork` fixture</li></ol>\n<ul><li>parent work linked to component/sub-work records.</li></ul>\n<ol><li>`workRepresentsWork` fixture</li></ol>\n<ul><li>work linked to works that depict/represent it.</li></ul>\n<p>---</p>\n<h2 id=\"round-75-addendum-search-relations-agent\">Round 75 Addendum — Search Relations: Agent</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API relation docs (Agent-focused search links with SPARQL patterns)</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Documented agent-centric search relations include:</li><li>`activityCarriedOutByAgent`</li><li>`activityParticipantAgent`</li><li>`agentMemberOfGroup`</li><li>`conceptInfluencedByAgent`</li><li>`groupFoundedByAgent`</li><li>`objectCuratedByAgent`</li><li>`objectEncounteredByAgent`</li><li>`objectOwnedByAgent`</li><li>`objectProducedByAgent`</li><li>`objectProductionInfluencedByAgent`</li><li>`setCreatedByAgent`</li><li>`workAboutAgent`</li><li>`workAboutOrRepresentsAgent`</li><li>`workCreatedByAgent`</li><li>`workPublishedByAgent`</li><li>`workRepresentsAgent`</li><li>Each relation specifies:</li><li>source class (`Agent` or `Group` where noted)</li><li>return class family (`Activity`, `Event/Activity`, `Agent`, `Concept`, `Group`, `HumanMadeObject`, `Set`, `Work`)</li><li>semantic edge (`carriedOutBy`, `participant`, `memberOf`, `influencedBy`, `foundedBy`, etc.)</li><li>Provided SPARQL snippets establish expected inverse-traversal semantics and can be used as behavioral oracle for query correctness.</li></ul>\n<h3 id=\"implementation-mapping-agent-search-relations\">Implementation Mapping — Agent Search Relations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Relation-name publication</li></ol>\n<ul><li>Publish stable HAL relation links for the documented agent-centric relations.</li></ul>\n<ol><li>Source-class gating</li></ol>\n<ul><li>Enforce relation availability by source class (for example `agentMemberOfGroup` source is `Group`).</li></ul>\n<ol><li>Result-class fidelity</li></ol>\n<ul><li>Ensure returned item types match the documented class family per relation.</li></ul>\n<ol><li>Semantic-query fidelity</li></ol>\n<ul><li>Align relation execution to documented inverse semantics (including production/event path traversals and union branches where specified).</li></ul>\n<ol><li>Complex-branch relation fidelity</li></ol>\n<ul><li>Preserve union/path logic for relations like `objectCuratedByAgent` and multi-edge creation/production queries.</li></ul>\n<ol><li>Search-page compliance</li></ol>\n<ul><li>Relation targets must return valid Search API `OrderedCollectionPage` structures.</li></ul>\n<ol><li>Empty-result omission</li></ol>\n<ul><li>Omit relation link entries when no matching records exist.</li></ul>\n<h3 id=\"tdd-additions-agent-search-relations\">TDD Additions — Agent Search Relations</h3>\n<p>Add failing-first tests for agent-relation conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates each listed relation is either present with valid HAL link shape or omitted when empty</li><li>validates followable relation targets return schema-valid search pages</li></ul>\n<p>Route-level:</p>\n<ul><li>validates `orderedItems[].type` against documented return class family per relation</li><li>validates source-class-incompatible relations are not emitted</li></ul>\n<p>Integration-level:</p>\n<ul><li>graph fixtures verify inverse discovery for:</li><li>activities carried out by/participated in by agents</li><li>group membership and group formation links</li><li>owned/curated/encountered/produced/influenced objects</li><li>sets created by agents</li><li>works about/representing/created/published by agents</li></ul>\n<p>Regression:</p>\n<ul><li>relation naming and semantics remain stable across storage backends/providers</li><li>SPARQL-equivalence checks detect semantic drift in traversal logic</li></ul>\n<h3 id=\"fixture-anchors-agent-search-relations-examples\">Fixture Anchors — Agent Search Relations Examples</h3>\n<p>Use these relation patterns as fixture seeds:</p>\n<ol><li>`activityCarriedOutByAgent` fixture</li></ol>\n<ul><li>agent linked to carried-out activity records.</li></ul>\n<ol><li>`activityParticipantAgent` fixture</li></ol>\n<ul><li>agent linked to participation-only event/activity records.</li></ul>\n<ol><li>`agentMemberOfGroup` fixture</li></ol>\n<ul><li>group with person/group members returned via inverse membership.</li></ul>\n<ol><li>`objectProducedByAgent` fixture</li></ol>\n<ul><li>agent linked to produced objects through production-participant paths.</li></ul>\n<ol><li>`objectCuratedByAgent` fixture</li></ol>\n<ul><li>curator/department linked to objects through custody or curating-activity pathways.</li></ul>\n<ol><li>`objectOwnedByAgent` fixture</li></ol>\n<ul><li>agent linked to currently owned objects.</li></ul>\n<ol><li>`workCreatedByAgent` and `workPublishedByAgent` fixtures</li></ol>\n<ul><li>agent linked to created/published works via creation/publication activities.</li></ul>\n<ol><li>`workAboutOrRepresentsAgent` fixture</li></ol>\n<ul><li>mixed work result set combining about and represents relations.</li></ul>\n<ol><li>`setCreatedByAgent` fixture</li></ol>\n<ul><li>agent linked to created sets/collections.</li></ul>\n<ol><li>`conceptInfluencedByAgent` fixture</li></ol>\n<ul><li>agent linked to concept creation influence chains.</li></ul>\n<p>---</p>\n<h2 id=\"round-76-addendum-search-relations-place\">Round 76 Addendum — Search Relations: Place</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API relation docs (Place-focused search links with SPARQL patterns)</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Documented place-centric search relations include:</li><li>`activityTookPlaceAtPlace`</li><li>`agentActiveAtPlace`</li><li>`agentBornOrFormedAtPlace`</li><li>`agentDiedOrDissolvedAtPlace`</li><li>`agentResidentAtPlace`</li><li>`conceptInfluencedByPlace`</li><li>`groupActiveAtPlace`</li><li>`groupDissolvedAtPlace`</li><li>`groupFormedAtPlace`</li><li>`objectCurrentPlace`</li><li>`objectEncounteredAtPlace`</li><li>`objectProducedAtPlace`</li><li>`objectProductionInfluencedByPlace`</li><li>`personActiveAtPlace`</li><li>`personBornAtPlace`</li><li>`personDiedAtPlace`</li><li>`placePartOfPlace`</li><li>`setCreatedAtPlace`</li><li>`workAboutOrRepresentsPlace`</li><li>`workAboutPlace`</li><li>`workCreatedAtPlace`</li><li>`workPublishedAtPlace`</li><li>`workRepresentsPlace`</li><li>Relation details define:</li><li>source class (`Place`)</li><li>return class family (`Event/Activity`, `Agent`, `Group`, `Person`, `HumanMadeObject`, `Place`, `Set`, `Work`, `Concept`)</li><li>semantic edge basis (`tookPlaceAt`, `bornAt`, `diedAt`, `formedAt`, `dissolvedAt`, `about`, `represents`, `createdAt`, etc.)</li><li>Provided SPARQL snippets establish expected inverse traversal behavior and should guide semantic correctness tests.</li></ul>\n<h3 id=\"implementation-mapping-place-search-relations\">Implementation Mapping — Place Search Relations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Relation-name publication</li></ol>\n<ul><li>Publish stable HAL relation links for the documented place-centric relation set.</li></ul>\n<ol><li>Result-class fidelity</li></ol>\n<ul><li>Ensure each relation returns the documented class family (including union-style families where specified).</li></ul>\n<ol><li>Temporal/lifecycle edge fidelity</li></ol>\n<ul><li>Preserve birth/death/formation/dissolution/activity location semantics distinctly across relation handlers.</li></ul>\n<ol><li>Production/publication/location path fidelity</li></ol>\n<ul><li>Preserve multi-hop path semantics for produced/created/published relations as indicated by model/SPARQL patterns.</li></ul>\n<ol><li>About-vs-represents separation</li></ol>\n<ul><li>Preserve distinction between `about`, `represents`, and combined `aboutOrRepresents` relation results.</li></ul>\n<ol><li>Search-page compliance</li></ol>\n<ul><li>Relation targets must return valid Search API `OrderedCollectionPage` responses.</li></ul>\n<ol><li>Empty-result omission</li></ol>\n<ul><li>Omit HAL relation links when no matching records exist.</li></ul>\n<h3 id=\"tdd-additions-place-search-relations\">TDD Additions — Place Search Relations</h3>\n<p>Add failing-first tests for place-relation conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates each listed place relation is either present with valid HAL link shape or omitted when empty</li><li>validates followable relation targets return schema-valid search pages</li></ul>\n<p>Route-level:</p>\n<ul><li>validates `orderedItems[].type` matches documented return class family per relation</li><li>validates combined relations (`workAboutOrRepresentsPlace`, agent born/formed, died/dissolved) preserve union semantics</li></ul>\n<p>Integration-level:</p>\n<ul><li>graph fixtures verify inverse discovery for:</li><li>activities/events at place</li><li>agents active/resident/born/formed/died/dissolved at place</li><li>groups formed/dissolved/active at place</li><li>objects currently at, encountered at, produced at, production-influenced by place</li><li>sets created at place</li><li>places part-of place</li><li>works about/representing/created/published at place</li><li>concepts influenced by place</li></ul>\n<p>Regression:</p>\n<ul><li>relation naming and source/return class mappings remain stable across adapters/backends</li><li>SPARQL-equivalence assertions detect path-semantics drift in query implementations</li></ul>\n<h3 id=\"fixture-anchors-place-search-relations-examples\">Fixture Anchors — Place Search Relations Examples</h3>\n<p>Use these relation patterns as fixture seeds:</p>\n<ol><li>`activityTookPlaceAtPlace` fixture</li></ol>\n<ul><li>place linked to event/activity records via `took_place_at`.</li></ul>\n<ol><li>Lifecycle-at-place fixtures</li></ol>\n<ul><li>`personBornAtPlace`, `personDiedAtPlace`, `groupFormedAtPlace`, `groupDissolvedAtPlace`.</li></ul>\n<ol><li>Agent-at-place fixtures</li></ol>\n<ul><li>`agentActiveAtPlace`, `agentResidentAtPlace`, plus combined born/formed and died/dissolved relations.</li></ul>\n<ol><li>Object-at-place fixtures</li></ol>\n<ul><li>current location, encountered-at, produced-at, and production-influenced-by place relations.</li></ul>\n<ol><li>Place hierarchy fixture</li></ol>\n<ul><li>`placePartOfPlace` inverse discovery.</li></ul>\n<ol><li>Set-at-place fixture</li></ol>\n<ul><li>`setCreatedAtPlace` via creation activities.</li></ul>\n<ol><li>Work-at-place fixtures</li></ol>\n<ul><li>`workAboutPlace`, `workRepresentsPlace`, combined `workAboutOrRepresentsPlace`, `workCreatedAtPlace`, `workPublishedAtPlace`.</li></ul>\n<ol><li>Concept-influence fixture</li></ol>\n<ul><li>`conceptInfluencedByPlace` relation from place to concept records.</li></ul>\n<p>---</p>\n<h2 id=\"round-77-addendum-search-relations-concept\">Round 77 Addendum — Search Relations: Concept</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API relation docs (Concept-focused search links, including Language/Material specializations)</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Documented concept-centric search relations include:</li><li>`activityClassifiedAsConcept`</li><li>`agentClassifiedAsConcept`</li><li>`conceptBroaderConcept`</li><li>`conceptClassifiedAsConcept`</li><li>`conceptInfluencedByConcept`</li><li>`objectClassifiedAsConcept`</li><li>`objectMadeOfMaterial`</li><li>`objectProductionTechniqueConcept`</li><li>`placeClassifiedAsConcept`</li><li>`setClassifiedAsConcept`</li><li>`workAboutConcept`</li><li>`workAboutOrRepresentsConcept`</li><li>`workClassifiedAsConcept`</li><li>`workCreationTechniqueConcept`</li><li>`workLanguageLanguage`</li><li>`workRepresentsConcept`</li><li>Relation definitions specify:</li><li>source class (`Concept`, plus special-source subclasses such as `Language` and `Material`)</li><li>return class family (`Temporal`, `Agent`, `Concept`, `HumanMadeObject`, `Place`, `Set`, `Work`, `LinguisticObject`)</li><li>semantic edge (`classifiedAs`, `broader`, `influencedBy`, `madeOf`, `productionTechnique`, `about`, `represents`, `creationTechnique`, `language`)</li><li>Provided SPARQL references act as semantic oracle for inverse traversal correctness.</li></ul>\n<h3 id=\"implementation-mapping-concept-search-relations\">Implementation Mapping — Concept Search Relations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Relation-name publication</li></ol>\n<ul><li>Publish stable HAL relation links for the documented concept-centric relation set.</li></ul>\n<ol><li>Source-class specialization</li></ol>\n<ul><li>Enforce source-class-specific relations:</li><li>`objectMadeOfMaterial` expects material-class source semantics</li><li>`workLanguageLanguage` expects language-class source semantics</li></ul>\n<ol><li>Result-class fidelity</li></ol>\n<ul><li>Ensure each relation returns the documented class family (including broader “Temporal” or “Work” family aliases where used).</li></ul>\n<ol><li>Classification-vs-technique-vs-about semantics</li></ol>\n<ul><li>Keep `classifiedAs`, `production/creationTechnique`, `about`, and `represents` semantics separated in relation handlers.</li></ul>\n<ol><li>Hierarchy and influence semantics</li></ol>\n<ul><li>Preserve `broader` inverse/narrower behavior and concept influence chains distinctly.</li></ul>\n<ol><li>Search-page compliance</li></ol>\n<ul><li>Relation targets must return valid Search API `OrderedCollectionPage` responses.</li></ul>\n<ol><li>Empty-result omission</li></ol>\n<ul><li>Omit relation links when no matching referring records exist.</li></ul>\n<h3 id=\"tdd-additions-concept-search-relations\">TDD Additions — Concept Search Relations</h3>\n<p>Add failing-first tests for concept-relation conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates each listed relation is either present with valid HAL link shape or omitted when empty</li><li>validates followable relation targets return schema-valid search pages</li></ul>\n<p>Route-level:</p>\n<ul><li>validates `orderedItems[].type` matches documented return class family per relation</li><li>validates source-class-specific relations are only emitted for compatible concept subclasses</li></ul>\n<p>Integration-level:</p>\n<ul><li>graph fixtures verify inverse discovery for:</li><li>entities classified as concept (activity/agent/object/place/set/work/concept)</li><li>concept hierarchy (`broader`) and influence relations</li><li>material-based object queries</li><li>concept-as-technique queries for object production and work creation</li><li>work about / represents concept and combined about-or-represents</li><li>linguistic works by language concept</li></ul>\n<p>Regression:</p>\n<ul><li>relation naming and source/return mappings remain stable across adapters/backends</li><li>classifier-vs-depiction semantics do not collapse into generic “related concepts” results</li></ul>\n<h3 id=\"fixture-anchors-concept-search-relations-examples\">Fixture Anchors — Concept Search Relations Examples</h3>\n<p>Use these relation patterns as fixture seeds:</p>\n<ol><li>`objectClassifiedAsConcept` fixture</li></ol>\n<ul><li>concept returns objects classified with that concept.</li></ul>\n<ol><li>`agentClassifiedAsConcept` fixture</li></ol>\n<ul><li>concept returns people/groups classified with that concept.</li></ul>\n<ol><li>`conceptBroaderConcept` fixture</li></ol>\n<ul><li>broader/narrower concept hierarchy inverse traversal.</li></ul>\n<ol><li>`objectMadeOfMaterial` fixture</li></ol>\n<ul><li>material concept returns objects made of it.</li></ul>\n<ol><li>`objectProductionTechniqueConcept` fixture</li></ol>\n<ul><li>concept returns objects whose production uses that technique.</li></ul>\n<ol><li>`workCreationTechniqueConcept` fixture</li></ol>\n<ul><li>concept returns works whose creation uses that technique.</li></ul>\n<ol><li>`workLanguageLanguage` fixture</li></ol>\n<ul><li>language concept returns linguistic works in that language.</li></ul>\n<ol><li>`workAboutConcept` / `workRepresentsConcept` fixture</li></ol>\n<ul><li>works about concept vs works depicting concept, plus combined relation.</li></ul>\n<ol><li>`setClassifiedAsConcept` / `placeClassifiedAsConcept` fixture</li></ol>\n<ul><li>concept returns classified sets and places.</li></ul>\n<ol><li>`activityClassifiedAsConcept` fixture</li></ol>\n<ul><li>concept returns temporal/activity records classified as concept.</li></ul>\n<p>---</p>\n<h2 id=\"round-78-addendum-search-relations-temporal-event-activity\">Round 78 Addendum — Search Relations: Temporal / Event / Activity</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API relation docs (Temporal/Event/Activity-focused search links)</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Documented temporal/activity-centric search relations include:</li><li>`activityCausedByActivity`</li><li>`activityPartOfActivity`</li><li>`conceptCreationCausedByActivity`</li><li>`conceptInfluencedByActivity`</li><li>`objectDestructionCausedByActivity`</li><li>`objectProductionCausedByActivity`</li><li>`personDeathCausedByActivity`</li><li>`setCreationCausedByActivity`</li><li>`workAboutActivity`</li><li>`workAboutOrRepresentsActivity`</li><li>`workCreationCausedByActivity`</li><li>`workRepresentsActivity`</li><li>Relation definitions specify:</li><li>source class family (`Event`, `Activity`, or broader `Temporal`)</li><li>return class family (`Temporal`, `Concept`, `HumanMadeObject`, `Person`, `Set`, `Work`)</li><li>causal, partitive, aboutness, and depiction inverse semantics</li><li>Provided examples emphasize:</li><li>causality chains (event/activity causing creation, destruction, death)</li><li>temporal containment (`partOf`)</li><li>works about/representing temporal entities</li></ul>\n<h3 id=\"implementation-mapping-temporal-activity-search-relations\">Implementation Mapping — Temporal/Activity Search Relations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Relation-name publication</li></ol>\n<ul><li>Publish stable HAL relation links for the documented temporal/event/activity relation set.</li></ul>\n<ol><li>Source-class family gating</li></ol>\n<ul><li>Enforce source compatibility for `Event`/`Activity`-specific vs broader `Temporal` relations.</li></ul>\n<ol><li>Result-class fidelity</li></ol>\n<ul><li>Ensure relation result item classes match documented return families.</li></ul>\n<ol><li>Causality semantics preservation</li></ol>\n<ul><li>Preserve explicit caused-by inverse semantics for production/destruction/creation/death related relations.</li></ul>\n<ol><li>Part-of temporal hierarchy semantics</li></ol>\n<ul><li>Preserve temporal part/whole traversal semantics for period/event/activity nesting.</li></ul>\n<ol><li>About-vs-represents separation</li></ol>\n<ul><li>Preserve distinction between `about`, `represents`, and combined about-or-represents relation behavior.</li></ul>\n<ol><li>Search-page compliance</li></ol>\n<ul><li>Relation targets must return valid Search API `OrderedCollectionPage` responses.</li></ul>\n<ol><li>Empty-result omission</li></ol>\n<ul><li>Omit relation links when no matching records exist.</li></ul>\n<h3 id=\"tdd-additions-temporal-activity-search-relations\">TDD Additions — Temporal/Activity Search Relations</h3>\n<p>Add failing-first tests for temporal/activity relation conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates each listed relation is either present with valid HAL link shape or omitted when empty</li><li>validates followable relation targets return schema-valid search pages</li></ul>\n<p>Route-level:</p>\n<ul><li>validates `orderedItems[].type` against documented return class family per relation</li><li>validates source-family-incompatible relations are not emitted</li></ul>\n<p>Integration-level:</p>\n<ul><li>graph fixtures verify inverse discovery for:</li><li>activities caused by source event/activity</li><li>temporal part-of hierarchies</li><li>concepts created/ influenced by temporal entities</li><li>objects whose production/destruction is causally linked</li><li>persons whose death is causally linked</li><li>sets created due to event/activity</li><li>works about/representing temporal entities</li><li>works created due to event/activity</li></ul>\n<p>Regression:</p>\n<ul><li>relation naming and class mapping remain stable across adapters/backends</li><li>causality and partitive semantics do not collapse into generic related-item queries</li></ul>\n<h3 id=\"fixture-anchors-temporal-activity-search-relations-examples\">Fixture Anchors — Temporal/Activity Search Relations Examples</h3>\n<p>Use these relation patterns as fixture seeds:</p>\n<ol><li>`activityCausedByActivity` fixture</li></ol>\n<ul><li>event/activity returning downstream caused activities.</li></ul>\n<ol><li>`activityPartOfActivity` fixture</li></ol>\n<ul><li>period/event/activity with nested temporal components.</li></ul>\n<ol><li>`objectProductionCausedByActivity` fixture</li></ol>\n<ul><li>causal activity returning produced object records.</li></ul>\n<ol><li>`objectDestructionCausedByActivity` fixture</li></ol>\n<ul><li>destructive event returning destroyed object records.</li></ul>\n<ol><li>`personDeathCausedByActivity` fixture</li></ol>\n<ul><li>event/activity returning persons with causally linked deaths.</li></ul>\n<ol><li>`conceptInfluencedByActivity` fixture</li></ol>\n<ul><li>temporal source returning influenced concept records.</li></ul>\n<ol><li>`workAboutActivity` / `workRepresentsActivity` fixture</li></ol>\n<ul><li>separated about vs represents work sets.</li></ul>\n<ol><li>`workAboutOrRepresentsActivity` fixture</li></ol>\n<ul><li>combined about-or-represents work set behavior.</li></ul>\n<ol><li>`workCreationCausedByActivity` fixture</li></ol>\n<ul><li>event/activity returning works created as causal outcome.</li></ul>\n<ol><li>`setCreationCausedByActivity` fixture</li></ol>\n<ul><li>event/activity returning sets created due to source activity.</li></ul>\n<p>---</p>\n<h2 id=\"round-79-addendum-search-relations-set\">Round 79 Addendum — Search Relations: Set</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API relation docs (Set-focused search links)</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Documented set-centric search relations include:</li><li>`activityUsedSet`</li><li>`conceptInfluencedBySet`</li><li>`conceptMemberOfSet`</li><li>`entityMemberOfSet`</li><li>`objectMemberOfSet`</li><li>`placeMemberOfSet`</li><li>`setMemberOfSet`</li><li>`temporalMemberOfSet`</li><li>`workAboutOrRepresentsSet`</li><li>`workAboutSet`</li><li>`workMemberOfSet`</li><li>`workRepresentsSet`</li><li>Relation definitions specify:</li><li>source class (`Set`)</li><li>return class family (`Activity`, `Concept`, `Entity`, `HumanMadeObject`, `Place`, `Set`, `Temporal`, `Work`)</li><li>semantic basis (`used`, `influencedBy`, `memberOf`, `about`, `represents`)</li><li>These relations extend set discoverability without requiring full member embedding in set records.</li></ul>\n<h3 id=\"implementation-mapping-set-search-relations\">Implementation Mapping — Set Search Relations</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Relation-name publication</li></ol>\n<ul><li>Publish stable HAL relation links for the documented set-centric relations.</li></ul>\n<ol><li>Membership-matrix fidelity</li></ol>\n<ul><li>Preserve distinct membership relation views by target class (`entity`, `object`, `place`, `set`, `temporal`, `work`, `concept`).</li></ul>\n<ol><li>Generic-vs-specialized relation coherence</li></ol>\n<ul><li>Ensure `entityMemberOfSet` remains a superset-compatible view while specialized member relations return filtered class families.</li></ul>\n<ol><li>About-vs-represents semantics</li></ol>\n<ul><li>Preserve distinct `workAboutSet`, `workRepresentsSet`, and combined `workAboutOrRepresentsSet` relation behavior.</li></ul>\n<ol><li>Activity/influence semantics</li></ol>\n<ul><li>Preserve `activityUsedSet` and `conceptInfluencedBySet` edges without collapsing into generic related-item sets.</li></ul>\n<ol><li>Search-page compliance</li></ol>\n<ul><li>Relation targets must return valid Search API `OrderedCollectionPage` responses.</li></ul>\n<ol><li>Empty-result omission</li></ol>\n<ul><li>Omit relation links when no matching records exist.</li></ul>\n<h3 id=\"tdd-additions-set-search-relations\">TDD Additions — Set Search Relations</h3>\n<p>Add failing-first tests for set-relation conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates each listed set relation is either present with valid HAL link shape or omitted when empty</li><li>validates followable relation targets return schema-valid search pages</li></ul>\n<p>Route-level:</p>\n<ul><li>validates `orderedItems[].type` matches documented return class family per relation</li><li>validates specialized member relations enforce class-specific filtering</li></ul>\n<p>Integration-level:</p>\n<ul><li>graph fixtures verify inverse discovery for:</li><li>activities using set</li><li>concepts influenced by set</li><li>concepts/entities/objects/places/sets/temporals/works that are members of set</li><li>works about set</li><li>works representing set</li><li>combined about-or-represents set relation</li></ul>\n<p>Regression:</p>\n<ul><li>relation naming and class-return mappings remain stable across providers/backends</li><li>specialized relations do not regress into only generic `entityMemberOfSet` behavior</li></ul>\n<h3 id=\"fixture-anchors-set-search-relations-examples\">Fixture Anchors — Set Search Relations Examples</h3>\n<p>Use these relation patterns as fixture seeds:</p>\n<ol><li>`activityUsedSet` fixture</li></ol>\n<ul><li>set linked to one or more activities using it.</li></ul>\n<ol><li>`entityMemberOfSet` fixture</li></ol>\n<ul><li>set with mixed-member classes returned in generic member relation.</li></ul>\n<ol><li>Specialized membership fixtures</li></ol>\n<ul><li>`objectMemberOfSet`, `placeMemberOfSet`, `setMemberOfSet`, `temporalMemberOfSet`, `workMemberOfSet`, `conceptMemberOfSet`.</li></ul>\n<ol><li>`conceptInfluencedBySet` fixture</li></ol>\n<ul><li>set linked to concept(s) influenced by set context.</li></ul>\n<ol><li>`workAboutSet` fixture</li></ol>\n<ul><li>works about set.</li></ul>\n<ol><li>`workRepresentsSet` fixture</li></ol>\n<ul><li>visual works depicting set.</li></ul>\n<ol><li>`workAboutOrRepresentsSet` fixture</li></ol>\n<ul><li>combined result set of about-or-represents relations.</li></ul>\n<p>---</p>\n<h2 id=\"round-80-addendum-data-discovery\">Round 80 Addendum — Data Discovery</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API 1.0: Data Discovery</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Linked Art records should be discoverable from non-Linked-Art entrypoints, especially HTML pages.</li><li>Discovery/signposting requirements:</li><li>HTML `&lt;head&gt;` link with `rel=&quot;describedby&quot;` to Linked Art JSON-LD record is required.</li><li>HTTP `Link` header with `rel=&quot;describedby&quot;` is recommended where possible.</li><li>exactly one linked-art `describedby` target per page to avoid client ambiguity.</li><li>media type should declare Linked Art JSON-LD profile:</li><li>`application/ld+json;profile=&#39;https://linked.art/ns/v1/linked-art.json&#39;`</li><li>This aligns with FAIR Signposting profile behavior.</li><li>Harvesting/synchronization guidance:</li><li>use IIIF Change Discovery API for cross-collection aggregation and sync.</li><li>include Linked Art record-type extension context:</li><li>`https://linked.art/ns/v1/record-types.json`</li><li>alongside IIIF discovery context</li><li>enables change stream entries to carry Linked Art record `type` values (for example `HumanMadeObject`).</li></ul>\n<h3 id=\"implementation-mapping-data-discovery\">Implementation Mapping — Data Discovery</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>HTML signposting requirement</li></ol>\n<ul><li>Ensure HTML views include exactly one `&lt;link rel=&quot;describedby&quot; ...&gt;` to canonical Linked Art record.</li></ul>\n<ol><li>HTTP link-header support</li></ol>\n<ul><li>Emit `Link: &lt;...&gt;; rel=&quot;describedby&quot;; type=&quot;application/ld+json;profile=&#39;...&#39;&quot;` when transport/runtime allows.</li></ul>\n<ol><li>Canonical record binding</li></ol>\n<ul><li>Keep describedby target stable, canonical, and one-to-one with rendered page entity.</li></ul>\n<ol><li>Change-discovery integration</li></ol>\n<ul><li>Expose or integrate IIIF Change Discovery endpoints for harvesting/sync workflows.</li></ul>\n<ol><li>Context extension compliance</li></ol>\n<ul><li>Ensure IIIF change stream contexts include both Linked Art record-types context and IIIF discovery context.</li></ul>\n<ol><li>Type propagation in change events</li></ol>\n<ul><li>Preserve Linked Art record types in change event `object.type` fields.</li></ul>\n<h3 id=\"tdd-additions-data-discovery\">TDD Additions — Data Discovery</h3>\n<p>Add failing-first tests for discovery conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates HTML responses include exactly one valid describedby link in `&lt;head&gt;`</li><li>validates describedby link MIME/profile declaration format</li><li>validates optional HTTP `Link` header format when enabled</li></ul>\n<p>Route-level:</p>\n<ul><li>HTML view route and JSON-LD data route stay correctly paired by describedby URI</li><li>duplicate/missing describedby link scenarios fail checks</li></ul>\n<p>Integration-level:</p>\n<ul><li>IIIF change stream includes required dual contexts (`record-types` + IIIF discovery)</li><li>change events include Linked Art record `id` and `type` values</li></ul>\n<p>Regression:</p>\n<ul><li>page template updates cannot remove or duplicate describedby signposts</li><li>harvesting stream changes cannot drop Linked Art record type extension context</li></ul>\n<h3 id=\"fixture-anchors-data-discovery-examples\">Fixture Anchors — Data Discovery Examples</h3>\n<p>Use these discovery patterns as fixture seeds:</p>\n<ol><li>HTML head signpost fixture</li></ol>\n<ul><li>one `&lt;link rel=&quot;describedby&quot; ...&gt;` to canonical Linked Art JSON-LD URI.</li></ul>\n<ol><li>HTTP header signpost fixture</li></ol>\n<ul><li>response with correct `Link` header profile/media type.</li></ul>\n<ol><li>Duplicate-link negative fixture</li></ol>\n<ul><li>page with multiple describedby links fails validation.</li></ul>\n<ol><li>IIIF context fixture</li></ol>\n<ul><li>change discovery payload with both required contexts in proper order.</li></ul>\n<ol><li>Change event type fixture</li></ol>\n<ul><li>update event object with Linked Art `id` and `type` (for example `HumanMadeObject`).</li></ul>\n<p>---</p>\n<h2 id=\"round-81-addendum-api-design-principles-and-practical-requirements\">Round 81 Addendum — API Design Principles and Practical Requirements</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API: Design Principles + Requirements and Design Specifics</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ol><li>scope via shared use cases</li></ol>\n<ol><li>internationalization support</li></ol>\n<ol><li>as simple as possible (progressive complexity)</li></ol>\n<ol><li>avoid stack lock-in</li></ol>\n<ol><li>REST/web compatibility and cacheability</li></ol>\n<ol><li>JSON-LD-first while following LOD principles</li></ol>\n<ol><li>standards/best-practice reuse when practical</li></ol>\n<ol><li>define success-not-failure for extensibility</li></ol>\n<ol><li>network-aware design</li></ol>\n<ol><li>solve at the correct layer (API vs model)</li></ol>\n<ul><li>Core design principles (IIIF-inspired) emphasize:</li><li>Practical requirements reinforce:</li><li>trivial implementation possible via static files</li><li>hand-authorable JSON should remain possible</li><li>response count/size should stay minimal while consistent</li><li>each statement should appear in one response where possible</li><li>if a resource has many incoming references, it should be its own response</li><li>inverse relationships should be resolved via dedicated APIs rather than duplicate assertions</li><li>partition/part relationships generally flow from many -&gt; one</li><li>embed 1:1 dependent constructs where separate dereference is unnecessary</li><li>URIs should remain opaque; no required URI structure assumptions</li></ul>\n<h3 id=\"implementation-mapping-api-design-requirements\">Implementation Mapping — API Design Requirements</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>File-first operability</li></ol>\n<ul><li>Ensure core read-paths can run from static JSON artifacts without requiring dynamic query infrastructure.</li></ul>\n<ol><li>Single-assertion direction policy</li></ol>\n<ul><li>Encode relationships once in canonical direction; provide inverse-discovery via search/HAL links.</li></ul>\n<ol><li>Many-to-one partitioning discipline</li></ol>\n<ul><li>Prefer child-to-parent links for partition-heavy domains (for example page -&gt; book, part -&gt; whole).</li></ul>\n<ol><li>Minimal redundancy guardrail</li></ol>\n<ul><li>Avoid duplicating the same fact across multiple payloads unless explicitly justified as performance exception.</li></ul>\n<ol><li>1:1 embed policy</li></ol>\n<ul><li>Embed dependent 1:1 structures (names, dimensions, timespans, etc.) unless separate dereference is needed.</li></ul>\n<ol><li>URI opacity</li></ol>\n<ul><li>Avoid route/client logic that depends on URI path-shape assumptions beyond dereferenceability.</li></ul>\n<ol><li>Layer-correct solutions</li></ol>\n<ul><li>Put data-description problems in model contracts; interaction/navigation problems in API/HAL/search layers.</li></ul>\n<h3 id=\"tdd-additions-api-design-requirements\">TDD Additions — API Design Requirements</h3>\n<p>Add failing-first tests for architecture conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates no duplicated canonical assertions across designated record pairs where single-direction policy applies</li><li>validates embedded 1:1 structures follow shared-structure contracts</li></ul>\n<p>Route-level:</p>\n<ul><li>validates inverse relationship discoverability through search/HAL links rather than duplicated forward+inverse fields</li><li>validates URI consumers treat IDs as opaque strings, not path-pattern parsed keys</li></ul>\n<p>Integration-level:</p>\n<ul><li>static-file fixture mode produces equivalent read responses to dynamic mode for core endpoints</li><li>partition fixtures confirm many-&gt;one link direction and inverse discovery behavior</li></ul>\n<p>Regression:</p>\n<ul><li>optimization changes cannot silently introduce broad statement duplication</li><li>backend swaps cannot break file-first minimum implementation mode</li></ul>\n<h3 id=\"fixture-anchors-api-design-requirements-examples\">Fixture Anchors — API Design Requirements Examples</h3>\n<p>Use these architecture patterns as fixture seeds:</p>\n<ol><li>Static-mode parity fixture</li></ol>\n<ul><li>endpoint responses from static artifacts match dynamic pipeline outputs.</li></ul>\n<ol><li>Single-direction relationship fixture</li></ol>\n<ul><li>fact appears once; inverse discovered via search link.</li></ul>\n<ol><li>Partition direction fixture</li></ol>\n<ul><li>child records reference parent; parent inverse list discovered via search API.</li></ul>\n<ol><li>Opaque URI fixture</li></ol>\n<ul><li>consumer utilities handle arbitrary URI structures without path-shape coupling.</li></ul>\n<ol><li>1:1 embed fixture</li></ol>\n<ul><li>embedded dependent structures (name/dimension/timespan) validate without separate dereference requirement.</li></ul>\n<p>---</p>\n<h2 id=\"round-82-addendum-json-ld-and-context-design\">Round 82 Addendum — JSON-LD and Context Design</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API: JSON-LD serialization + context design rules</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Canonical Linked Art context:</li><li>`https://linked.art/ns/v1/linked-art.json`</li><li>Canonical media type/profile:</li><li>`application/ld+json;profile=&quot;https://linked.art/ns/v1/linked-art.json&quot;`</li><li>Core serialization constraints:</li><li>terms are case-sensitive (for example `Type` vs `type`)</li><li>JSON properties cannot be repeated; multi-values use arrays</li><li>Linked Art avoids RDF ordered list structures and relies on array order</li><li>Other RDF/graph serializations may exist but are optional and must not be assumed.</li><li>Context design goals:</li><li>valid JSON-LD + LOD semantics</li><li>developer-friendly JSON shapes</li><li>cross-language implementation usability</li><li>Context transformation strategy from CRM terms includes:</li><li>namespace/prefix cleanup</li><li>number/punctuation simplification</li><li>class naming to UpperCamelCase</li><li>property naming to lower_snake_case</li><li>collision resolution and inconsistency normalization</li><li>Context uses JSON-LD 1.1 scoped contexts and set containers:</li><li>`@container: @set` for properties that may have multiple values</li><li>mapped partition relationships to consistent `part` / `part_of` keys</li></ul>\n<h3 id=\"implementation-mapping-json-ld-context-design\">Implementation Mapping — JSON-LD Context Design</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Context/media-type correctness</li></ol>\n<ul><li>Always emit canonical Linked Art context and correct JSON-LD profile media type on API responses.</li></ul>\n<ol><li>Case-sensitive key discipline</li></ol>\n<ul><li>Enforce key casing exactly per context definitions in serializers and validators.</li></ul>\n<ol><li>Array-normalization rule</li></ol>\n<ul><li>Emit array form for potentially multi-valued properties, even when only one value is present.</li></ul>\n<ol><li>Context-driven naming consistency</li></ol>\n<ul><li>Use context-resolved canonical keys (including normalized collision-resolved keys) consistently across all routes.</li></ul>\n<ol><li>Scoped-context behavior preservation</li></ol>\n<ul><li>Preserve `part` / `part_of` unified readability while keeping underlying semantic precision.</li></ul>\n<ol><li>Optional format tolerance</li></ol>\n<ul><li>Support alternate serializations where offered, but do not require them for conformance.</li></ul>\n<ol><li>Collision-map stability</li></ol>\n<ul><li>Treat documented collision/inconsistency remappings as stable API contract behavior, not implementation details.</li></ul>\n<h3 id=\"tdd-additions-json-ld-context-design\">TDD Additions — JSON-LD Context Design</h3>\n<p>Add failing-first tests for JSON-LD/context conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates root `@context` matches canonical Linked Art context URI</li><li>validates case-sensitive keys and rejection of incorrect-cased alternatives</li><li>validates single-or-many fields are serialized as arrays where context requires set behavior</li></ul>\n<p>Route-level:</p>\n<ul><li>validates `Content-Type` profile string for JSON-LD responses</li><li>validates partition relationships serialize consistently as `part` / `part_of` where scoped context applies</li></ul>\n<p>Integration-level:</p>\n<ul><li>round-trip tests verify JSON-LD expansions preserve expected RDF semantics</li><li>context collision-remap keys stay stable across endpoint families</li></ul>\n<p>Regression:</p>\n<ul><li>serializer changes cannot reintroduce CRM raw-term inconsistencies into payload keys</li><li>profile/media-type drift is caught by response-header contract tests</li></ul>\n<h3 id=\"fixture-anchors-json-ld-context-design-examples\">Fixture Anchors — JSON-LD Context Design Examples</h3>\n<p>Use these JSON-LD patterns as fixture seeds:</p>\n<ol><li>Canonical context fixture</li></ol>\n<ul><li>payload with exact linked-art context URI and profile media type.</li></ul>\n<ol><li>Case-sensitivity negative fixture</li></ol>\n<ul><li>incorrect-cased term keys fail validation.</li></ul>\n<ol><li>Array-singleton fixture</li></ol>\n<ul><li>potentially multi-valued property serialized as single-entry array.</li></ul>\n<ol><li>Partition key fixture</li></ol>\n<ul><li>scoped-context mapped `part` / `part_of` relations with expected semantics.</li></ul>\n<ol><li>Collision-key stability fixture</li></ol>\n<ul><li>payload uses normalized context keys (not raw CRM-numbered property names).</li></ul>\n<ol><li>Expansion integrity fixture</li></ol>\n<ul><li>JSON-LD expansion check confirming preserved predicate mapping.</li></ul>\n<p>---</p>\n<h2 id=\"round-83-addendum-protocol-http-rest\">Round 83 Addendum — Protocol (HTTP/REST)</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art API: Protocol</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>Linked Art protocol profile is REST/resource-centric over HTTP.</li><li>Transport/security/version guidance:</li><li>HTTPS strongly recommended</li><li>servers must support HTTP/1.1</li><li>servers should support HTTP/2+</li><li>Operation support:</li><li>publishers must support `GET` and `OPTIONS`</li><li>publishers should support `HEAD`</li><li>clients must not rely on `HEAD` support</li><li>Content negotiation:</li><li>request `Accept: application/ld+json;profile=&quot;https://linked.art/ns/v1/linked-art.json&quot;`</li><li>response `Content-Type: application/ld+json;profile=&quot;https://linked.art/ns/v1/linked-art.json&quot;`</li><li>alternate serializations may be supported, but discovery mechanism is not standardized by Linked Art</li><li>CORS requirements:</li><li>responses must include `Access-Control-Allow-Origin: *`</li><li>`OPTIONS` preflight responses must include CORS headers as well</li><li>URI policy:</li><li>no strict URI structure requirements (URIs remain opaque)</li><li>preferred shape: `scheme://hostname/prefix/endpoint/identifier`</li><li>preferred endpoint path names:</li><li>`concept`, `digital`, `event`, `group`, `object`, `person`, `place`, `provenance`, `set`, `text`, `visual`</li></ul>\n<h3 id=\"implementation-mapping-protocol\">Implementation Mapping — Protocol</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Method support compliance</li></ol>\n<ul><li>Ensure all public API routes support `GET` and `OPTIONS`; optionally support `HEAD` without client dependency.</li></ul>\n<ol><li>JSON-LD conneg compliance</li></ol>\n<ul><li>Enforce Accept/Content-Type profile handling for Linked Art JSON-LD responses.</li></ul>\n<ol><li>CORS baseline compliance</li></ol>\n<ul><li>Emit `Access-Control-Allow-Origin: *` on both normal and preflight responses for API resources.</li></ul>\n<ol><li>HTTP-version readiness</li></ol>\n<ul><li>Maintain HTTP/1.1 compatibility; prefer HTTP/2+ deployment where available.</li></ul>\n<ol><li>URI opacity discipline</li></ol>\n<ul><li>Treat all URIs as opaque in client/server logic; never depend on URI path parsing for semantics.</li></ul>\n<ol><li>URI good-practice alignment</li></ol>\n<ul><li>Where controllable, align endpoint naming and URI patterns with preferred conventions for maintainability.</li></ul>\n<h3 id=\"tdd-additions-protocol\">TDD Additions — Protocol</h3>\n<p>Add failing-first tests for protocol conformance:</p>\n<p>Contract-level:</p>\n<ul><li>validates response `Content-Type` includes Linked Art JSON-LD profile</li><li>validates preflight and normal responses include required CORS header</li></ul>\n<p>Route-level:</p>\n<ul><li>validates `GET` and `OPTIONS` are supported for endpoint families</li><li>validates unsupported methods return controlled/consistent status behavior</li></ul>\n<p>Integration-level:</p>\n<ul><li>validates conneg behavior for profile-accepting requests</li><li>validates route behavior remains stable regardless of URI shape assumptions</li></ul>\n<p>Regression:</p>\n<ul><li>deployment/config changes cannot drop CORS headers or content-profile headers</li><li>router changes cannot break preferred endpoint namespace mapping where implemented</li></ul>\n<h3 id=\"fixture-anchors-protocol-examples\">Fixture Anchors — Protocol Examples</h3>\n<p>Use these protocol patterns as fixture seeds:</p>\n<ol><li>GET success fixture</li></ol>\n<ul><li>endpoint returns JSON-LD payload with canonical Content-Type profile.</li></ul>\n<ol><li>OPTIONS preflight fixture</li></ol>\n<ul><li>preflight response includes `Access-Control-Allow-Origin: *`.</li></ul>\n<ol><li>HEAD optional-support fixture</li></ol>\n<ul><li>if implemented, returns headers-only response; client tests remain non-dependent.</li></ul>\n<ol><li>Conneg fixture</li></ol>\n<ul><li>request with Linked Art Accept profile returns matching profile Content-Type.</li></ul>\n<ol><li>URI opacity fixture</li></ol>\n<ul><li>alternative URI path patterns still resolve correctly without parser assumptions.</li></ul>\n<ol><li>Endpoint-name mapping fixture</li></ol>\n<ul><li>canonical endpoint paths (`object`, `person`, etc.) map to expected serializers.</li></ul>\n<p>---</p>\n<h2 id=\"round-84-addendum-code-and-tools-ecosystem\">Round 84 Addendum — Code and Tools Ecosystem</h2>\n<p>Source section basis:</p>\n<ul><li>Linked Art: Code and Tools references</li><li>Captured for this addendum on: May 30, 2026</li></ul>\n<p>Official-model takeaways captured for implementation:</p>\n<ul><li>This section is ecosystem guidance rather than normative API contract rules.</li><li>Referenced software/library/platform categories include:</li><li>Libraries:</li><li>Crom (Python)</li><li>LinkedArt.js (JavaScript)</li><li>Linked.Art.Net (C#/.NET)</li><li>Platforms:</li><li>LUX (open-source cross-collection discovery implementation)</li><li>Arches</li><li>Ogee Arches package (Linked Art model + vocabulary support)</li><li>Documentation/pattern tooling:</li><li>Zellij (semantic pattern library representation)</li><li>Validators:</li><li>JSON validator service based on Linked Art schemas</li><li>Other resources:</li><li>data-model visualization tools</li><li>Mermaid Live Editor</li><li>OpenRefine for collections data cleanup/handling</li></ul>\n<h3 id=\"implementation-mapping-code-and-tools\">Implementation Mapping — Code and Tools</h3>\n<p>Apply these requirements to adapters, normalization, and route outputs:</p>\n<ol><li>Non-normative dependency policy</li></ol>\n<ul><li>Treat tooling references as implementation accelerators, not as conformance requirements.</li></ul>\n<ol><li>Toolchain selection criteria</li></ol>\n<ul><li>Prefer tools that preserve Linked Art schema/context fidelity and integrate with existing test/validation workflows.</li></ul>\n<ol><li>Validator integration</li></ol>\n<ul><li>Keep JSON Schema validation in automated pipelines regardless of chosen library/platform stack.</li></ul>\n<ol><li>Pattern documentation integration</li></ol>\n<ul><li>Use pattern libraries/visualization tools to strengthen onboarding, mapping clarity, and query/template generation.</li></ul>\n<ol><li>Data hygiene workflow support</li></ol>\n<ul><li>Integrate data-cleaning tooling (for example OpenRefine-compatible flows) upstream of ingestion where helpful.</li></ul>\n<h3 id=\"tdd-additions-code-and-tools\">TDD Additions — Code and Tools</h3>\n<p>Add failing-first tests for toolchain reliability expectations:</p>\n<p>Contract-level:</p>\n<ul><li>validate core payloads with schema validators independent of runtime language/library</li></ul>\n<p>Integration-level:</p>\n<ul><li>smoke tests confirm chosen serializer/parser libraries preserve canonical context and key semantics</li><li>import/cleanup workflows retain required Linked Art fields after transformation</li></ul>\n<p>Regression:</p>\n<ul><li>library/platform upgrades do not alter canonical payload shape or break schema conformance</li><li>toolchain swaps maintain identical API-facing contracts</li></ul>\n<h3 id=\"fixture-anchors-code-and-tools-examples\">Fixture Anchors — Code and Tools Examples</h3>\n<p>Use these ecosystem-oriented patterns as fixture seeds:</p>\n<ol><li>Cross-library parity fixture</li></ol>\n<ul><li>same record serialized/parsed through selected library paths yields equivalent canonical JSON-LD.</li></ul>\n<ol><li>Validator parity fixture</li></ol>\n<ul><li>local CI schema validation and external validator results agree on pass/fail.</li></ul>\n<ol><li>Data-cleaning fixture</li></ol>\n<ul><li>pre/post-cleaning payloads retain required Linked Art semantics and identifiers.</li></ul>\n<ol><li>Visualization/documentation fixture</li></ol>\n<ul><li>model pattern artifacts generated from fixture graph remain consistent with schema contracts.</li></ul>\n<p>---</p>\n<h2 id=\"round-1-open-items-for-next-docs-drop\">Round 1 Open Items For Next Docs Drop</h2>\n<p>Please add official material in future rounds for:</p>\n<ul><li>detailed basic pattern examples</li><li>required vs recommended vs optional terminology specifics</li><li>concrete JSON-LD examples for activities, provenance, exhibitions, conservation, and object production/destruction</li><li>model versioning rules and upgrade guidance</li><li>specific assertions and archival hierarchy examples</li></ul>\n<p>When those arrive, we should extend this file with explicit fixture-driven test plans.</p>","updatedAt":"2018-10-20T01:46:40.000Z","checksum":"e6d48d474b3ef2ce9af7395c61cb0fd9ba28e2496c4dd865f1a1be5fe6b9e571","checksumPrefix":"e6d48d474b3e","anchorCount":344,"lineCount":8567,"rawUrl":"/api/docs/content?path=linked-art%2FLinkedArtModel1.0-Reference.md","htmlUrl":"/docs?doc=linked-art%2FLinkedArtModel1.0-Reference.md","apiUrl":"/api/docs/content?path=linked-art%2FLinkedArtModel1.0-Reference.md"}