Knowledge Graph untuk Grup Perusahaan dan Anak Usaha

Grup perusahaan terlihat sederhana di slide investor.

Holding di atas.

Anak usaha di bawah.

Beberapa brand di samping.

Tiga warna.

Selesai.

Di website, realitanya biasanya jauh lebih messy.

Satu subsidiary punya domain sendiri.

Yang lain hanya page di corporate site.

Ada brand yang bukan legal entity.

Ada joint venture.

Ada business unit.

Ada product name yang terdengar seperti company.

Ada parent yang berubah setelah acquisition.

Ada regional subsidiary.

Ada founder yang duduk di beberapa boards.

Kalau semua disatukan sebagai “Group X”, AI bisa salah merge entity.

Kalau semua dipisah tanpa relationship, AI bisa gagal memahami bahwa mereka bagian dari grup yang sama.

Knowledge graph untuk grup perusahaan harus menghindari dua ekstrem:

Semua dianggap satu entity.

Atau semua dianggap pulau.

Mulai dari Legal Reality

Pertanyaan pertama bukan:

“Brand architecture-nya apa?”

Pertanyaan pertama:

“Entity legal dan operasionalnya apa?”

List:

Holding company.

Subsidiaries.

Joint ventures.

Branches.

Business units.

Brands.

Products.

Foundations.

Associations.

Regional offices.

Not all have same legal status.

For public graph, classify carefully.

Organization.

Corporation.

LocalBusiness.

Brand.

Product.

Department/business unit.

Place.

Don't create Organization node for every marketing label.

Don't reduce legal subsidiary to Brand.

Type follows reality.

Contoh Struktur

Group:
PT Nusantara Digital Group.

Subsidiary A:
PT Nusantara Cloud Indonesia.

Subsidiary B:
PT Nusantara Commerce.

Brand:
CloudKu, owned/operated by Subsidiary A.

Product:
CloudKu Enterprise.

Business unit:
Nusantara Ventures, internal division of Group.

Joint venture:
PT Nusa Global JV, owned partly by Group and Partner X.

Already six entity roles.

If site calls all of them “Nusantara”, ambiguity.

Graph helps.

ParentOrganization dan subOrganization Harus Sesuai Reality

Schema.org provides properties such as parentOrganization and subOrganization for organizational relationships.

Useful.

But do not use if relation is only:

Partner.

Client.

Investor minority without parent control.

Distributor.

Franchisee.

Brand license.

Joint venture.

Parent-child relationship has meaning.

Legal/corporate governance should review.

Structured data cannot rewrite cap table.

If uncertain, keep relationship in human prose until verified.

Brand Ownership vs Organization Ownership

Subsidiary can own brand.

Parent can own subsidiary.

Then:

Parent Organization
→ owns/control relation internally
→ Subsidiary Organization

Subsidiary
→ owns/operates
→ Brand

Brand
→ applied to
→ Product

Don't shortcut:

Parent sameAs Brand.

Not same entity.

A group brand can share name with parent, but ontology still needs role.

If Group “Garuda” has Brand “Garuda”, content must explain.

Canonical pages reduce confusion.

Skenario Rapat yang Biasa Terjadi

Corporate comms:
“Semua website tulis ‘a member of Group X’.”

Legal:
“Subsidiary C sudah dijual.”

Brand:
“Logo masih pakai Group X.”

Developer:
“Schema parentOrganization masih Group X.”

SEO:
“AI masih bilang C anak usaha kita.”

This is entity drift at corporate scale.

Relationship graph needs effective date.

`validThrough`.

Former parent.

Current owner.

Public announcement.

Website update.

Logo cleanup.

Third-party profile.

Corporate structure isn't static.

Graph must have lifecycle.

Joint Venture adalah Kasus Sulit

JV may have two parents or shareholders.

Don't force one parent if legal reality shared.

Public page can say:

“PT Nusa Global JV is a joint venture between Group A and Group B.”

Structured representation may need careful modeling based on available vocabulary.

Do not invent unsupported schema property.

