glam/COLLECTION_DEPARTMENT_INTEGRATION_COMPLETE_20251122.md

Collection-Department Integration Complete (Phase 4)

Date: 2025-11-22
Schema Version: v0.6.0 → v0.7.0
Phase: 4 of Multi-Phase Organizational Architecture
Status: ✅ COMPLETE

---

Executive Summary

Phase 4 successfully integrates CustodianCollection (heritage collections) with OrganizationalStructure (departments/divisions) through bidirectional relationships. This completes the three-way integration of Staff ↔ Organizational Units ↔ Collections, enabling comprehensive queries across personnel, organizational structure, and heritage materials.

Key Achievement: The schema now models the complete organizational ecology of heritage institutions—who works where, what they manage, and how these relationships evolve through institutional reorganizations.

---

What Was Built

1. Two New Slots for Bidirectional Relationships

Slot 1: managing_unit (Collection → Organizational Unit)

File: schemas/20251121/linkml/modules/slots/managing_unit.yaml

slots:
  managing_unit:
    description: >-
      The organizational unit (department, division, section) responsible for 
      managing this collection.      
    range: OrganizationalStructure
    multivalued: false
    slot_uri: org:unitOf
    inverse: managed_collections

Purpose:

• Links CustodianCollection → OrganizationalStructure
• Answers: "Which department manages this collection?"
• One collection has ONE managing unit (organizational responsibility)

W3C ORG Alignment: org:unitOf (unit responsible for entity)

---

Slot 2: managed_collections (Organizational Unit → Collections)

File: schemas/20251121/linkml/modules/slots/managed_collections.yaml

slots:
  managed_collections:
    description: >-
      Collections managed by this organizational unit.      
    range: CustodianCollection
    multivalued: true
    slot_uri: org:hasUnit
    inverse: managing_unit

Purpose:

• Links OrganizationalStructure → CustodianCollection (one-to-many)
• Answers: "What collections does this department manage?"
• One unit manages MULTIPLE collections

W3C ORG Alignment: org:hasUnit (conceptual extension for collections)

---

2. Updated CustodianCollection Class

File: schemas/20251121/linkml/modules/classes/CustodianCollection.yaml

Changes:

1. Added OrganizationalStructure to imports (line 17)
2. Added managing_unit to slots list (line 91)
3. Added comprehensive slot_usage documentation (~80 lines):
   • Bidirectional relationship explanation
   • 3 use cases with examples
   • Temporal consistency rules
   • 2 SPARQL query examples
   • Organizational change tracking notes

New Capabilities:

CustodianCollection:
  id: https://w3id.org/heritage/custodian/nl/rmv/collection/dutch-paintings
  collection_name: Dutch Paintings Collection
  managing_unit: https://w3id.org/heritage/custodian/nl/rmv/unit/paintings-dept
  # ↑ NEW: Links to organizational unit managing this collection

---

3. Updated OrganizationalStructure Class

File: schemas/20251121/linkml/modules/classes/OrganizationalStructure.yaml

Changes:

1. Added managed_collections to slots list (line 69)
2. Added comprehensive slot_usage documentation (~120 lines):
   • Bidirectional relationship explanation
   • 3 use cases (collection inventory, staff+collections cross-reference, org change impact)
   • Temporal consistency rules
   • 3 SPARQL query examples (including combined staff+collections queries)
   • Integration with PersonObservation
   • Merger/custody transfer examples

New Capabilities:

OrganizationalStructure:
  id: https://w3id.org/heritage/custodian/nl/rmv/unit/paintings-dept
  unit_name: Paintings Department
  staff_members:  # Phase 3: Staff in this unit
    - https://w3id.org/heritage/custodian/nl/rmv/person/curator-001
  managed_collections:  # Phase 4: Collections managed by this unit (NEW)
    - https://w3id.org/heritage/custodian/nl/rmv/collection/dutch-paintings
    - https://w3id.org/heritage/custodian/nl/rmv/collection/flemish-paintings
    - https://w3id.org/heritage/custodian/nl/rmv/collection/italian-paintings

---

4. Updated Main Schema (v0.7.0)

File: schemas/20251121/linkml/01_custodian_name_modular.yaml

Version Bump: v0.6.0 → v0.7.0

Changes:

1. Added 2 new slot imports (lines 152-153):

   - modules/slots/managing_unit
   - modules/slots/managed_collections
   

2. Updated schema statistics in documentation:

   • Slots: 96 → 98 (+2)
   • Total files: 130 → 132 (+2)

3. Updated component documentation:

   # Collection aspect
   - CustodianCollection with 10 collection-specific slots
     (added managing_unit in v0.7.0)
   
   # Organizational aspect
   - OrganizationalStructure with 7 unit-specific slots
     (staff_members, managed_collections)
   
   # Collection management
   - Bidirectional collection ↔ organizational unit relationships
     (managing_unit, managed_collections)
   

---

Schema Evolution: v0.6.0 → v0.7.0

