Preliminary Definitions of the Representation Schemas
Used in the Modeler's Workspace

Michael Hucka, Kavita Shankar, David Beeman
{mhucka,kshankar}@bbb.caltech.edu, dbeeman@dogstar.colorado.edu
Bower Research Laboratory, Division of Biology 216-76
California Institute of Technology, Pasadena, CA 91125

Date: 30 October 2000

Contents

• 1 Introduction
• 2 Overview of the Approach
  • 2.1 Template Hierarchy
  • 2.2 XML-Based Encoding of Templates and Models
  • 2.3 Semi-Controlled Vocabularies
• 3 The Basic Templates
  • 3.1 The Base Template
  • 3.2 The Author Template
  • 3.3 The Reference Template
  • 3.4 The Data Template
  • 3.5 The Model Template
  • 3.6 The Method and Site Templates
• 4 Templates for Representing Models of Neuronal Cells
  • 4.1 The Neuronal Anatomy Template
  • 4.2 The Neuron Template
  • 4.3 The Neuron Part Template
• 5 Templates for Representing Models of Cell Mechanisms
  • 5.1 The Transmembrane Mechanism Template
  • 5.2 The Voltage-Gated Channel Template
  • 5.3 The Intracellular Mechanism Template
• 6 Example of Using the Model Description Language
  • 6.1 Channel Definitions
  • 6.2 Neuron Definition
  • 6.3 Other Object Definitions
• A. Procedure for Generating MWSUID Unique Identifiers for Database Objects
• B. XML Schemas for MWML, the Modeler's Workspace Markup Language
• C. References
• About this document ...

1 Introduction

The Modeler's Workspace is a software system intended to assist computational neuroscientists in interacting with databases of models and with neural simulation packages such as GENESIS. There are three components in the system: a user interface, a database server, and a global registry and repository.

This document describes the representation of database objects in the Modeler's Workspace. Each object in the system is created according to a specific format. Database designers traditionally call such a format a ``schema'', and object-oriented programmers call it a ``class'', but in an attempt to reduce the amount of abstract jargon in our writing, we simply call it a template. A template defines how a particular kind of database object is to be expressed, meaning the structure of the object's representation, the attributes or slots in the representation, and the types of data values that are permissible for each slot. Different object templates are used to create objects that represent different kinds of information. As explained below, templates in the Modeler's Workspace are organized in a simple hierarchy, and the system provides facilities for definining new templates.

This document is a companion to The Modeler's Workspace Database Organization and Interaction (Hucka, Shankar, and Emardson, 2000). Here we focus on the model representation; in the former, we focus on the relationships and interactions between databases. An overview of the entire system is provided in An Overview of the Modeler's Workspace (Hucka, Shankar, and Emardson, 2000). The database design presented here is based in part on ideas previously developed in versions of the Modeler's Workspace implemented by Jenny Forss, David Beeman, Sara Emardson, and others (Beeman et al., 1997; Forss et al., 1999).

2 Overview of the Approach

The Modeler's Workspace requires a representation language that abstracts away specifics of particular simulators such as GENESIS and NEURON, as well as provides ways of interacting with existing neuroscience databases on the Internet. Devising such a representation is difficult.

To begin addressing this problem, we first distinguish between a Modeler's Workspace Database, which is the database component of the Modeler's Workspace system, and foreign database, meaning any other kind of database. Since the design and implementation of the former are under our control, a Workspace Database can provide whatever functionality we deem necessary. Foreign databases are outside our control and may not provide the same level of functionality or representational structure.

In order to support some level of interoperability with foreign databases as well as neural simulators, and allow users and software developers to evolve new representations and tools, we use a multifaceted approach having the following key aspects:

1. Templates are organized in a simple class hierarchy, with a specific base template being the root of all representations and new templates being derived from either the base or another existing template.

2. A separate, global server called the Modeler's Workspace Directory is used to track the templates used by different databases (both Workspace Databases and foreign databases) on the Internet, to support search and other operations.

3. Dynamically-loadable software modules called plugins are used to interface the Modeler's Workspace to foreign databases and neuronal simulation packages. A database plugin for a particular foreign database handles translating commands and representations between the foreign database and the Modeler's Workspace system. A simulator plugin for a particular simulator handles translating commands and representations between the simulator and the Modeler's Workspace system.

In the remaining sections of this document, we describe the representational framework assumed in the Modeler's Workspace. Details of the Modeler's Workspace Directory and database plug-ins are provided in The Modeler's Workspace Database Organization and Interaction (Hucka, Shankar and Emardson, 2000).

2.1 Template Hierarchy

The representational framework used in the Modeler's Workspace is based loosely on object-oriented programming concepts. One of the key ideas used is the concept of inheritance applied to templates. All templates are derived from either a specific one called Base or an existing template. Base (defined in Section 3) is therefore the root of a template hierarchy.

Figure: All templates are derived from Base or another existing template. Open arrows indicate inheritance. The notation used here is based on the industry-standard UML and explained in detail in The Modeler's Workspace Notation for Describing Representations Intended for XML Encoding (Hucka, 2000).

The Base template itself contains few attributes, so it is not biased towards any particular kind of database object. It is normally not used to represent objects in and of itself. Figure 1 shows the first level of templates derived from Base in the Modeler's Workspace system. The templates are Author, Reference, Method, Model, Data, and Site; they are defined in detail in Section 3. The particular choice of first-level templates was inspired by the work of Gardner et al. (1999).

Each template inherits the same attributes as the template from which it is derived, and in addition, may add its own set of attributes. Users are allowed to add new attributes when creating a new template based on an existing one, but not to delete attributes. For example, if a given template has attributes x, y and z, a derived template can only add attributes; it cannot change or delete x, y or z. This restriction is necessary to ensure that search operations across databases make sense: if existing template attributes were to be modifiable, there could be no assurance that the fields retained their meanings across different databases, and database communication would become nearly impossible.

The object-oriented style of representation is useful for a variety of reasons. First, the existence of categorical templates allows the Modeler's Workspace User Interface to present the user with intelligent search forms. Specifically, the Modeler's Workspace search interface prompts the user to specify the type of object to search for (which is equivalent to specifying the template), and based on the user's choice, the system constructs a form using knowledge of the attributes defined by the template. The search form may include graphical elements specialized for the particular category of object involved. This allows the system to go beyond the usual fill-in-the-blanks search form and provide something more powerful and user-friendly.

A second reason is that, by chosing the search category appropriately, searches can be made more or less specific. Because of the hierarchical relationships, a user can select a template in the middle levels of the hierarchy, and search operations can be designed to encompass all objects that are below it in the hierarchy. This means, for example, that a search using Model will encompass objects created from templates derived from it, such as Neuron class objects, TransmembraneMechanism class objects, etc.

