The individualName field contains subfields so that a person's name can be broken down into parts.

Note that the the content model for the containing type allows a sequence of choices for the first element(s): <individualName>, <organizationName> and/or <positionName>. This means that a parent element (e.g., creator) may use combinations of the 3 sub-elements to make up a single logical party. For example, a creator with only the individualName of 'Joe Smith' is NOT the same as a creator with the individualName of 'Joe Smith' and the organizationName of 'NSF'. To include both a positionName and an organizationName as children of a <contact> implies that anyone currently occupying that positionName at that organizationName is an appropriate contact. The positionName should not be used in conjunction with individualName unless only that specific individual at that position would be considered appropriate for that designation.

Example(s):
Because this is an 'elementOnly' field, please look at the examples for the subfields 'givenName' and 'surName'.

The responsible party field contains the full name of the organization that is associated with the resource. This field is intended to describe which institution or overall organization is associated with the resource being described.

Note that the the content model for the containing type allows a sequence of choices for the first element(s): <individualName>, <organizationName> and/or <positionName>. This means that a parent element (e.g., creator) may use combinations of the 3 sub-elements to make up a single logical party. For example, a creator with only the individualName of 'Joe Smith' is NOT the same as a creator with the individualName of 'Joe Smith' and the organizationName of 'NSF'. To include both a positionName and an organizationName as children of a <contact> implies that anyone currently occupying that positionName at that organizationName is an appropriate contact. The positionName should not be used in conjunction with individualName unless only that specific individual at that position would be considered appropriate for that designation.

Example(s):
National Center for Ecological Analysis and Synthesis

This field is intended to be used instead of a particular person or full organization name. If the associated person who holds the role changes frequently, then Position Name would be used for consistency.

Note that the the content model for the containing type allows a sequence of choices for the first element(s): <individualName>, <organizationName> and/or <positionName>. This means that a parent element (e.g., creator) may use combinations of the 3 sub-elements to make up a single logical party. For example, a creator with only the individualName of 'Joe Smith' is NOT the same as a creator with the individualName of 'Joe Smith' and the organizationName of 'NSF'. To include both a positionName and an organizationName as children of a <contact> implies that anyone currently occupying that positionName at that organizationName is an appropriate contact. The positionName should not be used in conjunction with individualName unless only that specific individual at that position would be considered appropriate for that designation.

Example(s):
Niwot Ridge Data Manager

The address field is a container for multiple subfields that describe the physical or electronic address of the responsible party for a resource.
Example(s):
Please see the subfield examples.

The phone field describes information about the responsible party's telephone, be it a voice phone, fax, or TTD/TTY type telephone. This field contains an attribute used to identify the type.
Example(s):
805-555-2500

The electronic mail address is the email address for the party. It is intended to be an Internet SMTP email address, which should consist of a username followed by the @ symbol, followed by the email server domain name address. Other address types are allowable.
Example(s):
my-email@mydomain.edu

A link to associated online information, usually a web site. When the party represents an organization, this is the URL to a website or other online information about the organization. If the party is an individual, it might be their personal web site or other related online information about the party.
Example(s):
http://www.yourdomain.edu/~doe

An identifier that links this party to a directory of personnel. Although specific contact information for a party might change, the underlying correspondence to a real individual does not. This identifier provides a pointer within a personnel directory that may contain further, and possibly more current, information about the party.
Example(s):
uid=jtown,o=NCEAS,dc=ecoinformatics,dc=org

The salutation field is used in addressing an individual with a particular title, such as Dr., Ms., Mrs., Mr., etc.
Example(s):
Dr.

The given name field can be used for first name of the individual associated with the resource, or for any other names that are not intended to be alphabetized, (as appropriate). Note that while it is possible to include all given names in one field (as in the example below), it may be not be good practice to do so. For example, if an XSL transformation stylesheet were to abbreviate the content of a givenName to just the first initial, a givenName element that contained more than one name would not be transformed correctly.
Example(s):
Juan Luis
Jane

The surname field is used for the last name of the individual associated with the resource. This is typically the family name of an individual, for example, the name by which s/he is referred to in citations.
Example(s):
San Gil
Curtis-Ainsworth
Tao

