Entity Page untuk Tokoh: Data Mana yang Aman dan Relevan Dipublikasikan

Begitu sebuah organisasi mulai serius membangun entity architecture, pertanyaan tentang tokoh hampir selalu muncul.

“Founder perlu punya halaman sendiri nggak?”

“CEO perlu schema Person?”

“Boleh masukin tanggal lahir?”

“Alamat?”

“Nomor telepon?”

“Family relation?”

“Riwayat lengkap dari sekolah sampai sekarang?”

Di titik ini, proyek entity gampang tergelincir dari information architecture menjadi data hoarding.

Tidak semua data yang bisa ditemukan layak dipublikasikan.

Tidak semua atribut Person membantu pembaca.

Dan tidak semua enrichment membuat entity menjadi “lebih kuat”.

Entity page untuk tokoh harus dibangun dari tiga prinsip:

Relevansi.

Keamanan.

Verifiability.

Kalau satu data tidak membantu memahami peran publik tokoh, punya privacy risk, atau sumbernya lemah, tidak perlu dimasukkan hanya karena schema menyediakan property.

Tokoh adalah Manusia, Bukan Database Row

Ini starting point yang sering dilupakan.

Person entity mewakili manusia nyata.

Mereka punya privasi.

Context.

Perubahan karier.

Batas antara public role dan personal life.

Jadi pendekatan “semakin lengkap semakin bagus” salah.

Entity page bukan dossier.

Bukan background check.

Bukan data broker profile.

Untuk website organisasi, purpose biasanya sederhana:

Menjelaskan siapa orang ini dalam konteks organisasi atau karya publiknya.

Contoh:

Founder.

CEO.

Researcher.

Author.

Reviewer.

Board member.

Expert.

Spokesperson.

Profile harus fokus pada role itu.

Pertanyaan Pertama: Kenapa Halaman Ini Ada?

Kalau jawabannya:

“Biar ada Person schema.”

Belum cukup.

Halaman seharusnya punya human utility.

Journalist ingin tahu bio resmi.

Client ingin tahu siapa advisor.

Reader ingin tahu author qualification.

Partner ingin verify leadership.

Conference organizer mencari profile.

Research user ingin melihat publications.

Kalau tidak ada kebutuhan tersebut, page bisa jadi thin.

Tidak semua employee perlu public entity page.

Entity scope harus intentional.

Data yang Umumnya Relevan

Untuk professional entity page, data yang biasanya masuk akal:

Nama publik.

Current role.

Organization.

Professional biography.

Area expertise.

Public responsibilities.

Selected works.

Publications.

Projects.

Awards yang terverifikasi.

Professional memberships yang public.

Official professional profiles.

Public speaking.

Education jika relevant dan verified.

Career history yang material.

Official contact channel melalui organization.

Photo yang authorized.

Data ini membantu understanding.

Tetapi tetap harus dipilih.

CEO manufacturing company tidak harus mempublikasikan seluruh daftar hobby masa sekolah.

Relevance is filter.

Current Role Wajib Punya Tanggal atau Context

Role berubah.

CEO 2024 belum tentu CEO 2026.

Profile yang hanya berkata:

“A adalah CEO Company X.”

Tanpa update governance, cepat stale.

Better:

“A menjabat sebagai CEO Company X sejak [tanggal/tahun]” jika verified dan appropriate.

Atau:

“Per Agustus 2026, A menjabat…”

Untuk publication, jangan auto-timestamp setiap day kalau tidak benar-benar review.

Internal system should store effective date.

When role changes:

Update Person page.

Organization page.

Schema.

Author bio if relevant.

Press kit.

Public profiles.

Entity drift begins when role update partial.

Founder dan CEO Jangan Disamakan

Founder is historical relationship.

CEO is current role.

Seseorang bisa founder tetapi tidak lagi CEO.

Co-founder bisa beberapa.

Chairperson different.

Commissioner different.

If page says:

“Founder and CEO” after person stepped down as CEO, error.

Use separate facts.

“Founder of X.”

“Served as CEO from…”

“Currently serves as…”

This temporal clarity matters.

AI often blends roles if web sources are stale.

Professional Bio Harus Fact-Based

Avoid:

“Visionary leader.”

“World-class expert.”

“Renowned innovator.”

Unless context/source supports and purpose is promotional.

Better:

“B memimpin pengembangan product X dan sebelumnya bekerja di Y.”

“C meneliti information retrieval dan telah menulis publications on…”

Specific.

Factual.

Verifiable.

Human reader gets value.