A final reason for the utility of the representational framework presented here is that software can be made modular and extensible. New software modules can be developed for the Modeler's Workspace alongside new templates, customizing the system to interact with new types of objects without redesigning or restructuring the whole system. For each representation derived from an existing template, all the software elements that worked with the parent template will also work with the derived templates. This is because the derived template can only add attributes, and while the existing tools will ignore the new attributes, they will continue to work with the attributes that were inherited from the parent template. Developers can write new software modules that interact with the additional fields in the new templates and these software modules can be loaded into the Modeler's Workspace on demand, extending the software's functionality.

2.2 XML-Based Encoding of Templates and Models

XML, the Extensible Markup Language (Bosak and Bray, 1999; Bray, Paoli and Sperberg-McQueen, 1998) is a language used to express self-describing, semi-structured representations of information. It provides a way of marking up data with semantic tags that describe and structure the contents of the data. Although XML is typically thought of as a document format similar to HTML, in fact it is more general. It is a notation, a ``metalanguage'', a way of organizing a stream of data and marking up the different parts so that a program can parse the stream into constituents. In the words of one of its chief architects, ``Just as HTML created a way for every computer user to read Internet documents, XML makes it possible, despite the Babel of incompatible computer systems, to create an Esperanto that all can read and write. Unlike most computer data formats, XML markup also makes sense to humans, because it consists of nothing more than ordinary text'' (Bosak and Bray, 1999).

In the Modeler's Workspace, XML Schemas (Biron and Malhotra, 2000; Fallside, 2000; Thompson et al., 2000) are used to describe model templates, and actual models are encoded in XML using these Schemas. All of the constructs described in Sections 3-5 have direct equivalents in XML Schema.

