BACKGROUND
biological research is an increasingly information-rich endeavor, with complex, heterogeneous data being generated at rates that outstrip the ability to readily manage, integrate, and analyze it.
experimental platforms like mass spectrometry -based proteomics can produce tens to hundreds of gigabytes of data in a single run comprising less than two days of machine time.
a wide variety of similarly prodigious experimental approaches are in use by biologists.
there are also a large and growing number of publicly accessible repositories for biological information, the largest being genbank, uniprot, ensembl, and the ucsc genome browser.
each of these resources may contribute critical knowledge or data toward solving a biological research problem, but integrating their diverse structures and data types into a unified analysis remains very difficult.
one of our research endeavors that has encountered these issues is proteogenomic analysis of the human genome.
this uses proteomic data to examine the translation of rnas to proteins on a genome-wide scale.
we use computational techniques to map peptide-based ms data to their encoding genomic loci .
the approach is used to reveal alternatively spliced or frameshifted translation products that cannot be readily found by standard proteomic analysis methods.
this project involves the melding of several data sources that are large and heterogenous: ms-based proteomic data, genome sequences, gene annotation sets, snp sets, and more.
each ms data set may contain  <dig> or more individual spectra that must be analyzed in the context of one or more human genome sequences, each containing  <dig> nucleotides, along with multiple gene, est, cdna, and gene prediction annotation sets.
multiple spectral datasets are used, and they are available in a variety of formats depending on the source.
not only are data sets heterogeneous and unwieldy, but the sources and types of data available often change as technology progresses.
add to these the frequent changes in file formats, analysis approaches, and pipelines, all of which contribute to the steep challenges to maintaining an information management platform.
and change can go deeper than just new instruments or technologies employed; often, biological concepts change through time.
for example, the concept of "gene" has undergone many changes since mendel, and is currently experiencing another such change  <cit> .
when biological concepts change, information systems built to those concepts must often undergo extensive modification, raising the specter of extensive software maintenance.
for individual labs pursuing systems and genomic research, this is a daunting task.
when we set out to build an information system for the proteogenomic mapping project, these considerations led us to examine new means for managing, integrating, and analyzing project information.
we discovered an intriguing approach developed by jeff long, called "ultra-structure", which employs a relational database system with a non-standard schema and code development approach to deal with issues of heterogeneity, complexity, and change  <cit> .
this approach views all systems, regardless of their complexity, as the product of the "animation" of  relatively simple rules , not unlike wolfram's much more recent claims to "a new kind of science"  <cit> .
however, unlike wolfram's approach, long's approach is oriented towards practical problem solving, and has for more than twenty years been applied to concrete challenges such as document analysis for nuclear technologies  <cit>  and management of businesses  <cit> .
additionally, long has also successfully experimented with its application to the representation of music and the analysis of games.
when we encountered ultra-structure theory, it had not been applied to the biomedical and biological sciences, despite having properties well-suited to these fields, such as its ability to adapt to change and to integrate large heterogeneous datasets.
in this work, we examined whether ultra-structure could be practically applied to our proteogenomic annotation project, and then extended into other biological data management and integration tasks.
initially, we maintained two separate systems for this project, one using a traditional entity-relationship  modeling approach, and the second built using ultra-structure principles.
this allowed direct comparison of the approaches.
while the ultra-structure system is not limited to just one use , we focus here on illustrative examples drawn primarily from our proteogenomic annotation work.
the core of ultra-structure lies in expressing every piece of knowledge, information, or data as a "rule".
rules are managed in a standard relational database management system , but are organized in a unique way based on the concept of "ruleforms" .
each ruleform is a single table in the rdbms, representing a single syntactical structure for the rules it contains.
for example, a specific ruleform is used to declare the existence of entities of biological interest in a system , from small to large, including cells, molecules, dna, membranes, and test tubes.
all rules declaring bioentities are then expressed with identical syntax within this ruleform.
another type of ruleform is then used to express relationships between bioentities.
this bioentity network ruleform uses a specific syntactical form to express binary relationships such as "protein abc is-a tyrosine kinase" or "adenosine is-a nucleoside".
each ruleform, while specific about the syntactical structure of the rules it represents, is very general with regard to the concepts those rules can be used to model.
in both of the aforementioned ruleforms, there is nothing specific to any one field of biology encoded; they could be used equally well to express rules related to oncology research or proteogenomic annotation.
by representing everything about a system as rules , aspects of a system that are volatile are stored as data, rather than as database structure or computer code.
the programming code implemented for a system, known as "animation procedures", is general, operating at a high level on the structure of the rules rather than their specific content.
for the example of bioentities given above, any computer code written to operate on a bioentity operates on any kind of bioentity, not just those specific to a particular research field.
the area of managing biological information and complexity is an active one.
several projects have investigated issues of database integration from the perspectives of data warehousing  and database view integration .
some have utilized biological ontologies to manage biological information .
these warehousing approaches generally rely on the creation of a global schema, which is often large and complex, and dependent on the changing schemas of the databases they integrate.
this can lead to negative consequences, as stein related regarding the implosion of the integrated genome database  <cit> .
the "semantic web" is another approach to data integration that is gaining in popularity  <cit> .
this approach relies on open standards  to present data and relationships in a consistent, machine-readable manner.
automated procedures can traverse data relationships across the internet, allowing researchers  to access and integrate related information from around the world  <cit> .
such semantic approaches are in a similar vein as our work, attempting to find novel ways to effectively deal with the vast amounts of biological data we are faced with.
ultra-structure differs from the semantic web in that the latter is concerned with the machine-mediated exchange of data, whereas ultra-structure is focused on using a flexible rule-based system to manage local processes and data.
semantic web technologies could be overlaid on top of an ultra-structure system, allowing outside resources access to ultra-structure-managed data, thereby taking advantage of both approaches.
nadkarni and colleagues actively develop systems using the alternative database design methodology known as eav/cr , which has similarities to ultra-structure.
like ultra-structure, eav/cr systems offer an insulation against change by storing volatile conceptual and structural information as data.
however, the ultra-structure approach differs by also encoding information about behavior and processes as well, something these systems do not address.
while our implementation stores gigabytes of project data , it also implements processes such as the translation of an rna transcript to a protein molecule, encoding the rules of translation  in the database.
we have begun constructing a workflow management subsystem, tracking data analyses and processes using the same database structures.
when domain knowledge about any of these processes changes, such as discovery of new alternative genetic codes, database rules are readily updated.
ultra-structure is unique in this regard, as it can deal with information management on a variety of scales, including domain knowledge, experimental information, and biological and laboratory processes.
here we examine in more depth the application of ultra-structure to proteogenomic mapping through the use of concrete implementation examples.
methods
most approaches to information management model a system in terms of the concrete objects and relationships that are visible to the user or programmer.
the perspective of ultra-structure is that these surface-level features are the results of ongoing, dynamic processes.
these processes generate the objects, relationships, and attributes that we see as the outward manifestation of the system, and an ultra-structure system attempts to model these fundamental processes.
ultra-structure comes from a background of process philosophy  <cit> , which holds that processes, not objects, are the fundamental metaphysical constructs of the world.
in modern biological research, the surface-level features  are continually changing.
for example, in a little over  <dig> years, dna sequencing methods have progressed from early maxam-gilbert sequencing, through sanger sequencing, to microarray sequencing, on up through the current state-of-the-art next-generation sequencing methods.
when a database system is structured to directly mirror the data types produced by a changeable technology like this, it must be reconfigured each time the technology changes, along with sometimes extensive changes to the associated computer code.
the result is that such databases will grow in complexity until they suffer from significant maintenance challenges, at which point it may be simpler to completely scrap the system and start over.
to address this, ultra-structure introduces two primary levels of abstraction between the database management system and the "surface structure" that the user interacts with to store, analyze, and visualize their project data: the "deep structure" and the "middle structure" .
below, we briefly cover the basics of the ultra-structure implementation.
rather than a full exposition, we cover further implementation details as part of the examples shown in the "results" section.
rules
rules are the core of ultra-structure, as they govern the fundamental ongoing processes that create the system being modeled.
they are used to represent all changeable aspects of the system, including data, operational processes, attributes, etc.
for example, simple declarative rules for objects in the system are shown in figure  <dig>
in contrast to the "if/then" interpretation of rules in an expert system, ultra-structure rules are interpreted as "if/consider" constructs.
when the conditions on the left-hand side of a rule – known as "factors" – are met, the system is instructed to consider the information of the right-hand side – "considerations" – in subsequent processing.
this allows multiple rules to express considerations that apply to a given antecedent; as a result, we may conditionally modify how rules are interpreted.
for instance, in our system, one rule may state that in general, all sequence locations should be calculated relative to the 5' end of a chromosome.
but, another rule may declare that short peptide sequences are declared relative to the start of the coding sequence for a gene.
when rules are being interpreted, these two rules would present a conflict.
however, since applicable rules are all considered before selecting an outcome, other rules in the system can influence processing, such as by defining an order of precedence so that the rules related to peptide locations take priority.
while this has similarities to class inheritance in object-oriented systems, it is readily modifiable.
if we later need to change the interpretation priority for rule types, only one rule need be modified that tells the system how to prioritize the considerations.
rules are not completely free-form, though; they are subject to a variety of constraints, which are collectively known as the "deep structure".
deep structure
the "deep structure" abstraction level is designed to represent those things about a domain that are fixed and unchanging.
technically, the deep structure consists of the syntactical and semantic forms for expressing rules relevant to the application domain , as well as the associated computer code  that manipulates those rules.
ruleforms specify all the logically possible forms that a rule may take: "ruleforms are to collections of rules as numbers are to collections of things.
... ruleforms abstract morphology, while numbers abstract quantity; in a sense, ruleforms model the geometry of rules."
<cit>  in practice, ruleforms are implemented as database tables: the ruleform itself is the table definition, and individual rules that conform to that ruleform are rows within that table.
factors are implemented as a primary key  constraint on the ruleform table; considerations  are then the remainder of the columns of the table.
standard database system query mechanisms can be leveraged to quickly find applicable factors  for given system inputs, and furthermore, modern database systems can easily handle and query millions of rules.
the ruleform abstraction allows their use for many distinct functions, while keeping the number of tables low and comprehensible.
the development of ruleforms for a given domain comes about from following an iterative development process, starting with a high-level process-oriented perspective, implementation, and refinement.
across broad domains for which ultra-structure systems have been implemented, typical systems utilize  <dig> or fewer ruleforms .
while ruleforms can prescribe the forms of all rules of a system, the rules themselves are inanimate; they need to be interpreted in order to produce the desired behavior of the system.
the primary feature of the associated animation procedures is that they are implemented in a general way without detailed domain knowledge, allowing the system to accommodate new information or procedures without changing the underlying software.
since an ultra-structure system encodes information as formal rules in a database, including how rules are to be interpreted, this simplifies the needs for animation procedures, so that they must only deal with control logic, such as which ruleforms to inspect and when, and how to get data into and out of the system.
specific actions carried out by the software are driven by the contents of the rules being operated on; changing the rules changes the actions performed by the system.
as a result, animation procedure code will not need to be changed as domain knowledge changes.
in this regard, the animation procedures of ultra-structure are similar to the inference engines found in expert systems, but differ in the fact that they access different tables for different kinds of rules.
for example, one common need of many biological research systems is to calculate spatial or structural relationships between two items, such as whether a nucleotide is within a gene , or how close two amino acid residues are along a protein string.
in our system, an animation procedure deals with any type of arbitrary spatial calculation on linear strings, regardless of what type they are.
the biology-specific calculations, such as calculating all exons within a gene, are determined by protocol rules in the system.
together, the collection of ruleforms and the animation procedures that operate on them constitute the deep structure of an ultra-structure system.
in the case of our system, we have implemented  a deep structure which aims to capture the fundamental computational realities associated with biological research.
an example of deep structure in our system arises from the need to declare the existence of entities such as genes, proteins, cells, samples, and amino acids.
the bioentity ruleform from figure  <dig> is an example of an "existential ruleform", which is used to declare the existence of some concept or entity in the system: the "things" the system knows about.
our bioentity ruleform defines things that participate in biological processes, or are otherwise of biological interest.
this includes a broad diversity of concepts, from the isotope 14c and the third exon of the β-catenin gene, to broad categories, such as "non-polar amino acids".
a group of bioentities is itself considered a proper bioentity because it is subject to the same kinds of rules; rules that apply to the group also apply to the members of that group.
this ruleform defines the structure for rules declaring the existence of biological entities of any kind.
this is in contrast to a more standard rdbms, where different types of biological entities would typically be stored in separate tables.
here, if a new type of biological entity comes into play later, there is no change to the underling system; the "bioentity" ruleform can accommodate nearly any type of thing we might care to declare and track in the system.
while the "things" in a pure entity-attribute-value system might all be formally represented as generic "entities" or "objects", this is not the case in an ultra-structure system; everything in our universe of discourse is not a bioentity.
other existential ruleforms for our system are shown in table  <dig>  and include foundational concepts such as resources, attributes, locations, and units of measurement.
several existential ruleforms  are described, with illustrative examples.
in addition to the declared objects like bioentities, there can be a set of associated ruleforms that express attributes for them.
for example, in proteomic research, the masses of molecules must be tracked.
these can be expressed in different ways, based on how isotope distributions are accounted for, including "monoisotopic mass", "average isotopic mass", or "most abundant isotopic mass".
we express this information using the bioentity attribute ruleform shown in figure 3a, which is based on entity-attribute-value design .
the factors of this ruleform include a bioentity and an attribute, the latter defined with an existential ruleform shown in figure 3b.
attributes can track any kind of arbitrary information about an entity.
there are multiple consideration columns present to effectively represent values of different data types, but in this case, constraints ensure that only one may be non-null, reflected by the "value type" consideration of the attribute ruleform.
in addition to unconstrained columns containing numeric or text values , other columns may refer to other existential ruleforms, allowing different types of existential entities to be related to one another.
each type of existential ruleform may have an associated attribute ruleform .
once an entity is declared to exist in an existential ruleform, it can be combined with other entities to create new "network" rules that express relationships between them.
figure 4a shows a simplified example of a network ruleform in our system.
it expresses arbitrary binary relationships between bioentities using "subject/predicate/object"-style triples, where "subject" and "object" can be any entry represented in the bioentity ruleform; the predicate can be any relationship defined in the relationship existential ruleform .
this network ruleform can be used to specify which entities are the members of a group, the group itself being a bioentity.
in this framework, it is possible to build up networks, hierarchies, and relationships between a variety of entities easily.
users can directly add new relationship rules to the system to define whatever associations they might need, without modifying the database structure itself.
though omitted in the figures for clarity, several ruleforms have an additional factor called "resource", used for system provenance.
the bioentity attribute ruleform has a resource factor, which allows recording who declared the average mass of carbon to be  <dig>  daltons, or which ms analysis file contained the information that peptide ion  <dig> has a charge value of  <dig>  since the resource is a factor , this allows the storage of potentially conflicting information in separate rules.
this addresses the fact that information in scientific endeavors is often tentative and/or integrated from a variety of sources.
otherwise, information stored in the system would be limited to dogmatic declarations of concrete fact.
the resource factor is used wherever the declaration of data or rules may be tentative, conflicting, or changing.
other ruleforms in our system are used to define additional kinds of rules: "authorization rules" indicate what combinations of information are valid or permitted; "meta-rules" describe how to read other rules; and "protocol rules" specify sequences of actions and can be used to implement complex processes and workflows.
middle structure
the next layer of abstraction, the "middle structure", can best be thought of as representing the "laws" of the system; that is, the specific rules and constraints that govern a system's operation.
the middle structure is the content of the deep structure's ruleforms.
this represents the types of relationships that may occur between data in the system, and the processes that data undergo during analysis or query.
in our system, the middle structure declares the types of data kept about our biological research operations, the relationships between them, and the kinds of operations that can occur on the data.
whenever procedures, file formats, or data types change, the middle structure is changed to reflect this.
often the relevant database system changes can be made by the non-programmer, by modifying the database entries that comprise the rules of the system.
this puts the task of regular maintenance more fully into the hands of the systems users, who are the subject experts, rather than  third-party programmers.
in our system the middle structure encompasses bioentity rules defining various genome annotation sets, mass spectra, and amino acids; resource rules defining our gfs software, genome annotation providers, and individual gfs analysis output files; location rules defining specific regions of genomic sequence for annotations as well as gfs-mapped peptide locations; and several others.
another lab performing bacterial community analyses – a wholly different research area – could take the same deep structure, but instead populate the middle structure with a separate set of rules, such as bioentity rules defining restriction enzymes and bacterial species, bioentity network rules reflecting taxonomic relationships between bacterial species, events denoting specific analysis experiments, and locations representing lab freezer locations of samples.
we are in fact implementing a system for bacterial community analysis with collaborators, using our proteogenomic deep structure as a basis.
one brief example is in order.
we regularly exploit the concept of "overlap" between two sequences against a particular genome location, such as to find where peptides overlap annotated exons or genes.
the procedures for calculating overlap are not part of the structure or code of the system, since it reflects a specific use case; instead, it is represented by a small number of rules that are readily changed or added to as demands warrant.
many other relationships besides simple "overlap" may be of interest, such as "located downstream" or "contains"; these and others can be defined by the end user.
ultimately, by not over-specifying the deep structure of the system, users are able to modify the middle structure to obtain the surface structure they desire.
surface structure
in an ultra-structure system, the "surface structure" – the actual appearance of the real-world system – is not explicitly modeled or stored anywhere; rather, animation procedures driven by the content of the rule base  generate it.
surface structure is volatile in biological research, where experimental protocols change, new data types become available, and concepts are continually revised in light of new information.
as a result, information systems modeled on surface structure directly are themselves volatile, lending to maintenance issues.
an example of surface structure generated by our system can be seen in user interfaces derived from the combination of middle structure rules with general animation procedures.
for example, when a user queries the system to find a list of existing genomic annotations that positionally coincide with a peptide match from a tandem ms  experiment, the ultra-structure system dynamically generates the interface and resulting lists by examining its rules to determine what it means for genomic regions to overlap, as well as what values should be queried for and then returned to the user.
in our system, the surface structure is generated using animation procedures that interact with the rdbms middle and deep structure.
our system is built on the open source postgresql database server  <cit> .
animation procedures are implemented as internal database procedures written in either pl/pgsql  or sql , or as client-side methods written in java, using the hibernate  <cit>  object-relational mapping  library, or a combination of both.
in general, animation procedures that perform large amounts of database processing, or that require a great deal of dynamic query generation are implemented as internal database procedures, while simpler procedures, and those whose execution requires control or data structures that are difficult to implement in the database are performed on the client side.
we are also developing a web interface to the system using stripes  <cit> , an open source web application framework for java.
examples of some prototype interfaces can be seen online at .
some example sql queries are provided in additional file  <dig> for interested readers.
prototype code for the system is also provided in additional file  <dig>
RESULTS
at the beginning of this project, we developed the ultra-structure system while also maintaining a traditional er-modeled database for the project.
the latter was in place until it became clear that the ultra-structure system would reach sufficient utility for day-to-day use.
the er system developed to contain  <dig> individual tables representing everything from ms datasets to analysis results to various genomic annotation datasets downloaded from ucsc's genome resources  <cit> .
the er approach provided a quick start-up due to our familiarity with it at the time, but as the scope of the project evolved, shortcomings became apparent.
for instance, its structure assumed all annotations and proteomic data had coordinates relative to a single genome.
the subsequent availability of multiple genome drafts along with genomes of multiple individuals  <cit> , necessitated substantial redesign, which would have resulted in more tables to track and coordinate all the different versions of genomes against annotations and proteomic runs.
other shortcomings were more fundamental; for example, it was necessary to build into the er model some fixed representation for a "gene".
however, the definition of a gene is changing as more is uncovered about processes such as trans-splicing  <cit> , where one messenger rna is produced by concatenating exons from separate pre-mrnas.
on the other hand, implementation of the ultra-structure system was at first challenging, because the design process required a new way of thinking that focused on separating universal features of the system , from the changeable features .
the process has been iterative; we started with a core of ruleforms  representing the basics such as bioentities, networking of bioentities, resources, and events.
as we began implementing rules and features, we came upon the need for new ruleforms, such as one representing location information, and another representing bioentity attributes.
as we have become more adept at the ultra-structure approach, each refinement to the system has occurred more quickly, and resulted in a more coherent design.
the resulting ultra-structure system stores all the data that our original database could, and stores it in a more comprehensible manner, using fewer tables .
we have translated procedures from large, complex software functions into ultra-structure animation procedures that are smaller, easier to comprehend, and driven by rules in the database that can be altered to extend the capabilities of the system.
using our proteogenomic annotation project as an example, we describe the modeling processes and considerations that we faced in transitioning from a traditional er-modeled system to one based on ultra-structure.
rather than trying to be comprehensive in the description of the system, we focus in on several examples that illustrate the types of changes and considerations made.
further detail can be gleaned by examination of the system and documentation itself, prototype code for which is attached as a supplemental file.
example 1: modeling and implementing hierarchies of mass spectrometry data
hierarchies are ubiquitous in biological research, both in the subject of the research  and in the artifacts of the research itself .
these can be represented with er modeling methods by creating a series of tables linked by integrity constraints, with each table representing entities at successively deeper levels of the hierarchy.
mass spectrometry data is naturally hierarchical, with an experiment usually comprised of a group of separate lc-ms  runs, each of which consists of multiple spectra, which in turn are each comprised of series of peaks .
such data can be represented in a standard er design as shown in figure 5b, where the hierarchy of the data is mirrored by a hierarchy of tables in the database.
this has the benefit of being an intuitive and relatively natural representation.
ultra-structure instead represents this hierarchy by abstracting the concept of networks of bioentities in a general manner.
a grouping of data points such as a spectrum is a bioentity, as are each of the data points themselves .
the network itself is implemented in a new ruleform , the bioentity network .
this ruleform captures a high level, general aspect of the system: that there exist relationships between entities that participate in biological processes or interactions.
for the example of ms data, we define a relationship using the relationship ruleform  such as "has-precursor-ion", then use this to relate each specific product ion with the specific precursor ion it was derived from.
in a similar way, we can use an "included-in" relationship to associate a particular run with the dataset it is a part of.
these relationships existed in the er-based system as foreign key constraints.
however, a foreign key can only indicate that data from one table has an association with data from another table; it cannot formally and explicitly specify the nature of that relationship .
in ultra-structure, the relationship is encoded as data  within the middle structure of the system, providing explicit information about the nature of the relationship to human users and software.
new relationships are created by adding new rules to the relationship ruleform, which are immediately available for creating new rules in the bioentity network ruleform.
nearly any arbitrary network of bioentities can be formed, without changing the database structure.
it is straightforward to group ms data in new ways, for example to accommodate gel-based data instead of lc-ms runs.
in contrast, for the er model, new representations or hierarchy models are likely to involve changing the database schema itself, which in turn impacts the computer code that interacts with it.
each bioentity  may have one or more attributes.
for example, ion peaks may have an intensity and an associated mass, as well as an electrical charge.
we represent such attributes using a separate ruleform, "bioentity attribute" .
users can make the system aware of new attributes by adding the appropriate rules in the attributes ruleform .
as such, the bioentity attribute ruleform can be used to express the value of any attribute of any bioentity.
this attribute representation is similar to the eav/cr approach  <cit> , but in the latter, the attributes of all kinds of objects  are represented using an identical table structure, whereas ultra-structure attribute tables are tailored to each semantically distinct type of entity , reflecting fundamental differences in their use in the system.
for example, the bioentity attribute ruleform has a resource factor that facilitates provenance, which may not be necessary for attributes on other kinds of objects.
since ultra-structure ruleforms represent a higher-level abstraction than er-modeled tables, these three tables can now be used to represent much more than just ms/ms datasets.
indeed, the only things the original er tables could represent were ms/ms datasets; to begin using another type of dataset would have required remodeling the existing tables or adding new tables.
this flexibility of the ultra-structure approach will be demonstrated next.
example 2: representing genomic features
one aspect of our project is to map the ms-analyzed peptide spectra to location on one or more human genome sequences, then correlate those locations with features such as genes and exons that are part of publicly available annotation sets.
our er database implemented a problem-specific table structure, mirroring the mysql database dumps from ucsc  <cit> , as shown in figure 6a.
we found this design to have two limitations, illustrated in figure 6b.
first, the table structure makes a specific assumption about the types of information that must be recorded for a gene, and how these are related to one another.
if new features or structures for a gene are uncovered, such as a new splicing regulator in an intron, then the table must be redesigned, along with all the computer code written to interact with it.
second, some features of a gene, such as introns, are not made explicit in this model, but must be derived by calculations using other features.
this makes it harder for a human to review the source data in the database, and makes errors in the data or the code that interprets the data more likely.
the ultra-structure approach instead encourages taking a step back and looking more generally at the problem of representing annotation data.
we implemented a solution that took advantage of the existing ruleforms, considerably streamlining the representation.
at its core, the approach declares that all annotations are simply bioentities, such as "ucsc known gene transcript alignment uc001fet.
<dig> exon 1" or "ensembl transcript enst <dig> 5' utr".
as such, the abstract entities that the annotations represent  are declared independently of specific coordinates in an arbitrary genome draft.
this facilitates both representational efficiency and biological interpretation, because some annotations can appear in different drafts of a genome, and across genomes .
in essence, this abstraction provides an independent existence for the concepts associated with particular genomic features.
researchers or computer code can thus interact broadly and in a relational manner with them, without having to reference specific genomic coordinates, just as it is possible to talk about a building on a university campus by name and relate it to nearby buildings without having to refer to street addresses or geographic coordinates.
once established as bioentities, annotations can then be related to one another using bioentity network rules, expressing that this exon is part of that transcript, for example.
we need only declare the types of relationships that describe these connections.
using this representation, we can easily maintain abstract groupings or hierarchies of annotations that are biologically relevant.
for example, we use this to create a grouping for all annotations belonging to the set of "known gene annotations for human genome draft 18".
we can also use it to create groups such as "human genome draft  <dig> exons" or "transcripts associated with breast cancer".
representing all these open-ended grouping choices using a traditional er model requires additional tables and associated infrastructure, while ultra-structure provides for this capability with no further alterations of the database's schema.
example 3: representing genomic locations and positions
our project also needs to express discrete genomic coordinates for annotations and perform computations such as determining which  genes a particular peptide occurs in.
our original er system represented genomic locations similarly to the ucsc tables, capturing the surface structure of the problem in the database schema .
in designing the ultra-structure representation for locations, our goal was an abstract and general representation of locational information, flexible enough to represent other types of location information besides genomic regions.
the result is a location existential ruleform and several accessory ruleforms  that can represent many types of locations common to biological research: subcellular organelles, motifs and regions in peptide strands, test tubes in lab freezers, internet addresses of datasets, and even word and concept locations within journal articles and other text mining inputs.
the ruleform uses a consideration called "context", which is a reference to the location context ruleform, specifying the frame of reference in which a specific location is valid.
for instance, a genomic coordinate for the 18th draft of the human genome can only be interpreted in the context of the 18th draft; it makes no sense in the context of the 17th draft, since the underlying genome sequence is different.
similarly, the location of a test tube in a lab freezer will not make sense for calculations on genomic coordinates.
the location context attribute is then used to define the coordinate space of locations for a particular context.
for example, this allows specification that a "genomic coordinate" context must define a "chromosome", "strand", "start position", and "stop position", or that a "freezer location" context for protein samples is defined in terms of "room", "freezer", "shelf", "rack", "box", and "slot".
the location attribute ruleform is then used to store a specific location's coordinates, using a form similar to the bioentity attribute ruleform.
for example, "genomic location 100" is described by four rule entries: one for chromosome , one for directionality , and one each for "start" and "stop" positions, as seen in figure 7b.
specific locations, such as "genomic location 100", maintain a separate existence from any bioentity that may refer to them.
just as an annotation  can have multiple locations , so too can a single location correspond to several annotations.
we then use the bioentity location ruleform to connect gene annotation bioentities to their associated locations .
but it is not limited to that use; it is also used to associate matched peptides from mass spectrometric analyses to their genomic location.
by implementing a solution for one location-related purpose, we get a solution to another location-based problem essentially "for free".
example 4: animation procedures for generalized location calculations
as mentioned before, animation procedures perform procedural tasks without being programmed using any case or problem-specific knowledge .
one example is mapping ms/ms peptide data to genome coordinates, and then finding out what existing annotations say about those coordinates.
for this task, we need to be able to calculate relationships between locations, such as "contains", "before", or "after".
some ms/ms data may map a peptide with high confidence to a particular nucleotide sequence on chromosome 17; we will want to find all existing genomic annotations that contain, are contained by, overlap the 3' end of, or are located downstream of this location .
there can be many other relationships that are interesting, and it is difficult to predict ahead of time all the types of relationships users may want to examine.
but in the end, we are always dealing with arbitrary calculations on two locations that share a relationship, in order to find any relevant associated bioentities.
using the location-related ruleforms as the basis, we implemented a general animation procedure for performing coordinate-based location calculations.
for example, we know that genomic region a contains genomic region b if these regions are on the same strand of the same chromosome, and the start and stop positions of b are between those of a. this is defined explicitly as a set of rules in the location relationship ruleform that define a containment relationship .
if the rules for containment change , the only changes that need be made are to the rules that define the relationship.
other relationships can be similarly defined, such as "overlaps 3' end", "is downstream of", and "is upstream of".
the animation procedure takes as input a location, a location context , and a relationship.
the location acts as an anchor for the search, which will retrieve all locations in the given context such that the given relationship holds.
the animation procedure uses this information to generate a search key for rules in the location relationship ruleform  that define what conditions must be true to satisfy the user's query.
figure 8b shows the rules that would be selected for a particular genomic location overlap relationship.
the considerations of these rules, defining the conditions that exist between query location and retrieved location, are used to dynamically generate an sql statement that retrieves the requested locations.
these are then used to query another ruleform to find bioentities that are located at these locations; this information is then displayed to the user in a web browser interface .
nothing in either the structure of the location relationship ruleform or the code of the animation procedure is specific to genomic locations.
the end user could add location relationship definitions for genomes, freezers, or cells, and those would be immediately queryable within the user interface to the location procedures.
by storing this information as rules rather than in code, the biologist end user has great flexibility in adjusting the system to their needs.
in our project, we have most extensively used this capability to correlate results of our proteogenomic mapping with existing annotation sets in our database, to be reported in a separate publication.
example 5: animation procedure for deductive inference
expressing everything as a rule in the system facilitates automatic deductive inference procedures that can transform implicit assumptions and relationships into explicit rules.
for example, "inverse" rules can automatically be generated; if "serine is-a polar amino acid", then "polar amino acid includes serine" can be inferred.
rules can also be chained together.
a rule may declare that "gene x encodes-product protein a", and that "protein a is-a methyltransferase".
if the relationships "encodes-product" and "is-a" are declared to be validly combinable to deduce the resulting relationship of "gene-type", chaining these two rules together makes explicit that "gene x gene-type methyltransferase".
such a deductive process serves first as a mechanism for consistency checking, and secondly to uncover new connections in the data that may have been implicit but not obvious.
we implemented a general deductive inference animation procedure for each of our network ruleforms.
inverse rule generation is driven by the relationship of the network rule, which by explicit definition knows its corresponding inverse relationship ; the procedure simply inserts a new rule using this inverse relationship and swapping the subject and object of the original rule.
it also chains network rules together in logically valid ways to deduce new relationships, governed by the relationship chain ruleform.
an overview is shown in figure  <dig>  the animation procedure assembles pairs of network rules based on whether the object of the first rule is equal to the subject of the second rule .
for each pair, it is then determined whether there is a relationship chain rule that pertains to the combination of relationships represented .
if yes, a new rule can be deduced by assembling pieces of the input rules and the matching chain rule .
the nature of the deduced rule is dependent on the rules inspected in the course of the deduction; the animation procedure simply carries out a series of mechanical database queries and manipulations, purposefully ignorant of the details of what it is computing.
hence, we can easily tell the system that the "is-a" relationship is transitive by inserting an appropriate relationship chain rule whose "input 1", "input 2", and "result" columns are all set to "is-a".
thus, we do not have to code a special case into the deduction procedure to deal with transitive "is-a" relationships, and deduction using other relationships with more specific meaning  are easily modified by changing the meta-rules.
one practical example of this is that if the system has a rule linking a specific exon to a particular group of exons , the system can automatically deduce its putative membership in other applicable groups  using the network structure and the relationship chain rules for group membership.
by reviewing such deductions, a user may gain new insights into previously opaque relationships.
and if a deduced rule is thought contradictory or incorrect vis-a-vis known facts, then this points to the incorrectness of the premises  from which it was derived.
performing that kind of review can be a powerful method for checking the consistency of data and assumptions in the system.
discussion
a goal of ultra-structure development is to converge upon a deep structure sufficiently general to represent a broad domain of interest, such as systems biology research.
the expectation is that the deep structure will be arrived at iteratively, through testing implementations, experimenting, and redesigning.
that has been our experience in implementing this system.
for example, in an earlier iteration, there was no explicit ruleform for representing locations; we represented locations as bioentities.
without a separate concept of location, the system mixed the concept of coordinates of a genomic feature like an exon, with the concept of the exon itself.
as we began doing calculations that were unique to location information, such as computing "containment" relationships, it became clear that our original deep structure  was too limited.
by separating the concept of a thing like an exon into the bioentities ruleform, and its location into a new locations ruleform, our system made a lot more sense.
at the same time, the development of the location-related ruleforms opened up a greater set of capabilities for other purposes.
this process illustrates long's hypothesis that notational systems used to represent information can often present inherent limitations of which users are unaware, and that switching the underlying notation often resolves problems and presents new possibilities  <cit> .
redesigning the ruleforms in ultra-structure has impact throughout the system , and is much like any database redesign, in that it consumes time and effort.
the key with ultra-structure is then to converge on a foundational deep structure relatively early in the system's evolution.
if the result is sufficiently general, further redesigns are minimized, even if very different needs arise.
an example is our evolution of the system to represent gene annotations on dna in two distinct parts: the conceptual entities themselves  and networks thereof, and the discrete locations of those entities .
if genome coordinate systems later change, or gene concepts change, this underlying structure is unlikely to need major redesign.
for example, a great deal of work is now invested in characterizing methylation patterns on the histones around which dna is wound, since this appears to have significant regulatory effects on which genes are expressed or when.
hence, there may soon come a time at which annotations will need to include histone methylation patterns.
we cannot anticipate the precise way that these will be represented, but it is likely that the system is now general enough to readily accommodate this information without modification to the rule forms.
as the deep structure has emerged and stabilized, subsequent modifications to the system have revolved increasingly around the creation of new rules .
when we were in the phase of implementing the ruleforms, the ultra-structure approach seemed slow and difficult to implement, perhaps due to our lack of experience with it.
the high-level perspective required for ultra-structure design is quite different from the more standard design methodologies we were accustomed to.
fortunately, as an appropriate and general implementation of ruleforms and animation procedures was developed, we saw ever-increasing efficiency from our efforts, since each implemented part of the deep structure can be utilized for many purposes within the system, amortizing the programming and design workload.
an example is the time spent designing and redesigning our representation of locations.
initially this took longer to get right in ultra-structure than it would have using the standard approach of designating specific columns in specific database tables to represent features such as exon start and stop positions.
but now that it is in place, nearly any type of location calculation can be readily implemented.
we could use the system's deductive capability to determine anything from which planet a particular sample is located on, to  which organelle a protein is expressed inside of, or which freezer has a patient specimen.
little if any additional programming will be required, excepting the case where we realize our representation is not general enough.
in that case, some redesign work may be applied, but with the benefit of further generalizing the system.
an example of this kind of generality is in our recording of sequence tags.
sequence tags are short subsequences of a larger peptide , and can be used in conjunction with other information to help identify that larger peptide.
in early iterations of our system, we stored sequence tags as textual attribute values on peptide bioentities, e.g., "dnw" as part of the peptide "dnwdsvtstf".
after creation of the location ruleforms, we realized that sequence tags could be recast in the same way as any other genome annotation, with a bioentity representing the existence of a specific tag, and a set of location entries that describe where the tag is located relative to its parent peptide sequence.
we defined new "peptide location" rules in the middle structure of the location context table, with coordinates for the peptide, start, and stop positions.
these rules echo those used to record genomic locations, but without the strand coordinate .
now, sequence tags are handled like any other annotations on a sequence, except that these are annotations relative to a peptide sequence, whereas genes, exons, and the like are annotations relative to a chromosomal sequence.
interpreting sequence tags as just another type of sequence annotation is the kind of insight that ultra-structure was designed to reveal, bringing implementation efficiency and increased semantic clarity.
making explicit the information about what each thing is in the bioentities and bioentities network table, along with where each thing is in the locations-related tables, improves the readability and understandability of the data in the system for human users.
this is important because a key objective of ultra-structure design is to allow subject experts to directly interact with the rules of a system, without having to explain themselves to a programmer or rely on adequate documentation of existing systems to discover what the rules are.
achieving this makes systems more transparent and eliminates one of the greatest sources of error in systems: the communication between subject experts and computer experts generically referred to as "requirements analysis".
this allows subject experts to define their own "terms of art" as needed.
ultra-structure provides the ability to readily adapt to evolving requirements and conceptual change in the real world.
for example, the classical conception of a gene is that it comprises a contiguous region on one chromosomal strand, yielding a contiguous transcript which then undergoes splicing to produce the mature rna through the excision of intron regions.
this was the basis for our representation of genes in our original database system.
recently, new conceptual challenges to this classical model have arisen, including discovery of significant numbers of gene regions that produce distinct but overlapping transcripts, nested transcripts, and in some cases, mature rnas resulting from trans-gene splicing  <cit> .
our original representation of a gene, with a single start and stop site bounding the transcript, would not readily admit oddities like trans-splicing.
however, our ultra-structure system represents genes as just instances of bioentities, each of which can be networked to some set of exons , themselves each of which can have arbitrary location information associated and/or network relationships to other annotations, such as identified ms/ms peptides.
this scheme accommodates nearly any possible gene or transcript architecture.
the ultra-structure system stores trans-spliced transcripts in exactly the same way it stores more canonical, orf-based transcripts.
in fitting with long's original claims, we have found that our ultra-structure system accommodates changing concepts, procedures, and analyses quite well.
the high degree of modifiability of the system has resulted in other benefits.
one instance of this was the implementation of computing containment relationships on genomes, such as finding which overlapping gene annotations contain a given exon or peptide location.
initially the rules were set up to analyze containment relationships only on the same strand of a chromosome.
at one point we wanted to examine whether there were also any annotations of interest in the same region, but on the opposite strand.
we added this capability to the system with just four new middle structure rules added to the database: one to define a relationship ") and three to define the conditions for the relationship .
this was a simple procedure that could be performed directly and quickly by the end user with no programing or other system alteration.
performance of our initial prototype system is slower than if traditional er modeling techniques were used.
this is a well-known aspect of systems using decomposed schemas  in that "entity-centered" queries  perform on par with er-modeled systems, but "attribute-centered" queries  perform more slowly, due to repeated self-joins.
our work has not focused on performance optimizations yet, but this is the focus of ongoing work.
potential solutions exist, ranging from index tuning, alternative query techniques, system configuration tuning, and hardware improvements  <cit> .
additionally, performance advances in other reasoning systems  can potentially help here.
systems biology is a rapidly changing field, and perhaps one the greatest obstacles to progress is the challenge of effective data management, integration, and analysis across very large, heterogeneous, and complex data sets.
our proteogenomic mapping project presents a microcosm of these challenges with its need to integrate complex genomic and proteomic data sets, all the while keeping up with the rapidly changing technologies in both fields.
at present, our prototype ultra-structure system is already yielding significant payoff for this task.
but perhaps more significantly, it now provides a platform that can be readily adapted to other challenges.
that is not just theoretical; we are now beginning to apply the system to other tasks such as managing and analyzing microbiome data and managing and analyzing data from a next-generation sequencing facility.
the efforts invested in the deep structure for proteogenomics have immediate application in these other domains.
CONCLUSIONS
our move to the ultra-structure system was not without challenge.
thinking in the "ultra-structure way" was initially difficult, and progress was slow.
at times we wondered whether a payoff would arrive, or whether we should just go back to the original, more standard approach.
but once we reached a threshold of having a stable deep structure, progress has accelerated.
now it is becoming increasingly difficult for us to envision going back to our pre-ultra-structure methods, because we see payoffs not only in terms of implementation efficiency, but also in helping us think about our data management and analyses in new ways.
this leads us to ponder the question originally raised by long: could it be that the abstractions and notational systems we have been using were limiting forward progress, without us knowing it?
biological research is no longer content with just studying bits and pieces of an organism or cell, but is instead focused on examining the interactions and dynamics of entire biological systems.
perhaps the needs of the field have outgrown the traditional tools used to represent and analyze biological data.
we wonder: will new mental tools like ultra-structure design clarify or elucidate aspects of biology that may be concealed by more traditional abstractions?
if "complexity" is another way of saying "we don't understand", will new abstractions help overcome barriers to understanding in biology?
ultra-structure may, at least partially, answer these questions with a "yes".
it remains to be seen whether it is the ultimate solution, but so far it has moved us in those directions significantly from where we were before.
list of abbreviations used
eav: entity-attribute-value; er: entity-relationship; gfs: genome fingerprint scanning; ms: mass spectrometry; ms/ms: tandem mass spectrometry; orm: object-relational mapping; rdbms: relational database management system.
authors' contributions
cwm developed the database, web interface, and associated software, populated the system with middle structure rules, and drafted the manuscript.
jgl developed ultra-structure theory, created an initial system prototype, consulted in the initial stages of the project, and reviewed the manuscript.
bmh participated in the conception of the project, provided feedback during the research, and reviewed the manuscript.
mcg conceived of the project, provided advice and guidance on the system architecture, and assisted in the drafting and revision of the manuscript.
all authors have read and approved the final manuscript.
supplementary material
additional file 1
example sql queries.
contains some sample sql queries that the ultra-structure system uses.
these queries would not be used directly by end-users; instead, they are used or generated by animation procedures.
click here for file
additional file 2
ultra-structure prototype.
distribution of prototype code.
instructions for use are contained inside.
click here for file
acknowledgements
thanks to jainab khatun for providing preliminary feedback for the system.
thanks also to suzy vasa for a critical reading of the manuscript, and for several helpful suggestions.
funding support for the project was provided by nih national human genome research institutes award 2r01hg <dig> to mcg.

 biological research is an increasingly information-rich endeavor, with complex, heterogeneous data being generated at rates that outstrip the ability to readily manage, integrate, and analyze it. experimental platforms like mass spectrometry -based proteomics can produce tens to hundreds of gigabytes of data in a single run comprising less than two days of machine time. a wide variety of similarly prodigious experimental approaches are in use by biologists. there are also a large and growing number of publicly accessible repositories for biological information, the largest being genbank, uniprot, ensembl, and the ucsc genome browser. each of these resources may contribute critical knowledge or data toward solving a biological research problem, but integrating their diverse structures and data types into a unified analysis remains very difficult. one of our research endeavors that has encountered these issues is proteogenomic analysis of the human genome. this uses proteomic data to examine the translation of rnas to proteins on a genome-wide scale. we use computational techniques to map peptide-based ms data to their encoding genomic loci. the approach is used to reveal alternatively spliced or frameshifted translation products that cannot be readily found by standard proteomic analysis methods. this project involves the melding of several data sources that are large and heterogenous: ms-based proteomic data, genome sequences, gene annotation sets, snp sets, and more. each ms data set may contain or more individual spectra that must be analyzed in the context of one or more human genome sequences, each containing nucleotides, along with multiple gene, est, cdna, and gene prediction annotation sets. multiple spectral datasets are used, and they are available in a variety of formats depending on the source. not only are data sets heterogeneous and unwieldy, but the sources and types of data available often change as technology progresses. add to these the frequent changes in file formats, analysis approaches, and pipelines, all of which contribute to the steep challenges to maintaining an information management platform. and change can go deeper than just new instruments or technologies employed; often, biological concepts change through time. for example, the concept of "gene" has undergone many changes since mendel, and is currently experiencing another such change. when biological concepts change, information systems built to those concepts must often undergo extensive modification, raising the specter of extensive software maintenance. for individual labs pursuing systems and genomic research, this is a daunting task. when we set out to build an information system for the proteogenomic mapping project, these considerations led us to examine new means for managing, integrating, and analyzing project information. we discovered an intriguing approach developed by jeff long, called "ultra-structure", which employs a relational database system with a non-standard schema and code development approach to deal with issues of heterogeneity, complexity, and change. this approach views all systems, regardless of their complexity, as the product of the "animation" of relatively simple rules, not unlike wolfram's much more recent claims to "a new kind of science". however, unlike wolfram's approach, long's approach is oriented towards practical problem solving, and has for more than twenty years been applied to concrete challenges such as document analysis for nuclear technologies and management of businesses. additionally, long has also successfully experimented with its application to the representation of music and the analysis of games. when we encountered ultra-structure theory, it had not been applied to the biomedical and biological sciences, despite having properties well-suited to these fields, such as its ability to adapt to change and to integrate large heterogeneous datasets. in this work, we examined whether ultra-structure could be practically applied to our proteogenomic annotation project, and then extended into other biological data management and integration tasks. initially, we maintained two separate systems for this project, one using a traditional entity-relationship modeling approach, and the second built using ultra-structure principles. this allowed direct comparison of the approaches. while the ultra-structure system is not limited to just one use, we focus here on illustrative examples drawn primarily from our proteogenomic annotation work. the core of ultra-structure lies in expressing every piece of knowledge, information, or data as a "rule". rules are managed in a standard relational database management system, but are organized in a unique way based on the concept of "ruleforms". each ruleform is a single table in the rdbms, representing a single syntactical structure for the rules it contains. for example, a specific ruleform is used to declare the existence of entities of biological interest in a system, from small to large, including cells, molecules, dna, membranes, and test tubes. all rules declaring bioentities are then expressed with identical syntax within this ruleform. another type of ruleform is then used to express relationships between bioentities. this bioentity network ruleform uses a specific syntactical form to express binary relationships such as "protein abc is-a tyrosine kinase" or "adenosine is-a nucleoside". each ruleform, while specific about the syntactical structure of the rules it represents, is very general with regard to the concepts those rules can be used to model. in both of the aforementioned ruleforms, there is nothing specific to any one field of biology encoded; they could be used equally well to express rules related to oncology research or proteogenomic annotation. by representing everything about a system as rules, aspects of a system that are volatile are stored as data, rather than as database structure or computer code. the programming code implemented for a system, known as "animation procedures", is general, operating at a high level on the structure of the rules rather than their specific content. for the example of bioentities given above, any computer code written to operate on a bioentity operates on any kind of bioentity, not just those specific to a particular research field. the area of managing biological information and complexity is an active one. several projects have investigated issues of database integration from the perspectives of data warehousing and database view integration. some have utilized biological ontologies to manage biological information. these warehousing approaches generally rely on the creation of a global schema, which is often large and complex, and dependent on the changing schemas of the databases they integrate. this can lead to negative consequences, as stein related regarding the implosion of the integrated genome database. the "semantic web" is another approach to data integration that is gaining in popularity. this approach relies on open standards to present data and relationships in a consistent, machine-readable manner. automated procedures can traverse data relationships across the internet, allowing researchers to access and integrate related information from around the world. such semantic approaches are in a similar vein as our work, attempting to find novel ways to effectively deal with the vast amounts of biological data we are faced with. ultra-structure differs from the semantic web in that the latter is concerned with the machine-mediated exchange of data, whereas ultra-structure is focused on using a flexible rule-based system to manage local processes and data. semantic web technologies could be overlaid on top of an ultra-structure system, allowing outside resources access to ultra-structure-managed data, thereby taking advantage of both approaches. nadkarni and colleagues actively develop systems using the alternative database design methodology known as eav/cr, which has similarities to ultra-structure. like ultra-structure, eav/cr systems offer an insulation against change by storing volatile conceptual and structural information as data. however, the ultra-structure approach differs by also encoding information about behavior and processes as well, something these systems do not address. while our implementation stores gigabytes of project data, it also implements processes such as the translation of an rna transcript to a protein molecule, encoding the rules of translation in the database. we have begun constructing a workflow management subsystem, tracking data analyses and processes using the same database structures. when domain knowledge about any of these processes changes, such as discovery of new alternative genetic codes, database rules are readily updated. ultra-structure is unique in this regard, as it can deal with information management on a variety of scales, including domain knowledge, experimental information, and biological and laboratory processes. here we examine in more depth the application of ultra-structure to proteogenomic mapping through the use of concrete implementation examples. methods most approaches to information management model a system in terms of the concrete objects and relationships that are visible to the user or programmer. the perspective of ultra-structure is that these surface-level features are the results of ongoing, dynamic processes. these processes generate the objects, relationships, and attributes that we see as the outward manifestation of the system, and an ultra-structure system attempts to model these fundamental processes. ultra-structure comes from a background of process philosophy, which holds that processes, not objects, are the fundamental metaphysical constructs of the world. in modern biological research, the surface-level features are continually changing. for example, in a little over years, dna sequencing methods have progressed from early maxam-gilbert sequencing, through sanger sequencing, to microarray sequencing, on up through the current state-of-the-art next-generation sequencing methods. when a database system is structured to directly mirror the data types produced by a changeable technology like this, it must be reconfigured each time the technology changes, along with sometimes extensive changes to the associated computer code. the result is that such databases will grow in complexity until they suffer from significant maintenance challenges, at which point it may be simpler to completely scrap the system and start over. to address this, ultra-structure introduces two primary levels of abstraction between the database management system and the "surface structure" that the user interacts with to store, analyze, and visualize their project data: the "deep structure" and the "middle structure". below, we briefly cover the basics of the ultra-structure implementation. rather than a full exposition, we cover further implementation details as part of the examples shown in the "results" section. rules rules are the core of ultra-structure, as they govern the fundamental ongoing processes that create the system being modeled. they are used to represent all changeable aspects of the system, including data, operational processes, attributes, etc. for example, simple declarative rules for objects in the system are shown in figure in contrast to the "if/then" interpretation of rules in an expert system, ultra-structure rules are interpreted as "if/consider" constructs. when the conditions on the left-hand side of a rule – known as "factors" – are met, the system is instructed to consider the information of the right-hand side – "considerations" – in subsequent processing. this allows multiple rules to express considerations that apply to a given antecedent; as a result, we may conditionally modify how rules are interpreted. for instance, in our system, one rule may state that in general, all sequence locations should be calculated relative to the 5' end of a chromosome. but, another rule may declare that short peptide sequences are declared relative to the start of the coding sequence for a gene. when rules are being interpreted, these two rules would present a conflict. however, since applicable rules are all considered before selecting an outcome, other rules in the system can influence processing, such as by defining an order of precedence so that the rules related to peptide locations take priority. while this has similarities to class inheritance in object-oriented systems, it is readily modifiable. if we later need to change the interpretation priority for rule types, only one rule need be modified that tells the system how to prioritize the considerations. rules are not completely free-form, though; they are subject to a variety of constraints, which are collectively known as the "deep structure". deep structure the "deep structure" abstraction level is designed to represent those things about a domain that are fixed and unchanging. technically, the deep structure consists of the syntactical and semantic forms for expressing rules relevant to the application domain, as well as the associated computer code that manipulates those rules. ruleforms specify all the logically possible forms that a rule may take: "ruleforms are to collections of rules as numbers are to collections of things.... ruleforms abstract morphology, while numbers abstract quantity; in a sense, ruleforms model the geometry of rules." in practice, ruleforms are implemented as database tables: the ruleform itself is the table definition, and individual rules that conform to that ruleform are rows within that table. factors are implemented as a primary key constraint on the ruleform table; considerations are then the remainder of the columns of the table. standard database system query mechanisms can be leveraged to quickly find applicable factors for given system inputs, and furthermore, modern database systems can easily handle and query millions of rules. the ruleform abstraction allows their use for many distinct functions, while keeping the number of tables low and comprehensible. the development of ruleforms for a given domain comes about from following an iterative development process, starting with a high-level process-oriented perspective, implementation, and refinement. across broad domains for which ultra-structure systems have been implemented, typical systems utilize or fewer ruleforms. while ruleforms can prescribe the forms of all rules of a system, the rules themselves are inanimate; they need to be interpreted in order to produce the desired behavior of the system. the primary feature of the associated animation procedures is that they are implemented in a general way without detailed domain knowledge, allowing the system to accommodate new information or procedures without changing the underlying software. since an ultra-structure system encodes information as formal rules in a database, including how rules are to be interpreted, this simplifies the needs for animation procedures, so that they must only deal with control logic, such as which ruleforms to inspect and when, and how to get data into and out of the system. specific actions carried out by the software are driven by the contents of the rules being operated on; changing the rules changes the actions performed by the system. as a result, animation procedure code will not need to be changed as domain knowledge changes. in this regard, the animation procedures of ultra-structure are similar to the inference engines found in expert systems, but differ in the fact that they access different tables for different kinds of rules. for example, one common need of many biological research systems is to calculate spatial or structural relationships between two items, such as whether a nucleotide is within a gene, or how close two amino acid residues are along a protein string. in our system, an animation procedure deals with any type of arbitrary spatial calculation on linear strings, regardless of what type they are. the biology-specific calculations, such as calculating all exons within a gene, are determined by protocol rules in the system. together, the collection of ruleforms and the animation procedures that operate on them constitute the deep structure of an ultra-structure system. in the case of our system, we have implemented a deep structure which aims to capture the fundamental computational realities associated with biological research. an example of deep structure in our system arises from the need to declare the existence of entities such as genes, proteins, cells, samples, and amino acids. the bioentity ruleform from figure is an example of an "existential ruleform", which is used to declare the existence of some concept or entity in the system: the "things" the system knows about. our bioentity ruleform defines things that participate in biological processes, or are otherwise of biological interest. this includes a broad diversity of concepts, from the isotope 14c and the third exon of the β-catenin gene, to broad categories, such as "non-polar amino acids". a group of bioentities is itself considered a proper bioentity because it is subject to the same kinds of rules; rules that apply to the group also apply to the members of that group. this ruleform defines the structure for rules declaring the existence of biological entities of any kind. this is in contrast to a more standard rdbms, where different types of biological entities would typically be stored in separate tables. here, if a new type of biological entity comes into play later, there is no change to the underling system; the "bioentity" ruleform can accommodate nearly any type of thing we might care to declare and track in the system. while the "things" in a pure entity-attribute-value system might all be formally represented as generic "entities" or "objects", this is not the case in an ultra-structure system; everything in our universe of discourse is not a bioentity. other existential ruleforms for our system are shown in table and include foundational concepts such as resources, attributes, locations, and units of measurement. several existential ruleforms are described, with illustrative examples. in addition to the declared objects like bioentities, there can be a set of associated ruleforms that express attributes for them. for example, in proteomic research, the masses of molecules must be tracked. these can be expressed in different ways, based on how isotope distributions are accounted for, including "monoisotopic mass", "average isotopic mass", or "most abundant isotopic mass". we express this information using the bioentity attribute ruleform shown in figure 3a, which is based on entity-attribute-value design. the factors of this ruleform include a bioentity and an attribute, the latter defined with an existential ruleform shown in figure 3b. attributes can track any kind of arbitrary information about an entity. there are multiple consideration columns present to effectively represent values of different data types, but in this case, constraints ensure that only one may be non-null, reflected by the "value type" consideration of the attribute ruleform. in addition to unconstrained columns containing numeric or text values, other columns may refer to other existential ruleforms, allowing different types of existential entities to be related to one another. each type of existential ruleform may have an associated attribute ruleform. once an entity is declared to exist in an existential ruleform, it can be combined with other entities to create new "network" rules that express relationships between them. figure 4a shows a simplified example of a network ruleform in our system. it expresses arbitrary binary relationships between bioentities using "subject/predicate/object"-style triples, where "subject" and "object" can be any entry represented in the bioentity ruleform; the predicate can be any relationship defined in the relationship existential ruleform. this network ruleform can be used to specify which entities are the members of a group, the group itself being a bioentity. in this framework, it is possible to build up networks, hierarchies, and relationships between a variety of entities easily. users can directly add new relationship rules to the system to define whatever associations they might need, without modifying the database structure itself. though omitted in the figures for clarity, several ruleforms have an additional factor called "resource", used for system provenance. the bioentity attribute ruleform has a resource factor, which allows recording who declared the average mass of carbon to be daltons, or which ms analysis file contained the information that peptide ion has a charge value of since the resource is a factor, this allows the storage of potentially conflicting information in separate rules. this addresses the fact that information in scientific endeavors is often tentative and/or integrated from a variety of sources. otherwise, information stored in the system would be limited to dogmatic declarations of concrete fact. the resource factor is used wherever the declaration of data or rules may be tentative, conflicting, or changing. other ruleforms in our system are used to define additional kinds of rules: "authorization rules" indicate what combinations of information are valid or permitted; "meta-rules" describe how to read other rules; and "protocol rules" specify sequences of actions and can be used to implement complex processes and workflows. middle structure the next layer of abstraction, the "middle structure", can best be thought of as representing the "laws" of the system; that is, the specific rules and constraints that govern a system's operation. the middle structure is the content of the deep structure's ruleforms. this represents the types of relationships that may occur between data in the system, and the processes that data undergo during analysis or query. in our system, the middle structure declares the types of data kept about our biological research operations, the relationships between them, and the kinds of operations that can occur on the data. whenever procedures, file formats, or data types change, the middle structure is changed to reflect this. often the relevant database system changes can be made by the non-programmer, by modifying the database entries that comprise the rules of the system. this puts the task of regular maintenance more fully into the hands of the systems users, who are the subject experts, rather than third-party programmers. in our system the middle structure encompasses bioentity rules defining various genome annotation sets, mass spectra, and amino acids; resource rules defining our gfs software, genome annotation providers, and individual gfs analysis output files; location rules defining specific regions of genomic sequence for annotations as well as gfs-mapped peptide locations; and several others. another lab performing bacterial community analyses – a wholly different research area – could take the same deep structure, but instead populate the middle structure with a separate set of rules, such as bioentity rules defining restriction enzymes and bacterial species, bioentity network rules reflecting taxonomic relationships between bacterial species, events denoting specific analysis experiments, and locations representing lab freezer locations of samples. we are in fact implementing a system for bacterial community analysis with collaborators, using our proteogenomic deep structure as a basis. one brief example is in order. we regularly exploit the concept of "overlap" between two sequences against a particular genome location, such as to find where peptides overlap annotated exons or genes. the procedures for calculating overlap are not part of the structure or code of the system, since it reflects a specific use case; instead, it is represented by a small number of rules that are readily changed or added to as demands warrant. many other relationships besides simple "overlap" may be of interest, such as "located downstream" or "contains"; these and others can be defined by the end user. ultimately, by not over-specifying the deep structure of the system, users are able to modify the middle structure to obtain the surface structure they desire. surface structure in an ultra-structure system, the "surface structure" – the actual appearance of the real-world system – is not explicitly modeled or stored anywhere; rather, animation procedures driven by the content of the rule base generate it. surface structure is volatile in biological research, where experimental protocols change, new data types become available, and concepts are continually revised in light of new information. as a result, information systems modeled on surface structure directly are themselves volatile, lending to maintenance issues. an example of surface structure generated by our system can be seen in user interfaces derived from the combination of middle structure rules with general animation procedures. for example, when a user queries the system to find a list of existing genomic annotations that positionally coincide with a peptide match from a tandem ms experiment, the ultra-structure system dynamically generates the interface and resulting lists by examining its rules to determine what it means for genomic regions to overlap, as well as what values should be queried for and then returned to the user. in our system, the surface structure is generated using animation procedures that interact with the rdbms middle and deep structure. our system is built on the open source postgresql database server. animation procedures are implemented as internal database procedures written in either pl/pgsql or sql, or as client-side methods written in java, using the hibernate object-relational mapping library, or a combination of both. in general, animation procedures that perform large amounts of database processing, or that require a great deal of dynamic query generation are implemented as internal database procedures, while simpler procedures, and those whose execution requires control or data structures that are difficult to implement in the database are performed on the client side. we are also developing a web interface to the system using stripes, an open source web application framework for java. examples of some prototype interfaces can be seen online at. some example sql queries are provided in additional file for interested readers. prototype code for the system is also provided in additional file  at the beginning of this project, we developed the ultra-structure system while also maintaining a traditional er-modeled database for the project. the latter was in place until it became clear that the ultra-structure system would reach sufficient utility for day-to-day use. the er system developed to contain individual tables representing everything from ms datasets to analysis results to various genomic annotation datasets downloaded from ucsc's genome resources. the er approach provided a quick start-up due to our familiarity with it at the time, but as the scope of the project evolved, shortcomings became apparent. for instance, its structure assumed all annotations and proteomic data had coordinates relative to a single genome. the subsequent availability of multiple genome drafts along with genomes of multiple individuals, necessitated substantial redesign, which would have resulted in more tables to track and coordinate all the different versions of genomes against annotations and proteomic runs. other shortcomings were more fundamental; for example, it was necessary to build into the er model some fixed representation for a "gene". however, the definition of a gene is changing as more is uncovered about processes such as trans-splicing, where one messenger rna is produced by concatenating exons from separate pre-mrnas. on the other hand, implementation of the ultra-structure system was at first challenging, because the design process required a new way of thinking that focused on separating universal features of the system, from the changeable features. the process has been iterative; we started with a core of ruleforms representing the basics such as bioentities, networking of bioentities, resources, and events. as we began implementing rules and features, we came upon the need for new ruleforms, such as one representing location information, and another representing bioentity attributes. as we have become more adept at the ultra-structure approach, each refinement to the system has occurred more quickly, and resulted in a more coherent design. the resulting ultra-structure system stores all the data that our original database could, and stores it in a more comprehensible manner, using fewer tables. we have translated procedures from large, complex software functions into ultra-structure animation procedures that are smaller, easier to comprehend, and driven by rules in the database that can be altered to extend the capabilities of the system. using our proteogenomic annotation project as an example, we describe the modeling processes and considerations that we faced in transitioning from a traditional er-modeled system to one based on ultra-structure. rather than trying to be comprehensive in the description of the system, we focus in on several examples that illustrate the types of changes and considerations made. further detail can be gleaned by examination of the system and documentation itself, prototype code for which is attached as a supplemental file. example 1: modeling and implementing hierarchies of mass spectrometry data hierarchies are ubiquitous in biological research, both in the subject of the research and in the artifacts of the research itself. these can be represented with er modeling methods by creating a series of tables linked by integrity constraints, with each table representing entities at successively deeper levels of the hierarchy. mass spectrometry data is naturally hierarchical, with an experiment usually comprised of a group of separate lc-ms runs, each of which consists of multiple spectra, which in turn are each comprised of series of peaks. such data can be represented in a standard er design as shown in figure 5b, where the hierarchy of the data is mirrored by a hierarchy of tables in the database. this has the benefit of being an intuitive and relatively natural representation. ultra-structure instead represents this hierarchy by abstracting the concept of networks of bioentities in a general manner. a grouping of data points such as a spectrum is a bioentity, as are each of the data points themselves. the network itself is implemented in a new ruleform, the bioentity network. this ruleform captures a high level, general aspect of the system: that there exist relationships between entities that participate in biological processes or interactions. for the example of ms data, we define a relationship using the relationship ruleform such as "has-precursor-ion", then use this to relate each specific product ion with the specific precursor ion it was derived from. in a similar way, we can use an "included-in" relationship to associate a particular run with the dataset it is a part of. these relationships existed in the er-based system as foreign key constraints. however, a foreign key can only indicate that data from one table has an association with data from another table; it cannot formally and explicitly specify the nature of that relationship. in ultra-structure, the relationship is encoded as data within the middle structure of the system, providing explicit information about the nature of the relationship to human users and software. new relationships are created by adding new rules to the relationship ruleform, which are immediately available for creating new rules in the bioentity network ruleform. nearly any arbitrary network of bioentities can be formed, without changing the database structure. it is straightforward to group ms data in new ways, for example to accommodate gel-based data instead of lc-ms runs. in contrast, for the er model, new representations or hierarchy models are likely to involve changing the database schema itself, which in turn impacts the computer code that interacts with it. each bioentity may have one or more attributes. for example, ion peaks may have an intensity and an associated mass, as well as an electrical charge. we represent such attributes using a separate ruleform, "bioentity attribute". users can make the system aware of new attributes by adding the appropriate rules in the attributes ruleform. as such, the bioentity attribute ruleform can be used to express the value of any attribute of any bioentity. this attribute representation is similar to the eav/cr approach, but in the latter, the attributes of all kinds of objects are represented using an identical table structure, whereas ultra-structure attribute tables are tailored to each semantically distinct type of entity, reflecting fundamental differences in their use in the system. for example, the bioentity attribute ruleform has a resource factor that facilitates provenance, which may not be necessary for attributes on other kinds of objects. since ultra-structure ruleforms represent a higher-level abstraction than er-modeled tables, these three tables can now be used to represent much more than just ms/ms datasets. indeed, the only things the original er tables could represent were ms/ms datasets; to begin using another type of dataset would have required remodeling the existing tables or adding new tables. this flexibility of the ultra-structure approach will be demonstrated next. example 2: representing genomic features one aspect of our project is to map the ms-analyzed peptide spectra to location on one or more human genome sequences, then correlate those locations with features such as genes and exons that are part of publicly available annotation sets. our er database implemented a problem-specific table structure, mirroring the mysql database dumps from ucsc, as shown in figure 6a. we found this design to have two limitations, illustrated in figure 6b. first, the table structure makes a specific assumption about the types of information that must be recorded for a gene, and how these are related to one another. if new features or structures for a gene are uncovered, such as a new splicing regulator in an intron, then the table must be redesigned, along with all the computer code written to interact with it. second, some features of a gene, such as introns, are not made explicit in this model, but must be derived by calculations using other features. this makes it harder for a human to review the source data in the database, and makes errors in the data or the code that interprets the data more likely. the ultra-structure approach instead encourages taking a step back and looking more generally at the problem of representing annotation data. we implemented a solution that took advantage of the existing ruleforms, considerably streamlining the representation. at its core, the approach declares that all annotations are simply bioentities, such as "ucsc known gene transcript alignment uc001fet. exon 1" or "ensembl transcript enst 5' utr". as such, the abstract entities that the annotations represent are declared independently of specific coordinates in an arbitrary genome draft. this facilitates both representational efficiency and biological interpretation, because some annotations can appear in different drafts of a genome, and across genomes. in essence, this abstraction provides an independent existence for the concepts associated with particular genomic features. researchers or computer code can thus interact broadly and in a relational manner with them, without having to reference specific genomic coordinates, just as it is possible to talk about a building on a university campus by name and relate it to nearby buildings without having to refer to street addresses or geographic coordinates. once established as bioentities, annotations can then be related to one another using bioentity network rules, expressing that this exon is part of that transcript, for example. we need only declare the types of relationships that describe these connections. using this representation, we can easily maintain abstract groupings or hierarchies of annotations that are biologically relevant. for example, we use this to create a grouping for all annotations belonging to the set of "known gene annotations for human genome draft 18". we can also use it to create groups such as "human genome draft exons" or "transcripts associated with breast cancer". representing all these open-ended grouping choices using a traditional er model requires additional tables and associated infrastructure, while ultra-structure provides for this capability with no further alterations of the database's schema. example 3: representing genomic locations and positions our project also needs to express discrete genomic coordinates for annotations and perform computations such as determining which genes a particular peptide occurs in. our original er system represented genomic locations similarly to the ucsc tables, capturing the surface structure of the problem in the database schema. in designing the ultra-structure representation for locations, our goal was an abstract and general representation of locational information, flexible enough to represent other types of location information besides genomic regions. the result is a location existential ruleform and several accessory ruleforms that can represent many types of locations common to biological research: subcellular organelles, motifs and regions in peptide strands, test tubes in lab freezers, internet addresses of datasets, and even word and concept locations within journal articles and other text mining inputs. the ruleform uses a consideration called "context", which is a reference to the location context ruleform, specifying the frame of reference in which a specific location is valid. for instance, a genomic coordinate for the 18th draft of the human genome can only be interpreted in the context of the 18th draft; it makes no sense in the context of the 17th draft, since the underlying genome sequence is different. similarly, the location of a test tube in a lab freezer will not make sense for calculations on genomic coordinates. the location context attribute is then used to define the coordinate space of locations for a particular context. for example, this allows specification that a "genomic coordinate" context must define a "chromosome", "strand", "start position", and "stop position", or that a "freezer location" context for protein samples is defined in terms of "room", "freezer", "shelf", "rack", "box", and "slot". the location attribute ruleform is then used to store a specific location's coordinates, using a form similar to the bioentity attribute ruleform. for example, "genomic location 100" is described by four rule entries: one for chromosome, one for directionality, and one each for "start" and "stop" positions, as seen in figure 7b. specific locations, such as "genomic location 100", maintain a separate existence from any bioentity that may refer to them. just as an annotation can have multiple locations, so too can a single location correspond to several annotations. we then use the bioentity location ruleform to connect gene annotation bioentities to their associated locations. but it is not limited to that use; it is also used to associate matched peptides from mass spectrometric analyses to their genomic location. by implementing a solution for one location-related purpose, we get a solution to another location-based problem essentially "for free". example 4: animation procedures for generalized location calculations as mentioned before, animation procedures perform procedural tasks without being programmed using any case or problem-specific knowledge. one example is mapping ms/ms peptide data to genome coordinates, and then finding out what existing annotations say about those coordinates. for this task, we need to be able to calculate relationships between locations, such as "contains", "before", or "after". some ms/ms data may map a peptide with high confidence to a particular nucleotide sequence on chromosome 17; we will want to find all existing genomic annotations that contain, are contained by, overlap the 3' end of, or are located downstream of this location. there can be many other relationships that are interesting, and it is difficult to predict ahead of time all the types of relationships users may want to examine. but in the end, we are always dealing with arbitrary calculations on two locations that share a relationship, in order to find any relevant associated bioentities. using the location-related ruleforms as the basis, we implemented a general animation procedure for performing coordinate-based location calculations. for example, we know that genomic region a contains genomic region b if these regions are on the same strand of the same chromosome, and the start and stop positions of b are between those of a. this is defined explicitly as a set of rules in the location relationship ruleform that define a containment relationship. if the rules for containment change, the only changes that need be made are to the rules that define the relationship. other relationships can be similarly defined, such as "overlaps 3' end", "is downstream of", and "is upstream of". the animation procedure takes as input a location, a location context, and a relationship. the location acts as an anchor for the search, which will retrieve all locations in the given context such that the given relationship holds. the animation procedure uses this information to generate a search key for rules in the location relationship ruleform that define what conditions must be true to satisfy the user's query. figure 8b shows the rules that would be selected for a particular genomic location overlap relationship. the considerations of these rules, defining the conditions that exist between query location and retrieved location, are used to dynamically generate an sql statement that retrieves the requested locations. these are then used to query another ruleform to find bioentities that are located at these locations; this information is then displayed to the user in a web browser interface. nothing in either the structure of the location relationship ruleform or the code of the animation procedure is specific to genomic locations. the end user could add location relationship definitions for genomes, freezers, or cells, and those would be immediately queryable within the user interface to the location procedures. by storing this information as rules rather than in code, the biologist end user has great flexibility in adjusting the system to their needs. in our project, we have most extensively used this capability to correlate results of our proteogenomic mapping with existing annotation sets in our database, to be reported in a separate publication. example 5: animation procedure for deductive inference expressing everything as a rule in the system facilitates automatic deductive inference procedures that can transform implicit assumptions and relationships into explicit rules. for example, "inverse" rules can automatically be generated; if "serine is-a polar amino acid", then "polar amino acid includes serine" can be inferred. rules can also be chained together. a rule may declare that "gene x encodes-product protein a", and that "protein a is-a methyltransferase". if the relationships "encodes-product" and "is-a" are declared to be validly combinable to deduce the resulting relationship of "gene-type", chaining these two rules together makes explicit that "gene x gene-type methyltransferase". such a deductive process serves first as a mechanism for consistency checking, and secondly to uncover new connections in the data that may have been implicit but not obvious. we implemented a general deductive inference animation procedure for each of our network ruleforms. inverse rule generation is driven by the relationship of the network rule, which by explicit definition knows its corresponding inverse relationship; the procedure simply inserts a new rule using this inverse relationship and swapping the subject and object of the original rule. it also chains network rules together in logically valid ways to deduce new relationships, governed by the relationship chain ruleform. an overview is shown in figure the animation procedure assembles pairs of network rules based on whether the object of the first rule is equal to the subject of the second rule. for each pair, it is then determined whether there is a relationship chain rule that pertains to the combination of relationships represented. if yes, a new rule can be deduced by assembling pieces of the input rules and the matching chain rule. the nature of the deduced rule is dependent on the rules inspected in the course of the deduction; the animation procedure simply carries out a series of mechanical database queries and manipulations, purposefully ignorant of the details of what it is computing. hence, we can easily tell the system that the "is-a" relationship is transitive by inserting an appropriate relationship chain rule whose "input 1", "input 2", and "result" columns are all set to "is-a". thus, we do not have to code a special case into the deduction procedure to deal with transitive "is-a" relationships, and deduction using other relationships with more specific meaning are easily modified by changing the meta-rules. one practical example of this is that if the system has a rule linking a specific exon to a particular group of exons, the system can automatically deduce its putative membership in other applicable groups using the network structure and the relationship chain rules for group membership. by reviewing such deductions, a user may gain new insights into previously opaque relationships. and if a deduced rule is thought contradictory or incorrect vis-a-vis known facts, then this points to the incorrectness of the premises from which it was derived. performing that kind of review can be a powerful method for checking the consistency of data and assumptions in the system. discussion a goal of ultra-structure development is to converge upon a deep structure sufficiently general to represent a broad domain of interest, such as systems biology research. the expectation is that the deep structure will be arrived at iteratively, through testing implementations, experimenting, and redesigning. that has been our experience in implementing this system. for example, in an earlier iteration, there was no explicit ruleform for representing locations; we represented locations as bioentities. without a separate concept of location, the system mixed the concept of coordinates of a genomic feature like an exon, with the concept of the exon itself. as we began doing calculations that were unique to location information, such as computing "containment" relationships, it became clear that our original deep structure was too limited. by separating the concept of a thing like an exon into the bioentities ruleform, and its location into a new locations ruleform, our system made a lot more sense. at the same time, the development of the location-related ruleforms opened up a greater set of capabilities for other purposes. this process illustrates long's hypothesis that notational systems used to represent information can often present inherent limitations of which users are unaware, and that switching the underlying notation often resolves problems and presents new possibilities. redesigning the ruleforms in ultra-structure has impact throughout the system, and is much like any database redesign, in that it consumes time and effort. the key with ultra-structure is then to converge on a foundational deep structure relatively early in the system's evolution. if the result is sufficiently general, further redesigns are minimized, even if very different needs arise. an example is our evolution of the system to represent gene annotations on dna in two distinct parts: the conceptual entities themselves and networks thereof, and the discrete locations of those entities. if genome coordinate systems later change, or gene concepts change, this underlying structure is unlikely to need major redesign. for example, a great deal of work is now invested in characterizing methylation patterns on the histones around which dna is wound, since this appears to have significant regulatory effects on which genes are expressed or when. hence, there may soon come a time at which annotations will need to include histone methylation patterns. we cannot anticipate the precise way that these will be represented, but it is likely that the system is now general enough to readily accommodate this information without modification to the rule forms. as the deep structure has emerged and stabilized, subsequent modifications to the system have revolved increasingly around the creation of new rules. when we were in the phase of implementing the ruleforms, the ultra-structure approach seemed slow and difficult to implement, perhaps due to our lack of experience with it. the high-level perspective required for ultra-structure design is quite different from the more standard design methodologies we were accustomed to. fortunately, as an appropriate and general implementation of ruleforms and animation procedures was developed, we saw ever-increasing efficiency from our efforts, since each implemented part of the deep structure can be utilized for many purposes within the system, amortizing the programming and design workload. an example is the time spent designing and redesigning our representation of locations. initially this took longer to get right in ultra-structure than it would have using the standard approach of designating specific columns in specific database tables to represent features such as exon start and stop positions. but now that it is in place, nearly any type of location calculation can be readily implemented. we could use the system's deductive capability to determine anything from which planet a particular sample is located on, to which organelle a protein is expressed inside of, or which freezer has a patient specimen. little if any additional programming will be required, excepting the case where we realize our representation is not general enough. in that case, some redesign work may be applied, but with the benefit of further generalizing the system. an example of this kind of generality is in our recording of sequence tags. sequence tags are short subsequences of a larger peptide, and can be used in conjunction with other information to help identify that larger peptide. in early iterations of our system, we stored sequence tags as textual attribute values on peptide bioentities, e.g., "dnw" as part of the peptide "dnwdsvtstf". after creation of the location ruleforms, we realized that sequence tags could be recast in the same way as any other genome annotation, with a bioentity representing the existence of a specific tag, and a set of location entries that describe where the tag is located relative to its parent peptide sequence. we defined new "peptide location" rules in the middle structure of the location context table, with coordinates for the peptide, start, and stop positions. these rules echo those used to record genomic locations, but without the strand coordinate. now, sequence tags are handled like any other annotations on a sequence, except that these are annotations relative to a peptide sequence, whereas genes, exons, and the like are annotations relative to a chromosomal sequence. interpreting sequence tags as just another type of sequence annotation is the kind of insight that ultra-structure was designed to reveal, bringing implementation efficiency and increased semantic clarity. making explicit the information about what each thing is in the bioentities and bioentities network table, along with where each thing is in the locations-related tables, improves the readability and understandability of the data in the system for human users. this is important because a key objective of ultra-structure design is to allow subject experts to directly interact with the rules of a system, without having to explain themselves to a programmer or rely on adequate documentation of existing systems to discover what the rules are. achieving this makes systems more transparent and eliminates one of the greatest sources of error in systems: the communication between subject experts and computer experts generically referred to as "requirements analysis". this allows subject experts to define their own "terms of art" as needed. ultra-structure provides the ability to readily adapt to evolving requirements and conceptual change in the real world. for example, the classical conception of a gene is that it comprises a contiguous region on one chromosomal strand, yielding a contiguous transcript which then undergoes splicing to produce the mature rna through the excision of intron regions. this was the basis for our representation of genes in our original database system. recently, new conceptual challenges to this classical model have arisen, including discovery of significant numbers of gene regions that produce distinct but overlapping transcripts, nested transcripts, and in some cases, mature rnas resulting from trans-gene splicing. our original representation of a gene, with a single start and stop site bounding the transcript, would not readily admit oddities like trans-splicing. however, our ultra-structure system represents genes as just instances of bioentities, each of which can be networked to some set of exons, themselves each of which can have arbitrary location information associated and/or network relationships to other annotations, such as identified ms/ms peptides. this scheme accommodates nearly any possible gene or transcript architecture. the ultra-structure system stores trans-spliced transcripts in exactly the same way it stores more canonical, orf-based transcripts. in fitting with long's original claims, we have found that our ultra-structure system accommodates changing concepts, procedures, and analyses quite well. the high degree of modifiability of the system has resulted in other benefits. one instance of this was the implementation of computing containment relationships on genomes, such as finding which overlapping gene annotations contain a given exon or peptide location. initially the rules were set up to analyze containment relationships only on the same strand of a chromosome. at one point we wanted to examine whether there were also any annotations of interest in the same region, but on the opposite strand. we added this capability to the system with just four new middle structure rules added to the database: one to define a relationship ") and three to define the conditions for the relationship. this was a simple procedure that could be performed directly and quickly by the end user with no programing or other system alteration. performance of our initial prototype system is slower than if traditional er modeling techniques were used. this is a well-known aspect of systems using decomposed schemas in that "entity-centered" queries perform on par with er-modeled systems, but "attribute-centered" queries perform more slowly, due to repeated self-joins. our work has not focused on performance optimizations yet, but this is the focus of ongoing work. potential solutions exist, ranging from index tuning, alternative query techniques, system configuration tuning, and hardware improvements. additionally, performance advances in other reasoning systems can potentially help here. systems biology is a rapidly changing field, and perhaps one the greatest obstacles to progress is the challenge of effective data management, integration, and analysis across very large, heterogeneous, and complex data sets. our proteogenomic mapping project presents a microcosm of these challenges with its need to integrate complex genomic and proteomic data sets, all the while keeping up with the rapidly changing technologies in both fields. at present, our prototype ultra-structure system is already yielding significant payoff for this task. but perhaps more significantly, it now provides a platform that can be readily adapted to other challenges. that is not just theoretical; we are now beginning to apply the system to other tasks such as managing and analyzing microbiome data and managing and analyzing data from a next-generation sequencing facility. the efforts invested in the deep structure for proteogenomics have immediate application in these other domains.  our move to the ultra-structure system was not without challenge. thinking in the "ultra-structure way" was initially difficult, and progress was slow. at times we wondered whether a payoff would arrive, or whether we should just go back to the original, more standard approach. but once we reached a threshold of having a stable deep structure, progress has accelerated. now it is becoming increasingly difficult for us to envision going back to our pre-ultra-structure methods, because we see payoffs not only in terms of implementation efficiency, but also in helping us think about our data management and analyses in new ways. this leads us to ponder the question originally raised by long: could it be that the abstractions and notational systems we have been using were limiting forward progress, without us knowing it? biological research is no longer content with just studying bits and pieces of an organism or cell, but is instead focused on examining the interactions and dynamics of entire biological systems. perhaps the needs of the field have outgrown the traditional tools used to represent and analyze biological data. we wonder: will new mental tools like ultra-structure design clarify or elucidate aspects of biology that may be concealed by more traditional abstractions? if "complexity" is another way of saying "we don't understand", will new abstractions help overcome barriers to understanding in biology? ultra-structure may, at least partially, answer these questions with a "yes". it remains to be seen whether it is the ultimate solution, but so far it has moved us in those directions significantly from where we were before. list of abbreviations used eav: entity-attribute-value; er: entity-relationship; gfs: genome fingerprint scanning; ms: mass spectrometry; ms/ms: tandem mass spectrometry; orm: object-relational mapping; rdbms: relational database management system. authors' contributions cwm developed the database, web interface, and associated software, populated the system with middle structure rules, and drafted the manuscript. jgl developed ultra-structure theory, created an initial system prototype, consulted in the initial stages of the project, and reviewed the manuscript. bmh participated in the conception of the project, provided feedback during the research, and reviewed the manuscript. mcg conceived of the project, provided advice and guidance on the system architecture, and assisted in the drafting and revision of the manuscript. all authors have read and approved the final manuscript. supplementary material additional file 1 example sql queries. contains some sample sql queries that the ultra-structure system uses. these queries would not be used directly by end-users; instead, they are used or generated by animation procedures. click here for file additional file 2 ultra-structure prototype. distribution of prototype code. instructions for use are contained inside. click here for file acknowledgements thanks to jainab khatun for providing preliminary feedback for the system. thanks also to suzy vasa for a critical reading of the manuscript, and for several helpful suggestions. funding support for the project was provided by nih national human genome research institutes award 2r01hg to mcg.
