BioMOBY Object Structure

It is our intention that MOBY Objects should be as lightweight as possible. This not only reduces bandwith, speeds up service response time, and reduces server load, it also reduces conflict that arises from disagreement over the structure of more complex objects. More importantly, however, it results in the creation of Services that have near-transparent semantics. Because of the limited Service Ontology, the functionality of BioMoby services must be clearly described in a single word. Generally speaking, if an Object contains "lots of information", the Service that generates it will be quite complex. Complex services cannot be described in the BioMoby system. As such, BioMoby services attempt to be highly modular - complex data is derived by accessing a broader arrange of lightweight services and integrating this data client-side, in contrast to accessing a "one service provides all" Service whose output consists of many data-types.

MOBY Object structure is inferred by looking up the Object Class in the Class Ontology. Each node in the ontology is a different Class Name, and each arc is a relationship of the type ISA (inheritance), HASA (container of maximal one object of the given class), or HAS (container of zero or more of the given class). ISA relationships are guaranteed to be acyclic.

The root "Object" Class: Minimal Structure

All MOBY Objects inherit from the root "Object" Class, and since complex objects can only be derived through inheritence from (ISA), or combination of (HASA/HAS) existing objects, every sub-object in a complex object is, itself, a valid MOBY Object which inherits directly or indirectly from the "Object" Class.

The root "Object" Class has a very simple composition. It consists of three components:
  1. the Object Class - defines the representation of the resource
  2. the namespace of the resource being represented in that object
  3. the identifier within that namespace that specifies the precise resource represented in the object
These three elements are referred to as the "MOBY Triple".
e.g. a namespace might be a GenBank (NCBI) "gi", and an identifier in that namespace might be "163483"; meaning that the MOBY Triple refers to the resource defined as a GenBank record with the gi=163483

The first component of the triple, the Object Class, is an indication of how that data entity ("resource") contained in the object is going to be represented. Different Classes may reveal different parts of the same data resource.
e.g. an object of the class Sequence with NCBI_gi=163483 would contain the nucleotide or amino acid sequence referred to in that GenBank record, while an object of the class Authorship with NCBI_=163483 would contain the name of the Author(s) for that GenBank record.

When represented in XML, the MOBY Triple is structured as follows:
            <Class namespace="" id=""/>
Thus, the root object describing the GenBank record we describe above would be represented as (all element names and attribute names fall into the moby: namespace)
            <moby:Object moby:namespace="NCBI_gi" moby:id="163483"/>
The content of the Object element is ignored with the exception of the Classes representing primitives (e.g. Integer, Float, String, etc.; discussed in the Special Case Primitives section of the Class Ontology). For example, in the following object
           <moby:Object namespace="NCBI_gi" moby:id="163483" > this value is ignored </Object>
the text "this value is ignored" is ignored by both client and service.

Optional Components in the root "Object" Class

Two optional components may also be present in a base Object (and thus in any derived object, and their sub-objects):

The root "Object" Class: Full Composition

The root "Object" Class, thus, has the following structure when all elements are present (the moby: namespace has been removed from element and attribute names for readability):
          <Object namespace="" id="" attributeName="">
                    <Object namespace="" id="" />
                    <Object namespace="" id="" />
                    <serviceSoftware software_name="" software_version="" software_comment=""/>
                    <serviceDatabase database_name="" database_version="" database_comment=""/>
                    <serviceComment>comment here</serviceComment>  
There are special objects which should be used for interacting with MOBY Central. You can read more about them here.

Additional Requirements of Service Responses

All additional requirements are now deprecated.