not how it’s laid out in the database. Thus OME is not locked into maintaining
this data layout format, and it could just as well be storing attributes as key/
value pairs in a single long, skinny table. The one table per SemanticType data
layout format was selected for performance reasons because it leads to signifi-
cantly fewer rows and therefore significantly lower database overhead due to
indices and storage than if using key/value pairs.
Leveraging OME’s support for plug-in ontologies, many of OME’s essential
data structures are not hard-coded but, rather, defined using SemanticTypes and
imported during the OME install process. These are called the OME core types
and are fully compliant SemanticTypes defined in XML that are no different
than user-defined ...