What Is roleName Schema?

roleName is the Schema.org property that names a role played, performed, or filled by a Person or Organization through a Role entity.

It accepts Text or URL and is used on Role, which means it is inherited by OrganizationRole, EmployeeRole, LinkRole, and PerformanceRole. Examples include Treasurer, Quarterback, Inker, Penciller, or another function that qualifies a relationship. roleName supersedes namedPosition. It does not identify the Person, Organization, job posting, or relationship by itself; those remain separate nodes and properties around the role wrapper.

• Place roleName on Role or a Role subtype.
• Use a clear Text or authoritative URL value.
• Keep participant, organization, and relationship data separate.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Primary specification: Schema.org definition for roleName.

roleName labels what a role is, while the surrounding graph explains who holds it, where, and when.

roleName is used on Role and therefore applies to Role subtypes such as OrganizationRole, EmployeeRole, LinkRole, and PerformanceRole.

It should not be attached directly to Person, Organization, JobPosting, CreativeWork, or MemberProgramTier merely because those entities have a title-like field. A Person can use jobTitle, a JobPosting can use title, and any Thing can use name. roleName is specifically for a Role wrapper that qualifies a relationship. The property adds value only when the role node itself is justified.

1. Confirm the subject is Role or a subtype.
2. Identify the relationship being qualified.
3. Choose the public role label or controlled URL.
4. Keep other entity names on their own nodes.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Use roleName inside a real role wrapper, not as a universal title field.

roleName names the function represented by a Role, while name is the general label of any Thing, including the role entity itself.

A role can technically have both, but duplicating the same text across roleName and name usually adds little. roleName communicates that the value is the function being played, such as Treasurer. The Person’s name remains on Person, and the Organization’s name remains on Organization. Avoid using roleName for a person’s identity or name for role semantics when the role-specific property is available.

• Use roleName for the function.
• Use Person.name for the role holder.
• Use Organization.name for the organization.
• Use Role.name only when the role entity needs a distinct general label.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Keeping names on their own entities prevents a role title from replacing the person or organization identity.

roleName qualifies a Role relationship, while jobTitle is a Text property directly describing a Person’s job title.

A simple current staff profile may use Person.jobTitle with worksFor and need no role wrapper. EmployeeRole plus roleName becomes useful when dates, multiple roles, salary context, or distinct employment periods matter. The two can coexist if they remain consistent, but independent sources often drift. Do not create EmployeeRole solely to duplicate jobTitle, and do not use jobTitle for a non-employment association office, team position, or alumni role.

1. Use jobTitle for a simple current Person title.
2. Use EmployeeRole and roleName for qualified employment context.
3. Use OrganizationRole for non-employment organization roles.
4. Derive overlapping labels from one authoritative source.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Choose jobTitle for a direct current label and roleName when the relationship needs a structured role context.

Use Text for ordinary human-readable role labels and URL when the role points to a stable, authoritative concept whose meaning the site intentionally reuses.

Most websites should use concise Text such as Editor, Treasurer, or Quarterback. A URL can work when an organization maintains a controlled role vocabulary or references a recognized external concept. The URL must resolve, remain stable, and unambiguously identify the role - not merely link to the person’s profile or a job page. Do not manufacture URLs for every local title or replace readable page content with opaque codes.

• Prefer clear Text for normal site roles.
• Use URL for a stable controlled concept.
• Ensure the URL identifies the role itself.
• Keep a readable visible role label on the page.
• Avoid campaign, search, and temporary URLs.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Text is the default; URL is useful only when it identifies a durable role concept rather than another entity or page.

Standardize roleName values around customer-facing, evidence-backed functions while preserving meaningful distinctions in seniority, discipline, and organizational context.

Uncontrolled templates can emit CEO, Chief Executive Officer, chief executive, Founder & CEO, and internal codes for the same role. Build a governed map of canonical display labels and aliases. Do not over-normalize distinct roles into one generic term, and do not embellish titles for search. The visible page, roleName, jobTitle where present, and authoritative staff or membership record should align.

1. Collect current role labels across systems.
2. Normalize spacing, casing, and obvious aliases.
3. Preserve materially different roles.
4. Choose a canonical customer-facing label.
5. Map legacy labels and block new unreviewed variants.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Role naming should reduce accidental variants without erasing real differences or inflating titles.

Localization should translate generic role functions where appropriate while preserving official names, canonical role identity, and the meaning of organization-specific titles.

Editor or Treasurer may have clear localized equivalents, while branded programs, legal offices, sports positions, and professional designations may require careful treatment. Do not create a new role entity solely because the label is translated. Reuse canonical Person, Organization, and role identities, and vary the visible Text by locale only when the translation remains accurate. Controlled URL values can provide one cross-language concept while the page shows a localized label.

• Reuse canonical role identity across locales.
• Translate generic functions accurately.
• Preserve official or branded role names where required.
• Avoid machine translation without domain review.
• Audit locale-specific template fallbacks.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Localized labels can vary, but the underlying role relationship and identity should remain consistent.

Migrate from the superseded namedPosition property to roleName by preserving verified values, updating all emitters, testing consumers, and removing legacy output after a controlled transition.

Search templates, serializers, stored content, microdata, RDFa, JSON-LD, feeds, and emails. During a brief coexistence window, derive both properties from one authoritative role source so they cannot disagree. Do not migrate bad internal codes or stale titles blindly; normalize and verify the role first. Once consumers read roleName and rendered variants pass, remove namedPosition and add a regression guard against its return.

1. Inventory every namedPosition emitter.
2. Classify and normalize existing values.
3. Emit roleName from the authoritative source.
4. Test all templates and downstream consumers.
5. Remove namedPosition after verified transition.
6. Add a regression check.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

A safe migration changes the property and improves the role vocabulary without changing the underlying relationship.