Internal graph can have precise ownership percentages if appropriate and authorized.

Public graph only published facts.

If ownership percentages private, don't expose.

Knowledge graph is not cap table leak.

Branches vs Subsidiaries

Branch is not necessarily separate legal entity.

“Surabaya branch of Company A.”

Subsidiary:
Separate Organization controlled by parent.

Why matter?

AI query:
“Who owns Company Surabaya?”

If branch marketed as separate company, response can be wrong.

Page should say:

“Surabaya branch of PT Company A.”

Use local business/location representation appropriately.

Don't create independent Organization if none.

Entity modeling protects legal clarity.

Business Unit Bukan Anak Usaha

“AI Division.”

“Enterprise Unit.”

“Consumer Business.”

These sound like organizations.

But may be internal department.

Do not list as subsidiary.

Graph:

Organization → department → unit, conceptually.

Public content can explain.

If Schema.org type doesn't fit exactly, don't force.

A WebPage section may be enough.

Not every organizational concept needs its own public node.

Group Directory Bisa Menjadi Canonical Hub

For complex groups, create page:

“Group Structure.”

Not corporate puff.

Real map.

Parent.

Subsidiaries.

Brands.

Business units.

Locations.

Status.

Links.

Effective date.

This page helps:

Investor.

Journalist.

Supplier.

Job candidate.

AI auditor.

Keep updated.

If legal structure differs from brand structure, show two views.

Legal entities.

Commercial brands.

Don't mix.

That is extremely useful.

Canonical Entity Page per Subsidiary

Each important subsidiary should have identity page.

Name.

Legal name.

Role.

Parent.

Brands/products.

Country.

Leadership if relevant.

Official domain.

Contact.

Status.

Evidence.

Group page links.

Subsidiary links back to group.

Reciprocal relationship natural.

If subsidiary has own domain, cross-domain relation should be explicit.

“Part of Group X.”

Not just common footer logo.

Machine and human need sentence.

Entity IDs Harus Stabil Lintas Domain

Parent on group.com.

Subsidiary on sub.co.id.

Product on product.com.

Internal registry maps.

ORG-GROUP-001.

ORG-SUB-004.

BR-008.

PROD-099.

Public @id/URLs stable.

If each site independently defines parent with different names/IDs, fragmentation.

Example:

Group site:
“PT Nusantara Digital Group.”

Subsidiary:
“Nusantara Group.”

Product:
“NDG Holding.”

These may be same organization.

Use canonical ID reference.

Governance.

Cross-site schema should not invent duplicates.

Ownership Tidak Sama dengan Brand Association

Company can operate brand under license.

Franchise.

Distributor.

JV.

Do not write “owned by” because logos appear together.

Use exact relationship.

Operated by.

Distributed by.

Franchised by.

Licensed from.

Partnership with.

If vocabulary cannot model, prose.

Accuracy > machine neatness.

This is especially important in Indonesia where distribution and licensing structures can be complex.

Public graph should not simplify legal relationship into false ownership.

Person Relationship Bisa Span Several Entities

Founder may be:

Founder of parent.

Commissioner subsidiary.

CEO another unit.

Investor JV.

Person page should state roles.

Date.

Current/historical.

Don't use one worksFor edge to imply all.

Graph can model multiple roles internally.

Public page should not expose private positions.

For current public roles, clear.

AI often blends executive titles across group.

This is high-frequency entity error.

One canonical leadership page per entity helps.

Group-Level Claims Harus Scope-Correct

“Group X serves 1 million customers.”

Does that include all subsidiaries?

Source?

Date?

Does subsidiary website repeat as its own customer count?

Danger.

Group metrics should stay group-level.

Subsidiary metrics subsidiary-level.

Product metrics product-level.

Evidence must attach to correct node.

Graph helps prevent metric leakage.

Without it, content writer copy-pastes group achievement to all child entities.

AI can amplify false claim.

Knowledge graph is governance control.

Financial Data Sangat Sensitif

Revenue.

Ownership percentage.

Valuation.

Profit.

Shareholding.