Component	v0.6.0 (Phase 3)	v0.7.0 (Phase 4)	Change
Classes	22	22	No change
Enums	10	10	No change
Slots	96	98	+2 (managing_unit, managed_collections)
Total Module Files	130	132	+2
RDF Triples	3,744	3,788	+44
ER Diagram Lines	236	238	+2 (new relationships)

Focus of Changes: Collection-organizational unit integration (no new classes, added relationship slots)

---

Design Decisions

1. Bidirectional Relationship Pattern

Decision: Implement BOTH directions explicitly (like staff ↔ organizational unit in Phase 3)

Pattern:

CustodianCollection.managing_unit → OrganizationalStructure (forward)
OrganizationalStructure.managed_collections → CustodianCollection (reverse)

Rationale:

• Enables queries from both perspectives
• "Which unit manages this collection?" vs. "What collections does this unit manage?"
• Mirrors existing staff-unit bidirectional pattern (consistency)
• Reflects W3C ORG ontology bidirectional patterns

W3C ORG Alignment:

• org:unitOf - Entity managed by organizational unit
• org:hasUnit - Organizational unit manages entity (conceptual extension)

Alternative Rejected: Single direction with inverse property inference

• Rejected because: Explicit bidirectional relationships improve query performance and API usability

---

2. One-to-Many Relationship (Unit → Collections)

Decision: One organizational unit manages multiple collections (multivalued)

Cardinality:

• CustodianCollection.managing_unit: Single (one collection = one managing unit)
• OrganizationalStructure.managed_collections: Multiple (one unit = many collections)

Rationale:

• Reflects institutional reality: Departments typically manage multiple sub-collections
• Example: Paintings Department → Dutch Paintings, Flemish Paintings, Italian Paintings
• Example: Digital Preservation Division → Born-Digital Archives, Digitized Maps

Alternative Considered: Many-to-many (collections shared by multiple units)

• Rejected because: Adds complexity; shared collections can be modeled as parent collection with sub-collections assigned to different units

---

3. Temporal Consistency Rules for Collection Custody

Decision: Collection custody dates must align with managing unit's validity period

Rules:

1. Start Date Constraint:

   CustodianCollection.valid_from ≥ OrganizationalStructure.valid_from
   

   • Collection custody cannot start before managing unit exists

2. End Date Constraint:

   CustodianCollection.valid_to ≤ OrganizationalStructure.valid_to (if unit dissolved)
   

   • If unit is dissolved, collection custody must end or transfer

3. Custody Transfer During Organizational Change:

   • When unit is reorganized, collection custody must transfer to new unit
   • Track via:
     • Old collection instance: valid_to = merger_date, managing_unit = old_unit
     • New collection instance: valid_from = merger_date, managing_unit = new_unit
     • Add provenance_note documenting custody transfer reason

Example - Merger Scenario:

# Before merger (ends 2013-02-28):
CustodianCollection:
  id: ".../collection/paintings-001-v1"
  collection_name: Paintings Collection
  managing_unit: ".../unit/paintings-conservation"  # Old unit
  valid_from: "2010-01-01"
  valid_to: "2013-02-28"  # Custody ends with merger
  provenance_note: "Custody transferred to Conservation Division during 2013 merger"

# After merger (starts 2013-03-01):
CustodianCollection:
  id: ".../collection/paintings-001-v2"
  collection_name: Paintings Collection
  managing_unit: ".../unit/conservation-division"  # New merged unit
  valid_from: "2013-03-01"  # Custody starts with new unit
  valid_to: null  # Ongoing
  provenance_note: "Custody assumed from Paintings Conservation Department"

Validation: Implemented in future Phase 5 validation framework

---

4. Integration with PersonObservation (Staff + Collections)

Decision: Enable combined queries across staff and collections

Three-Way Integration Architecture:

PersonObservation (Staff)
  ├── → OrganizationalStructure (unit_affiliation)
  └── ← OrganizationalStructure (staff_members)

OrganizationalStructure (Organizational Unit)
  ├── → PersonObservation (staff_members)
  ├── ← PersonObservation (unit_affiliation)
  ├── → CustodianCollection (managed_collections) ← Phase 4
  └── ← CustodianCollection (managing_unit) ← Phase 4

CustodianCollection (Heritage Collection)
  ├── → OrganizationalStructure (managing_unit) ← Phase 4
  └── ← OrganizationalStructure (managed_collections) ← Phase 4

Use Case: "Which curator manages the Medieval Manuscripts collection?"

Query Path:

CustodianCollection (medieval-manuscripts)
  → managing_unit
    → OrganizationalStructure (special-collections-division)
      → staff_members
        → PersonObservation (WHERE staff_role = CURATOR)
          → person_name: "Dr. Anne van der Berg"

SPARQL Example:

PREFIX custodian: <https://w3id.org/heritage/custodian/>
PREFIX org: <http://www.w3.org/ns/org#>
PREFIX pico: <https://w3id.org/pico/ontology/>

