PersonGroup
RIXML 2.5 Element
Optional container element for specifying research product authors within an organization. Level One excludes ContactInfo child elements. Can be omitted entirely when no author tagging is needed.
The PersonGroup element is used to hold the name(s) of the individual person(s) and/or the name of the group. In the case of an individual person, the person tag and its associated personID are used (no personGroupID or description is needed). PersonGroups can be formally organized groups or they can be fluid groups that come together to deliver content. If the "group" consists of only one person, there is no need to define a group ID and description; it is sufficient to have the 'person' tag and the associated personID under the 'group' tag.
Usage
Optional element within Organization, appearing at most once. When present, must contain at least one PersonGroupMember element. Omit completely when not tagging authors.
Business Context
Supports author attribution for research products, enabling proper crediting and expertise tracking for research analysts and contributors in distribution workflows.
Specification Guide
Overview
PersonGroup is a container element that organizes individuals (formally structured teams or ad-hoc collaborations) credited with creating a research product. It sits in the authorship hierarchy Organization → PersonGroup → PersonGroupMember → Person, and accommodates the full range of attribution scenarios from a single analyst to a multi-member, named research team. Group-level identity (such as 'Global Equity Research') is carried on PersonGroup itself, while individual contributors are listed via PersonGroupMember children.
Usage
PersonGroup is an optional child of Organization in RIXML 2.x, with multiple occurrences allowed so a single product can be attributed to several distinct teams (sources: user-guide-2.1 p.18, data-dictionary-2.5.1 p.27). Typical contents are one or more PersonGroupMember elements plus, in the full schema, ContactInfo for group-level contact details.
Key usage patterns:
- Single author: When the group represents one person, you can omit group-level metadata such as personGroupID and the group Name; just include the Person (with personID) inside a single PersonGroupMember (sources: user-guide-2.1 p.18, user-guide-2.2 p.18, data-dictionary-2.5.1 p.27).
- Named team: Set personGroupID and provide a group Name when the team itself is the credited author (e.g. when individuals are not separately listed) [data-dictionary-2.5.1 p.15].
- Multiple groups: Use sequence to order groups and primaryIndicator to mark the principal group; role (from RoleEnum) describes the group's function relative to the product (sources: user-guide-2.1 p.18, user-guide-2.2 p.18).
- Language variants (2.5+): Alternative-language renderings of group identity are carried via PersonGroupDetailsAlternativeLanguages [data-dictionary-2.5.1 p.27].
In the v3 draft, PersonGroup becomes a required child of a new PersonGroupList container and every Person — even a lone author — must be wrapped in a PersonGroup, making the wrapper structurally mandatory rather than optional (sources: data-dictionary-v3-draft p.34, meeting-2025-01 p.36, meeting-2025-06 p.23).
Rules
- MUSTWhen PersonGroup is present, it must contain at least one PersonGroupMember element to identify the product's authors.[RIXML Level One Addendum v2.2 p.13] [RIXML Level One Addendum v2.3 p.7] [RIXML Level One Addendum v2.5 p.7]
- MUSTGroup names should be carried in the Name child of PersonGroup, while individual names belong in PersonGroupMember → Person; groups and people must be tagged separately rather than conflated.[RIXML Research Data Dictionary v2.5.1 p.15]
- MAYWhen a PersonGroup represents a single individual, personGroupID and a group description are not required — only the Person element with its personID need be supplied.[RIXML User Guide v2.1 p.18] [RIXML User Guide v2.2 p.18] [RIXML User Guide v2.3 p.18] [RIXML Research Data Dictionary v2.5.1 p.27] [RIXML All-Member Meeting January 2025 p.37]↗
- INFORMATIVEContactInfo is not required by the Level One compliance profile inside PersonGroup; Level One implementations may omit it, though the underlying schema permits it.[RIXML Level One Addendum v2.2 p.12] [RIXML Level One Addendum v2.3 p.7] [RIXML Level One Addendum v2.3.1 p.7] [RIXML Level One Addendum v2.5 p.7]
- MUSTIn v3, every Person must be contained within a PersonGroup, even when there is only a single author, so that authorship structure is consistent across all scenarios.[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]↗
- SHOULDNames on Organization, PersonGroup and Person should support multi-language variants for international distribution (delivered via alternative-language detail elements in 2.5 and via NameList structures in v3).[RIXML Quarterly Update 2013 Q1 p.2]↗ [RIXML All-Member Meeting June 2023 p.27]↗
Relationships
- child-ofOrganization — PersonGroup is an optional, repeatable child of Organization within the Source package, scoping the group to the publishing organization.
- requiresPersonGroupMember — When present, PersonGroup must contain at least one PersonGroupMember; each member wraps an individual Person.
- containsContactInfo — PersonGroup may contain ContactInfo to provide group-level contact channels in the full schema; the Level One profile does not require this child.
- containsPersonGroupDetailsAlternativeLanguages — From 2.5, PersonGroup can carry PersonGroupDetailsAlternativeLanguages to expose group identity in additional languages.
- wrapsPerson — Every Person must be reached via a PersonGroup wrapper; in v3 this is mandatory even for a sole author.
- qualified-byPersonGroup.primaryIndicator — primaryIndicator designates which PersonGroup is principal when multiple groups are listed.
- qualified-byPersonGroup.sequence — sequence establishes display order across multiple PersonGroup instances on the same product.
- qualified-byPersonGroup.role — role (values from RoleEnum) specifies the function of the group relative to the research product.
- qualified-byPersonGroup.personGroupID — personGroupID uniquely identifies a formally named group; it is unnecessary for single-person groups.
Where It Fits
Canonical Path
Definition
| Type | |
| Namespace | http://www.rixml.org/2017/9/RIXML |
| Min Occurs | 1 |
| Max Occurs | 1 |
Attributes
personGroupIDstring |
Some unique label used to reference a particular group of people. optionalSince 2.1 |
sequenceinteger |
Used to indicate any meaningful ordering of the Products contained in this Research item. Particularly useful in publishing compendium products made up of multiple sub-products. Ordering is ascending. optionalSince 2.1 |
primaryIndicatorYesNoEnum |
Indicates the primary PersonGroup, when more than one are specified. optionalSince 2.1 |
roleRoleEnum |
The role of the group relative to this research item. This is especially useful if only the group is specified without any members or if all members share the same role -- as in a group of document authors or meeting attendees. optionalSince 2.1 |
Children
Namestring0..1 |
Indicates the name of the group. This is not required, but can be used where groups are formally named or if there is a name created for the group involved with a publication or event. optionalSince 2.1 |
PublisherDefinedValuestring0..1 |
If the role attribute has the value PublisherDefined, this element is used to hold the publisher's own description of the role. optionalSince 2.1 |
PersonGroupMember(complex)0..unbounded |
optionalSince 2.1 |
ContactInfoContactInfoType0..unbounded |
optionalSince 2.1 |
PersonGroupDetailsAlternativeLanguages(complex)0..1 |
optionalSince 2.5 |
Example
<PersonGroup />Version History
PersonGroupDetailsAlternativeLanguages2.1–2.3.1: PersonGroup is an optional, repeatable child of Organization with attributes personGroupID, sequence, primaryIndicator and role; children are PersonGroupMember and ContactInfo (sources: user-guide-2.1 p.18, user-guide-2.2 p.18, user-guide-2.3.1 p.17). Across these releases the Level One compliance profile treats ContactInfo inside PersonGroup as not required (sources: level-one-2.2 p.12, level-one-2.3 p.7, level-one-2.3.1 p.7).
2.4: Substantively unchanged; documentation clarifies that single-person groups can omit group-level metadata and that PersonGroup supports both formal teams and ad-hoc collaborations [data-dictionary-2.4 p.27]. Globalisation feedback in 2013 flagged PersonGroup name values as a future target for multi-language support [quarterly-2013-q1 p.2].
2.5 / 2.5.1: Adds PersonGroupDetailsAlternativeLanguages as a child so group identity can be expressed in multiple languages [data-dictionary-2.5.1 p.27]. The 'group name vs individual name' separation between PersonGroup.Name and PersonGroupMember.Person is explicitly emphasised [data-dictionary-2.5.1 p.15].
v3 (draft): PersonGroup becomes a required child of a new PersonGroupList container and gains a *List substructure (PersonGroupNameList, PersonGroupMemberList, ContactInfoList) [data-dictionary-v3-draft p.34]. Attributes are refined to personGroupID, sequence, isPrimary (boolean replacing the YesNo indicator), role and rolePublisherDefinedValue. Crucially, every Person — including a single author — must now be wrapped in a PersonGroup, making the wrapper structurally mandatory (sources: meeting-2025-01 p.36, meeting-2025-06 p.23). The design discussion explicitly rejected a simpler PersonList container because PersonGroup carries information about the group itself, not merely a collection of persons [data-dictionary-v3-draft p.30].
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
Level One compliance excludes ContactInfo elements inside PersonGroup
For Level One compliance, PersonGroup must contain at least one PersonGroupMember element when present
When a PersonGroup consists of only one person, there is no need to define a group ID and description; only the person tag and associated personID are sufficient
Semantic Relationships
Contrasts With1 relationship
Group names should be tagged in PersonGroup.Name while individual names should be tagged in PersonGroupMember.Person, maintaining separation between groups and individuals
RIXML Research Data Dictionary v2.5.1, p.15— Which Analysts to include in the RIXML File
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
Constrains2 relationships
When multiple PersonGroups exist, the primaryIndicator attribute determines which one takes precedence
RIXML Research Data Dictionary v2.5.1, p.28— primaryIndicator (Optional, YesNoEnum)
For Level One compliance, when PersonGroup is present, it must contain at least one PersonGroupMember element
RIXML Level One Addendum v2.5, p.7— Research.Product.Source.Organization.PersonGroupMember
Broadens1 relationship
The PersonGroup role attribute is particularly valuable when all members share the same role or when only the group is specified without individual members
RIXML Research Data Dictionary v2.5.1, p.28— primaryIndicator (Optional, YesNoEnum)
Qualifies1 relationship
PersonGroupMember primaryIndicator identifies which individual member has primary status within a group, allowing multiple primary members per group
RIXML Research Data Dictionary v2.5.1, p.29— Elements and Attributes: