Name components (e.g. family name and given name) have been split into another document.

1. Use cases & requirements

The Person class should have properties for:

  1. name

    Mr. John Q. Public, Esq.

  2. alternate names

    To find a person by a pseudonym or nickname, e.g. “Mark Twain” for Samuel Clemens.

  3. former names

    If a councillor changes name, earlier council transcripts should continue to use the former name.

  4. identifiers

    Eric Cantor has the THOMAS identifier 01674.

  5. preferred email address

    To contact a representative via email.

  6. gender

    To determine personal pronouns, e.g. “John Doe will be at his constituency office next week.”

  7. date of birth

    To provide biographical detail, or to report a person’s age.

  8. date of death

    To determine whether a person is alive or dead, e.g. in order to disable the deceased’s contact form.

  9. head shot

    To identify the person visually.

  10. one-line biography

    To provide a brief biography.

  11. biography

    To provide a long form biography.

  12. national identity

    Nine members of the House of Peoples shall comprise a quorum, provided that at least three Bosniak, three Croat, and three Serb delegates are present.

  13. the means of contacting the person

    1 Main Street
    Anytown, USA

  14. external links

    A representative’s Wikipedia page or official website.

2. Standard reuse

Briefly, the survey of existing specifications concludes that:

  • Only person:Person fits the data specification’s definition of a person.
  • person:birthName and PersonMaidenName are the only properties for former names.
  • Only facebook:bio describes biographies without importing the BIO vocabulary.

With respect to the choice of terms:

  • Many specifications use the same terms, including FOAF, and RFC 6350 (vCard 4.0). FOAF and terms are reused, given their breadth of adoption.
  • dcterms:alternative can be used for alternate names; vCard 4.0 instead can set a PREF parameter on names, to make one name preferred.
  • foaf:nick is frequently used for abbreviations, including IRC nicknames, and is therefore used for issued identifiers.

3. Classes and properties

Term Mapping Definition
Person person:Person A real person, alive or dead
name foaf:name A person's preferred full name
alternate name dcterms:alternative An alternate name, such as a pseudonym
former name opengov:otherName A former name, such as a maiden name
identifier foaf:nick An issued identifier, e.g. a Library of Congress Name Authority File number
email address1 schema:email2 A preferred email address
gender foaf:gender A gender
date of birth schema:birthDate3 A date of birth
date of death schema:deathDate A date of death
head shot schema:image4 A URL of a head shot
one-line biography bio:olb A one-line account of a person's life
biography bio:biography An extended account of a person's life
national identity opengov:nationalIdentity A national identity
contact detail opengov:contactDetail A means of contacting the person
external links rdfs:seeAlso A URL to a document about the person

1. Add additional email addresses as contact details, using the ContactDetail class.

2. schema:email is used instead of foaf:mbox, because email is a more familiar term than mbox.

3. schema:birthDate is used instead of foaf:birthday to match schema:deathDate, for which FOAF has no property.

4. schema:image is used instead of foaf:img, because abbreviations like img are avoided.

4. Serialization

JSON differences from other RDF serializations:

  • The former name and alternate name properties are serialized as a single other_names property, whose value is an array of name objects.
  • The term identifiers is used instead of nick and is serialized as an array of identifier objects.
  • The term summary5 is used instead of olb, because abbreviations are avoided.
  • The term links is used instead of seeAlso and is serialized as an array of link objects.

5. With respect to reuse, Drupal uses the term summary to describe a brief version of a long text.

5. Code lists


The following is a subset of vCard 4.0’s code list. Implementations may use values from outside this list to reflect the diversity of gender identities.

  • male
  • female