Role: The PERSON Class captures contact information on past and current members of the zebrafish community. It can not be considered formally as a complete set of researchers relevant to the community, because new members appear continually and frequently, and because many papers are co-authored by people who are not really in the zebrafish community. Thus, for instance, not all persons (e.g. co-authors who work on other systems) listed as PUBLICATION authors occur as PERSONs
How entered: The vast majority of PERSONs are entered by DB Admin from existing contact lists maintained by the Institute of Neuroscience. New PERSON entries are also generated (if necessary) when a person submits a request for an authorization code, which is needed to enter data. Even people who are not registered submitters may appear in the PERSON list; they email a request to the DB Admin.
Security: Only the DB Admin is able to add and delete PERSON records. However, users are allowed to alter all attributes, except their name, to reflect changes in their situation.
| Superclasses: | GENERIC_OBJECT | |
| SOURCE | name, address, phone, fax, email, URL |
name (TEXT, REQUIRED). Holds the MEDLINE format of the person’s name (i.e. what you see in a MEDLINE paper author list); this is to support automated connection of new publications to existing authors.
nicknames (TEXT, OPTIONAL). Contains a semicolon separated list of alternate names for the individual. The goal is to track individuals who use a pen name, alternative spellings, or whose name has changed due to marriage or other circumstances.
bio (TEXT, OPTIONAL). Holds a person’s biographical sketch. This attribute is not filled in when the new PERSON entry is initially created; it is the responsibility of the person to connect to the database and provide this information to update his/her record. No validation.
nonZF_pubs (TEXT, OPTIONAL). A text field in which a PERSON may list other non-zebrafish publications they have produced. Though no formatting is enforced, we presume (and perhaps should recommend) that people type in semicolon-separated citations in standard MEDLINE format. Provides an essentially non-searchable place for people to list non-zebrafish publications.
publications: All PERSONs are cross-indexed to the PUBLICATIONs which they have authored. This is implemented using the “intersection table” PERSON-PUB (see section IV), which allows a PERSON’s list of publications to be constructed dynamically. No explicit list of publications needs to be maintained in a PERSON’s record.
lab: All PERSONs are cross-indexed with the LABs in which they work. This allows each PERSON to be a member of zero or more LABs. Again, this is implemented using the intersection table PERSON-LAB, so that no explicit tracking of LAB is required in the PERSON data record.
login (CHAR(8), OPTIONAL). This field contains the persons login name. It is non-NULL only if the person has been registered as an authorized submitter to the database. This field may not contain spaces or other weird characters, and is never publicly displayed.
password (CHAR(8), OPTIONAL). This field contains the current password of an authorized submitter. It is used by the system to verify authenticity of submissions. The password is assigned when the person becomes an authorized submitter and is given an “account” by the DB admin. This field is never publicly displayed.
last_submit (DATE, OPTIONAL). This field allows the system to record when the person last entered a submission into the database. This is used to track usage and purge inactive accounts after some period.
• Do we REALLY want to list the nonZF_pubs field? Could we do away with it, and just assume that people list such pubs on their personal home pages, the URL for which is part of their record? Seems like this approach would be useful from the perspective of avoiding data overload.