Special objects for interacting with MOBY Central

There are three special objects designed specifically for interacting with MOBY Central, all described below:

Registration Object

This XML block is sent back to you as the SOAP payload for all registration and deregistration calls to MOBY Central:
  <MOBYRegistration>
     <success> <!-- 1 | 0 | -1 --> </success>
     <id> <!-- some id number for your registration --> </id>  
     <message> <![CDATA[message here]]> </message>
     <RDF><![CDATA[ the RDF of your service instance here (if applicable) ]]></RDF>
  </MOBYRegistration>
success takes the value "1" to indicate success, "0" to indicate failure, and "-1" to indicate "Pending Curation". id is the deregistration ID of your registered object or service to use in a deregister call. message will contain any additional information such as the reason for failure.

Service Query Object

To query MOBY Central, you fill out the relevant elements of a Query Ojbect. These include the input and/or output data Classes (by name from the Class ontology), the Service-type (by name from the Service-type ontology), the authority (service provider URI), or any number of keywords that must appear in the service description.
  • MOBY Central finds all services which match the contents of the Query Object.
  • All elements are optional, however at least one must be present.
  • All elements present are considered to be increasingly limiting on the search (i.e. "AND").
  • keywords are:
    • one keyword or fragment per keyword element
    • wildcard "*" is allowed in combination with keyword fragments and or sentence fragments (lone "*" is meaningless and ignored)
    • multiple keywords are considered joined by "AND".
In addition to the search parameters, there are three "flags" that can be set in the Query object:
  1. expandServices: when TRUE, this flag will cause MOBY Central to traverse the Service ontology and discover services that are child types (more specific) than the Service-type you requested. For example, you might request "alignment", and it would discover services such as "Blast", "Smith Waterman", "Needleman Wunsch".
  2. expandObjects: when TRUE, this flag will cause MOBY Central to traverse the Class ontology to find services that operate not only on the Object Class you are querying, but also any ontolological parent types of that Object Class. For example, if you request services that work on AnnotatedSequence Objects this flag will also return services that work on Sequence objects, since AnnotatedSequence objects inherit from Sequence objects.
  3. authoritative: When this boolean flag is TRUE, only services that report themselves to be "authoritative" for a particular transformation will be discovered. When set to any other value both authoritative and non-authoritative services will be discovered.
The Query object structure is as follows:
  <inputObjects>
    <Input>
         <!-- one or more Simple or Collection articles -->
    </Input>
  </inputObjects>
  <outputObjects>
    <Output>
         <!-- one or more Simple or Collection articles -->
    </Output>
  </outputObjects>
  <serviceType>ServiceTypeTerm</serviceType>
  <Category>moby</Category>
  <authURI>desired.service.provider</authURI>
  <signatureURL>http://location.to/service/description</signatureURL>
  <serviceName>MyServiceName</serviceName>;
  <expandObjects>1|0</expandObjects> 
  <expandServices>1|0</expandServices>
  <authoritative>1|0</authoritative>
  <keywords>
       <keyword>something</keyword>
       ....
       ....
  </keywords>
When using this object in a query, all of these elements must be present, however they may be empty. Any elements that are filled in, will be joined by an AND during the search. OR is accomplished by comparing the results of multiple queries.

Service List Response Object

Many calls to MOBY Central return a list of services matching your query criteria. The XML for the Service List response is as follows:
 <Services>
   <Service authURI="authority.URI.here" serviceName="MyService" 
	         lsid='urn:lsid:authority.uri:serviceinstance:id'>
     <serviceType lsid='urn:lsid:authority.uri:servicetype:OntologyTerm'>
	       Ontology_Term
	    </serviceType>
     <authoritative>1</authoritative>
     <Category>moby</Category> <!-- 'moby' or 'moby-async' or 'post' -->
     <Description><![CDATA[free text description here]]></Description>
     <contactEmail>your@email.addy.here</contactEmail>
     <URL>http://service.endpoint.here/scriptname</URL>
     <Input>
          <!-- zero or more Simple and/or Collection articles -->
     </Input>
     <Output>
          <!-- zero or more Simple and/or Collection articles --> 
     </Output>
     <secondaryArticles>
          <!-- zero or more Secondary (Parameter) articles -->
     </secondaryArticles>
   </Service>
   ...  <!--  one or more Service blocks may be returned -->
   ...
   ...
 </Services>
The "Service" XML element, contains the attributes of authority URI (authURI), service name (serviceName), and the LSID representing the service instance; the combination of authURI and serviceName is sufficient to unambiguously describe any MOBY service instance in a MOBY Central registry. Thus these are used to retrieve the service definition using the MOBY Central retrieveService procedure call.