Person
RIXML 2.5 Element
Represents individual product author with required personID attribute containing UUID value. Level One excludes ContactInfo child elements. UUID differs from organization and product identifiers.
Usage
Required element within PersonGroupMember, appearing exactly once. Must have personID attribute with UUID value unique to the person. Contains name elements.
Business Context
Provides precise individual identification for research authors, enabling author tracking, expertise mapping, and proper attribution across research distribution networks.
Specification Guide
Overview
The Person element represents an individual contributor to a research product — typically an analyst, author or other named participant — and carries that individual's identifier, name components, professional details and (outside Level One) contact information. It is the atomic unit of authorship attribution in RIXML, sitting beneath PersonGroupMember within PersonGroup under Organization in the Source sub-tree. Its role is to enable consistent identification, crediting and follow-up communication with the humans behind a research product across publishers, vendors and downstream platforms (sources: data-dictionary-2.4 p.29, user-guide-2.3 p.18, data-dictionary-2.5.1 p.31).
Usage
Person appears as a required child of PersonGroupMember and must occur exactly once per member (sources: level-one-2.5 p.8, level-one-2.3 p.8). At minimum it carries a personID attribute and a FamilyName child; GivenName, MiddleName and especially DisplayName are strongly recommended for proper presentation (sources: user-guide-2.3 p.18, data-dictionary-2.5.1 p.31). Optional content varies by version but in 2.4/2.5 typically includes job-related fields (JobTitle, Division, JobRole), credentials and name suffixes, biographical content (Biography/BiographyFormatted), a photo reference, one or more ContactInfo elements, and one or more PersonLabel elements carrying vendor- or platform-specific identifier codes (sources: data-dictionary-2.4 p.29, data-dictionary-2.5.1 p.31, quarterly-2012-q2 p.3). Only individuals who directly contributed to the research content should be included; support staff such as research assistants or editors should be omitted (sources: data-dictionary-2.4 p.15, data-dictionary-2.5.1 p.15). Group or team identities belong in PersonGroup rather than Person — the two are tagged separately [data-dictionary-2.5.1 p.15]. For multi-language presentation in v2.5, use PersonDetailsAlternativeLanguages to provide localised name variants alongside the primary PersonDetails [data-dictionary-2.5.1 p.31]. In the v3.0 draft this is being restructured so that language variants live directly inside the Person aggregation rather than in a separate alternative-languages container (sources: meeting-2023-06 p.28, meeting-2025-01 p.35).
Rules
- MUSTEach PersonGroupMember must contain exactly one Person element.[RIXML Level One Addendum v2.5 p.8] [RIXML Level One Addendum v2.3 p.8] [RIXML Level One Addendum v2.3.1 p.8] [RIXML Level One Addendum v2.2 p.13]
- MUSTPerson must carry a personID attribute that uniquely identifies the individual within the publisher's scope.[RIXML User Guide v2.1 p.19] [RIXML User Guide v2.2 p.18] [RIXML User Guide v2.3 p.18] [RIXML Research Data Dictionary v2.5.1 p.31]
- MUSTFor Level One compliance, personID must contain a UUID value, distinct from organization, research, product and resource identifiers.[RIXML Level One Addendum v2.2 p.13] [RIXML Level One Addendum v2.3 p.8] [RIXML Level One Addendum v2.3.1 p.8] [RIXML Level One Addendum v2.5 p.8]
- MUSTPerson must contain exactly one FamilyName child element.[RIXML Level One Addendum v2.5 p.8] [RIXML Level One Addendum v2.3.1 p.8] [RIXML User Guide v2.2 p.18] [RIXML Research Data Dictionary v2.5.1 p.31]
- SHOULDDisplayName should be supplied to control how the publisher or person wants their name presented.[RIXML User Guide v2.1 p.19] [RIXML User Guide v2.3 p.19] [RIXML Research Data Dictionary v2.5.1 p.31]
- SHOULDOnly individuals who directly contributed to the research content should be included in Person; support roles such as research assistants and editors should be omitted.[RIXML Research Data Dictionary v2.4 p.15] [RIXML Research Data Dictionary v2.5.1 p.15]
- MUSTGroup or team names belong in PersonGroup (via its Name element), while individual names belong in Person under PersonGroupMember — the two must not be mixed.[RIXML Research Data Dictionary v2.5.1 p.15]
- INFORMATIVEContactInfo children of Person are not required by Level One; Level One implementations typically omit them, though they may appear under fuller compliance levels.[RIXML Level One Addendum v2.5 p.8] [RIXML Level One Addendum v2.3 p.8] [RIXML Level One Addendum v2.3.1 p.8]
- SHOULDAuthor contact details (such as phone and email via ContactInfo) should be supplied so that vendors can identify authors using unique contact information rather than relying on synchronised vendor code systems.[Best Practices for Publishing RIXML p.10]
- INFORMATIVEMulti-language name support for Person (alongside PersonGroup, Organization, Title, Synopsis and Abstract) was introduced in RIXML v2.5 to enable localised analyst identification.[RIXML Quarterly Update 2017 Q2 p.8]↗ [RIXML Quarterly Update 2017 Q3 p.8]↗
- MUSTIn the v3.0 draft, every Person must be contained within a PersonGroup element, even when there is only a single author.[RIXML Research Suite Data Dictionary v3.0 (DRAFT) p.33]↗ [RIXML All-Member Meeting January 2025 p.36]↗ [RIXML All-Member Meeting June 2025 p.23]↗
- SHOULDIn v3.0, full person information (name and unique ID) should be provided in the Person element itself, with downstream component references using only the ID rather than re-stating author details.[RIXML Research Suite Data Dictionary v3.0 (DRAFT) p.81]↗
Relationships
- contained-byPersonGroupMember — Person is a required child of PersonGroupMember and appears exactly once per member.
- contained-byPersonGroup — In v3.0, Person must be nested within a PersonGroup even for single-author research, preserving a uniform authorship structure.
- requiresFamilyName — Person must contain exactly one FamilyName child.
- qualifiesDisplayName — DisplayName indicates how the person's name should be presented and is strongly recommended.
- qualifiesContactInfo — ContactInfo provides communication endpoints (phone, email, etc.) for the individual; multiple instances may appear, although Level One does not require them inside Person.
- qualifiesPersonLabel — PersonLabel supplies vendor-specific or external identifier codes that supplement the publisher's personID for cross-platform identification.
- qualifiesPersonDetailsAlternativeLanguages — In v2.5, PersonDetailsAlternativeLanguages carries localised name and detail variants for a Person; in v3.0 this is folded back into the Person aggregation itself.
- referencesResource — In v3.0 the optional PhotoResourceIdRef inside Person is an XML keyref to a Resource holding the person's photograph; the referenced resource's resourceID must match.
- qualifiesStatusInfo — In roster-update payloads, StatusInfo expresses the operational state of an individual Person record (e.g. added, removed, modified).
- contrasts-withPersonGroup — Person represents an individual; PersonGroup represents a team or collective. The two are tagged separately and group names belong in PersonGroup rather than Person.
Where It Fits
Canonical Path
Definition
| Type | PersonType |
| Namespace | http://www.rixml.org/2017/9/RIXML |
| Min Occurs | 1 |
| Max Occurs | 1 |
Attributes
personIDstring |
An identifier used to identify the person. For accurate identification it is required that the personID be unique for a given publisher, but the implementation of the ID is left to the publishers to implement as they deem fit. Examples: combination of LastName and FirstName, combination of internal employee ID and RIXML publisher ID. requiredSince 2.1 |
Children
JobRolestring0..1 |
Indicates the functional role played by the person relative to his/her job in the organization, for example, analyst, strategist, economist, etc. optionalSince 2.1 |
FamilyNamestring1..1 |
Indicates the family name of the person. requiredSince 2.1 |
GivenNamestring0..1 |
Indicates the given name of the person. optionalSince 2.1 |
MiddleNamestring0..1 |
Indicates the middle name of the person. optionalSince 2.1 |
DisplayNamestring0..1 |
Strongly Recommended. Indicates how the publisher or person wants the name to be presented, for example: Dr. John Doe Sr. CPA, CFA. optionalSince 2.1 |
JobTitlestring0..1 |
Indicates the official title of the person within an organization -- e.g. Managing Director, Vice President, etc. optionalSince 2.1 |
Divisionstring0..1 |
Indicates the division that the person officially works for within an organization. optionalSince 2.1 |
FamilyNameSuffixstring0..1 |
An accommodation for family name modifiers traditionally appearing after the person's name -- e.g. Jr., Sr., III.. optionalSince 2.4 |
Credentialsstring0..1 |
An accommodation for credentials traditionally appearing after the person's name -- e.g. C.F.A., Ph.D., Esq.. optionalSince 2.4 |
Biographystring0..1 |
Biographical information about the person. No markup permitted. optionalSince 2.4 |
BiographyFormattedstring0..1 |
Biographical information about the person. Limited markup permitted - HTML code for paragraph, ordered lists and unordered lists with list items, bold, underline, and italics. optionalSince 2.4 |
PhotoResourceIdRefstring0..1 |
An XML Schema keyref that will link to a Resource element representing a small photograph image of the person. Value must match a Resource.resourceID in this Product. optionalSince 2.4 |
ContactInfoContactInfoType0..unbounded |
optionalSince 2.1 |
PersonLabelstring0..unbounded |
optionalSince 2.3 |
PersonDetailsAlternativeLanguages(complex)0..1 |
optionalSince 2.5 |
Example
<Person personID="example">
<FamilyName> ... </FamilyName>
</Person>Version History
PersonLabelFamilyNameSuffix, Credentials, Biography, BiographyFormatted, PhotoResourceIdRefPersonDetailsAlternativeLanguagesv2.1–2.3: Person is established as a required child of PersonGroupMember with mandatory personID and FamilyName, plus optional GivenName, MiddleName, DisplayName, JobTitle, Division, JobRole, and one or more ContactInfo elements (sources: user-guide-2.1 p.19, user-guide-2.2 p.18, user-guide-2.3 p.18). PersonLabel for vendor-specific codes is documented in 2.3 [release-notes-2.3 p.4]. Level One profiles (2.2, 2.3, 2.3.1, 2.5): Level One narrows Person to a UUID-valued personID plus name elements; ContactInfo is not required by Level One (sources: level-one-2.2 p.13, level-one-2.3 p.8, level-one-2.3.1 p.8, level-one-2.5 p.8). v2.4: Person is significantly enriched with photo references, expanded title and sub-title structures, biographical content (Biography, BiographyFormatted), professional credentials and name-suffix handling [quarterly-2012-q2 p.3]. Globalisation of name values is identified as a future direction [quarterly-2013-q1 p.2]. v2.5: Multi-language support for Person names (and team names via PersonGroup) is formally added, alongside multi-language Organization names, Titles, Synopsis and Abstract; in 2.5.1 this is exposed through PersonDetailsAlternativeLanguages (sources: quarterly-2017-q2 p.8, quarterly-2017-q3 p.8, data-dictionary-2.5.1 p.31). v3.0 (draft): The element is restructured around aggregations — PersonID, PersonDetailsList, ContactInfoList, PersonLabelList — with an optional PhotoResourceIdRef keyref to Resource [data-dictionary-v3-draft p.30]. The separate PersonDetailsAlternativeLanguages container is removed and language variants are integrated directly into Person [meeting-2025-01 p.35]. Every Person must now sit inside a PersonGroup even when the research has a single author (sources: data-dictionary-v3-draft p.33, meeting-2025-06 p.23). New optional qualifiers under discussion include PreferredPronouns [meeting-2024-06 p.28].
Business Rules
Group names should appear in the Name element within PersonGroup, while individual names should appear in PersonGroupMember.Person element, with groups and people tagged separately
For Level One compliance, personID must be a UUID and must be unique from other identifier UUIDs
Level One compliance excludes ContactInfo elements inside Person
Person element must contain exactly one FamilyName element
The personID should be used for the unique identifier used by the author's firm, while PersonLabel elements should be added as required by each aggregation vendor or distribution channel
Design Decisions
The personID attribute must be a UUID for Level One compliance
To ensure unique identification of person elements using standardized UUID format
RIXML Level One Addendum v2.5, p.8
Semantic Relationships
Qualifies1 relationship
PersonLabel elements provide vendor-specific author codes while personID serves as the firm's internal unique identifier
RIXML Research Data Dictionary v2.5.1, p.15— Author identification
Mutually Exclusive With1 relationship
For single-person groups, the Person element with personID suffices without needing a personGroupID or group description
RIXML Research Data Dictionary v2.5.1, p.27— PersonGroup
Constrains3 relationships
The personID must be unique within the scope of a given publisher organization to ensure accurate person identification
RIXML Research Data Dictionary v2.5.1, p.31— personID (Required, String)
The PersonGroupMember element must contain exactly one Person element
RIXML Level One Addendum v2.5, p.8— Research.Product.Source.Organization.PersonGroupMember.Person
The Person element must contain exactly one FamilyName element
RIXML Level One Addendum v2.5, p.8— Research.Product.Source.Organization.PersonGroupMember.Person.FamilyName
Contrasts With3 relationships
The UUID for OrganizationID will not be the same as the one used for personID
RIXML Level One Addendum v2.5, p.7— Research.Product.Source.Organization.OrganizationID
The UUID for personID will not be the same as the one used for OrganizationID
RIXML Level One Addendum v2.5, p.8— Research.Product.Source.Organization.PersonGroupMember.Person
The UUID for personID will not be the same as the one used for resourceID
RIXML Level One Addendum v2.5, p.8— Research.Product.Source.Organization.PersonGroupMember.Person