Back to Pantheon Home Page
Insofar sensible, the GCP MOBY data types closely mirror the inheritance and topology of their corresponding GCP demeter domain models. Like the Demeter models, the MOBY data types are split into two levels:
GCP MOBY Data Types are intended to be derived from the GCP ("Demeter") Domain Model as a platform specific implementation of the model. For consistency in comparison to the Demeter domain models, the MOBY data types are expressed as Unified Modeling Language (UML) class diagrams. They are, of course, rooted in the BioMOBY core simple (primitive) and complex (MOBY Object derived) data types (see diagram below; note that a MOBY Collection is a set of any kind of MOBY primitive or Object derived type).
A general design principle in the MOBY platform-specific implementation of the GCP domain model is that most complex class association/attribute component of a parent data type are cross-linked to their parent using a GCP_SimpleIdentifier proxy object (or, in some rare instances, plain old vanilla MOBY:Object). To retrieve the full details of a given component object, it is assumed that the user will invoke an additional web service using that GCP_SimpleIdentifier as the input argument. This strategy provides for very loose decoupling of related data objects from one another.
For example, controlled vocabulary and ontology terms are specified by GCP_SimpleIdentifier. When a full definition of the term is required, the GCP_SimpleIdentifier is fed as input into a suitable web service to return the detailed definition of the term (which also provides a Demeter point of reference from which to navigate the entire ontology).
Associations with GCP_SimpleIdentifier proxy objects imply a dependency between classes that the MOBY data type model often notes using the UML "dependency" (dashed) arrow, used to highlight the fact that one data type dereferences another.
The UML diagrams for some article names of the GCP MOBY data types indicate zero-to-many multiplicity (0..* or simply *), usually, of GCP_SimpleIdentifier objects. This should be interpreted to mean that the articleName in question should be modeled as a MOBY:Collection of the indicated data type (e.g. a MOBY:Collection of GCP_SimpleIdentifier) and the articleName would label the MOBY:Collection itself.
Note that for brevity, the example tables for MOBY data types will not generally indicate the multiplicity of article names but the multiplicity (hence, MOBY:Collection usage) for the embedded components should be assumed as indicated on the UML diagrams.
The MOBY data type can also be shown graphically. Here is a list of available graphs.
The latest Unified Modelling Language (UML) diagrams are being rendered with the Violet UML tool within the Eclipse IDE.
MOBY data types have "article names" or rather, attributes. The narratives have their names in bold. From technical reasons, the figures express class attributes as "get" methods (e.g. getUniqueIdentifier()) - but the narratives talk about them as attributes (e.g. uniqueIdentifier).
Referring to other classes in the text is not always consistent - but usually these references are in italic.