If public, cite authoritative filings.

If private, don't publish because graph wants completeness.

Internal graph can store with access control.

Public graph uses disclosed figures only.

AI optimization cannot override financial confidentiality.

This should be a hard policy.

Acquisition Changes Graph Direction

Company A acquires B.

Before:
B parent independent.

After:
A parent/owner.

But historical articles still pre-acquisition.

Graph needs:

effective date.

previous parent/independent status.

new relationship.

Acquisition announcement.

Old brand maybe retained.

Don't rewrite old timeline.

Public current page:
“B has been part of A Group since date.”

Historical clarity.

AI can still cite old source, but current canonical truth exists.

Merger is Different

A + B → C.

Not simply A parent B.

May create new legal entity or surviving entity.

Need legal mapping.

Predecessor/successor.

Old domains.

Products.

People.

Do not use sameAs for merged organizations automatically.

They were not always same entity.

Reorganization semantics matter.

If unsure, legal team defines.

KG implementation follows.

Group Knowledge Graph Bisa Menjadi Basis Internal Link

Group page → subsidiary.

Subsidiary → parent.

Subsidiary → brand.

Brand → product.

Evidence → relevant entity.

Good.

But not every relation needs sitewide footer link.

Use contextual.

For multi-domain, cross-domain nav can help.

“Part of Group X.”

“Visit corporate site.”

Reader context.

Don't create 100 reciprocal links between all sister companies.

Siblings are related through parent, not necessarily direct.

Graph avoids link spaghetti.

Schema Generation from Registry

Ideal workflow:

Corporate master data.

Approved public fields.

Entity registry.

Schema generator.

CMS pages.

Consistency validator.

When subsidiary renamed:

Update registry.

All outputs flagged.

This is scalable.

Manual hardcoding across 20 websites will drift.

Graph becomes infrastructure.

But small groups can use spreadsheet.

Technology should fit size.

Audit Group Graph

Questions:

Is every subsidiary current?

Any sold companies still listed?

Any joint venture wrongly marked subsidiary?

Any brand mistaken for legal entity?

Any domain assigned wrong owner?

Leadership current?

Locations correct?

sameAs only true identity?

Parent relationship supported?

Effective dates?

Public/private fields separated?

Structured data matches visible content?

Run quarterly or after corporate event.

High-change groups need more frequent.

AI Query Test

“Companies under Group X.”

“Who owns Subsidiary Y?”

“Is Brand Z part of Group X?”

“Who is CEO Subsidiary Y?”

“What products does Brand Z offer?”

“Is Company A still part of Group X?”

Repeat across models.

Measure:

Correct hierarchy.

False merge.

False split.

Outdated ownership.

Wrong leadership.

Citation source.

Again, this is observation.

Don't claim graph caused answer.

Track before/after cleanup.

Group Website Bukan Satu Super-Entity

A group is a network.

Trying to compress everything into one Organization node loses meaning.

But creating hundreds of isolated Organization nodes without parent relations loses network.

Knowledge graph solves by keeping both:

Identity.

Relationship.

Every node independent enough to be correct.

Connected enough to show structure.

That is the goal.

Human Visitor Should Understand Structure without Opening Source Code

If public graph only exists in JSON-LD and visible website says nothing, weak UX.

A procurement officer should see:

“Company A is a subsidiary of Group B.”

A job candidate should know whether applying to parent or child.

A customer should know brand operator.

An investor should see structure.

Public truth should be visible.

Structured data mirrors.

Not hides.

Grup Perusahaan adalah Tempat Knowledge Graph Benar-benar Punya Nilai

Because the problem is relational by nature.

Who owns whom.

Who operates what.

Which brand belongs where.

Which person leads which entity.

Which company is current.

Which relationship is historical.

A flat sitemap cannot express all of that elegantly.

A governed graph can.

But only if legal reality, temporal reality, and public disclosure rules are respected.

Otherwise graph looks impressive and quietly publishes the wrong corporate structure.

For groups and subsidiaries, semantic precision is not an SEO luxury.

It is basic corporate truth.