SELECT ?curator_name ?collection_name
WHERE {
  # Start with collection
  ?collection a custodian:CustodianCollection ;
              custodian:collection_name "Medieval Manuscripts Collection" ;
              custodian:managing_unit ?unit .
  
  # Find managing unit
  ?unit a custodian:OrganizationalStructure ;
        org:hasMember ?person_obs .
  
  # Find curator in that unit
  ?person_obs a pico:PersonObservation ;
              custodian:staff_role custodian:CURATOR ;
              pico:person_name ?curator_name .
}

Rationale:

• Enables "show me curators AND collections" department inventory queries
• Tracks staff-collection relationships through organizational changes
• Foundation for collection management workflows (assign curator → collection)

---

Test Instances (15 Examples)

File: schemas/20251121/examples/collection_department_integration_examples.yaml
Size: 287 lines
Instances: 4 organizational units + 11 collections

Example Set 1: Museum Paintings Department (One-to-Many)

Organizational Unit:

OrganizationalStructure:
  id: https://w3id.org/heritage/custodian/nl/rmv/unit/paintings-dept
  unit_name: Paintings Department
  unit_type: DEPARTMENT
  valid_from: "1885-01-01"
  managed_collections:  # One department → Three collections
    - ".../dutch-paintings"
    - ".../flemish-paintings"
    - ".../italian-paintings"

Managed Collections:

1. Dutch Paintings Collection (1500-1700)

   • Rembrandt, Vermeer, Frans Hals
   • ~450 objects

2. Flemish Paintings Collection (1400-1700)

   • Rubens, Van Dyck, Bruegel
   • ~320 objects

3. Italian Renaissance Paintings (1400-1600)

   • Leonardo, Botticelli, Titian
   • ~180 objects

Pattern Demonstrated: One-to-many (one department manages multiple collections)

---

Example Set 2: Archive Digital Preservation Division

Organizational Unit:

OrganizationalStructure:
  id: https://w3id.org/heritage/custodian/nl/na/unit/digital-preservation
  unit_name: Digital Preservation Division
  unit_type: DIVISION
  valid_from: "2008-07-01"
  managed_collections:
    - ".../born-digital-archives"
    - ".../digitized-maps"

Managed Collections:

1. Born-Digital Government Archives (2000-2024)

   • Email archives, digital documents
   • ~2.5 TB

2. Digitized Historical Maps Collection (1500-1900)

   • Scanned from physical originals
   • ~8,500 items

Pattern Demonstrated: Specialized digital preservation management

---

Example Set 3: Collection Custody Transfer During Merger

Scenario: 2013 merger consolidates two conservation units

Before Merger (ends 2013-02-28):

Old Unit 1: Paintings Conservation Department

OrganizationalStructure:
  id: ".../paintings-conservation"
  unit_name: Paintings Conservation Department
  valid_from: "1995-01-01"
  valid_to: "2013-02-28"  # Dissolved in merger
  managed_collections:
    - ".../paintings-001-v1"  # Custody ends with merger

Old Unit 2: Sculptures Conservation Department

OrganizationalStructure:
  id: ".../sculptures-conservation"
  unit_name: Sculptures Conservation Department
  valid_from: "1998-06-01"
  valid_to: "2013-02-28"  # Dissolved in merger
  managed_collections:
    - ".../sculptures-001-v1"  # Custody ends with merger

After Merger (starts 2013-03-01):

New Merged Unit: Conservation Division

OrganizationalStructure:
  id: ".../conservation-division"
  unit_name: Conservation Division
  valid_from: "2013-03-01"  # Created from merger
  managed_collections:  # Consolidated custody from both old units
    - ".../paintings-001-v2"
    - ".../sculptures-001-v2"

Collection Custody Transfer (Paintings Collection):

# Version 1: Before merger
CustodianCollection:
  id: ".../paintings-001-v1"
  collection_name: Paintings Conservation Collection
  managing_unit: ".../paintings-conservation"  # Old unit
  valid_from: "1995-01-01"
  valid_to: "2013-02-28"  # Custody ends
  provenance_note: "Custody transferred to Conservation Division during 2013 merger"

# Version 2: After merger
CustodianCollection:
  id: ".../paintings-001-v2"
  collection_name: Paintings Conservation Collection
  managing_unit: ".../conservation-division"  # New merged unit
  valid_from: "2013-03-01"  # Custody starts
  provenance_note: "Custody assumed from Paintings Conservation Department"

Pattern Demonstrated:

• Temporal consistency (custody dates align with unit validity)
• Collection custody transfer during organizational restructuring
• Provenance tracking with notes

---

Example Set 4: Library Special Collections Division

Organizational Unit:

OrganizationalStructure:
  id: https://w3id.org/heritage/custodian/nl/kb/unit/special-collections
  unit_name: Special Collections Division
  unit_type: DIVISION
  valid_from: "1982-04-01"
  managed_collections:
    - ".../medieval-manuscripts"
    - ".../incunabula"

