Role: The IMAGE class provides a framework for storing image data. It is assumed that all such data entries consist of a single graphics file, along with a set of attributes that describe exactly what the graphics file contains. Both published and unpublished image data may be submitted to the database. This class of data (IMAGE), is one of the most common kinds of data in the database; every effort is made to optimize searching and indexing image data.
How/Who enters: Image data are primarily entered by authorized submitters, who submit a file upload form of some sort. Each entry is tagged with the date, time, and user who submitted it.
Security: Any authorized submitter may enter images into the database. Once a user is authorized, submitted images are never screened by some sort of editorial committee, but are inserted into the database. This means that it is incumbent on submitters to be honest and conscientious about the accuracy and quality of data they submit. Once submitted, an image record may be changed ONLY by the DB Admin -- requests for corrections and/or updates (e.g. when the image is published somewhere) must be handled through the DB Admin.
| Superclasses: | GENERIC_OBJECT | |
| DATA_ITEM | comments, primary_pub, related_pubs |
stage (closed set, REQUIRED). This attribute describes the developmental stage of the organism at the time the image was taken. Allowable values are the stages that are defined by the staging series. Stages may be subdivided (only) by making a textual note in the legend attribute.
stage_percent (integer range 1-99, OPTIONAL). Describes how far along in the given stage the organism in the image is. For example, one might then have an image at Dome, 50%), indicating that the organism is approximately halfway through Dome stage. This essentially provides a mechanism to subdivide stages. Leaving this field blank implies that it is unknown how far through the given stage the organism is.
resolution (TEXT, required). States the resolution with which the animal’s stage of development was recorded. Must be one of {stage, hours, days}. This value was used at image submission time to compute stage_hours_start and stage_hours_end; it must be stored so that we can properly denote the resolution of each image when it is retrieved and displayed.
stage_hours_start (REAL, REQUIRED). A real value giving a time in decimal hours (at standard conditions) at which the time frame in which this image falls begins.
stage_hours_end (REAL, REQUIRED). A real value giving a time in decimal hours (at standard conditions) at which the time frame in which this image falls ends.
stock (FISH, REQUIRED). This field contains a pointer to the FISH record that represents the (mutant or wild-type) strain of which the animal pictured is a member. Note that this approach assumes that the FISH record in question has already been entered into the database.
representative (BOOLEAN, REQUIRED). A Boolean flag that is set to “true” if this image is to be used as the “representative” image for this stock. Each stock (line) may have only one representative image specified for it. The representative image is placed at the top of the “stock-viewer” page when viewing the information on that stock.
specimen (closed set, REQUIRED). Specifies the type of specimen shown in the image. Valid entry must be chosen from the closed set {LM-section, EM-section, whole-mount}
image type (closed set, REQUIRED). Specifies the nature of the image. Valid entry must be chosen from the closed set {still, movie, optical series, 3-D}
orientation (closed set, REQUIRED). Specifies the orientation of the animal. The viewpoint of the camera when the image was taken. Valid entries must be a member of the closed set {dorsal - anterior to top, ventral - anterior to top, sagittal - anterior to left, sagittal - anterior to right, parasagittal - anterior to left, parasagittal - anterior to right, transverse - dorsal to top, dorsal oblique, ventral oblique, transverse oblique - dorsal to top}.
animal state (closed set, REQUIRED). Specifies the state of the animal at the time the image was taken. Valid entries are {live, fixed}. (added 1/15/97 Eck)
labeling (TEXT, OPTIONAL). This field contains a pointer to the LABEL(s) used on the specimen shown in the image.
visible_structs (listof (PART), REQUIRED). The information in this field is used to describe the anatomical structures visible in the image. Note that the list may include both parts annotated on the image, and ones that are visible but not specifically highlighted by annotation.
image_file (LARGE_OBJECT, REQUIRED). This field holds an object of type LARGE_OBJECT that is the actual binary image file that the record describes.
• What about the other attributes that were included in our original data model, Monte? --> You’ve left them out in this draft. Like for instance Brain Region (Diencephalon, etc.), Cell Type (Interneuron, Sensory Neuron, etc.), Labeling, Cell Part (whole cell, dendrite, etc.) and others. Are you thinking that all this just gets put in the legend? Realize that this means no searching/sorting by these attributes. Monte: They’re specified by parts list.
• Note that under stock we require a pointer to an existing strain of FISH. How often is someone entering an image associated with a stock not yet in the database? What should we do in this case? Perhaps handle the same way as we do with missing PUBLICATIONS, that is, send mail to DB Admin. Or we could allow user to enter a new FISH or MUTANT on the spot. Won’t user enter IMAGE at same time as new FISH?
• What do we do about images stained with multiple LABELs? It must be supported.
• We have said the visible_structs list should include both annotated (e.g. with arrows/labels) and un-annotated (but nonetheless visible) structures. Is this realistic? Are submitters willing to go through and list every single structure that is visible in each image, whether or not it is of interest to them at all? How do we enforce this? Moreover, what is the use of an un-annotated image showing, say, the telencephalon, to a user who is looking through the developmental atlas to find out what it looks like? Eck thinks we should change this attribute to “annotated structs” and list only those (Monte disagrees). Also, we should think about whether to implement this as part of the EXPRESSION-DATA intersection table (see CHROMOSOME) rather than as listof, which is inefficient to search.
• It is unclear how the interface could support the specification of the visible_structs field, allowing the user to select visible parts from the PARTs catalog. Maybe clickmap of the tree representation of the PARTs catalog?
• The system should verify not only that a file exists, but that the file is in an appropriate format (e.g. GIF, PICT, JPG). To this end, the interface should ask the user to specify not only the file, but also the file type.