glam/frontend/public/schemas/20251121/linkml/modules/classes/PersonObservation.yaml

id: https://nde.nl/ontology/hc/class/PersonObservation
name: PersonObservation
title: Person Observation (Staff Role Context)
prefixes:
  linkml: https://w3id.org/linkml/
  hc: https://nde.nl/ontology/hc/
  schema: http://schema.org/
  pico: https://personsincontext.org/model#
  pnv: https://w3id.org/pnv#
  crm: http://www.cidoc-crm.org/cidoc-crm/
  foaf: http://xmlns.com/foaf/0.1/
  prov: http://www.w3.org/ns/prov#
  dcterms: http://purl.org/dc/terms/
  sdo: https://schema.org/
imports:
- linkml:types
- ../slots/id
- ../slots/person_name
- ../slots/has_person_name
- ../slots/birth_date
- ../slots/birth_place
- ../slots/death_place
- ../slots/date_of_death
- ../slots/deceased
- ../slots/age
- ../slots/occupation
- ../slots/religion
- ../slots/gender_identity
- ../slots/pronouns
- ../slots/staff_role
- ../slots/role_title
- ../slots/unit_affiliation
- ../slots/role_start_date
- ../slots/role_end_date
- ../slots/observation_source
- ../slots/affected_by_event
- ../slots/contact_email
- ../slots/expertise_areas
- ../slots/refers_to_person
- ../slots/web_claims
- ../slots/linkedin_profile_path
- ../slots/linkedin_profile_url
- ../slots/extraction_metadata
- ../slots/created
- ../slots/modified
- ./PersonWebClaim
- ./PersonName
- ./ExtractionMetadata
- ./Person
- ../slots/class_metadata_slots
classes:
  PersonObservation:
    class_uri: pico:PersonObservation
    description: |
      An observation of a person serving in a staff role at a heritage custodian institution,
      as documented in a specific source at a specific point in time.

      **PiCo Pattern Adaptation**:
      The PiCo (Persons in Context) ontology distinguishes between:
      - **PersonObservation**: Data about a person as found in a source (evidence-based)
      - **PersonReconstruction**: Aggregated identity from multiple observations (inferred)

      For heritage custodian staff tracking, we adapt this pattern:
      - **PersonObservation**: Staff role as documented in institutional sources
        (annual reports, org charts, staff directories, archival records)
      - Focus on ROLES and AFFILIATIONS rather than biographical details
      - Temporal validity tracks employment period in specific position

      **Key Distinction from General Person Data**:
      This class models INSTITUTIONAL ROLES, not complete biographical data:
      - Emphasis: Role, title, unit affiliation, employment dates
      - NOT: Full biographical reconstruction (birth, death, family, etc.)
      - Sources: Institutional records (not vital records, census, etc.)

      
      **Hub Architecture Integration**:
      - PersonObservation refers to Person hub via `refers_to_person` (PICO pattern)
      - PersonObservation refers to OrganizationalStructure via `unit_affiliation`
      - OrganizationalStructure refers back via `staff_members` (bidirectional)
      - PersonObservation affected by OrganizationalChangeEvent via `affected_by_event`
      - Person hub links to Event via `participated_in_events`
      - Temporal alignment: employment dates vs. organizational unit validity

      **Use Cases**:
      1. **Staff directories**: Document current and historical staff roles
      2. **Organizational provenance**: Track who managed departments/collections
      3. **Workforce history**: Analyze staffing patterns over time
      4. **Expertise tracking**: Find conservators, curators by specialization
      5. **Reorganization impact**: Track staff transitions during structural changes

      **Example - Conservation Staff**:

      ```yaml
      PersonObservation:
        person_name: "Dr. Jane Smith"
        staff_role: CONSERVATOR
        role_title: "Senior Paintings Conservator"
        unit_affiliation: ".../org-unit/rm-conservation-division"
        role_start_date: "2013-03-01"
        role_end_date: null  # Still employed
        observation_source:
          source_type: "Staff directory"
          source_uri: "https://rijksmuseum.nl/staff/jane-smith"
          observation_date: "2024-11-22"
      ```

      **Example - Staff Through Organizational Change**:

      ```yaml
      # Before merger (2013-02-28)
      PersonObservation:
        person_name: "Dr. Jane Smith"
        staff_role: CONSERVATOR
        role_title: "Head, Paintings Conservation Department"
        unit_affiliation: ".../org-unit/rm-paintings-conservation"
        role_start_date: "2010-01-01"
        role_end_date: "2013-02-28"

      # After merger (2013-03-01)
      PersonObservation:
        person_name: "Dr. Jane Smith"
        staff_role: CONSERVATOR
        role_title: "Deputy Director, Conservation Division"
        unit_affiliation: ".../org-unit/rm-conservation-division"
        role_start_date: "2013-03-01"
        role_end_date: null
        affected_by_event: ".../event/rm-conservation-merger-2013"
      ```      
    exact_mappings:
    - pico:PersonObservation
    close_mappings:
    - schema:Person
    - schema:Role
    - crm:E21_Person
    - foaf:Person
    - prov:Agent
    slots:
    - affected_by_event
    - age
    - birth_date
    - birth_place
    - contact_email
    - created
    - date_of_death
    - death_place
    - deceased
    - expertise_areas
    - extraction_metadata
    - gender_identity
    - has_person_name
    - id
    - linkedin_profile_path
    - linkedin_profile_url
    - modified
    - observation_source
    - occupation
    - person_name
    - pronouns
    - refers_to_person
    - religion
    - role_end_date
    - role_start_date
    - role_title
    - specificity_annotation
    - staff_role
    - template_specificity
    - unit_affiliation
    - web_claims
    slot_usage:
      id:
        slot_uri: dcterms:identifier
        description: |
          Unique identifier for this staff role observation.
          Format: https://nde.nl/ontology/hc/person-obs/{custodian-id}/{person-slug}/{role-slug}
          Example: https://nde.nl/ontology/hc/person-obs/nl-nh-ams-m-rm/jane-smith/conservator-2013          
        range: uriorcurie
        required: true
        identifier: true
        pattern: ^https://nde\.nl/ontology/hc/person-obs/[a-z0-9-]+/[a-z0-9-]+/[a-z0-9-]+$
      person_name:
        slot_uri: schema:name
        description: "Full name of the person as recorded in institutional sources.\n\
          \n**Schema.org**: `schema:name` for person's name\n\n**Format**: Use natural\
          \ name order (Western: \"Given Family\", non-Western: as appropriate)\n\n\
          **Normalization**: \n- Include titles/honorifics if institutionally used\
          \ (\"Dr.\", \"Prof.\")\n- Preserve name as it appears in organizational\
          \ context\n- Use PNV (Person Name Vocabulary) for detailed name parsing\
          \ (future extension)\n\n**Examples**:\n- \"Dr. Jane Smith\"\n- \"Prof. dr.\
          \ Willem van der Berg\"\n- \"Maria García Rodríguez\"\n"
        range: string
        required: true
      has_person_name:
        slot_uri: pnv:hasName
        description: "Structured name following Person Name Vocabulary (PNV).\n\n\
          **Use alongside person_name** for both quick access (string) and \nstructured\
          \ parsing (PNV components).\n\n**Essential for Dutch names** with tussenvoegsels\
          \ (van, de, van der, etc.)\nto enable proper alphabetical sorting by base_surname.\n\
          \n**See**: modules/classes/PersonName.yaml for full PNV structure\n**See**:\
          \ modules/slots/has_person_name.yaml for detailed documentation\n"
        range: PersonName
        required: false
        inlined: true
      refers_to_person:
        slot_uri: pico:observationOf
        description: "Links this PersonObservation to the central Person hub it describes.\n\
          \n**HUB-OBSERVATION PATTERN (PICO)**:\n\nThe PiCo (Persons in Context) ontology\
          \ establishes a fundamental distinction:\n- **Person** (hub): Abstract identity,\
          \ minimal data, stable over time\n- **PersonObservation** (this class):\
          \ Evidence-based data from specific sources\n\nMultiple observations from\
          \ different sources, time periods, or institutions\ncan all refer to the\
          \ same Person hub, building up a complete picture.\n\n```\nPersonObservation\
          \ (LinkedIn 2024) ──refers_to_person──┐\n                              \
          \                         │\nPersonObservation (Annual Report 2020) ──refers_to──>\
          \ Person (hub)\n                                                       │\n\
          PersonObservation (Staff Directory 1995) ─────────────┘\n```\n\n**WHY THIS\
          \ MATTERS**:\n\n1. **Cross-Institution Career Tracking**:\n   Same person\
          \ worked at Rijksmuseum (obs 1), Van Gogh Museum (obs 2).\n   Both observations\
          \ link to ONE Person hub.\n   \n2. **Source Reconciliation**:\n   LinkedIn\
          \ says \"Director\", annual report says \"General Director\".\n   Both are\
          \ valid observations of the same Person - no need to choose.\n   \n3. **Temporal\
          \ Evolution**:\n   Person's title changed over time. Each observation captures\
          \ a snapshot.\n   Hub provides stable identity anchor.\n\n**USAGE**:\n\n\
          ```yaml\nPersonObservation:\n  person_name: \"Taco Dibbits\"\n  role_title:\
          \ \"General Director\"\n  unit_affiliation: \".../org-unit/rm-executive\"\
          \n  refers_to_person: \"https://nde.nl/ontology/hc/person/taco-dibbits\"\
          \n  observation_source:\n    source_type: \"Staff directory\"\n    observation_date:\
          \ \"2025-01-15\"\n```\n\n**RELATIONSHIP TO OTHER PATTERNS**:\n\n| From |\
          \ Slot | To | Purpose |\n|------|------|----|---------|\n| CustodianObservation\
          \ | refers_to_custodian | Custodian | Org observation → org hub |\n| PersonObservation\
          \ | **refers_to_person** | **Person** | Person observation → person hub\
          \ |\n| Event | involved_actors | Person/Custodian | Event → participants\
          \ |\n| Person | participated_in_events | Event | Person → events (inverse)\
          \ |\n\n**See**: modules/classes/Person.yaml for Person hub class\n**See**:\
          \ modules/slots/refers_to_person.yaml for slot definition\n"
        range: Person
        required: false
        comments:
        - Required is false initially to allow PersonObservation without hub linkage
        - Production data SHOULD always have this link for full PICO compliance
        - 'Inverse relationship: Person.has_person_observation (implemented v0.9.8)'
      birth_date:
        slot_uri: sdo:birthDate
        description: |
          Date of birth as recorded in source.

          **Format**: ISO 8601 date (YYYY-MM-DD) OR string for approximate dates.

          **PiCo Pattern**: Records date as mentioned in source, may be imprecise.

          **Examples**:
          - "1970-08-15" (precise)
          - "1970" (year only)
          - "ca. 1750" (approximate, string format)

          **See**: modules/slots/birth_date.yaml for detailed documentation          
        range: string
        required: false
      birth_place:
        slot_uri: sdo:birthPlace
        description: |
          Place of birth as recorded in source.

          **Format**: String (place name) OR URI (GeoNames, Wikidata).

          **Examples**:
          - "Amsterdam, Noord-Holland, Netherlands"
          - "http://sws.geonames.org/2759794/"

          **See**: modules/slots/birth_place.yaml for detailed documentation          
        range: string
        required: false
      death_place:
        slot_uri: sdo:deathPlace
        description: |
          Place of death as recorded in source.

          **Format**: String (place name) OR URI (GeoNames, Wikidata).

          **Holocaust/Conflict**: May include concentration camps, conflict zones.

          **See**: modules/slots/death_place.yaml for detailed documentation          
        range: string
        required: false
      date_of_death:
        slot_uri: sdo:deathDate
        description: |
          Date of death (uses TimeSpan for fuzzy dates).

          **Pre-existing slot**: See modules/slots/date_of_death.yaml          
        range: TimeSpan
        required: false
      deceased:
        slot_uri: schema:deathDate
        description: |
          Boolean flag indicating person is known to be deceased.

          **Use Case**: Mark deceased without knowing exact date.

          **Pre-existing slot**: See modules/slots/deceased.yaml          
        range: boolean
        required: false
      age:
        slot_uri: pico:hasAge
        description: |
          Age as recorded in source (when birth_date unknown).

          **Format**: String (allows "4" or "4 months" or "approximately 40").

          **Derivation**: Combined with source date to infer birth_date range.

          **See**: modules/slots/age.yaml for detailed documentation          
        range: string
        required: false
      occupation:
        slot_uri: sdo:hasOccupation
        description: |
          Occupation/profession as mentioned in source (outside institutional role).

          **Distinction from staff_role**:
          - occupation: General profession (e.g., "art historian")
          - staff_role: Institutional role class (e.g., Curator)

          **Format**: String (vernacular term) OR URI (Wikidata, HISCO).

          **Multivalued**: Person may have multiple occupations.

          **See**: modules/slots/occupation.yaml for detailed documentation          
        range: string
        multivalued: true
        required: false
      religion:
        slot_uri: pico:hasReligion
        description: |
          Religion/worldview as mentioned in source.

          **SENSITIVE DATA**: Handle with appropriate privacy considerations.

          **Format**: String (vernacular term) OR URI (Wikidata).

          **PiCo Pattern**: Records religion as found in historical source.

          **See**: modules/slots/religion.yaml for detailed documentation          
        range: string
        required: false
      gender_identity:
        slot_uri: schema:gender
        description: |
          Gender identity as expressed or recorded.

          **Free-text**: Allows inclusive representation beyond binary.

          **Pre-existing slot**: See modules/slots/gender_identity.yaml          
        range: string
        required: false
      pronouns:
        slot_uri: schema:knows
        description: |
          Pronouns used by or for this person.

          **Multilingual support**: May include Dutch (hij/hem, zij/haar),
          English (he/him, she/her, they/them), etc.

          **Pre-existing slot**: See modules/slots/pronouns.yaml          
        range: string
        required: false
      staff_role:
        slot_uri: schema:roleName
        description: |
          Primary staff role from controlled class hierarchy.

          **Schema.org**: `schema:roleName` for organizational role

          **Range**: StaffRole class hierarchy (51 specialized subclasses)

          **Purpose**: Enable role-based queries ("Find all conservators")

          **IMPORTANT - FORMAL TITLE vs DE FACTO WORK**:
          This slot captures the OFFICIAL job appellation/title assigned by the institution.
          Actual de facto work may differ from or stretch beyond this formal classification.
          Staff may perform duties outside their formal title, especially in smaller institutions.

          **Distinction from role_title**:
          - staff_role: Conservator class (controlled category with properties)
          - role_title: "Senior Paintings Conservator" (institutional job title string)

          **Classes replace enum**: Per Single Source of Truth principle, the StaffRoleTypeEnum
          was converted to a class hierarchy to enable richer modeling.

          See: modules/classes/StaffRole.yaml, modules/classes/StaffRoles.yaml          
        range: StaffRole
        required: true
      role_title:
        slot_uri: schema:jobTitle
        description: |
          Official job title as used by the institution.

          **Schema.org**: `schema:jobTitle` for institutional title

          **Examples**:
          - "Head of Digital Preservation"
          - "Senior Curator of Medieval Art"
          - "Collections Manager"
          - "Deputy Director for Public Services"

          **Variability**: Job titles vary widely across institutions.
          Use staff_role for standardized categorization.          
        range: string
        required: false
      unit_affiliation:
        slot_uri: schema:affiliation
        description: |
          Organizational unit (department/team) where person serves.

          **Schema.org**: `schema:affiliation` for organizational membership
          **W3C ORG**: Can map to `org:memberOf` (inverse of org:hasMember)

          **Reference**: Links to OrganizationalStructure.id

          **Temporal Alignment**:
          - Person's role_start_date should be >= unit's valid_from
          - Person's role_end_date should be <= unit's valid_to (if unit dissolved)

          **Example**: ".../org-unit/rm-conservation-division"

          **Rationale**: Staff roles exist within organizational context.
          Tracking unit affiliation enables:
          - Department staffing analysis ("How many staff in Conservation?")
          - Expertise location ("Which unit handles manuscript conservation?")
          - Reorganization impact ("Who moved to new Digital Services division?")          
        range: OrganizationalStructure
        required: false
      role_start_date:
        slot_uri: schema:startDate
        description: |
          Date when person began serving in this role.

          **Schema.org**: `schema:startDate` for employment/membership start
          **PROV-O**: Can map to `prov:startedAtTime` for activity start

          **Format**: ISO 8601 date (YYYY-MM-DD)

          **Precision**:
          - Full date preferred: "2013-03-01"
          - Partial dates allowed: "2013-03" (month precision), "2013" (year precision)

          **Temporal Consistency**:
          - Must be >= unit_affiliation.valid_from (if unit reference exists)
          - Should align with organizational events if role started due to reorganization

          **Example**: "2013-03-01" (started on merger date)          
        range: date
        required: false
      role_end_date:
        slot_uri: schema:endDate
        description: |
          Date when person ended service in this role (or null if still employed).

          **Schema.org**: `schema:endDate` for employment/membership end
          **PROV-O**: Can map to `prov:endedAtTime` for activity end

          **Format**: ISO 8601 date (YYYY-MM-DD) or null

          **Null Interpretation**: null = currently employed in this role

          **Temporal Consistency**:
          - Must be > role_start_date
          - Must be <= unit_affiliation.valid_to (if unit dissolved)

          **Reasons for End Date**:
          - Retirement
          - Role change (promotion, lateral move)
          - Organizational change (unit dissolved, merged)
          - Departure from institution

          **Example**: "2013-02-28" (ended before merger) or null (still employed)          
        range: date
        required: false
      observation_source:
        slot_uri: prov:hadPrimarySource
        description: |
          Source where this staff role information was observed.

          **PiCo Pattern**: PersonObservation MUST link to source (evidence-based)
          **PROV-O**: `prov:hadPrimarySource` for provenance tracking

          **Source Types**:
          - Staff directory (online or print)
          - Organizational chart
          - Annual report
          - Institutional website
          - Archival personnel records
          - Publication credits
          - Email signature

          **Structure**: Reference to SourceDocument with:
          - source_type: "Staff directory", "Annual report", etc.
          - source_uri: URL if available
          - observation_date: When source was consulted

          **Data Quality**: Observation with documented source = higher confidence          
        range: SourceDocument
        required: false
      affected_by_event:
        slot_uri: prov:wasInfluencedBy
        description: |
          Organizational change event that affected this person's role.

          **PROV-O**: `prov:wasInfluencedBy` for entity influenced by activity

          **Use Cases**:
          - Person promoted during reorganization
          - Person reassigned due to unit merger
          - Person's role changed after department split
          - Person retained position despite structural changes

          **Reference**: Links to OrganizationalChangeEvent.event_id

          **Temporal Alignment**:
          - If role_start_date = event_date: Role created by event
          - If role_end_date = event_date: Role ended by event

          **Example**: Person starts in new "Digital Services Division" on
          date of reorganization event that created the division.

          **Provenance**: Documents WHY role changed (organizational context)          
        range: OrganizationalChangeEvent
        required: false
      contact_email:
        slot_uri: schema:email
        description: |
          Professional contact email (if publicly available).

          **Schema.org**: `schema:email` for contact information

          **Privacy**: Only include if email is publicly listed (staff directory, website)

          **Format**: Valid email address

          **Use Case**: Enable contact for research inquiries, collaborations          
        range: string
        required: false
        pattern: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
      expertise_areas:
        slot_uri: schema:knowsAbout
        description: |
          Areas of professional expertise or specialization.

          **Schema.org**: `schema:knowsAbout` for knowledge/expertise

          **Examples**:
          - Conservation: "18th-century paintings", "Paper conservation", "Preventive conservation"
          - Curatorial: "Dutch Golden Age", "Modern sculpture", "Decorative arts"
          - Archival: "Digital preservation", "Medieval manuscripts", "Corporate archives"
          - Library: "Rare books", "Metadata standards", "Linked open data"

          **Use Cases**:
          - Find expertise: "Who specializes in textile conservation?"
          - Research collaboration: "Curators working on contemporary art"
          - Collection management: "Match conservation specialists to objects"

          **Multivalued**: Person may have multiple expertise areas          
        range: string
        multivalued: true
        required: false
      web_claims:
        slot_uri: prov:wasDerivedFrom
        description: |
          Verifiable claims about this person extracted from web pages.

          **RULE 26 COMPLIANCE**: All person/staff data SHOULD have web claim provenance.

          **Pattern**: Each PersonWebClaim provides:
          - claim_type: full_name, role_title, department, email, etc.
          - claim_value: The extracted value
          - source_url: URL where claim was found
          - xpath: XPath to element (for HTML sources)
          - retrieved_on: Timestamp of extraction
          - retrieval_agent: Tool used (firecrawl, playwright, exa, manual)

          **Use Cases**:
          - Track provenance of person data
          - Enable verification of extracted information
          - Document multiple sources for same fact
          - Resolve conflicts between sources

          **Example**:
          ```yaml
          web_claims:
            - person_claim_type: full_name
              person_claim_value: "Dr. Jane Smith"
              source_url: https://museum.org/team
              person_xpath: /html/body/main/div[2]/h3
              retrieved_on: "2025-01-15T10:30:00Z"
              retrieval_agent: firecrawl
              person_xpath_match_score: 1.0
          ```

          **See**: modules/classes/PersonWebClaim.yaml for full schema          
        range: PersonWebClaim
        multivalued: true
        required: false
        inlined: true
        inlined_as_list: true
      linkedin_profile_path:
        slot_uri: prov:hadPrimarySource
        description: |
          File path to LinkedIn profile data (per Rule 12, Rule 20).

          **Pattern**: LinkedIn profiles are stored as individual JSON files
          rather than inline data to avoid duplication and enable updates.

          **File Location**: data/custodian/person/entity/{linkedin-slug}_{timestamp}.json

          **Example**: "data/custodian/person/entity/jane-smith_20250115T103000Z.json"

          **Rationale**:
          - Same person may work at multiple custodians
          - Profile data can be updated independently
          - Reduces duplication (50+ lines → 1 path)

          **See**: Rule 12 (Person Data Reference Pattern), Rule 20 (Person Entity Profiles)          
        range: string
        required: false
      linkedin_profile_url:
        slot_uri: schema:sameAs
        description: |
          LinkedIn profile URL for this person.

          **Schema.org**: `schema:sameAs` for linking to same entity on other platforms

          **Format**: Full URL (https://www.linkedin.com/in/username)

          **Privacy**: Only include if LinkedIn profile is publicly accessible.

          **Photo URLs**: For profile photos, use CDN URL (media.licdn.com),
          NOT the overlay page URL (per Rule 16).

          **Example**: "https://www.linkedin.com/in/jane-smith-curator"          
        range: uri
        required: false
      extraction_metadata:
        description: "Provenance metadata for how this person observation was extracted.\n\
          \n**PROV-O Alignment**: This slot links the observation (prov:Entity) \n\
          to the extraction activity (prov:Activity).\n\n**Use Case**: Track automated\
          \ extraction from LinkedIn, web scraping,\nor manual data entry.\n\n**Relationship\
          \ to Other Provenance**:\n- `observation_source`: High-level source document\
          \ reference\n- `web_claims`: Individual verifiable claims with XPath\n-\
          \ `extraction_metadata`: Automated extraction activity provenance\n\n**Example**:\n\
          ```yaml\nextraction_metadata:\n  source_file: data/custodian/person/affiliated/parsed/rijksmuseum_staff.json\n\
          \  extraction_date: \"2025-12-12T22:00:00Z\"\n  extraction_method: exa_crawling_exa\n\
          \  extraction_agent: claude-opus-4.5\n  cost_usd: 0.001\n```\n"
        range: ExtractionMetadata
        inlined: true
        required: false
      created:
        slot_uri: schema:dateCreated
        description: |
          Timestamp when this DATABASE RECORD was created.          
        range: datetime
      modified:
        slot_uri: schema:dateModified
        description: |
          Timestamp when this DATABASE RECORD was last modified.          
        range: datetime
      specificity_annotation:
        range: SpecificityAnnotation
        inlined: true
      template_specificity:
        range: TemplateSpecificityScores
        inlined: true
    comments:
    - PiCo PersonObservation pattern adapted for institutional staff role tracking
    - Focus on ROLES and AFFILIATIONS within heritage organizations
    - NOT general biographical reconstruction (PiCo PersonReconstruction is separate
      concept)
    - refers_to_person links observation to Person hub (core PICO pattern)
    - Multiple observations from different sources can refer to same Person hub
    - Temporal validity enables tracking staff through organizational changes
    - 'Bidirectional links: staff → unit (unit_affiliation), unit → staff (staff_members)'
    - Person hub → Event via participated_in_events enables career event tracking
    - 'Rule 26 compliance: web_claims slot enables verifiable provenance for person
      data'
    - LinkedIn data stored separately in person/entity/ files (Rule 12, Rule 20)
    examples:
    - value:
        id: https://nde.nl/ontology/hc/person-obs/nl-nh-ams-m-rm/jane-smith/conservator-2013
        person_name: Dr. Jane Smith
        refers_to_person: https://nde.nl/ontology/hc/person/jane-smith
        staff_role: CONSERVATOR
        role_title: Deputy Director, Conservation Division
        unit_affiliation: https://nde.nl/ontology/hc/org-unit/rm-conservation-division
        role_start_date: '2013-03-01'
        role_end_date: null
        affected_by_event: https://nde.nl/ontology/hc/event/rm-conservation-merger-2013
      description: Conservator promoted during department merger, linked to Person
        hub
    - value:
        id: https://nde.nl/ontology/hc/person-obs/nl-nh-ams-m-rm/taco-dibbits/director-2016
        person_name: Taco Dibbits
        refers_to_person: https://nde.nl/ontology/hc/person/taco-dibbits
        staff_role: DIRECTOR
        role_title: General Director
        role_start_date: '2016-09-01'
        role_end_date: null
        linkedin_profile_url: https://www.linkedin.com/in/taco-dibbits
        linkedin_profile_path: data/custodian/person/entity/taco-dibbits_20250115T103000Z.json
        web_claims:
        - person_claim_type: full_name
          person_claim_value: Taco Dibbits
          source_url: https://www.rijksmuseum.nl/en/about-us/organisation
          person_xpath: /html/body/main/section[2]/div[1]/h2
          retrieved_on: '2025-01-15T10:30:00Z'
          retrieval_agent: firecrawl
          person_xpath_match_score: 1.0
        - person_claim_type: role_title
          person_claim_value: General Director
          source_url: https://www.rijksmuseum.nl/en/about-us/organisation
          person_xpath: /html/body/main/section[2]/div[1]/p[1]
          retrieved_on: '2025-01-15T10:30:00Z'
          retrieval_agent: firecrawl
          person_xpath_match_score: 1.0
      description: Museum director with Person hub link and full web claim provenance
        (Rule 26 compliant)