From our experience with BrainView and, once again, from our user study, we realized that since the database would have to be able to manage an extraordinarily diverse range of evolving information, no static schema would suffice. This information might include, data representing GENESIS objects and models; textual and pictorial data; animation data from behavioral experiments; and digitized experimental data. In addition there is an entire level of meta-data that has to be managed in order to maintain the database as a whole.
We decided that a frame-based knowledge representation would be the most appropriate data model for two reasons. Firstly it is capable of representing a wide range of data. Secondly we wanted the database to be flexible enough so that if a query did not offer the specific data desired, the system would at least be ``intelligent'' enough to present a reasonable alternative, or compute an alternative through simulation. The user, of course, would at all times be informed of the exact source of the data, be it original experimental data, related experimental data, or simulated data.
A frame-based knowledge representation is essentially the same as a semantic network except slots can be gathered into collections or frames that resemble an abstract data type. Frame-based knowledge representations are such that information is arranged as a network of hierarchies. Each hierarchy is built from a number of sub-frames inheriting characteristics from their respective parent-frames. This allows specialization of data structures as needed. For example, a Purkinje cell frame and an inferior olivary neuron frame would each have the single cell frame as its parent. The single cell frame will have in it, a number of slots that are needed to generally describe single cells. The Purkinje cell frames can then inherit these characteristics and alter them to be specific to Purkinje cells; and similarly for the olivary neuron. Given each of these inherited frames (say the Purkinje frame), the system can use them to prototype specific instances in the database. For example, one can attach two instances to the Purkinje frame that describe Purkinje cell implementations developed by two different authors (say DeSchutter and Jaeger). If for some reason Jaeger is not able to provide a piece of information for a particular slot in the frame then any queries attempted on that slot will be defaulted to values in the general Purkinje frame. Hence the idea is that if the specific data instance is not available, a reasonable equivalent is always present.
Figure 4 sketches an example of a set of frames in the database used to describe single cells. We are, at this time, still in the process of formalizing the set of initial base frames for the system.
Return to Brain Menu