Usage:
   run-cmdline-client -h[elp]
   run-cmdline-client [<find-arguments>]
   run-cmdline-client [<find-arguments>] <other-arguments>
or
   run-any-client MobyCmdLineClient -h[elp]
   run-any-client MobyCmdLineClient [<find-arguments>]
   run-any-client MobyCmdLineClient [<find-arguments>] <other-arguments>

(If run without any arguments or only with <find-arguments>, then it
prints the registry's endpoint and namespace that is going to be used.)

where <find-arguments> specify what Moby registry to connect to:

   -e <URL>
      <URL> ia an endpoint of a Moby registry
   -uri <namespace>
      <namespace> is a URI defining Moby registry's namespace
 or
   -registry <registry-synonym>
      <registry-synonym> is a convenient way to specify a known registry;
      the list of known registries can be obtained by the -lr option

where <other-arguments> specify what to ask a Moby registry to do:

   To get lists of various entities registered by Moby:

   -ls   ... list names of all available services
   -la   ... list names of all available services sorted by authorities
   -lp   ... list names of all available service providers
   -lt   ... list names and descriptions of all service types
   -ln   ... list names and descriptions of all namespaces
   -ld   ... list names and descriptions of all data types
   -lu   ... list URLs of RDF documents describing this registry
   -lr   ... list of known BioMoby registries
             (with -on prints only names/synonyms of the registries) 

 To get entities by their names:

   -wsdl <service-name>
      print WSDL of the given service (using the first available
      authority name for such service name)
   -wsdl <service-name,authority>
      print WSDL of the given service; service is specified by its
      name and by its authority
      (note that the parameter has two parts delimited by a comma)
   -data <data-type-name>
      print definition of given data type
   -rdf [stypes | dtypes | services | namespaces | full]
      print RDF resource of the given contents

 To get ontological relationships of given entities:

   -ot <service-type-name>
      print all parents names of given service type
   -od <data-type-name>
      print all relantionships (types and names) of given data type
   -od2 <data-type-name> ISA
   -od2 <data-type-name> HASA
   -od2 <data-type-name> HAS
      print all relantionships of given type for given data type

 To find services given by their attributes:

   -fn <service-name>
      find services matching this name
   -fn <service-name,authority>
      find services matching this name and authority

   -ft <service-type>
      find services of the given service type

   -fc <category>
      find services of the given category

   -f <keywords>
      find services by keywords (apply logical OR if more keywords);
      <keywords> is a comma-delimited lists of keywords

 To find services by their input and/or output data types
 (note that this works only for simple data, not for collections):

   -fs-type <service-type>
   -fs-auth <authority>
   -fs-in   <inputs> 
      <inputs> are comma-delimited names of inputs;
      each of them is a pair of an input type and a namespace
      separated by an equal sign... sorry
   -fs-out   <outputs>
      <outputs> are comma-delimited names of output types

   You may limit the number of found services by specifying:
   -nc ... do not include services that are child types (more
           specific) than the type you requested
           (this option also applies when searching with -ft)
   -np ... do not include services operating on parent types of
           the data types you requested

 The found services are printed in details, unless:
   -on ... print only names of found services

 To register a data type:

   -rd-name  <data-type-name>
   -rd-desc  <data-type-description>
   -rd-auth  <data-type-authority>
   -rd-email <data-type-contact>
   -rd-isa   <data-type-parents>
      this should be a comma-delimited list of names of the
      parent data types (but Moby accepts now only one parent)
   -rd-hasa  <data-type-attributes>
   -rd-has   <data-type-attributes>
      these should be comma-delimited lists of names of the
      data types referred from this data type;
      every element of this list may have two parts
      separated by a colon: <article-name>:<data-type-name>

 To register a service type:

   -rt-name  <service-type-name>
   -rt-desc  <service-type-description>
   -rt-email <service-type-contact>
   -rt-auth  <service-type-authority>
   -rt-isa   <service-type-parents>
      this should be a comma-delimited list of names of the
      parent service types

 To register a namespace:

   -rn-name  <namespace-name>
   -rn-desc  <namespace-description>
   -rn-auth  <namespace-authority>
   -rn-email <namespace-contact>

 To register a service:

   -rs-name  <service-name>
   -rs-type  <service-type-name>
   -rs-categ <service-category>
   -rs-desc  <service-description>
   -rs-auth  <service-authority>
   -rs-email <service-contact>
   -rs-url   <service-URL>
   -rs-main  <service-authoritative>  use: 1 or 0

   -rs-rdf   <service-signature-URL>
      <service-signature-URL> points to your HTTP space
      to a place where an RDF describing this service will be
   -rs-rdfpath <path-to-RDF-file>
      if the service registration is successful, the returned
      RDF is copied to a file given by <path-to-RDF-file>
      (which completes the registration process);
      use it, however, with caution because this client
      overwrites a possibly existing document (it does not
      merge the new RDF with the possibly existing one);
      Default: it creates a temporary file where the
      returned RDF is stored

   -rs-in    <inputs>
      <inputs> are comma-delimited names of inputs;
      each of them is a pair of an input type and a namespace
      separated by an equal sign... sorry

   -rs-ifile <files-with-inputs>
      <files-with-inputs> are a comma-separated list of
      file names defining input data; the files should
      have format of Java properties, e.g...

   One can combine both methods: -rs-in and -rs-ifile.

   -rs-out   <outputs>
      <outputs> are comma-delimited names of output types

   -rs-ofile <files-with-outputs>
      <files-with-outputs> are a comma-separated list of
      file names defining output data; the files should
      have format of Java properties, e.g...

   One can combine both methods: -rs-out and -rs-ofile.

 To unregister various entities:

   -ud <name>  ... unregister data type known under this name
   -ut <name>  ... unregister service type known under this name
   -un <name>  ... unregister namespace known under this name
   -us <name,authority>  ... unregister service known under this name

 And the rest:

   -call <method-name> [<input-xml>]
     call a method given by <method-name>, potentially with the
     input XML data given by <input-xml>; if the <input-xml>
     is a name of an existing file, the contents of this file
     is used as an input parameter to the called mathod

   -debug  ... print debug messages

 And yet another rest:

   -scall <service-name> <input-xml>
     call a service (!, not a Moby Central) given by <service-name>
     with the input XML data given by <input-xml>; if the <input-xml>
     is a name of an existing file, the contents of this file
     is used instead; an example of a service and its input:

     service name: getMIPSFastaProteinSequence
     input XML:
     <?xml version="1.0" encoding="UTF-8"?>
     <moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
       <moby:mobyContent>
         <moby:mobyData moby:queryID="a1">
           <moby:Simple moby:articleName="">
             <moby:Object moby:namespace="AGI_LocusCode" moby:id="At2g17950" />
           </moby:Simple>
         </moby:mobyData>
       </moby:mobyContent>
     </moby:MOBY>

     format of <service-name>: service-name[,service-authority]

[Undocumented and 'in-the-progress' options: -async, -url <service-url>.]

[Note: You can also use -argsfile <filename> to read arguments from a
file. See details in src/Clients/help/argsfile.example.]