Machine gets attributes.

Marketing adjective adds little.

Data Pribadi yang Biasanya Tidak Perlu

Home address.

Personal phone.

Private email.

Family members.

Children names.

Spouse information.

Personal financial details.

Government ID.

Passport.

Tax number.

Exact birth location if not relevant.

Date of birth if not needed.

Private social accounts.

Daily routines.

Sensitive health information.

Political affiliation.

Religion.

Sexual orientation.

Personal security details.

Even if some data is available elsewhere, don't republish without clear purpose and consent/legal basis.

Entity optimization does not justify privacy exposure.

Tanggal Lahir Perlu Sangat Hati-hati

Date of birth is common in biographies.

But for corporate person page, ask:

Why is it relevant?

For public historical figure, maybe.

For CEO or author, often not.

Age can be derived.

Privacy risk increases.

Identity theft context.

If organization has no need, leave out.

Do not scrape from random databases.

Schema property availability is not publication requirement.

This principle should be explicit in editorial policy.

Alamat Person Hampir Selalu No

For living professionals, publish organization address if needed.

Not home.

Person works at Organization.

Contact via office.

If public figure has official constituency office or professional studio, list that entity/place context, not private residence.

Structured data can connect Person to Organization without exposing personal location.

Machine readability should not create safety risk.

Contact Point: Use Professional Channel

Good:

Official company email.

Press contact.

Public assistant.

Professional contact form.

LinkedIn if official/professional.

Bad:

Personal WhatsApp scraped online.

Private Gmail from old PDF.

Personal phone found in WHOIS history.

Entity page should respect channel boundary.

If person wants public direct contact, use consented official channel.

Consent matters.

Photo juga Punya Rights

Don't scrape portrait from random media.

Use authorized image.

Company press photo.

Creative Commons if compliant.

Official profile image with permission.

Image rights are separate from factual data.

Entity page should include alt text and caption accurate.

Don't name people in group photo incorrectly.

Visual entity error is still entity error.

Education: Relevan, tetapi Jangan Prestige Farming

Education can help explain expertise.

But verify.

Official university profile.

Person CV.

Company bio.

Public interview.

Do not infer degree from social post.

Don't exaggerate:

“Studied at X” ≠ “graduated from X.”

“Attended program” ≠ degree.

This is common error.

Write exact claim supported.

Person entity authority should come from truth, not prestige.

Awards and Certifications

Same principle.

Award recipient:

Person or company?

Year?

Category?

Issuer?

Certification active?

Professional license current?

Don't attach Organization award to Person because they are CEO.

Don't attach team certification to individual.

Evidence scope.

A Person page with 30 unverified badges creates more risk than authority.

Authorship adalah Relationship yang Penting

For publisher/research site, Person page can connect:

Person → authorOf → Article.

Person → researcherOn → Study.

Person → reviewerOf → Report.

This is useful.

But author attribution must be real.

Don't create fake named authors for SEO.

Don't assign executive as author to content they didn't write.

E-E-A-T discussions often tempt ghost authorship.

Entity integrity requires actual role.

If content editorially produced by team, say team.

Reviewer relation can be explicit if true.

Skenario Editorial

SEO:
“Kita bikin bio lengkap CEO, termasuk lahir di mana, sekolah TK sampai S2, spouse, semua social.”

Legal:
“Kenapa?”

“Biar entity-nya kaya.”

PR:
“Yang dibutuhkan journalist cuma current role, career, expertise, official photo, contact.”

Security:
“Home town and family detail jangan.”

CEO:
“Saya juga nggak mau.”

This is the right intervention.

Entity richness is not data quantity.

It's relevant relationship clarity.

Minimal Person Page yang Bagus

H1:
Full public name.

Intro:
Current role + organization + core expertise.

Sections:

Current role.

Professional background.

Selected public work.

Publications/projects.

Relationship to organization.

Official profiles.

Press/professional contact.

Last reviewed.

Maybe education.

Maybe awards.

Enough.

No private biography unless person is a public cultural/historical figure and website purpose justifies.

Person Page vs Author Page

Sometimes same.

Sometimes different.

Author page:

Bio.

Articles.

Expertise.

Editorial role.

Person entity.

Leadership page:

Corporate role.

Career.

Organization relation.

Could be one canonical Person page with both functions.

Avoid duplicate bios at:

/author/name/

/team/name/

/leadership/name/

All with different info.

Choose canonical Person page.

Other pages link/reference.

This reduces fragmentation.

If CMS author archive needed, canonical strategy carefully designed.