The delivery point field is used for the physical address for postal communication. This field is used to accommodate the many different international conventions that are the equivalent to a U.S. 'street address'.
Example(s):
7209 Coast Drive, Building 44

The city field is used for the city name of the contact associated with a particular resource.
Example(s):
San Francisco

The administrative area field is the equivalent of a 'state' in the U.S., or Province in Canada. This field is intended to accommodate the many types of international administrative areas.
Example(s):
Colorado

The postal code is equivalent to a U.S. zip code, or the number used for routing to an international address. The U.S. postal code should include the 5 digit code plus the 4 digit extension.
Example(s):
93106-2231

The country field is used for the name of the contact's country.
Example(s):
U.S.A.

The responsible party contains multiple subfields that are used to describe a person, organization, or position within an organization. It is intended to be used to fully document contact information for many types of associations, such as owner, manager, steward, curator, etc.

Type: xs:string

Use: optional

Default value: voice

This attribute gives the type of phone to which this number applies. By default, this is assumed to be of type "voice", but other possibilities include "facsimile" and "tdd".

Type: xs:string

Use: required

This attribute names the directory system to which this userId applies. This will generally be a URL that shows how to look up information, for example an LDAP url. However, it could also be a non-parsable description of the directory system if that is all that is available.
Example(s):
ldap:///ldap.ecoinformatics.org/dc=ecoinformatics,dc=org

Type: res:IDType

Use: optional

Type: res:SystemType

Use: optional

Type: res:ScopeType

Use: optional

Default value: document

Type: res:IDType

Use: optional

Type: res:SystemType

Use: optional

Type: res:ScopeType

Use: optional

Default value: document

The ResponsibleParty Type contains elements that are used to describe the person, organization or position within an organization that is associated in some way with the resource. It is intended to be used to fully document contact information for many types of associations, such as owner, manager, steward, curator, etc.

Note that the content model for a responsible party type allows a sequence of choices for the first element(s): <individualName>, <organizationName> and/or <positionName>. This means that a parent element (e.g., creator) may use combinations of the 3 sub-elements to make up a single logical party. For example, a creator with only the individualName of 'Joe Smith' is NOT the same as a creator with the individualName of 'Joe Smith' and the organizationName of 'NSF'. To include both a positionName and an organizationName as children of a <contact> implies that anyone currently occupying that positionName at that organizationName is an appropriate contact. The positionName should not be used in conjunction with individualName unless only that specific individual at that position would be considered appropriate for that designation.

Example(s):
Please see the examples for the particular subfields.

The person Type is used to enter the salutation, and two types of name parts for an individual associated with the resource. It uses these three subfields to help parse the person's entire name.

The two elements, <givenName> and <surName>, allow parsing of many types of names, even though distinct elements do not exist for concepts like "middle name" and "compound surname". <givenName> should be used for parts of the name that are often shortened to a first initial, or are not used for ordering, and typically includes first and middle names. The <surName> field is intended to be used for the part of the name that is generally displayed in its entirety and/or is alphabetized or otherwise ordered when appropriate. Note that only one <surName> is allowed, and is required, while <givenName>s are optional and unbounded.

The arrangement and content of the sub-elements is entirely up to the EML document's author, who presumably has first-hand knowledge of how the names are to be constructed. For example, if element position is important (e.g., the list of a book's authors), then EML authors should put the creators in that order. If it is appropriate for a resource to have its creators sorted alphabetically, then the EML author should construct the name parts so that the<surName> field may be used for this purpose. At this time, EML is not able to express cultural conventions so that authors may indicate the correct order for <givenName>s and <surName> when the whole name is expressed. However support for international names is under consideration for a future version of EML, along with other internationalization features.

Example(s):
Please see the examples within each subfield.

The address field is provides detailed information for communicating with a party contact via electronic mail or postal mail, including the physical delivery location.
Example(s):
Please see the examples for each subfield

The role code field provides information on how a person or organization is related to a resource. There may be many people associated, including an 'originator' of a dataset, an 'author', 'editor', or 'publisher' of a literature resource, or an organization that is a 'distributor'. the full list of choices is included in the example.
Example(s):
author, contentProvider, custodianSteward, distributor, editor, metadataProvider, originator, pointOfContact, principalInvestigator, processor, publisher, or user.