Please note that this documentation is in draft and is not finalised.
We would encourage you provide any comments, questions, or suggestions for changes by use in-line commenting on this page. To do so simply highlight a section of text and then click on the "Comment" option that appears.
Person is one of the top-level entities in Tennis Open Data Standards - this section will introduce its key features and help you to create a message to transfer details about a person.
1. What is a Person?
The Person entity is used to represent any individual involved in tennis. This is most often a player but can also be a coach, a parent, an umpire, an organiser, an officer in a national association - anyone with a role in tennis. Sources can use a Person entity to keep a single reference to a person throughout his or her tennis life - for example from junior player, through to professional player, then coach, umpire, club chairperson, and senior's circuit player. This person entity can include multiple roles, for example senior player, professional umpire and parent of a junior player.
2. Person Schema
To see a graphical representation of the data model (schema) for the Person entity please expand the link below:
View Person Schema Diagram
3. Creating a Person
The minimum information required to create a Person entity is an ID and a name (StandardFamilyName or StandardGivenName, both where available).
In PersonID you must supply your unique identifier for the Person.
The value of PersonID must be unique within your data. To make IDs unique globally TODS uses a URN-style system, so the full globally unique tournament ID is:
When you’re exchanging information with a client or supplier it is very likely that you both have an id for the Person. To make exchange easier TODS allows for any number of additional IDs to be included with Person. See ‘Including Multiple Identifiers
’ for more information.
Where it is known we strongly recommend using the Tennis ID as the globally unique ID for any player or other person. This can be provided by the ITF for any individual and is the easiest way to ensure that a single unique record for a person is maintained across multiple systems and sources.
5. Person Names
TODS allows for different forms or representations of names for a Person providing flexibility for use of across different languages.
NativeGivenName/Native: the name written in the local language script of source/client (as agreed between parties).
StandardGivenName/StandardFamilyName: the name, in Latin script, that the person is usually known by. For example Andy Murray rather than Andrew Murray. This will usually be a translation or transliteration of the Native Name.
PassportGivenName/PassportFamilyName: the person's name in ASCII characters (A-Z only), as shown in the person's passport. This form of the name is commonly used to aid deduplication of records across different databases and data systems.
For more information on use of names see Transliteration of Names to Latin Script
6. Adding more information
Once the minimum information has been supplied you can add additional information if it is available or as it becomes available. There are attributes for key information like date of birth, gender, nationality.
There are attributes defined for providing links to a person's social media profiles, web site and other contact information. Finally there is a section to provide more general biographical information about a person such as hobbies, interests, sporting career and so forth.
TODS defines a set of standard attributes that are widely used within tennis. If you need to supply some extra information that doesn’t fit one of the standard attributes you can use an extension. See ‘How to include additional information using Extensions’ for more information.
Go back to Tennis Open Data Standards home page.