Role: The purpose of the Phys_Structure class is to implement a flexible, extensible mechanism for describing the hierarchical structural relationships among the various anatomical parts of the zebrafish. In conjunction with the PART catalog, this data structure provides the basis for implementing vital functions including:
• Enforcing uniform terminology when identifying anatomical structures visible in an image.
• Constructing and displaying dynamic graphical representations (e.g. a tree) of the anatomical structure as a means for users to specify in what area of the fish they are interested, to identify anatomical parts, or to access other interface-related functions.
The approach to implementing the PHYS_STRUCTURE class is somewhat abstract. Each member of the class defines a single structural relationship between two PARTs. For example, the brain consists of a forebrain, a midbrain, and a hindbrain. This relationship is represented in the following four instances of the Phys_Structure class:
| Container | Containee | ||
| nervous system | brain | ||
| brain | forebrain | ||
| brain | midbrain | ||
| brain | hindbrain |
The primary advantage of this approach is that no hard-wired connections between various parts exist; it is relatively easy to revise the anatomical atlas to reflect newly identified structures or to subdivide existing structures into finer grained components. It is anticipated that many such modifications to the agreed-upon taxonomy will be made in coming years by zebrafish researchers. A disadvantage is that a larger number of queries will be required to extract the overall hierarchical structure of the organism.
How/Who enters: All records in the PHYS_STRUCTURE catalog are entered and maintained exclusively by the DB Admin. Presumably modifications are made only after reaching a consensus among members of the zebrafish research community. It is assumed that the basic anatomical taxonomy has initially been developed through the collaborative efforts of zebrafish researchers.
Security: Security issues are minimal, because only the DB Admin is able to add or edit records.
| Superclasses: | GENERIC_OBJECT |
Container (PART, REQUIRED). This field contains the name of a superpart, the part that contains the containee. Allowed values are any PART listed in the PART catalog.
Containee (PART, REQUIRED). This field contains the name of a subpart, the part that is contained by the part specified in the container. Allowed values are any PART listed in the PART catalog.
Number (integer, REQUIRED). This field specifies how many of the containee parts exist in the container part. For example, this would specify that a fish has two (2) eyes.
• There is a potent tradeoff between flexibility and efficiency associated with the representation of the structure of the organism. The distributed PHYS_STRUCTURE approach described above represents the most flexible extreme, supporting the widest variety of queries and the easiest modifications to the hierarchical structure. However, it may also be quite inefficient if we frequently need to construct the entire physical structure.
In short, it remains to be seen whether this is the best representational approach. One compromise might be to use this distributed representation as the basic representation, and periodically use it to construct some other, more efficient structure (i.e. a linked list of some sort) which can be cached and used for everyday tree traversals.
• Monte: What about functional, developmental, structural relationships?