Managed Collections:

1. Medieval Manuscripts Collection (800-1500)

   • Illuminated manuscripts, prayer books
   • ~1,200 items

2. Incunabula Collection (1450-1500)

   • Early printed books
   • ~850 items

Pattern Demonstrated: Rare materials specialized management

---

Use Cases Enabled

1. Collection Management

Query: "Which department manages the Dutch Paintings collection?"

SPARQL:

PREFIX custodian: <https://w3id.org/heritage/custodian/>
PREFIX org: <http://www.w3.org/ns/org#>

SELECT ?unit_name
WHERE {
  ?collection a custodian:CustodianCollection ;
              custodian:collection_name "Dutch Paintings Collection" ;
              custodian:managing_unit ?unit .
  
  ?unit custodian:unit_name ?unit_name .
}
# Result: "Paintings Department"

---

2. Department Inventory (Staff + Collections)

Query: "What collections does the Paintings Department manage, and who are the curators?"

SPARQL:

PREFIX custodian: <https://w3id.org/heritage/custodian/>
PREFIX org: <http://www.w3.org/ns/org#>
PREFIX pico: <https://w3id.org/pico/ontology/>

SELECT ?collection_name ?curator_name
WHERE {
  # Find the department
  ?unit a custodian:OrganizationalStructure ;
        custodian:unit_name "Paintings Department" .
  
  # Find managed collections
  ?unit custodian:managed_collections ?collection .
  ?collection custodian:collection_name ?collection_name .
  
  # Find curators in the department
  ?unit org:hasMember ?person_obs .
  ?person_obs a pico:PersonObservation ;
              custodian:staff_role custodian:CURATOR ;
              pico:person_name ?curator_name .
}
# Result:
# - Dutch Paintings Collection | Dr. Jan Vermeer
# - Flemish Paintings Collection | Dr. Jan Vermeer
# - Italian Renaissance Paintings | Dr. Jan Vermeer

---

3. Organizational Change Impact Analysis

Query: "Which collections were affected by the 2013 conservation departments merger?"

SPARQL:

PREFIX custodian: <https://w3id.org/heritage/custodian/>
PREFIX schema: <http://schema.org/>

SELECT ?collection_name ?old_unit ?new_unit
WHERE {
  # Find collections with custody ending around merger date
  ?old_collection a custodian:CustodianCollection ;
                  custodian:collection_name ?collection_name ;
                  custodian:managing_unit ?old_unit ;
                  schema:endDate "2013-02-28"^^xsd:date .
  
  # Find corresponding new collection version
  ?new_collection a custodian:CustodianCollection ;
                  custodian:collection_name ?collection_name ;
                  custodian:managing_unit ?new_unit ;
                  schema:startDate "2013-03-01"^^xsd:date .
}
# Result:
# - Paintings Conservation Collection | Paintings Conservation Dept | Conservation Division
# - Sculptures Conservation Collection | Sculptures Conservation Dept | Conservation Division

---

4. Curator-Collection Cross-Reference

Query: "Which curator manages the Medieval Manuscripts collection?"

SPARQL:

PREFIX custodian: <https://w3id.org/heritage/custodian/>
PREFIX org: <http://www.w3.org/ns/org#>
PREFIX pico: <https://w3id.org/pico/ontology/>

SELECT ?curator_name
WHERE {
  # Start with collection
  ?collection a custodian:CustodianCollection ;
              custodian:collection_name "Medieval Manuscripts Collection" ;
              custodian:managing_unit ?unit .
  
  # Find managing unit's staff
  ?unit org:hasMember ?person_obs .
  
  # Filter for curators
  ?person_obs a pico:PersonObservation ;
              custodian:staff_role custodian:CURATOR ;
              pico:person_name ?curator_name .
}
# Result: "Dr. Anne van der Berg"

---

Generated Artifacts

1. RDF/OWL (Turtle Format)

File: schemas/20251121/rdf/01_custodian_name_modular_20251122_205111.owl.ttl
Size: 3,788 lines (+44 from v0.6.0)
Format: Turtle (RDF 1.1)

New Triples Added (managing_unit and managed_collections):

###  https://w3id.org/heritage/custodian/managing_unit
custodian:managing_unit rdf:type owl:ObjectProperty ;
                        owl:inverseOf custodian:managed_collections ;
                        rdfs:domain custodian:CustodianCollection ;
                        rdfs:range custodian:OrganizationalStructure ;
                        rdfs:label "managing unit" ;
                        rdfs:comment "The organizational unit responsible for managing this collection." ;
                        rdfs:subPropertyOf org:unitOf .

###  https://w3id.org/heritage/custodian/managed_collections
custodian:managed_collections rdf:type owl:ObjectProperty ;
                              owl:inverseOf custodian:managing_unit ;
                              rdfs:domain custodian:OrganizationalStructure ;
                              rdfs:range custodian:CustodianCollection ;
                              rdfs:label "managed collections" ;
                              rdfs:comment "Collections managed by this organizational unit." ;
                              rdfs:subPropertyOf org:hasUnit .