SameAs pada Person

SameAs can connect equivalent identity pages:

Official LinkedIn.

ORCID.

Google Scholar profile if appropriate.

Wikidata.

Wikipedia.

Institutional profile.

GitHub for developer if official/professional.

But only if same person.

Name collision risk high.

Do not add profile because same name.

Verify:

Photo.

Organization.

Career.

Location.

Public work.

sameAs error on Person can merge two humans.

High severity.

Person Names Sangat Mudah Bentrok

“Agus Santoso.”

“Dewi Lestari.”

“Michael Tan.”

Many people.

Canonical page should include disambiguators:

Role.

Organization.

Field.

Selected work.

Maybe middle name.

Official profiles.

Don't include unnecessary private data to disambiguate.

Professional attributes are enough in most cases.

Former Name and Name Variants

People can use:

Academic name.

Professional name.

Pen name.

Married name.

Abbreviation.

Transliteration.

If publicly relevant and person consents/context supports, include alternateName.

But sensitive identity history should not be exposed casually.

Especially legal name changes.

Use only when public professional identity requires reconciliation.

Respect person.

Entity graph is not investigative journalism by default.

Public Figures vs Private Professionals

Threshold differs.

Politician, celebrity, historical figure, public scholar may have broad public biography.

Corporate employee does not automatically become public figure because website creates page.

Use role-based publication.

Senior executive may have more public info due corporate responsibility.

Still privacy limits.

Don't conflate discoverability with public-interest justification.

This is both ethical and operational.

Sensitive Claims Butuh Strong Evidence

Legal dispute.

Criminal allegation.

Health condition.

Political belief.

Family conflict.

Do not put on corporate entity page unless there is compelling public purpose, authoritative source, legal review, and editorial mandate.

For GEO.or.id-style entity architecture, these are generally out of scope.

The goal is professional identity, not controversial biography.

If site is journalism, different editorial standards apply.

Site context matters.

Person Schema Harus Match Visible Content

If JSON-LD says:

jobTitle: CEO.

Visible page says Advisor.

Conflict.

SameAs lists private profile not shown/approved.

WorksFor old company.

AlumniOf unverified.

Don't treat structured data as secret enrichment.

Public source code is visible.

Schema should represent public facts.

Minimal, accurate.

Good.

Too much, risky.

Internal Person Graph Can Be Richer, but Access-Controlled

HR system knows:

Employee ID.

Manager.

Team.

Office.

Skills.

Start date.

Compensation.

Performance.

Internal graph can use under permissions.

Public projection only:

Name.

Role.

Team maybe.

Bio.

Public work.

Contact.

Separate.

Never expose internal IDs or HR data because public schema pipeline reused same object.

This architecture bug is preventable.

Use publication flags.

`public: true/false`.

Field-level controls.

AI agent era makes this more critical.

Evidence Source untuk Person Facts

Priority:

Official bio.

Organization page.

Person's official professional profile.

University/research institution.

Public registry for regulated role.

Conference bio.

Published interview.

Reliable media.

But check freshness.

A 2019 conference bio may say Person is CTO of old company.

Historical, not current.

Every role fact needs time context.

Cross-source consistency.

Correction Workflow

If AI says wrong founder or role:

1. Verify official truth.
2. Check Person page.
3. Check Organization page.
4. Check structured data.
5. Search stale official bios.
6. Check high-impact third-party profiles.
7. Update/correct where possible.
8. Retest.
9. Log error.

Don't publish more personal data as first response.

The solution to entity confusion is not privacy sacrifice.

Measurement for Person Entity Page

Queries:

“Who is CEO of Company X?”

“Who founded Company X?”

“What is Person Y’s role?”

“What has Person Y worked on?”

“Is Person Y associated with Company Z?”

Test across models.

Record:

Correct.

Outdated.

Mixed person.

Wrong organization.

Wrong role.

Citation.

Severity.

If identity improves after cleanup, good.

Still don't claim causal certainty.

Entity Page Should Protect the Person as Much as It Explains Them

This is the key.

A good Person page helps readers understand:

Who is this person?

Why are they relevant here?

What have they done publicly?

What role do they currently hold?

Where can I verify?

It does not answer every possible question.

It should not.

Restraint is part of information quality.

In AI search, there is pressure to make everything machine-readable.

That pressure needs a boundary.

Human beings are not products to fully enumerate.

Publish what is professionally relevant, verified, safe, and intended for public use.

Leave the rest private.

An entity page that respects that boundary is not “less optimized”.

It is better governed.