Predicate Proposal - Email address

Value statement: Email addresses provide relevant contact information for an entity.

Definition: “The email address associated with this entity that is 1. public (it is openly known the entity is associated with this email address) and 2. official (the entity has formally associated themselves with this phone number by posting it on a website, social media link, etc. that they are in control of)”.

Tooltip definition of the predicate: “The public and official email address associated with this entity”

Type of value: String

For enums - all possible values: N/A

# of accepted values: multiple - i.e. some entities will maintain multiple primary email accounts, i.e. a company may have a customerservice@[companyname].com, legal@[companyname].com, etc.

Estimated frequency of new values or changes: Emails are changed very infrequently, by either a company/organization or a person. Companies/organizations may introduce a new email on average once every 2-3 years.

Inverse Properties and Name: N/A

Also known as: e-mail address

Estimated cardinality of this predicate:

  • ~5 billion emails for entities that would reasonably be in Golden’s graph
    • Assume 1 billion people will be in Golden’s graph. Assume a person has, on average, 2 emails associated with them (virtually every person has an email address, with many having more than one)
    • Assume 1 billion companies/organizations will be in Golden’s graph. Assume a company/organization has, on average, 3 emails associated with it (large companies/organizations may have multiple emails)

Examples of proper use:

Examples of improper use:

  • Justin Bieber’ ‘email address’ is ‘’, where ‘’ is not a publicly disclosed email address
  • Justin Bieber’ ‘email address’ is ‘’, where ‘’ is not an account that Justin Bieber is known to control, but rather is a fan account set up by his community of fans

Usage in other schemas:

Constraints: Should only be applied to

  • companies/organizations
  • people

Masculine/Feminine Form: N/A

Restrictions (ie PII concerns): there may be PII concerns associated with an email address. Seems best to handle this as a one off - i.e. remove the value only if someone requests that it be removed, which is complicated but possible once this data is stored in IPFS.

  • Suggested applicable templates on company, organization, port, laboratory, educational institution, person

Very minor question here. We say only companies/organizations/people here, but in "Suggested applicable templates below we say: “company, organization, port, laboratory, educational institution, person”

Do we want to expand the constraints to include port, laboratory, educational institution?

1 Like

I would agree we should later.

In that constraints section I’m just referring to templates we have defined in the dapp’s schema. i.e. we can’t add ‘port’ as a possible ‘is a’ value ‘email address’ can be applied to when we only have the ‘port’ template defined on