by representing both data and processes as formal rules within a database, an ultra-structure system constitutes a flexible framework that enables users to explicitly store domain knowledge in both a machine- and human-readable form. it also enables us to readily incorporate new data types, sources, and domain knowledge with no change to the database structure or associated computer code. we transitioned our proteogenomic mapping information system from a traditional entity-relationship design to one based on ultra-structure. we find ultra-structure offers substantial benefits for biological information systems, the largest being the integration of diverse information sources into a common framework. end users themselves can change the system's capabilities without programmer intervention, simply by altering database contents; no computer code or schemas need be modified. this provides flexibility in adapting to change, and allows integration of disparate, heterogenous data sets within a small core set of database tables, facilitating joint analysis and visualization without becoming unwieldy. ultra-structure may be a significant step towards solving the hard problem of data management and integration in the systems biology era. research is dynamic, with frequently changing protocols, techniques, instruments, and file formats. the system is not tied specifically to proteogenomic research, but is rather designed to accommodate virtually any kind of biological research.
 modern, high-throughput biological experiments generate copious, heterogeneous, interconnected data sets. research is dynamic, with frequently changing protocols, techniques, instruments, and file formats. because of these factors, systems designed to manage and integrate modern biological data sets often end up as large, unwieldy databases that become difficult to maintain or evolve. the novel rule-based approach of the ultra-structure design methodology presents a potential solution to this problem. by representing both data and processes as formal rules within a database, an ultra-structure system constitutes a flexible framework that enables users to explicitly store domain knowledge in both a machine- and human-readable form. end users themselves can change the system's capabilities without programmer intervention, simply by altering database contents; no computer code or schemas need be modified. this provides flexibility in adapting to change, and allows integration of disparate, heterogenous data sets within a small core set of database tables, facilitating joint analysis and visualization without becoming unwieldy. here, we examine the application of ultra-structure to our ongoing research program for the integration of large proteomic and genomic data sets.  we transitioned our proteogenomic mapping information system from a traditional entity-relationship design to one based on ultra-structure. our system integrates tandem mass spectrum data, genomic annotation sets, and spectrum/peptide mappings, all within a small, general framework implemented within a standard relational database system. general software procedures driven by user-modifiable rules can perform tasks such as logical deduction and location-based computations. the system is not tied specifically to proteogenomic research, but is rather designed to accommodate virtually any kind of biological research.  we find ultra-structure offers substantial benefits for biological information systems, the largest being the integration of diverse information sources into a common framework. this facilitates systems biology research by integrating data from disparate high-throughput techniques. it also enables us to readily incorporate new data types, sources, and domain knowledge with no change to the database structure or associated computer code. ultra-structure may be a significant step towards solving the hard problem of data management and integration in the systems biology era. 