画板 1

    Person Archive Data Governance: A Jean-Claude Duvalier Case Study

    3 hr ago0 views

    This article explains how to turn a historical person entry into a structured, searchable, traceable, and auditable data asset. Using Jean-Claude Duvalier as a sample, it covers data scope definition, entity modeling, field standardization, event timelines, relationship graphs, extraction workflows, quality control, search design, security compliance, implementation phases, and common pitfalls.

    1. From Person Entries to Governed Data Assets

    In the source material, the core information centers on one historical figure, including name, aliases, birth date, birthplace, education, positions held, family members, and later public activities. At first glance, this looks like an ordinary biographical introduction. From a data governance perspective, however, it contains several structural object types: persons, dates, locations, organizations, positions, family relationships, events, and sources.

    If this content is only displayed as text, its information value is limited. Once it is modeled as data, it can support search, correlation analysis, timeline construction, relationship graph building, and fact verification. This article uses Jean-Claude Duvalier-related material as a sample to discuss how to turn such person profiles into high-quality, reusable, and traceable technical data assets.

    This topic applies to digital humanities, historical repositories, public knowledge bases, person archive systems, news material organization, and enterprise knowledge governance. The technical goal is not simply to display text, but to enable the following capabilities:

    1. Searchability: Query by person, time, location, position, and kinship.
    2. Connectability: Link persons with education, political positions, family relationships, and historical events.
    3. Traceability: Every structured record should be traceable to its original source.
    4. Auditability: Field modifications, version changes, and manual review processes should be recorded.
    5. Governability: Conflicting data, low-confidence data, and sensitive fields should have defined handling strategies.

    2. Define the Data Scope First: What Should Be Governed?

    Before technical modeling, the first step is to define which information should be included in a person archive. Based on the source material, several core data categories can be abstracted.

    1. Basic Person Attributes

    These include Chinese name, foreign-language name, aliases, nationality, ethnicity, birth date, death date, birthplace, occupation, and primary identity. These fields form the most basic descriptive information for a person entity.

    Example fields:

    1. {
    2.   "person_id": "person:jean_claude_duvalier",
    3.   "names": [
    4.     {
    5.       "value": "Jean-Claude Duvalier",
    6.       "language": "en",
    7.       "type": "full_name"
    8.     },
    9.     {
    10.       "value": "Jean-Claude Duvalier",
    11.       "language": "fr",
    12.       "type": "full_name"
    13.     },
    14.     {
    15.       "value": "Baby Doc",
    16.       "language": "en",
    17.       "type": "nickname"
    18.     }
    19.   ],
    20.   "birth_date": "1951-07-03",
    21.   "death_date": "2014-10-04",
    22.   "birth_place": "Port-au-Prince, Haiti",
    23.   "nationality": "Haitian",
    24.   "main_role": "political figure"
    25. }

    2. Education and Early Life Experience

    The source material mentions the person’s early environment, schools attended, and legal studies. In a technical treatment, it is not necessary to retain institution names as the only identifying basis, but they should be abstracted into “education experience” events and linked to time and location.

    For example:

    1. {
    2.   "education_events": [
    3.     {
    4.       "stage": "secondary education",
    5.       "institution_type": "school",
    6.       "location": "Port-au-Prince",
    7.       "confidence": 0.9
    8.     },
    9.     {
    10.       "stage": "higher education",
    11.       "field": "law",
    12.       "institution_type": "university",
    13.       "confidence": 0.85
    14.     }
    15.   ]
    16. }

    3. Political Positions and Public Activities

    The source material includes the person’s service as head of state and later return to public attention. Such information should be abstracted into “position events” or “public activity events” rather than being represented only as static person labels.

    For example:

    1. {
    2.   "role_events": [
    3.     {
    4.       "role": "head of state",
    5.       "period_start": "1971",
    6.       "period_end": "1986",
    7.       "status": "historical_role",
    8.       "confidence": 0.9
    9.     },
    10.     {
    11.       "role": "public activity participant",
    12.       "event_date": "2011",
    13.       "activity": "returned to Haiti and participated in reconstruction-related discussions",
    14.       "confidence": 0.8
    15.     }
    16.   ]
    17. }

    4. Family Relationships

    Family relationships are common structured objects in person archives. The source material involves father, mother, spouse, son, and daughter relationships. When modeling, these should be split into “person nodes” and “relationship edges” rather than being written as plain text paragraphs.

    Example:

    1. {
    2.   "relationships": [
    3.     {
    4.       "subject": "person:jean_claude_duvalier",
    5.       "relation": "child_of",
    6.       "object": "person:francois_duvalier"
    7.     },
    8.     {
    9.       "subject": "person:jean_claude_duvalier",
    10.       "relation": "child_of",
    11.       "object": "person:simone_duvalier"
    12.     },
    13.     {
    14.       "subject": "person:jean_claude_duvalier",
    15.       "relation": "spouse_of",
    16.       "object": "person:michelle_bennett_pasquet"
    17.     },
    18.     {
    19.       "subject": "person:jean_claude_duvalier",
    20.       "relation": "parent_of",
    21.       "object": "person:nicolas_duvalier"
    22.     },
    23.     {
    24.       "subject": "person:jean_claude_duvalier",
    25.       "relation": "parent_of",
    26.       "object": "person:anya_duvalier"
    27.     }
    28.   ]
    29. }

    3. Entity Modeling: Extracting “Objects” from Text

    The first step in person archive data governance is not writing summaries directly, but identifying entities. For this sample, at least the following entity types are required:

    Entity Type Example Role
    Person Jean-Claude Duvalier Archive subject
    Date July 3, 1951 Event time point
    Location Port-au-Prince Birthplace and activity location
    Organization School, university, government organization Education and position background
    Event Birth, schooling, office holding, return, death Timeline construction
    Relationship Father-son, spouse, children Relationship graph construction
    Source Original material, authoritative entry, version record Fact verification and auditing

    The key principle of entity modeling is: every citable, queryable, and connectable information unit should have a unique identifier.

    For example, a person entity can use:

    1. person:jean_claude_duvalier

    A father entity can use:

    1. person:francois_duvalier

    A location entity can use:

    1. place:port_au_prince

    An event entity can use:

    1. event:jean_claude_duvalier_birth

    Unique identifiers help avoid data duplication caused by same names, aliases, and translation differences.

    4. Field Standardization: Solving Multilingual Names, Aliases, and Fuzzy Expressions

    Person profiles often contain Chinese names, foreign-language original names, aliases, nicknames, abbreviations, and different translation versions. Without standardization, search and correlation become very difficult.

    For this sample, the following name variants need to be handled:

    1. Preferred full name: Jean-Claude Duvalier
    2. Original foreign-language name: Jean-Claude Duvalier
    3. Alias or nickname: Baby Doc
    4. Descriptive translation of the nickname: “Little Doctor”

    Technically, this can be handled with a structure such as “preferred name + alias list + source marker”.

    1. {
    2.   "preferred_name": {
    3.     "language": "en",
    4.     "value": "Jean-Claude Duvalier"
    5.   },
    6.   "alias_list": [
    7.     {
    8.       "value": "Jean-Claude Duvalier",
    9.       "language": "fr",
    10.       "type": "original_name"
    11.     },
    12.     {
    13.       "value": "Baby Doc",
    14.       "language": "en",
    15.       "type": "nickname"
    16.     }
    17.   ]
    18. }

    Dates should also be standardized into a unified format, preferably YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ. For example:

    1. July 3, 1951 -> 1951-07-03
    2. October 4, 2014 -> 2014-10-04

    Location names should be standardized as much as possible to a “city, country” level, such as:

    1. Port-au-Prince -> Port-au-Prince, Haiti

    If more country and region data is introduced later, administrative division codes can be added to reduce place-name ambiguity.

    5. Event Timeline: Turning Static Information into a Dynamic Trajectory

    A person archive should not stop at static descriptions such as “was born in a certain year”. It should build an event timeline. The advantage of an event timeline is that it can show relationships among the person’s life course, position changes, public activities, and historical nodes.

    In this sample, the following main events can be abstracted:

    1. Born in Port-au-Prince, Haiti.
    2. Received secondary education and university education in early life.
    3. Entered the national political system and held an important position.
    4. Left public office and remained inactive for a long period.
    5. Returned to Haiti and participated in public reconstruction-related discussions.
    6. Died in Port-au-Prince.

    An event model should include fields such as:

    1. {
    2.   "event_id": "event:jean_claude_duvalier_birth",
    3.   "subject": "person:jean_claude_duvalier",
    4.   "event_type": "birth",
    5.   "event_date": "1951-07-03",
    6.   "location": "place:port_au_prince",
    7.   "description": "Born in Port-au-Prince, the capital of Haiti",
    8.   "confidence": 0.98,
    9.   "source_ids": [
    10.     "source:biographical_profile_001"
    11.   ]
    12. }

    Event timelines can support the following types of analysis:

    • Person life-cycle views
    • Position change records
    • Links between education background and political paths
    • Links between birthplace and public activity locations
    • Links between family relationships and succession-related events
    • Comparative analysis with contemporaneous historical events

    It is important to note that events on a timeline should not only state “something happened in a certain year”. Each event should also indicate its source and confidence level. For historical person data, special care should be taken to avoid writing rumors, speculation, or unverified information into the formal fact layer.

    6. Relationship Graph: Connecting Isolated Persons into a Network

    A relationship graph is an important extension of person archive governance. Compared with traditional tables, graphs are better suited to express complex connections, such as kinship, employment or position relationships, organizational affiliation, location associations, and event participation relationships.

    For this sample, the following relationship models can be built.

    1. Kinship Relationships

    1. person:jean_claude_duvalier --child_of--> person:francois_duvalier
    2. person:jean_claude_duvalier --child_of--> person:simone_duvalier
    3. person:jean_claude_duvalier --spouse_of--> person:michelle_bennett_pasquet
    4. person:jean_claude_duvalier --parent_of--> person:nicolas_duvalier
    5. person:jean_claude_duvalier --parent_of--> person:anya_duvalier

    2. Education and Organization Relationships

    1. person:jean_claude_duvalier --studied_at--> institution:secondary_school
    2. person:jean_claude_duvalier --studied_at--> institution:university_law_program

    3. Position and Public Activity Relationships

    1. person:jean_claude_duvalier --held_role--> role:head_of_state
    2. person:jean_claude_duvalier --participated_in--> event:public_reconstruction_discussion

    4. Location Associations

    1. person:jean_claude_duvalier --born_in--> place:port_au_prince
    2. person:jean_claude_duvalier --died_in--> place:port_au_prince

    When modeling relationship graphs, several issues should be considered:

    1. Relationships must have direction: For example, “father of child” and “child of father” should not be confused.
    2. Relationships must have time ranges: For example, a marriage relationship may have a start time and an end time.
    3. Relationships must have sources: This is especially important for kinship and political position relationships.
    4. Relationships must have versions: When new material corrects an old relationship, historical versions should be retained.

    7. Data Extraction Workflow: From Raw Text to Structured Records

    Turning a raw person entry into structured data usually requires the following workflow.

    1. Document Ingestion

    Person profiles, entry text, image captions, tables, and external references should be unified into a data pipeline. The original content can be stored as a document asset in generic object storage and assigned a unique document identifier.

    2. Text Segmentation and Sentence Identification

    Long text should be split into sentences or paragraphs to support subsequent entity recognition and relationship extraction. For example:

    1. The person was born on July 3, 1951, in Port-au-Prince, the capital of Haiti.

    This can be extracted as:

    1. {
    2.   "sentence_id": "sent_001",
    3.   "text": "The person was born on July 3, 1951, in Port-au-Prince, the capital of Haiti.",
    4.   "extracted": [
    5.     {
    6.       "entity": "person",
    7.       "value": "Jean-Claude Duvalier"
    8.     },
    9.     {
    10.       "entity": "date",
    11.       "value": "1951-07-03"
    12.     },
    13.     {
    14.       "entity": "place",
    15.       "value": "Port-au-Prince"
    16.     }
    17.   ]
    18. }

    3. Named Entity Recognition

    Identify persons, dates, locations, organizations, positions, and other entities in the text. Generic entity recognition capabilities should be used here, rather than depending on a specific product interface.

    4. Relationship Extraction

    Identify relationships among entities, such as:

    • A person was born in a place.
    • A person studied at an institution.
    • Two persons have a kinship relationship.
    • A person held a position.

    5. Standardization and Normalization

    Dates, place names, person names, and institution types should be unified into standard dictionaries. For example:

    1. July 3, 1951 -> 1951-07-03
    2. Port-au-Prince -> place:port_au_prince
    3. University of Haiti -> institution:haiti_university

    6. Conflict Detection

    If multiple sources provide different values for the same field, a conflict should be marked. For example, if multiple versions exist for a birth year, one version should not directly overwrite another. Instead, a conflict record should be generated.

    7. Human Review

    For sensitive information involving historical figures, political figures, and family relationships, a manual review step should be established. Automated extraction only produces candidate results. Final ingestion into the archive should require review.

    8. Version Release

    Every structured data update should generate a version number, for example:

    1. {
    2.   "record_version": "v1.3",
    3.   "published_at": "2026-06-15T08:00:00Z",
    4.   "change_summary": "Added family relationship fields and birth source citation"
    5. }

    8. Quality Governance: Facts, Opinions, Sources, and Confidence

    The most important part of person archive governance is not having many fields, but having trustworthy fields. Especially for historical and political figures, facts, opinions, rumors, and sources must be strictly separated.

    1. Separate Facts from Opinions

    For example:

    • Fact: The person was born on a specific date.
    • Fact: The person once held a certain position.
    • Fact: The person returned to a certain place in a certain year.
    • Opinion: The person is described as a “dictator”.
    • Evaluation: The person had a negative or positive impact on national development.

    In a basic fact repository, verifiable facts should be stored first. Evaluative content should be placed in an opinion layer, comment layer, or analysis layer, with author, source, and context clearly marked.

    2. Source Grading

    Sources can be divided into different levels:

    Level Type Handling Approach
    A Authoritative archives, formal publications, official records Can directly enter the fact layer
    B Reliable media, academic materials Requires cross-verification
    C General encyclopedias, aggregated content Used only as leads
    D Anonymous sources, unverified claims Should not enter the fact layer

    3. Confidence Labeling

    Every extraction result should have a confidence value. For example:

    1. {
    2.   "fact": "The person was born on July 3, 1951",
    3.   "confidence": 0.98,
    4.   "source_level": "A"
    5. }
    1. {
    2.   "fact": "The person participated in reconstruction-related work",
    3.   "confidence": 0.72,
    4.   "source_level": "B"
    5. }

    4. Conflict Handling

    If two sources disagree on a field, one value should not simply be deleted. Instead, the conflict should be recorded:

    1. {
    2.   "field": "death_date",
    3.   "candidates": [
    4.     {
    5.       "value": "2014-10-04",
    6.       "source": "source_001",
    7.       "confidence": 0.96
    8.     }
    9.   ],
    10.   "resolution": "adopted",
    11.   "resolver": "manual_review"
    12. }

    9. Search and Query Design

    After structuring, the person archive should support multiple search methods.

    For example, querying a person born in 1951:

    1. {
    2.   "match": {
    3.     "birth_date": "1951-07-03"
    4.   }
    5. }

    2. Full-Text Search

    For example, searching for keywords such as “Port-au-Prince”, “birth”, “president”, and “returned to Haiti”.

    For example, querying events that occurred in a certain year:

    1. {
    2.   "filter": {
    3.     "event_date": {
    4.       "gte": "1970-01-01",
    5.       "lte": "1980-12-31"
    6.     }
    7.   }
    8. }

    For example, querying all children of a person:

    1. {
    2.   "subject": "person:jean_claude_duvalier",
    3.   "relation": "parent_of",
    4.   "object_type": "person"
    5. }

    For example, querying all sources of a fact:

    1. {
    2.   "fact_id": "fact_birth_date",
    3.   "return_fields": [
    4.     "source_url",
    5.     "source_title",
    6.     "source_level",
    7.     "confidence"
    8.   ]
    9. }

    10. Security and Compliance: Historical Person Data Still Needs Permissions and Auditing

    Even if a person is deceased, the data system still needs to consider compliance, privacy, political sensitivity, and access control. A person archive should follow these principles.

    1. Minimization Principle

    Only collect data directly related to knowledge organization. Avoid excessive recording of private information unrelated to the topic.

    2. Tiered Authorization

    Different user roles should have different permissions:

    • General readers: Read-only access to public fields
    • Reviewers: Access to data pending review
    • Data administrators: Modify fields and versions
    • Auditors: View operation logs
    • Security administrators: Manage permissions and sensitive fields

    3. Audit Logs

    All key operations should be logged, including:

    • Who modified which field and when
    • Values before and after modification
    • Whether manual review was performed
    • Whether data was deleted or rolled back
    • Whether data was exported or batch-downloaded

    4. Sensitive Field Protection

    Content involving religious belief, family members, health information, and political evaluation should be tagged as sensitive. Sensitive fields can be used for internal management, but external display should require review.

    5. Export Control

    When batch-exporting person archives, watermarks, access controls, and operation auditing should be configured to prevent improper dissemination of data.

    11. Practical Implementation Path

    If a similar person archive knowledge base is to be built, the following phased approach can be used.

    Phase 1: Basic Archive Layer

    Goal: Turn raw text into structured records.

    • Define person, date, location, event, and relationship fields
    • Establish unique identifiers
    • Complete basic field extraction
    • Mark sources
    • Create version numbers

    Phase 2: Relationship Graph Layer

    Goal: Ensure persons are not isolated.

    • Establish kinship relationships
    • Establish education experience relationships
    • Establish position relationships
    • Establish location associations
    • Establish event participation relationships

    Phase 3: Quality Governance Layer

    Goal: Improve trustworthiness.

    • Introduce source grading
    • Introduce confidence values
    • Introduce conflict detection
    • Introduce human review
    • Introduce fact/opinion separation mechanisms

    Phase 4: Knowledge Service Layer

    Goal: Make data queryable, displayable, and reusable.

    • Provide person archive pages
    • Provide timeline views
    • Provide relationship graph views
    • Provide source traceability views
    • Provide search interfaces

    Phase 5: Intelligent Analysis Layer

    Goal: Discover patterns from structured data.

    • Person group profiles
    • Relationship networks among contemporaneous historical figures
    • Location and event association analysis
    • Institution and person movement analysis
    • Source coverage analysis

    12. Common Pitfalls and Recommendations

    Pitfall 1: Focusing Only on Text Display Without Structuring

    If data exists only in articles, the system cannot support relationship queries, timeline filtering, or graph analysis. Structuring is the prerequisite for building a knowledge base.

    Pitfall 2: Putting Everything into the Fact Layer

    Evaluations, speculation, and political judgments should not be mixed with basic facts. The fact layer must remain neutral and verifiable.

    Pitfall 3: Ignoring Aliases and Translation Differences

    If multilingual names and aliases are not standardized, the same person may be modeled repeatedly.

    Pitfall 4: Relationships Without Sources

    This is especially important for kinship and position relationships. Without source support, incorrect relationships may be amplified by the system.

    Pitfall 5: No Version Control

    Historical materials often need correction. Without version control, incorrect fields may permanently overwrite correct fields.

    13. Conclusion

    Using Jean-Claude Duvalier-related material as a sample, we can see that a person archive is not merely a simple biographical introduction. It is a typical multi-source, unstructured, long-term governance data object. Through entity modeling, field standardization, event timelines, relationship graphs, source verification, confidence management, and permission auditing, scattered person information can be transformed into a high-quality knowledge asset.

    For digital humanities, historical repositories, public knowledge services, and enterprise knowledge governance, this method has broad applicability. The core is not stacking fields, but establishing trustworthy data order: every piece of information should have a source, every relationship should be traceable, every modification should be recorded, and every fact should be searchable, verifiable, and reusable.

    09040904

    Top articles