Usage:
   java MobyGraphs -h[elp]
   java MobyGraphs [<find-arguments>] <other-arguments>
   or
   run-graphs-client <same arguments as above>

where <find-arguments> specify what Moby registry to connect to (or
      what cache to use instead):

   -cachedir <dir>
      a directory where to cache information from a Moby registry;
      depending on -e and -uri there will be a subdirectory in <dir>
      used; if such subdirectory already exists its contents is used
      instead fetching data from the Moby registry; if it does not
      exist it is created and filled with date fetched from the Moby
      registry

   -e <URL>
      <URL> is 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
      from the MobyCmdLineClient (run-cmdline-client -lr)

where <other-arguments> are:

 General arguments:
 ------------------   
   -q   ... quiet mode

   graph properties:
   -rankdir <LR | TB>
            LR (default): graph directed Left to Right,
            TB: graph directed Top to Bottom

 Making a graph of data types:
 -----------------------------
   -d   ... make graph showing data types

   output destination (default: standard output):
   -fd <file> ... where to put the data types graph
   -f <file>  ... where to put (any) created graph

 Making a graph of service types:
 --------------------------------
   -t   ... make graph showing service types

   output destination (default: standard output):
   -ft <file> ... where to put the service types graph
   -f <file>  ... where to put (any) created graph

 Making a graph of service instances:
 ------------------------------------
   -s   ... make graph showing service instances

   output destination (default: standard output):
   -fs <file> ... where to put the services graph
   -f <file>  ... where to put (any) created graph

   output format:
   -dot  ... Grapviz 'dot' language (this is default);
             to display the result use something like:
                dot -Tpng <file> | display
             (where <file> is what specified by -f)
   -rdf  ... as RDF (not used for -datapath)

   output filter (what services to be included):
   -auth <authority[,authority]...>
   -name <service[,service]...>
   -depth <depth>  ... an integer, how far to go from
                       given services (default is 1)
   or
   -path <service1> <service2>
    draw all pathes from <service1> to <service2>

 Making a graph of service instances based on I/O types:
 -------------------------------------------------------
   -s   ... make graph showing service instances

   -datapath <data-type-name-1> <data-type-name-2>
    draw path(s) starting in <data-type-name-1> and
         ending in <data-type-name-2>;
    <data-type-name-x> can be:
       namespace/dataTypeName or simply
       dataTypeName
       Example: -datapath GO/Object AminoAcidSequence

   -separate ... create one output file for each found path;
                 only paths without cycles and forking are
                 included
    (this option is automatically implied also when any of
     arguments -join or -sculf or -onlyscufl are used)
    
   -join <paths-per-page>
    create separate paths (as defined by -separate) but
    join them again together (as parallel graphs) in graphs
    each of them with maximum <path-per-page> paths

   -scufl ... generate workflow definition (for Taverna)
              for each separate path
   -onlyscufl ... do only what -scufl does without generating
                  any graphs

   additional properties for workflow definition
   (used only with -scufl or -onlyscufl):
   -rawinput
       the generated workflow definition will not include input
       data processors (converting basic data types into Moby XML
       structure. By default it does.
   -rawoutput
       the generated workflow definition will not include output
       data processors (converting basic data types from Moby XML
       structure. By default it does.
   -raw
       the generated workflow definition will not include input
       nor output data processors (converting basic data types
       into/from Moby XML structure. By default it does. This
       does what -rawinput and -rawoutput do together.
   -tverbose
       workflow creation will produce many messages.
       By default it does not.

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