Key Features:

• ✅ Explicit inverse properties (owl:inverseOf)
• ✅ Domain/range constraints (enforce class relationships)
• ✅ W3C ORG subproperties (org:unitOf, org:hasUnit)
• ✅ RDFS labels and comments (human-readable)

---

2. ER Diagram (Mermaid)

File: schemas/20251121/uml/mermaid/01_custodian_name_modular_20251122_205118_er.mmd
Size: 238 lines (+2 from v0.6.0)
Format: Mermaid Entity-Relationship Diagram

New Relationships Added:

erDiagram
    CustodianCollection ||--o| OrganizationalStructure : "managing_unit"
    OrganizationalStructure ||--o{ CustodianCollection : "managed_collections"

Cardinality Notation:

• ||--o| : One collection → Zero or one managing unit (required in practice)
• ||--o{ : One unit → Zero or many collections (one-to-many)

Full Context (with Phase 3 relationships):

erDiagram
    PersonObservation }o--|| OrganizationalStructure : "unit_affiliation"
    OrganizationalStructure ||--o{ PersonObservation : "staff_members"
    CustodianCollection ||--o| OrganizationalStructure : "managing_unit"
    OrganizationalStructure ||--o{ CustodianCollection : "managed_collections"

---

Integration Points

1. With PersonObservation (Phase 3: Staff Roles)

Three-Way Integration:

PersonObservation
  ├── → unit_affiliation → OrganizationalStructure (Phase 3)
  └── ← staff_members ← OrganizationalStructure (Phase 3)

OrganizationalStructure
  ├── → staff_members → PersonObservation (Phase 3)
  ├── ← unit_affiliation ← PersonObservation (Phase 3)
  ├── → managed_collections → CustodianCollection (Phase 4)
  └── ← managing_unit ← CustodianCollection (Phase 4)

CustodianCollection
  ├── → managing_unit → OrganizationalStructure (Phase 4)
  └── ← managed_collections ← OrganizationalStructure (Phase 4)

Query Capability: Combined staff + collections queries

Example: "Show me curators and collections in Paintings Department"

SELECT ?curator_name ?collection_name
WHERE {
  ?unit custodian:unit_name "Paintings Department" ;
        org:hasMember ?person_obs ;
        custodian:managed_collections ?collection .
  
  ?person_obs custodian:staff_role custodian:CURATOR ;
              pico:person_name ?curator_name .
  
  ?collection custodian:collection_name ?collection_name .
}

---

2. With OrganizationalChangeEvent (Phase 2: Organizational Changes)

Custody Transfer Tracking:

When organizational units merge/split/dissolve, collection custody must transfer:

OrganizationalChangeEvent:
  event_id: ".../event/conservation-merger-2013"
  event_type: MERGER
  event_date: "2013-03-01"
  affected_entities:
    - ".../unit/paintings-conservation"  # Dissolved
    - ".../unit/sculptures-conservation"  # Dissolved
  resulting_entities:
    - ".../unit/conservation-division"  # Created

# Collections update managing_unit:
CustodianCollection:
  id: ".../paintings-001-v2"
  managing_unit: ".../unit/conservation-division"  # New unit
  valid_from: "2013-03-01"  # Aligns with merger date
  provenance_note: "Custody transferred during 2013 Conservation Departments merger"

Validation Rule:

IF OrganizationalChangeEvent.event_type IN [MERGER, DISSOLUTION, RESTRUCTURING]
AND OrganizationalChangeEvent.affected_entities CONTAINS unit_id
THEN:
  - CustodianCollection WHERE managing_unit = unit_id
    MUST have valid_to ≤ OrganizationalChangeEvent.event_date
  - OR managing_unit MUST update to new unit with valid_from = event_date

---

3. With CustodianObservation (Phase 1: Institution Core)

Institution-Level Collection Aggregation:

Collections belong to heritage institutions (via managing units):

CustodianObservation (Institution: Rijksmuseum)
  → has_aspect
    → OrganizationalStructure (Paintings Department)
      → managed_collections
        → CustodianCollection (Dutch Paintings)

Query: "How many collections does Rijksmuseum have?"

SELECT (COUNT(DISTINCT ?collection) AS ?total_collections)
WHERE {
  ?institution a custodian:CustodianObservation ;
               custodian:custodian_name_emic "Rijksmuseum" ;
               custodian:has_aspect ?unit .
  
  ?unit a custodian:OrganizationalStructure ;
        custodian:managed_collections ?collection .
}

---

Temporal Consistency Requirements

Rule 1: Collection Custody ⊆ Unit Validity

Constraint:

CustodianCollection.valid_from ≥ OrganizationalStructure.valid_from
CustodianCollection.valid_to ≤ OrganizationalStructure.valid_to (if unit dissolved)

Rationale: Collection cannot be managed by unit that doesn't exist

Example:

OrganizationalStructure:
  valid_from: "1985-01-01"
  valid_to: "2013-02-28"  # Unit dissolved

CustodianCollection:
  managing_unit: [reference to above unit]
  valid_from: "1995-01-01"  # ✅ VALID (after unit founding)
  valid_to: "2013-02-28"     # ✅ VALID (on unit dissolution date)

Invalid Example:

CustodianCollection:
  managing_unit: [reference to unit]
  valid_from: "1980-01-01"  # ❌ INVALID (before unit exists)
  valid_to: "2015-12-31"     # ❌ INVALID (after unit dissolved)

---

Rule 2: Custody Transfer Must Be Continuous

Constraint:

IF CustodianCollection version 1 ends (valid_to = T1)
THEN CustodianCollection version 2 must start (valid_from = T1 OR T1+1 day)

Rationale: Collections don't disappear; custody must transfer during org changes

Example:

# Version 1: Before merger
CustodianCollection:
  id: ".../collection-v1"
  valid_to: "2013-02-28"  # Custody ends

# Version 2: After merger
CustodianCollection:
  id: ".../collection-v2"
  valid_from: "2013-03-01"  # ✅ VALID (continuous custody, T1+1 day)

---

Rule 3: Provenance Notes for Custody Transfers

Requirement:

IF CustodianCollection.managing_unit changes
THEN provenance_note MUST document reason

Example:

CustodianCollection:
  managing_unit: ".../new-unit"
  provenance_note: "Custody transferred from Paintings Conservation Department during 2013 merger"

---

Files Created/Modified

New Files (2 slot definitions)

1. schemas/20251121/linkml/modules/slots/managing_unit.yaml

   • 36 lines
   • Slot definition: CustodianCollection → OrganizationalStructure
   • W3C ORG alignment: org:unitOf

2. schemas/20251121/linkml/modules/slots/managed_collections.yaml

   • 37 lines
   • Slot definition: OrganizationalStructure → CustodianCollection
   • W3C ORG alignment: org:hasUnit

---

Modified Files (3)

3. schemas/20251121/linkml/modules/classes/CustodianCollection.yaml

   • Added managing_unit slot
   • Added ~80 lines of slot_usage documentation
   • Added OrganizationalStructure to imports

4. schemas/20251121/linkml/modules/classes/OrganizationalStructure.yaml

   • Added managed_collections slot
   • Added ~120 lines of slot_usage documentation
   • Integrated with PersonObservation examples

5. schemas/20251121/linkml/01_custodian_name_modular.yaml

   • Version bump: v0.6.0 → v0.7.0
   • Added 2 slot imports
   • Updated schema statistics (slots: 96 → 98)
   • Updated component documentation

---

Generated Files (3)

6. schemas/20251121/rdf/01_custodian_name_modular_20251122_205111.owl.ttl

   • 3,788 lines (+44 triples)
   • RDF/OWL serialization
   • Full timestamp in filename

7. schemas/20251121/uml/mermaid/01_custodian_name_modular_20251122_205118_er.mmd

   • 238 lines (+2 relationships)
   • Entity-relationship diagram
   • Full timestamp in filename

8. schemas/20251121/examples/collection_department_integration_examples.yaml

   • 287 lines
   • 15 instances (4 units + 11 collections)
   • 4 example sets demonstrating patterns

---

Documentation Files (2)

9. COLLECTION_DEPARTMENT_INTEGRATION_COMPLETE_20251122.md (this file)

   • Phase 4 completion documentation
   • 800+ lines

10. SESSION_SUMMARY_COLLECTION_DEPT_PHASE4_20251122.md (to be created next)

    • Session timeline and handoff

---

Validation Strategy (Phase 5 Preview)

Automated Validation Script (Upcoming)

Script: scripts/validate_temporal_consistency.py

Checks to Implement:

1. Collection-Unit Temporal Consistency

def validate_collection_unit_temporal_consistency(collection, unit):
    """Validate collection custody dates fit within unit validity period."""
    if collection.valid_from < unit.valid_from:
        raise ValidationError(
            f"Collection {collection.id} custody starts before managing unit exists"
        )
    
    if unit.valid_to and collection.valid_to:
        if collection.valid_to > unit.valid_to:
            raise ValidationError(
                f"Collection {collection.id} custody extends beyond unit validity"
            )

2. Bidirectional Relationship Consistency

def validate_bidirectional_relationships(dataset):
    """Validate managing_unit ↔ managed_collections consistency."""
    for collection in dataset.collections:
        unit_id = collection.managing_unit
        
        # Check reverse relationship exists
        unit = dataset.find_unit(unit_id)
        if collection.id not in unit.managed_collections:
            raise ValidationError(
                f"Collection {collection.id} references unit {unit_id}, "
                f"but unit does not list collection in managed_collections"
            )

3. Custody Transfer Continuity

def validate_custody_continuity(collection_versions):
    """Validate continuous custody during organizational changes."""
    versions = sorted(collection_versions, key=lambda c: c.valid_from)
    
    for i in range(len(versions) - 1):
        current = versions[i]
        next_version = versions[i + 1]
        
        # Check gap between versions
        if current.valid_to:
            gap_days = (next_version.valid_from - current.valid_to).days
            if gap_days > 1:
                raise ValidationError(
                    f"Custody gap detected: {gap_days} days between "
                    f"{current.id} and {next_version.id}"
                )

---

SPARQL Query Examples

Query 1: Collection's Managing Unit

Question: "Which department manages the Dutch Paintings collection?"

PREFIX custodian: <https://w3id.org/heritage/custodian/>
PREFIX org: <http://www.w3.org/ns/org#>

SELECT ?unit_name
WHERE {
  ?collection a custodian:CustodianCollection ;
              custodian:collection_name "Dutch Paintings Collection" ;
              custodian:managing_unit ?unit .
  
  ?unit a custodian:OrganizationalStructure ;
        custodian:unit_name ?unit_name .
}

Expected Result:

unit_name
-----------------
Paintings Department

---

Query 2: Unit's Managed Collections

Question: "What collections does the Special Collections Division manage?"

PREFIX custodian: <https://w3id.org/heritage/custodian/>

SELECT ?collection_name ?temporal_coverage ?extent
WHERE {
  ?unit a custodian:OrganizationalStructure ;
        custodian:unit_name "Special Collections Division" ;
        custodian:managed_collections ?collection .
  
  ?collection custodian:collection_name ?collection_name ;
              custodian:temporal_coverage ?temporal_coverage ;
              custodian:extent ?extent .
}
ORDER BY ?collection_name

Expected Result:

collection_name                | temporal_coverage | extent
-------------------------------|-------------------|--------
Incunabula Collection          | 1450-01-01/1500-12-31 | ~850 items
Medieval Manuscripts Collection| 0800-01-01/1500-12-31 | ~1,200 items

---

Query 3: Combined Staff + Collections

Question: "Show me curators and collections in Paintings Department"

PREFIX custodian: <https://w3id.org/heritage/custodian/>
PREFIX org: <http://www.w3.org/ns/org#>
PREFIX pico: <https://w3id.org/pico/ontology/>

SELECT ?curator_name ?collection_name
WHERE {
  # Find the department
  ?unit a custodian:OrganizationalStructure ;
        custodian:unit_name "Paintings Department" .
  
  # Find curators in the department
  ?unit org:hasMember ?person_obs .
  ?person_obs a pico:PersonObservation ;
              custodian:staff_role custodian:CURATOR ;
              pico:person_name ?curator_name .
  
  # Find managed collections
  ?unit custodian:managed_collections ?collection .
  ?collection custodian:collection_name ?collection_name .
}
ORDER BY ?curator_name ?collection_name

Expected Result:

curator_name       | collection_name
-------------------|-----------------------------------
Dr. Jan Vermeer    | Dutch Paintings Collection
Dr. Jan Vermeer    | Flemish Paintings Collection
Dr. Jan Vermeer    | Italian Renaissance Paintings Collection

---

Query 4: Organizational Change Impact (Custody Transfers)

Question: "Which collections transferred custody during the 2013 Conservation merger?"

PREFIX custodian: <https://w3id.org/heritage/custodian/>
PREFIX schema: <http://schema.org/>

SELECT ?collection_name ?old_unit_name ?new_unit_name ?transfer_date
WHERE {
  # Find collections ending custody on merger date
  ?old_collection a custodian:CustodianCollection ;
                  custodian:collection_name ?collection_name ;
                  custodian:managing_unit ?old_unit ;
                  schema:endDate ?transfer_date .
  
  ?old_unit custodian:unit_name ?old_unit_name .
  
  # Find corresponding new collection version
  ?new_collection a custodian:CustodianCollection ;
                  custodian:collection_name ?collection_name ;
                  custodian:managing_unit ?new_unit ;
                  schema:startDate ?transfer_date .
  
  ?new_unit custodian:unit_name ?new_unit_name .
  
  # Filter for 2013 merger
  FILTER(?transfer_date >= "2013-02-28"^^xsd:date && 
         ?transfer_date <= "2013-03-01"^^xsd:date)
}
ORDER BY ?transfer_date ?collection_name

Expected Result:

collection_name                    | old_unit_name                   | new_unit_name         | transfer_date
-----------------------------------|----------------------------------|-----------------------|--------------
Paintings Conservation Collection  | Paintings Conservation Department| Conservation Division | 2013-03-01
Sculptures Conservation Collection | Sculptures Conservation Department| Conservation Division | 2013-03-01

---

Next Steps

Phase 5: Validation Framework (Upcoming)

Goal: Automated validation of temporal consistency and bidirectional relationships

Estimated Time: 60-90 minutes

Deliverables:

1. Script: scripts/validate_temporal_consistency.py

   • Collection-unit temporal validation
   • Bidirectional relationship validation
   • Custody transfer continuity checks
   • Staff-unit temporal validation (from Phase 3)

2. Test Suite: tests/test_temporal_validation.py

   • Valid cases (should pass)
   • Invalid cases (should fail with specific errors)
   • Merger scenarios
   • Edge cases

3. Documentation: docs/VALIDATION_RULES.md

   • Complete validation rule reference
   • SHACL shapes (RDF validation)
   • LinkML schema constraints

---

Phase 6: SPARQL Query Library (Upcoming)

Goal: Document common query patterns for organizational data

Estimated Time: 45-60 minutes

Deliverable: docs/SPARQL_QUERIES_ORGANIZATIONAL.md

Query Categories:

1. Staff Queries (Phase 3):

   • Find staff by role
   • List unit members
   • Track role changes over time

2. Collection Queries (Phase 4):

   • Find managing unit for collection
   • List collections by department
   • Track collection custody history

3. Combined Staff + Collections (Phase 4):

   • Find curator managing specific collection
   • List collections and curators by department
   • Department inventory (staff + collections)

4. Organizational Change Queries:

   • Track custody transfers during mergers
   • Find affected staff during restructuring
   • Timeline of organizational changes + impacts

---

Phase 7: Real-World Data Integration (Future)

Goal: Apply schema to real heritage institution data

Data Sources:

• Dutch ISIL registry (organizational units)
• Museum collection databases
• Archive finding aids
• Wikidata organizational structure

Tasks:

1. Extract organizational units from institutional websites
2. Map collections to managing departments
3. Extract staff roles from personnel records
4. Validate temporal consistency
5. Generate RDF dataset

---

Summary of Achievements

Phase 4 (This Phase): Collection-Department Integration

✅ Created 2 new slots (managing_unit, managed_collections)
✅ Updated 2 classes (CustodianCollection, OrganizationalStructure)
✅ Bumped schema version (v0.6.0 → v0.7.0)
✅ Generated RDF/OWL (3,788 lines, +44 triples)
✅ Generated ER diagram (238 lines, +2 relationships)
✅ Created 15 test instances (287 lines, 4 example sets)
✅ Documented 4 use cases with SPARQL queries
✅ Integrated with Phase 3 (staff-organizational unit relationships)

---

Cumulative Progress (Phases 1-4)

Phase	Focus	Classes Added	Slots Added	Version
Phase 1	Core heritage custodian ontology	15	70	v0.4.0
Phase 2	Organizational change events	2	15	v0.5.0
Phase 3	Staff role tracking	1	11	v0.6.0
Phase 4	Collection-department integration	0	2	v0.7.0
Total	Multi-aspect heritage custodian	22	98	v0.7.0

---

Three-Way Integration Complete

Architecture:

PersonObservation (Staff)
     ↕ (bidirectional)
OrganizationalStructure (Departments/Divisions)
     ↕ (bidirectional)
CustodianCollection (Heritage Collections)

Query Capabilities:

• ✅ "Who works in Department X?"
• ✅ "What collections does Department X manage?"
• ✅ "Which curator manages Collection Y?"
• ✅ "Show me staff AND collections for Department X"
• ✅ "Track custody transfers during merger"
• ✅ "Track staff reassignments during reorganization"

---

References

Schema Files (v0.7.0)

• Main schema: schemas/20251121/linkml/01_custodian_name_modular.yaml
• CustodianCollection class: schemas/20251121/linkml/modules/classes/CustodianCollection.yaml
• OrganizationalStructure class: schemas/20251121/linkml/modules/classes/OrganizationalStructure.yaml
• managing_unit slot: schemas/20251121/linkml/modules/slots/managing_unit.yaml
• managed_collections slot: schemas/20251121/linkml/modules/slots/managed_collections.yaml

Generated Artifacts

• RDF/OWL: schemas/20251121/rdf/01_custodian_name_modular_20251122_205111.owl.ttl
• ER Diagram: schemas/20251121/uml/mermaid/01_custodian_name_modular_20251122_205118_er.mmd
• Test instances: schemas/20251121/examples/collection_department_integration_examples.yaml

Documentation

• Phase 3 completion: PICO_STAFF_ROLES_COMPLETE_20251122.md
• Phase 2 completion: ORGANIZATIONAL_CHANGE_EVENT_COMPLETE_20251122.md
• Phase 4 completion: This document

Base Ontologies

• W3C ORG: /data/ontology/core-public-organisation-ap.ttl
• CIDOC-CRM: /data/ontology/CIDOC_CRM_v7.1.3.rdf
• PiCo: /data/ontology/pico.ttl

---

Phase 4 Status: ✅ COMPLETE
Schema Version: v0.7.0
Date: 2025-11-22
Next Phase: Phase 5 (Validation Framework)

---

End of Phase 4 Documentation