For handling representations in a collection of databases (Modeler's Workspace and foreign databases), XML offers three key features:

• Separation of the template description (in the form of an XML Schema) from the content. As long as there is agreement on basic guidelines and protocols, databases can have their own specialized representations. If the schemas are advertised, the Modeler's Workspace can retrieve them separately and use them to determine which model classes a database uses in common with other databases, and which classes are unique.

• As mentioned above, schema descriptions can be used to dynamically create user interfaces, for example, for search forms.

• The text-based format of XML allows a powerful way of handling novel data types: a database server that contains specialized data can provide, say, JavaScript code implementing an applet for viewing the data. The applet script can be sent as part of the XML document when the document is retrieved by a client program.

The powerful generality of XML suggests that more than just the model representations can be expressed using it, and indeed, the Modeler's Workspace uses XML for all file formats. For example, the Workspace initialization file, storing user's preference settings and other information, is written in an XML format. In addition, glossary and notes are also stored in XML files that are read when the Workspace is started up. Each glossary and note entry has a tag, so that the program can reference each entry directly. This not only makes the information organization cleaner, it also makes it possible to issue updates to the glossary/notes files more easily.

2.3 Semi-Controlled Vocabularies

Many of the attributes in the templates have essentially unconstrained values. For example, there are no a priori constraints applicable for such things as the name of a model. But in many other cases it is useful to place constraints on the permissible values of an attribute, especially string attributes, in the form of a controlled vocabulary. Gardner et al. (see http://cortex.med.cornell.edu/dataModel/) are leading an effort to define a set of controlled vocabularies for use in biological databases. These are meant to capture the allowed values for an attribute. A controlled vocabulary is especially useful for search operations: when database objects use attribute values drawn from a common vocabulary, it is much more likely that a database search will succeed in finding a match than if users are given free reign to enter any value for every attribute. Controlled vocabularies reduce the chances that differences in spelling, the use of different terms having the same meaning, and other incidental effects will cause a search to fail.

We borrow this general idea for the Modeler's Workspace, but in some situations we also allow for attribute values that are not strictly limited to values from a set vocabulary. We call this a semi-controlled vocabulary. Such semi-controlled vocabularies can be attached to an attribute to provide a set of initial, suggested values. When these are available for a given attribute in a model template, the editing field for that attribute provides a pull-down list containing the set of suggested values, allowing the user to easily select a value from the list. In addition, the user is allowed to type in a new value if none of the existing values are suitable.

The use of a semi-controlled vocabulary involves a tradeoff as compared to a strict controlled vocabulary. The provision for allowing users to type in new values means that search operations may no longer be as effective. However, we feel that we are not able to define a sufficiently comprehensive controlled vocabulary for all attributes, and that moreover, users would react negatively to an interface that does not allow them to type in new attribute values when the predefined set is insufficient. We believe that we can obtain most of the benefits of a controlled-vocabulary approach by providing reasonably comprehensive default vocabularies, so that users are likely to find a predefined value close enough for their needs.

3 The Basic Templates

The graphical notation for defining templates that we use throughout this document is explained separately in The Modeler's Workspace Notation for Describing Representations Intended for XML Encoding (Hucka, 2000). We urge readers to peruse this document before proceeding further here.

The six most basic templates derived from Base, shown in Figure 1, are Author, Reference, Method, Model, Data, and Site. These are general data structures that are not limited to representing specific biological objects such as neurons and ion channels.

In this section, we detail the preliminary versions of the six basic templates. Some of them, such as Author and Reference, can be used directly, and we expect that they will not require further specialization. Others, such as Model, clearly need to be specialized to apply them to particular areas. The specializations that we have developed so far for the Modeler's Workspace are intended for representing models of single neurons and associated elements such as ion channels. Sections 4 and 5 describe the templates for models of neuronal cells and various cell mechanisms.

3.1 The Base Template

The Base template has only two attributes, id and version. The former places a unique identifier on every object; the latter allows the system to track the evolution of data objects. The diagram below depicts the Base template and the Version structure:

The id attribute of type MWSUID is an identifier that is unique to a given Workspace Database. Every object is given a unique identifier so that other objects can refer to it. For example, a model of a neuron may refer to several models of ion channels as part of its definition. In order for the system to be able to link models together, the database objects themselves must have identifiers that are unique within a given Workspace Database server. This identifier must be recorded in the database object itself. The name of an object (for those database objects that have names, such as Model, described in Section 3.5) is not sufficient in this capacity because the name can be changed by the user. The procedure used in the Modeler's Workspace system for generating unique identifiers is described in Appendix A.

The Version structure for attribute version contains fields for such things as a timestamp, a version number, the version number of the immediate parent version, etc. Two of the attributes are required to be given values: timeStamp, the time when the data object being described was stored (represented using the XML Schema datatype timeInstant); and versionNumber, a descriptor for the particular version of the data object being described. The remaining information in the Version structure is optional: versionName, a symbolic name or tag for the version (e.g., ``RELEASE_1''); logMessage, the user's description of what has been changed in a given version; parentVersion, the version that is the ancestor to the current one; and source, a reference to the object in question. Despite their names, the version ``numbers'' are actually stored as strings, because in many version control systems such as RCS and CVS (Fogel, 1999; Mikkelsen and Pheriogo, 1997), version numbers have the form ``1.4.9'' and these cannot be represented as integer or floating point quantities. The source attribute allows an object to retain a reference to the original database object from which it came, so that when copies of the object are made and communicated on a network, they retain information about the original source. (This is analogous to the $Source$ keyword in RCS/CVS.)

Since all objects must be derived from Base, all objects inherit id and version attributes. This may at first seem odd, because it may seem that some types of objects such as ``data'' do not need versions. However, we believe that all database object representations can benefit from having version information, because it enables changes (such as the addition of more details) to be tracked through a version control system. The Modeler's Workspace will include version control facilities for managing models in a Workspace Database.

3.2 The Author Template

r2.4in

The Author template inherits the id and version attributes from the Base template, and adds attributes for identifying a person by name, address, web home page and other characteristics, as shown in the diagram at the right. (The attributes implicitly inherited from the Base template are not repeated here.)

The primary purpose of a separate Author template is to allow users to enter into their databases the information about a given author once, then link to the author information from other objects (such as models and article references). This will produce savings in effort as well as storage space. This will also permit the construction of databases devoted to author information. We envision that such databases could be constructed using, for example, the author information contained in the proceedings from the annual Computational Neuroscience conference, and then made available as a public resource on the Internet. Users of the Modeler's Workspace could then import author records from this database server, potentially avoiding having to enter author information altogether.

The following is an example of a data object encoded in XML, based on the template defined above and using the UML-to-XML translation approach described by Hucka (2000):

This example illustrates several points. The first line begins with the tag mwml, indicating that the rest of the data stream is encoded using the Modeler's Workspace Markup Language, an application of XML. MWML is defined in Section B. The first line also contains a version number, indicating that the data stream is based on version 1 of the MWML specification. (Such versioning allows for future updates to MWML.) Subsequent lines contain the definition of an author object, with a variety of XML attributes encoding information about the author. The value of id is artificial and shown for illustrative purposes only. The version information, because it is defined as a substructure (see the definition of Base in the previous section), is structured as a subelement inside author, with the tag version. Both the author and version elements omit mention of certain optional attributes that have not been given values in this example.

3.3 The Reference Template

r2.45in

The Reference template inherits the id and version attributes from the Base template, and adds attributes describing literature references. The attributes in the template are based on BibTeX records (Lamport, 1994). Author and editor information is represented in terms of links to Author objects.

Not all of the attributes in Reference will be used in every literature reference. For any given Reference object, attribute referenceType indicates the kind of reference it is, whether a book, journal article, etc. In a well-designed user interface, the choice of referenceType made by the user can trigger the interface to selectively present only those attributes relevant to the type of reference in question. Thus, if the user is creating an article reference, attributes such as journal and month would be significant and worth showing in the interface, but if the user is creating a book reference, these attributes would not be shown; instead, other attributes such as chapter and editor would be relevant.

As with the Author template described above, the use of a separate Reference template will allow users to enter common literature information into their databases and reuse them when creating models. We also envision that databases containing reference information could be established as public resources on the Internet. Their contents could be created automatically using software that converts information from PubMed and other sources.

The following is an example article reference encoded in XML. In this example, the author information is shown as a list of references following an XML XLink syntax. At this time, the exact form of the URIs for linking to database objects is unknown, so in this example, the four authors of the paper are shown as links to imaginary database objects named 1484450292207951A4CC@obi-wan.bbb.caltech.edu, etc. The reference are all assumed to point to objects in the same Workspace Database. (The object references may be different in actual database implementations.)

3.4 The Data Template

The Data template is another subclass of Base. It provides basic support for storing data in a workspace database or pointing to data stored in a remote database.

The title and description attributes can be used to provide information about the data for human readers. The author list is intended to point to the ``authors'' of the data, meaning the individuals responsible for gathering or otherwise producing the data. The reference list is intended to point to relevant literature references; for example, if the database object is an electronic form of a set of data published in a journal article, one of the references should point to a Reference database object that provides information about the article.

The dataView attribute is a list of DataView structures that can be used to point to data sets. A DataView contains attributes such as viewLabel, viewSequence, and dateAndTime, that allow users to describe a particular view of a data set. The actual data set is stored on in the attribute dataSet, a list of DataSet structures.

A DataSet structure contains a number of attributes:

label: A user-defined string that identifies the data in some fashion deemed useful by the author.

sequence: Another user-defined string that can be used to identify sequence information; this is useful when the data in a list of data sets are part of a sequence of experiments with similar conditions.

type: Another user-defined string that authors can use to further refine the description of a data set.

isRaw: A boolean flag; a ``yes'' value indicates that the data is itself raw data, rather than being derived or interpreted from raw data.

format: A string that indicates the format of the data in the data field. Some example values for this attribute might be ``time-series'', ``GIF'', ``Neurolucida'', etc.

url: A pointer to the actual stored data, for those cases when the data is stored externally. The datatype of this attribute is the type uriReference defined by XML Schema. If this attribute is non-null, then the data attribute will typically be null.

data: A data set, for those cases where the structure does not point to external data but rather includes the data directly. If this attribute is non-null, then the url attribute will typically be null.

Note that since both the dataView and dataSet attributes are lists, a given object can have more than one DataView structure, each containing more than one DataSet, leading to a flexible organization of information. The Data template and this arrangement of attributes is based partly on Gardner et al.'s (1999) Data_Element structure.

The following is an example of how an object created according to Data might appear in the form of an XML data stream:

The example shows a data object entitled ``Recording set #1", with two authors (expressed as links to other objects presumably located in the same database). There are no links to Reference items. This data object has two DataView structures, the first of which having three DataSet structures and the second having two. All of the data sets are references to external data located at particular URLs on the Internet.

In the Modeler's Workspace, the primary reason for providing a separate class of objects for storing information about experimental data is that, generally, many models may be based on the same data sets. Therefore, it is useful to be able to store information about experimental data as an independent entity.

3.5 The Model Template

The Model template is intended to serve as a common starting point for all model template definitions. It is a generic structure, not specific to any particular kind of modeling. Specific kinds of models, such as for neuronal cells (Section 4) and intracellular and transmembrane mechanisms (Section 5), are derived by starting from Model and adding new attributes.

As with the other main templates, the Model template is an extension of the Base template and therefore implicitly inherits id and version attributes. Model then adds several more attributes. The attributes name and description allow a user to name a model and provide a brief description of it. To provide for the possibility of including equations, superscripts, and other formatted content, the description is stored in XHTML format. The notes attribute provides a place for recording information about a model that is not easily recorded in any other attribute. One example of the use of notes is to paste plot output resulting from simulating the model; a model's author might choose to include such plot output for the benefit of other researchers.

The lists for author and reference information serve the same roles as they do in other templates. The author list is intended to point to the ``authors'' of the model; the reference list is intended to point to relevant literature, specifically articles discussing the model. For example, if a database object is related to a model published in a journal article, one of the references should point to a Reference object that provides information about the article. It is important to note, however, that the author list should not point to the authors of the article, unless the authors of the article are also the authors of the model definition.

The version attribute inherited from Base is especially useful in the context of models, because it allows the Modeler's Workspace database to track the history of modifications to user's models.

3.6 The Method and Site Templates

The Method template is intended to capture information about experimental methodologies. The Site template is intended to capture information about such things as neuronal recording sites, brain regions, etc. These templates have not yet been defined and await further development.

4 Templates for Representing Models of Neuronal Cells

The main template for representing models of neurons is Neuron. It makes use of several other templates, in particular NeuronalAnatomy, NeuronPart, TransmembraneMechanism and IntracellularMechanism. Figure 2 depicts the hierarchical relationships between the templates. In this section, we discuss the Neuron, NeuronalAnatomy and NeuronPart templates. We leave the cell mechanism templates to Section 5.

Figure 2: Additional templates derived from the six basic templates shown in Figure 1. These are the additional templates needed to represent some common types of models of neurons.

4.1 The Neuronal Anatomy Template

NeuronalAnatomy specializes the basic Data template to provide a container for anatomical information about neurons. It is primarily intended to be used for storing information about cell morphologies.

As the NeuronalAnatomy template inherits from Data, it has the data containers defined by the parent template. In particular, NeuronalAnatomy inherits a dataView list attribute that can be used to store a list of either references to or actual data describing the morphology of a neuron. Attribute neuronType is a string that is intended to allow users to describe the type of neuron involved. An example value might be ``pyramidal''. The value supplied by the user is entirely their choice. The attribute cellLocation is a string for describing the anatomical location of the neuron. The attributes neurotransmitters and neuroreceptors are intended to summarize the neurotransmitters with which the neuron may interact and the neuroreceptors to which the neuron may respond. They are lists of strings, with each string naming one substance. A neuron that is sensitive to five neurotransmitters would have five strings in the attribute neurotransmitters. The cellLocation, neurotransmitters and neuroreceptors attributes have semi-controlled vocabularies associated with them, following the approach taken by Gardner et al. (1999).

The main purpose of the semi-controlled vocabularies for the Modeler's Workspace is to allow the system to provide, in the user interface, an initial list of possible values as hints for the user. We believe this will both help users enter information into models and also increase the chances that different models are more likely to use consistent nomenclature. The semi-controlled vocabularies will be hierarchical in nature. Figure 3 lists the current vocabularies for the attributes cellLocation, neurotransmitters and neuroreceptors.

Information about the subject from which the anatomical data is drawn can be recorded in the optional subject field. The associated Subject structure provides slots for a description of the kind of subject (e.g., ``rat''), whether it's male or female, and its age. The age attribute has a string data type rather than a numerical type because users may need the freedom of expressing age in a variety of forms, such as ``1 year 2 months'' or ``4 hours''.

Figure: Semi-controlled vocabularies, as they are currently defined, for attributes cellLocation, neurotransmitters and neuroreceptors in NeuronalAnatomy.

cellLocation cortical basket stellate pyramidal deep superficial DCN DCN-busy DCN-octopus visual retinal-ganglion olfactory olfactory-receptor mitral mitral-tufted mitral-displaced amacrine cell-of-Martinoti fusiform horizontal auditory vestibular-har thalamic relay reticular hypothalamic hippocampal pyramidal-CA1 pyramidal-CA3 dentate-granule basal ganglia neostriatal-spiny cerebellar purkinje golgi granule granule-type-I granule-type-II granule-type-III brainstem nigral-dopaminergic Ia-interneuron motor-neuron other

neurotransmitters acetylcholine amines catecholamine dopamine epinephrine norepinephrine histamine serotonin amino acid GABA glycine glutamate peptides ANF/ANP bradykinin CGRP CCK CRF enkephalins LHRH neuropeptide Y somatostatin substance-P vasopressin/oxytocin purine adenosine ATP gaseous CO NO other

neuroreceptors acetylcholine nicotinic muscarinic amines dopamine dopamineD1 dopamineD2 dopamineD3 dopamineD4 dopamineD5 glycine histamine histamineH1 histamineH2 serotonin serotonin5-HT3 serotonin5-HT-GPCRs amino acid GABA GABA A GABA B GABA C glutamate glutamate AMPA glutamate Kainate glutamate NMDA glutamate mGluR peptides adenosine A2 adrenergic alpha 1 adrenergic alpha 2 adrenergic beta ATP-P2X ATP-P2Y CCK CCKA CCK-B opioid opioid mu opioid delta opioid kappa other

4.2 The Neuron Template

The Neuron template extends the basic Model template with additional attributes for anatomical information, experimental information, the segment structure of the model neuron, and other characteristics. Neuron is fairly complex. We begin by discussing the basic idea behind its form.

4.2.1 Basic Ideas Behind the Approach

In GENESIS, models of neurons are described in terms of compartments, whereas in NEURON, models are described using the higher-level construct of cable segments. One of the parameters in a NEURON model determines the number of compartments that a given segment should be divided into at simulation time. We adopt NEURON's latter approach here, and describe neurons fundamentally in terms of segments. This allows a model to be mapped to either GENESIS or NEURON; to translate models into GENESIS, the Modeler's Workspace simply needs to pre-divide the segment structure into compartments and then send the compartmentalized version to GENESIS. The reverse mapping, from a GENESIS model to a model in the current framework, can be implemented in the worst case by treating each GENESIS compartment as one segment. More realistically, however, we believe the system will be able to employ some heuristics in many cases to map multiple compartments into single segments.

In order to support the ability to define entire portions of neurons as building-block parts, and thereby have the ability to create and maintain parts libraries, the representational framework shown here introduces one more intermediate level of abstraction, the section. A section in a Neuron model is either a segment or a reference to a NeuronPart object (see Section 4.3). A NeuronPart object is simply a collection of segments that define some useful building-block structure. A model neuron is defined in terms of one or more sections, each of which is a membrane segment or a reference to a separate part model object.

The Section structure shown in the diagram of Neuron is an abstract type; the structures MembraneSegment and PartReference are derived from Section and are the actual types used for the section list in a Neuron object. MembraneSegment is used to define a segment directly; PartReference is (as its name implies) a reference to a collection of segments designated as a part and stored as a separate database object. In XML terms, the structure of a model is along the lines of the following partial example:

In the fictitious example above, most attributes are omitted for clarity. The definition of the model is in terms of six elements listed under section. Note how segment definitions are interspersed with part references. The XML attribute xsi:type is used to specify whether a given section element is of the derived type MembraneSegment or PartReference, in accordance with the XML Schema standard involving the use of derived types (Fallside, 2000). The id identifiers are numbered consecutively for each section in the section list, whether a given section is a segment or a part reference.

The following drawing illustrates how a model can be structured in terms of segments and part references. This uses the same components as the example above:

4.2.2 Structures Used in the Neuron Model Representation

We now turn to describing the different attributes and substructures in the Neuron template. At the highest level, there are are several general attributes. The attributes temperature, Q10Factor and scalingFactor specify the temperature assumed for the parameter values in the model, and scaling factors to be used to adjust parameters for other temperatures if needed. The neuronanatomy attribute in Neuron is a link to an object based on NeuronalAnatomy. The intent is to allow modelers to store or point to the experimentally-derived cell morphology upon which a given neuron model is based. Of course, a given model may not have an associated experimental morphology, in which case, the neuroanatomy attribute would have an empty value. The experiments attribute is a list of links to Data objects. Its purpose is to give users the ability to store links to experimental data about the neuron they are modeling.

Both MembraneSegment and PartReference inherit four attributes from the definition of Section. Attribute id is a unique identifier for the section. Attribute parent is the value of the id of the parent section to which a given section is connected. Attribute name is intended to allow the user to give a name to a segment for their own use; similarly, attribute type is intended to allow a user to describe the kind of anatomical structure of which the segment is a part. For example, in a model containing an apical dendrite described using a number of segments, a user might give the dendritic segments the names ``dend1'', ``dend2'', etc., and assign the string ``apical dendrite'' as the type of all the segments describing the dendrite. These two attributes are entirely for the user's benefit and do not affect how a model is translated into a particular simulator's scripting language; the user could just as well assign gibberish or no value at all to the name and type attributes of all the segments in their model.

The geometry of a segment is described using a collection of attributes gathered under a SegmentGeometry structure. For a given segment, the numberOfCompartments attribute indicates to a simulator such as GENESIS or NEURON the number of compartments into which the segment should be divided. The boolean attribute symmetrical determines whether the compartments should be made symmetrical with respect to the placement of the axial resistance; this attribute is primarily useful for simulators such as GENESIS that make a distinction between symmetrical and asymmetrical compartments. The attribute absoluteDimensions indicates whether the geometry values are measured relative to a parent segment or are given as absolute values. The attribute dimensionUnits specifies the units assumed for the coordinate and dimension attributes. The attributes x, y, and z indicate the dimensions of the segment, while the length attribute sets the length of the segment. The shape attribute specifies the shape of the segment; currently the only two values allowed are ``cylindrical'' and ``spherical'', after the same options available in GENESIS for compartment shapes.

The startDiameter and endDiameter attributes indicate the diameters of the two ends of the segment cylinder. The two diameters allow for segments that are tapered (i.e., cones). For simulators that can handle conically-shaped compartments, the two diameters can be used to calculate the starting and ending diameters of each compartment that make up the segment of membrane; for simulators that cannot handle conical compartments, the segment can be turned into a series of cylindrical compartments, each of which is of a different diameter than the previous one, thereby simulating a tapering segment.

The passive properties of a membrane segment are set using the attributes in the PassiveProperties structure. These are all the common variables used in simulating neuronal membranes in GENESIS and NEURON: specificResistance, specificCapacitance, specificAxialResistance, membraneRestingPotential, membraneLeakagePotential, equilibriumPotential, and maxElectrotonicLength. Each of these attributes also has an associated _units attribute that specifies the units of the value.

A membrane segment can have zero or more active properties identified by a structure of type ActiveProperty. An active property can be an ion channel or other kind of intracellular or transmembrane mechanism. An ActiveProperty structure only contains information linking to another database object and a set of variable assignments. The assumption is that channels and other mechanisms are complex enough to require their own separate object representations. The assign attribute is a two-dimensional list of strings that is intended to let a user specify values for variables in the pointed-to model. The idea is to allow users to put variables in places where quantities are required in a mechanism model, and then use the variableAssignments attribute to tell the simulation program what values to give those variables.

Finally, the messages attribute in MembraneSegment is used to tie together elements that need to exchange parameter values, for example for calcium concentration. The messages attribute is a list of zero or more Message structures. The sources and destinations of messages can be other segments; they can also be active property components such as channels. The sources and destinations are specified in terms of identifiers; since every segment and active property structure has a unique identifier, message can be unambiguously directed to/from any other active property or segment within a model. Each message has a messageName, which is used to specify the name of a variable that is to be exchanged between the destination and target elements.

As mentioned above, a section of a neuron model can also be specified as a reference to a part model. This is handled using a PartReference data structure. Like the Segment structure, the PartReference structure is a subclass of Section, which means it inherits attributes id, name, type, and parent. In addition, the part structure adds a link to a NeuronPart model object. It also adds attributes attachmentPoint (which indictates how far from the end point of the parent segment the part should be attached) and orientation (which indicates the three-dimensional orientation of the part with respect to the parent segment). The assignn attribute is used to specify how variables in the part model should be given values.

4.3 The Neuron Part Template

The NeuronPart template exists to provide a way to construct reusable part models for Neuron objects. Portions of neuron models can be recorded in NeuronPart objects, allowing those portions to be reused in models by linking to them from within Neuron objects.

The body of a NeuronPart object consists of a list of MembraneSegment structures and a separate list of VariableAssignment structures. The definitions of these structures are taken directly from the structures used in the Neuron template.

The list of MembraneSegment elements is used to define the part in terms of membrane segments. The segments can have all the attributes of segments in full Neuron objects; for example, they can refer to active properties such as ion channels.

The attribute assign holds a list of VariableAssignment structures. These are intended to support the use of variables as substitutes for numerical or other values in attributes. The additional capability of using variables in place of actual attribute values is necessary to permit part models to be parametrized. The variables can be given values in the Neuron object that links to them, as described in the previous section.

5 Templates for Representing Models of Cell Mechanisms

The templates described in this section are used to represent active properties in neural cell models. We begin by describing the TransmembraneMechanism template and its subclasses, and then describe the IntracellularMechanism template and its subclasses beginning in Section 5.3.

5.1 The Transmembrane Mechanism Template

The TransmembraneMechanism template is intended to serve as a starting point for definitions of cell mechanisms such as ion channels, calcium concentration pools, etc. It is used as the basis for defining the Voltage-GatedChannel, Ligand-Activated Channel, and IonicPump templates. At this time, we have only defined Voltage-GatedChannel; it is discussed in the next section.

The TransmembraneMechanism template inherits from Model the attributes name, description, notes, author, and reference. It adds three new attributes of its own: cellType, experimentalData, and pharmacodynamics. The cellType attribute is a string that allows users to describe the type of neural cell involved. It has a semi-controlled vocabulary associated with it listed in Figure 4. The user may select from one of the values or supply a different value of their choice. The attribute experimentalData is a list of pointers to Data objects, for referring to experimental data relevant to a particular model of a transmembrane mechanism. The attribute pharmacodynamics is a list of Pharmacodynamics objects used to record information about pharmacodynamics experiments involving the transmembrane mechanism.

Figure: Preliminary semi-controlled vocabulary for attribute cellType in TransmembraneMechanism.

cellType

cerebellar purkinje golgi granule type I type II type III cortical basket stellate pyramidal CA1 CA3 deep superficial olfactory DCN bushy octopus dentate granule Ia-interneuron

motor-neuron neostriatal-spiny nigral-dopaminergic olfactory-receptor retinal amacrine bipolar ganglion receptor cone rod stellate thalamic relay reticular vestibular-hair mitral tufted displaced other

One assumption needs to be stated at the outset. It is not possible to take a generalized channel representation such as what is presented here and translate it directly into something appropriate for a simulator such as GENESIS or NEURON without additional assumptions. We assume that the programs which translate channel representations into simulator code will have specific expectations about the form of the representation. We expect also that the translator program will augment the representations with additional elements that are not explicitly state. For example, a working simulation involving channels needs to have variables for quantities such as the channel current. Rather than try to build into the representation here something that lists which variables should be added to a simulation script, we assume that the translation program will construct simulator-specific code using both the channel model representation and additional code that is common to all channel models.

5.2 The Voltage-Gated Channel Template

As its name implies, the Voltage-GatedChannel template can be used to represent voltage-gated ion channels. The representation is based in large part on that used by GENESIS, and can handle channels not only of the common Hodgkin-Huxley variety, but also a number of variants. The representation is fairly complex, so the following discussion is divided into parts.

5.2.1 Ions and Gating Variables

The diagram for Voltage-GatedChannel shows that the top-level structure consists of a number of attributes and a list of ions. Attributes channelType and currentType are strings used to describe the type of channel and the type of current it passes. The user is free to choose any values for these attributes. An example value for the channelType attribute may be ``K'' (for potassium), whereas for currentType, it might be ``K(A)'', signifying an A-type transient K current. The attributes cellRestingMembranePotential and cellRestingMembranePotential_units record information about the resting membrane potential of the cell in which the channel is found. The attributes temperature, Q10Factor and scalingFactor specify the temperature assumed for the parameter values in the model and scaling factors to be used to adjust parameters for other temperatures if needed.

A given channel may pass more than one kind of ion, although current channel models most often involve only one ion. Nevertheless, to handle the case of multiple ions, the ion attribute in Voltage-GatedChannel is a list of Ion structures. Each Ion structure contains the following attributes: name, a string that records the user-chosen name of the ion (e.g., ``potassium''); isMainIon, a boolean flag that records whether the ion is the main one passed by a channel or whether it is a secondary ion (for those channels that involve multiple ions); equilibriumPotential, a floating point value representing the membrane potential at which there is no net flux of the ion across the membrane; and gatingVariable, a list of one to three GatingVariable structures.

In neuronal modeling, individual ion channels are often though of as containing a small number of gates that control the flow of ions through the channel. The GatingVariable structure contains attributes related to the properties of a gate. The collection of gating variables in a particular channel model captures the bulk of the information necessary to describe the behavior of the channel. Each GatingVariable structure contains the following attributes:

name: The name of the gating variable, constrained to be one of the strings ``X'', ``Y'', or ``Z'', following the convention used by GENESIS. These refer to the variables in the equation for channel conductance,

$$G_k = \bar{g}_k X^{X_{power}} Y^{Y_{power}} Z^{Z_{power}}$$ (1)

In this equation, $G_k$ signifies the conductance due to a channel of type $k$, and $\bar{g}_k$ is a normalization constant that determines the maximum possible conductance when all the channels are open. To give an example, for the case of the sodium channel in the squid axon, $X = m$, $X_{power} = 2$, $Y = h$, $Y_{power} = 1$, and $Z_{power} = 0$, to produce the common Hodgkin-Huxley formula $G_k = \bar{g} m^2 h$. The variable $X = m$ is sometimes called the activation factor and $Y = h$ is the inactivation factor.

exponent: An integer indicating the value of $X_{power}$, $Y_{power}$ or $Z_{power}$, as appropriate.

dependencyType: A list of strings that describes whether a given gating variable is dependent on voltage, concentration, time or other quality. It is a list because a gating variable can be dependent on more than one simultaneously.

instantCalculation: A boolean variable used to note whether a gating variable's value is meant to be determined instantaneously from $\alpha/\beta$ or $m_\infty/\tau$ values, rather than solving differential equations. If true, the value of a variable $X$ is determined using $X = \alpha/(\alpha + \beta)$. In GENESIS, this is often used with the Z gate to model a Ca-dependent conductance, or to implement Morris-Lecar models having zero time constant for activation (Bower and Beeman, 1998).

format: Whether the data describing the gating variable's behavior are stored in $\alpha/\beta$ or $m_\infty/\tau$ format. Some users prefer one format over the other--often, modelers tend to prefer $\alpha/\beta$, and experimenters like to show $m_\infty/\tau$ because they are more closely related to the results of voltage clamp experiments. The choice is made by the user and should reflect the format in which the user actually input the parameter values. The data are left untouched regardless of the user's choice; it is up to the simulator program (or other consumer of models in a database) to do whatever is necessary to translate between $\alpha/\beta$ and $\tau/m_\infty$ as necessary.

representationForm: A string specifying which of the three possible representations (``parametrized'', ``tabulated'' or ``equation''), is being used for the gating variable. This is discussed in more detail below.

representation: The attributes setting the behavior of the gating variable, stored in an object derived from the class GatingVariableRepresentation.

message: A list of message structures used to link a gating variable to other mechanisms in a cell. Messages are described in Section 5.2.5 below.

We have eschewed attempting to provide separate structures for every different variation on voltage-gated channels. Instead, the approach here uses a common model organization that maps all the variations into one of three types of representations: a parametrized form, a tabulated form, and a catch-all equation-form. Within the parametrized form there are several predefined common types. The three forms are subclasses of GatingVariableRepresentation, and are described below.

Each gating variable can be independently described using one of the three main forms. This gives the user freedom to model categories of channels that use combinations of, say, a gating variable described using a parametrized form and another gating variable described using a tabulated form. Regardless of the particular form, every gating variable has two rate functions, one for forward and one for backward. Each of the three subclasses of GatingVariableRepresentation therefore have two attributes, forward and backward.

5.2.2 The Parametrized Form

The version of the Hodgkin-Huxley model of voltage-gated channels used here is based on a general format used in GENESIS. It is characterized by three main assumptions about the equations for channel conductance and the forward and backward rate functions. First, the model assumes an Ohm's law relationship between current and conductance, with

$$I_k = G_k (E_k - V_m)$$ (2)

$$G_k = \bar{g}_k X^{X_{power}} Y^{Y_{power}} Z^{Z_{power}}$$ (3)

where $E_k$ is the equilibrium potential for the channel of type $k$, $\bar{g}_k$ is a normalization constant, and $V_m$ is the membrane potential. Second, the gating variables are calculated from differential equations of the form

$$\frac{d X}{d t} = \alpha(V_m)(1 - X) - \beta X$$ (4)

$$\frac{d Y}{d t} = \alpha(V_m)(1 - Y) - \beta Y$$ (5)

$$\frac{d Z}{d t} = \alpha(V_m)(1 - Z) - \beta Z$$ (6)

The third and final assumption is that the voltage dependence of the $\alpha(V_m)$ and $\beta(V_m)$ functions are each expressed using a differential equation that can ultimately be rewritten in the form

$$\alpha(V_m) = \frac{A + BV_m}{C + H \exp(\frac{V_m + D}{F})}$$ (7)

The attribute category in the ParametrizedForm structure determines which of several variations of this equation should be presented to the user. We have so far determined the following categories: ``General Parametrized Form'', ``Hodgkin-Huxley Exponential'', ``Hodgkin-Huxley Sigmoid'', ``Hodgkin-Huxley Linoid'', ``Sigmoidal $m_\infty$ and constant $\tau$'', and ``Borg-Graham''.

Formula 7 given above is the most general; it is called the ``General Parametrized Form''. This same formula for $\alpha$ and $\beta$ can represent the three common forms of Hodgkin-Huxley equations:

• Exponential: By setting $B = 0$, $C = 0$, $D = -V_0$, $F \ = -B$ and $H = 1$, we get the Hodgkin-Huxley exponential form,

  $$\alpha(V_m) = A \exp(\frac{V_m - V_0}{B})$$ (8)

  
  

• Sigmoid: By setting $B = 0$, $C = 1$, $D = -V_0$, $F = B$ and $H = 1$, we get the Hodgkin-Huxley sigmoid form,

  $$\alpha(V_m) = \frac{A}{\exp(\frac{V_m - V_0}{B}) + 1}$$ (9)

  
  

• Linoid: By setting $A = -A V_0$, $B = A$, $C = -1$, $D = -V_0$, $F = B$ and $H = 1$, we get the Hodgkin-Huxley linoid form,

  $$\alpha(V_m) = \frac{A(V_m - V_0)}{\exp(\frac{V_m - V_0}{B}) - 1}$$ (10)

  
  

Other forms can also be represented using this general approach as well. (The parametrized format of equation 7 is an extension of the GENESIS setupalpha command. It adds a new parameter $H$ that enables this to be used to represent a wider variety of functions, including constant expressions.)

We assume that the user interface for a tool such as Modeler's Workspace will provide a fill-in-the-blanks facility that triggers on the user's choice from a pull-down list for the category attribute, and displays one of the specialized equation forms for user input. This will help present the user with a slightly more familiar format, for those cases when they are interested in using one of the common types of equations.

ParametrizedForm does not have attributes related to tabular fill or interpolation. The reason is that ParametrizedForm is intended to describe gate variables using a particular, general equation. The issue of how the generalized equation is implemented in a simulator (for example, whether it is internally turned into a table of numbers, as in GENESIS' tabchannel) is a simulator-specific issue. Some simulators may not turn the generalized equation into a table at all. Therefore, it does not seem suitable to provide attributes related to table translation in the ParametrizedForm data structure. However, it is appropriate for the TabulatedForm, and therefore, TabulatedForm does have attributes that let a user specify how a table should be expanded by interpolation; see the next subsection.

5.2.3 The Tabulated Form

The TabulatedForm structure is used to represent gate variables with tabulated data. This can be useful in cases where a modeler has experimental data characterizing the behavior of a channel gate. The representation here provides for separate tables for the forward and backward rate functions. Each can be a one- or two-dimensional table of floating-point quantities stored in elem, along with variables startingValue and endingValue that express the range of the independent quantity in the table. Both startingValue and endingValue are lists of one-to-two floating-point numbers, to handle the case of 1-D and 2-D tables.

The interpolation attribute, using the InterpolationParameters structure, allows a user to express expectations about how a given table should be expanded by interpolation. This is useful if the user has a small number of data points, but expects those data points to be used to fill a larger table using a particular interpolation method. The possible values of method are restricted to a small number of predefined methods, to help ensure users see the same results in different simulation programs. The attribute interpolatedSize

5.2.4 The Equation Form

The EquationForm structure stores rate functions expressed as formulas. The Equation structure has the following parameters for this purpose: equation, a text string representing a formula; startingVoltage and endingVoltage, floating-point values representing the range of voltage values for which the formula is valid; assign, a list of ParameterAssignment structures for assigning values to symbolic parameters used in the formula; and an optional divisions attribute that can be used to specify the number of divisions into which the equation should be discretized over the range startingVoltage to endingVoltage.

The syntax of the expression language permitted in the equation attribute is taken from the C and Java languages. The differences are that we allow the caret symbol (^) as a short-form replacement for the pow function for exponentiation, and add the function nint, which is available in some UNIX C libraries but is not an ISO C standard function. The functions permitted in the text string representation of the formula are: cos, sin, tan, sqr, sqrt, pow, log, log10, exp, asin, acos, atan, abs, nint, ceil and floor. (`log' here is the natural logarithm.) The operators permitted in the text string representation of the formula are summarized in Table 1. All operators in formulae return floating-point values. For boolean operators, 0 and 0.0 are interpreted as ``false'' and all other values are interpreted as ``true''.

Table 1: A table of the expression operators available, based on the C language (Harbison and Steele, 1995). In the Class column, ``primary'' implies the construct is an operand, ``prefix'' implies the operation is applied to the following arguments, ``unary'' implies there is one argument, ``binary'' implies there are two arguments, and ``ternary'' implies there are three. The values in the Precedence column show how the order of different types of operation are determined. Higher integers imply higher precedence. For example, the expression a*b+c is evaluated as (a*b)+c because the * operator has higher precedence. The Associates column shows how the order of similar precedence operations is determined; for example, a - b + c is evaluated as (a - b) + c because the + and - operators are left-associative.

Tokens	Operator	Class	Precedence	Associates
(expression)	sub expression	primary	9	n/a
f(...)	function call	prefix	9	left
not, !	logical not	unary	8	right
-	negation	unary	7	right
^	power	binary	6	left
*	multiplication	binary	5	left
/	division	binary	5	left
+	addition	binary	3	left
-	subtraction	binary	3	left
and, &&	logical and	binary	3	left
or, ||	logical or	binary	2	left
xor	logical exclusive or	binary	2	left
? :	conditional	ternary	1	right

The conditional operator, ``? :'', warrants some elaboration. It is sometimes useful to express a discontinuous rate function. For example, Traub et al. (1991) use the following formula for $g_{C_a}/r$, a forward inactivation rate function used in one of their channel models:

$$g_{C_a}/r = \begin{cases}0.005 & \text{if $V_m \leq 0$}\\ \exp(-V_m/20)/200 & \text{if $V_m > 0$} \end{cases}$$ (11)

This can be expressed using the syntax of the EquationForm as follows:

Note that there is nothing preventing constructs that use nested conditionals. For example,

expresses a hypothetical conditional expression that involve three ranges of the value of variable V.

Finally, another point is worth clarifying in this context. EquationForm is not intended to express an equation that is used to fill a TabulatedForm table. The three representational forms (ParametrizedForm, TabulatedForm, EquationForm) are independent methods for describing channel behavior. A GENESIS or NEURON simulator plugin translating an EquationForm representation may generate a script-language function that embodies the EquationForm equation, or it may create a discretized, tabulated representation of the funtion. The latter case would be likely for GENESIS. However, if the translation program does produce a tabular representation of the equation, it should not then store the results in a TabulatedForm representation in the model definition. The different forms store the user's input; they should not be modified by a simulator plugin translation program.

5.2.5 Messages

To implement certain kinds of channels in a simulation, certain quantities must be exchanged between the channel gating variables and other elements in the cell model within which the channel is situated. This kind of value-passing or message-passing is specified using the ModelMessage structure list attached to the message attribute in GatingVariable.

A given Voltage-GatedChannel object may have zero or more messages. Each ModelMessage structure specifies a message name (e.g., ``voltage''), a source or destination (which could be, e.g., a calcium concentration object created from a ConcentrationPool template), and a direction (i.e., whether the message is coming from a source or going to a destination). References to models are implemented using XML XLink, with two attributes source and destination, both pointing to Model objects. This allows linking to any database object that is derived from the Model template, including all Neuron and channel models.

5.3 The Intracellular Mechanism Template

The IntracellularMechanism template is intended to serve as a common starting point for defining items such as calcium concentration pools.

This section is currently unfinished.

6 Example of Using the Model Description Language

In this section, we present an example of translating a model into the Modeler's Workspace representation defined in this document. The approach to translating into XML Schemas the object class definitions presented in the sections above is described in the companion document The Modeler's Workspace Notation for Describing Representations Intended for XML Encoding (Hucka, 2000). Appendix B gives the full listing of a preliminary version of an XML Schema corresponding to the Modeler's Workspace representation.

6.1 Channel Definitions

The model of a hippocampal pyramidal cell by Traub et al. (1991) requires defining several channel objects and an overall cell object. The channel models are listed below; the cell model is given in Section 6.2.

6.1.1 The $g_{Na}$ Channel

6.1.2 The $g_{Ca}$ Channel

6.1.3 The $g_{K(DR)}$ Channel

6.1.4 The $g_{K(AHP)}$ Channel

6.1.5 The $g_{K(C)}$ Channel

6.1.6 The $g_{K(A)}$ Channel

6.2 Neuron Definition

The object defined in this section is a rendition of the CA3 pyramidal neuron modeled by Traub et al. (1991). It refers to the channels defined in the previous section.

6.2.1 Neuron

This section is currently unfinished.

6.3 Other Object Definitions

The model described in this section refers to a number of external objects, such as Author and Reference. Example definitions are shown below.

6.3.1 Reference: Traub et al. 1991

6.3.2 Author: Roger Traub

6.3.3 Author: Robert Wong

6.3.4 Author: Richard Miles

6.3.5 Author: Hillary Michelson

6.3.6 Author: Kavita Shankar

6.3.7 Author: Michael Hucka

A. Procedure for Generating MWSUID Unique Identifiers for Database Objects

The Modeler's Workspace Database uses a unique identifier scheme patterned after message-id's used in Internet electronic mail (Crocker, 1982; Färber, 1998; Levinson, 1997). The MWSUID data type in Modeler's Workspace representations stores such an identifier. The technique for generating a MWSUID value is fairly simple, and is based on concatenating the following components, in order, into a text string:

1. The current time in UNIX Universal Time Format (UTC).
2. The hexadecimal process and thread identifiers of the running database program.
3. The ``at'' ('@') character.
4. The fully qualified domain name of the computer host running the Workspace Database.

UNIX UTC is the time counted as the number of seconds since 1970-01-01 00:00:00. Each character used in the text string is limited to one of the lower 126 ASCII printing characters (i.e., ASCII excluding characters such as space, newline, etc.).

The value of the ``current time'' used above is taken as the first time the object is saved by the user to the Workspace Database. Thereafter, the time component of the identifier is never changed--the object identifier is left frozen for that database object. If the object is edited, it retains its unique identifer; however, if the object is copied with the same database, or deleted, the unique identifier is lost and not reused. New objects or object copies always receive a new identifier. An example of a unique identifier generated using this scheme is: ``1484450292207948AF2C@obi-wan.bbb.caltech.edu''.

B. XML Schemas for MWML, the Modeler's Workspace Markup Language

This section is currently unfinished.

C. References

Biron, P. V., and Malhotra, A. (2000). XML Schema Part 2: Datatypes (W3C Working Draft 7 April 2000). Available via the World Wide Web at http://www.w3.org/TR/xmlschema-2/.

Bosak, J., and Bray, T. (1999). XML and the Second-Generation Web. Scientific American, May. Also available via the World Wide Web at http://www.sciam.com/1999/0599issue/0599bosak.html.

Bower, J. M., and Beeman, D. (1998). The Book of GENESIS: Exploring Realistic Neural Models with the GEneral NEural SImulation System (2nd Ed.). New York: Springer-Verlag.

Bray, T., Paoli, J., and Sperberg-McQueen, C. M. (1998) Extensible Markup Language (XML) 1.0, W3C Recommendation 10-February-1998. Available via the World Wide Web at http://www.w3.org/TR/1998/REC-xml-19980210.

Crocker, D. H. (1982). RFC #822: Standard for the Format of ARPA Internet Text Messages. Available via the World Wide Web at http://www.ietf.org/iesg/1rfc_index.txt.

Eriksson, H.-E., and Penker, M. (1998). UML Toolkit. New York: John Wiley & Sons.

Fallside, D. C. (2000). XML Schema Part 0: Primer. Available via the World Wide Web at http://www.w3.org/TR/xmlschema-0/.

Färber, C. A. (1998). Internet Draft: Guidelines for the Generation of Message IDs and Similar Unique Identifiers. Available via the World Wide Web at http://www.landfield.com/usefor/1998/Sep/0012.html.

Fogel, K. (2000). Open Source Development with CVS. The Coriolis Group.

Gardner, D., Abato, M., DeBellis, R., Erde, S. M., Knuth, K. H., White, T. (1999). Common Data Model 2000: Open Methods for Neuroscience Data Description and Interchange. Society for Neuroscience Abstracts, p. 1910.

Hucka, M., Shankar, K., and Emardson, S. (2000). The Modeler's Workspace Database Organization and Interaction. Unpublished manuscript, Division of Biology, The California Institute of Technology, Pasadena, California, U.S.A.

Lamport, L. (1994). LaTeX: A Document Preparation System. Addison-Wesley.

Levinson, E. (1997). RFC #2111: Content-ID and Message-ID Uniform Resource Locators. Available via the World Wide Web at http://www.ietf.org/iesg/1rfc_index.txt.

Mikkelsen, T., and Pheriogo, S. (1997). Practical Software Configuration Management. Upper Saddle River, NJ: Prentice-Hall.

Oestereich, B. (1999). Developing Software with UML: Object-Oriented Analysis and Design in Practice. Harlow, England: Addison-Wesley.

Thompson, H. S., Beech, D., Maloney, M., and Mendelsohn, N. (2000). XML Schema Part 1: Structures (W3C Working Draft 7 April 2000). Available via the World Wide Web at http://www.w3.org/TR/xmlschema-1/.

Traub, R. et al. (1991). A Model of a CA3 Hippocampal Pyramidal Neuron Incorporating Voltage-Clamp Data on Intrinsic Conductances. Journal of Neurophysiology, 66(2):635-650.

About this document ...

Preliminary Definitions of the Representation Schemas
Used in the Modeler's Workspace

This document was generated using the LaTeX2HTML translator Version 99.2beta8 (1.46)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -white -split +0 -show_section_numbers -image_type gif -no_navigation -local_icons -discard -mkdir -dir html mws-rep

The translation was initiated by on 2001-06-21