[MOBY-guts] biomoby commit
Mark Wilkinson
mwilkinson at pub.open-bio.org
Thu Apr 15 14:38:22 UTC 2004
mwilkinson
Thu Apr 15 10:38:22 EDT 2004
Update of /home/repository/moby/moby-live/Perl/MOBY
In directory pub.open-bio.org:/tmp/cvs-serv16304
Modified Files:
Central.html
Log Message:
updating all documentation that has gone out of sync with the code
moby-live/Perl/MOBY Central.html,1.12,1.13
===================================================================
RCS file: /home/repository/moby/moby-live/Perl/MOBY/Central.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- /home/repository/moby/moby-live/Perl/MOBY/Central.html 2003/12/02 01:08:24 1.12
+++ /home/repository/moby/moby-live/Perl/MOBY/Central.html 2004/04/15 14:38:22 1.13
@@ -2,7 +2,7 @@
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>MOBY::Central.pm - API for communicating with the MOBY Central registry</title>
-<link rev="made" href="mailto:markw at illuminae.(none)" />
+<link rev="made" href="mailto:markw at illuminae.com" />
</head>
<body style="background-color: white">
@@ -155,14 +155,14 @@
<li><strong><a name="item_hasa">MOBY, by default, supports three types of Class Relationships: ISA, HAS, and HASA (these are the relationship ontology terms)</a></strong><br />
</li>
<ul>
-<li><strong><a name="item_foo_isa_bar_is_a_straight_inheritence%2c_where_all">Foo ISA bar is a straight inheritence, where all attributes of bar are guaranteed to be present in foo.</a></strong><br />
+<li><strong><a name="item_foo_isa_bar_is_a_straight_inheritence_2c_where_all">Foo ISA bar is a straight inheritence, where all attributes of bar are guaranteed to be present in foo.</a></strong><br />
</li>
-<li><strong><a name="item_foo_has_bar_is_a_container_type%2c_where_bar_is_an">foo HAS bar is a container type, where bar is an object inside of foo in one or more copies.</a></strong><br />
+<li><strong><a name="item_foo_has_bar_is_a_container_type_2c_where_bar_is_an">foo HAS bar is a container type, where bar is an object inside of foo in one or more copies.</a></strong><br />
</li>
-<li><strong><a name="item_foo_hasa_bar_is_a_container_type%2c_where_bar_is_a">foo HASA bar is a container type, where bar is an object inside of foo in one copy only</a></strong><br />
+<li><strong><a name="item_foo_hasa_bar_is_a_container_type_2c_where_bar_is_a">foo HASA bar is a container type, where bar is an object inside of foo in one copy only</a></strong><br />
</li>
</ul>
-<li><strong><a name="item_notice_that%2c_in_a_has_and_hasa_relationships%2c_">notice that, in a HAS and HASA relationships, it is necessary to indicate an article name for each contained object type. Thus, for example, you could have a sequence object that contained a String object with name ``nucleotideSequence'' and an Integer object with the name ``sequenceLength''.</a></strong><br />
+<li><strong><a name="item_notice_that_2c_in_a_has_and_hasa_relationships_2c_">notice that, in a HAS and HASA relationships, it is necessary to indicate an article name for each contained object type. Thus, for example, you could have a sequence object that contained a String object with name ``nucleotideSequence'' and an Integer object with the name ``sequenceLength''.</a></strong><br />
</li>
</ul>
<p>Input XML :</p>
@@ -215,7 +215,7 @@
</li>
<li><strong><a name="item_the_isa_ontology_terms_must_exist_or_this_registra">the ISA ontology terms must exist or this registration will fail.</a></strong><br />
</li>
-<li><strong><a name="item_all_parameters_are_required%2e">all parameters are required.</a></strong><br />
+<li><strong><a name="item_all_parameters_are_required_2e">all parameters are required.</a></strong><br />
</li>
<li><strong><a name="item_email_must_be_valid_for_later_deregistration_or_up">email must be valid for later deregistration or updates</a></strong><br />
</li>
@@ -306,13 +306,13 @@
</li>
<li><strong><a name="item_a_service_must_have_at_least_one_input_or_output_o">a service must have at least one Input OR Output Object Class. Either Input or Output may be blank to represent ``PUT'' or ``GET'' services respectively</a></strong><br />
</li>
-<li><strong><a name="item_the_contactemail_address_must_be_valid%2c_as_it_is">the contactEmail address must be valid, as it is used to authorize deregistrations and changes to the service you registered.</a></strong><br />
+<li><strong><a name="item_the_contactemail_address_must_be_valid_2c_as_it_is">the contactEmail address must be valid, as it is used to authorize deregistrations and changes to the service you registered.</a></strong><br />
</li>
-<li><strong><a name="item_the_%22authoritativeservice%22_tag_is_used_to_indi">the ``authoritativeService'' tag is used to indicate whether or not the registered service is ``authoritative'' for that transformation. i.e. if anyone else were to perform the same transformation they would have to have obtained the information to do so from you. This is similar to, but not necessarily identical to, mirroring someone elses data, since the data in question may not exist prior to service invocation.</a></strong><br />
+<li><strong><a name="item_the__22authoritativeservice_22_tag_is_used_to_indi">the ``authoritativeService'' tag is used to indicate whether or not the registered service is ``authoritative'' for that transformation. i.e. if anyone else were to perform the same transformation they would have to have obtained the information to do so from you. This is similar to, but not necessarily identical to, mirroring someone elses data, since the data in question may not exist prior to service invocation.</a></strong><br />
</li>
<li><strong><a name="item_only_input_secondary_articles_are_defined_during_r">only Input Secondary articles are defined during registration; Output Secondary objects are entirely optional and may or may not be interpreted Client-side using their articleName tags.</a></strong><br />
</li>
-<li><strong><a name="item_service_categories%3a">Service Categories:</a></strong><br />
+<li><strong><a name="item_service_categories_3a">Service Categories:</a></strong><br />
</li>
<ul>
<li><strong><a name="item_structure">moby - for services that use the MOBY SOAP messaging format and object structure (i.e. the objects used in service transaction inherit from the root 'Object' Class in the MOBY Class ontology).</a></strong><br />
@@ -320,45 +320,45 @@
<ul>
<li><strong><a name="item_organization">authURI - a URI representing your organization (e.g. yourdomain.com); no http-prefix, and no trailing path information is allowed.</a></strong><br />
</li>
-<li><strong><a name="item_servicename_%2d_an_arbitrary%2c_but_unique%2c_name">serviceName - an arbitrary, but unique, name for your service within your authURI namespace</a></strong><br />
+<li><strong><a name="item_servicename__2d_an_arbitrary_2c_but_unique_2c_name">serviceName - an arbitrary, but unique, name for your service within your authURI namespace</a></strong><br />
</li>
-<li><strong><a name="item_url_%2d_the_url_to_a_soap_cgi_server_that_can_invo">URL - the URL to a SOAP CGI server that can invoke a method as described by your serviceName</a></strong><br />
+<li><strong><a name="item_url__2d_the_url_to_a_soap_cgi_server_that_can_invo">URL - the URL to a SOAP CGI server that can invoke a method as described by your serviceName</a></strong><br />
</li>
</ul>
-<li><strong><a name="item_wsdl_%2d_for_other_soap_services_that_do_not_use_t">wsdl - for other SOAP services that do not use the MOBY messaging format. The other elements in the registration should be interpreted as follows:</a></strong><br />
+<li><strong><a name="item_wsdl__2d_for_other_soap_services_that_do_not_use_t">wsdl - for other SOAP services that do not use the MOBY messaging format. The other elements in the registration should be interpreted as follows:</a></strong><br />
</li>
<ul>
<li><strong>authURI - a URI representing your organization (e.g. yourdomain.com); no http-prefix, and no trailing path information is allowed.</strong><br />
</li>
<li><strong>serviceName - an arbitrary, but unique, name for your service within your authURI namespace</strong><br />
</li>
-<li><strong><a name="item_url_%2d_the_url_from_which_a_wsdl_document_describ">URL - the URL from which a WSDL document describing your service can be retrieved by an HTTP GET call.</a></strong><br />
+<li><strong><a name="item_url__2d_the_url_from_which_a_wsdl_document_describ">URL - the URL from which a WSDL document describing your service can be retrieved by an HTTP GET call.</a></strong><br />
</li>
</ul>
-<li><strong><a name="item_comments_about_input_and_output_for_moby_and_non%2">Comments about Input and Output for MOBY and non-MOBY services</a></strong><br />
+<li><strong><a name="item_comments_about_input_and_output_for_moby_and_non_2">Comments about Input and Output for MOBY and non-MOBY services</a></strong><br />
</li>
<ul>
-<li><strong><a name="item_in_%22moby%22_services%2c_the_input_and_output_mes">in ``moby'' services, the input and output messaging structure is defined by the BioMOBY API, and the services use data Objects that are defined in the Class ontology as inheriting from the root ``Object'' Class.</a></strong><br />
+<li><strong><a name="item_in__22moby_22_services_2c_the_input_and_output_mes">in ``moby'' services, the input and output messaging structure is defined by the BioMOBY API, and the services use data Objects that are defined in the Class ontology as inheriting from the root ``Object'' Class.</a></strong><br />
</li>
-<li><strong><a name="item_for_%22wsdl%22_services%2c_there_is_additional_fle">For ``wsdl'' services, there is additional flexibility:</a></strong><br />
+<li><strong><a name="item_for__22wsdl_22_services_2c_there_is_additional_fle">For ``wsdl'' services, there is additional flexibility:</a></strong><br />
</li>
<ul>
-<li><strong><a name="item_similar_to_a_%22moby%22_service%2c_your_%22wsdl%22">Similar to a ``moby'' service, your ``wsdl'' service must consume/produce named data types. These are represented as LSID's</a></strong><br />
+<li><strong><a name="item_similar_to_a__22moby_22_service_2c_your__22wsdl_22">Similar to a ``moby'' service, your ``wsdl'' service must consume/produce named data types. These are represented as LSID's</a></strong><br />
</li>
<li><strong><a name="item_you_do_not_need_to_register_these_data_types_in_mo">YOU DO NOT NEED TO REGISTER THESE DATA TYPES in MOBY Central; it is up to you what your LSID's represent, and MOBY Central WILL NOT try to resolve them!</a></strong><br />
</li>
<li><strong><a name="item_or">You may mix ontologies when describing your service - i.e. you may freely use any MOBY Object as your input or (XOR) your output and use a non-MOBY object (LSID) for the alternate so long as you follow the MOBY message structure for the parameter that uses the MOBY Object</a></strong><br />
</li>
<ul>
-<li><strong><a name="item_you_may_register%2c_for_example%2c_a_service_that_">You may register, for example, a service that consumes a non-MOBY data Class and outputs a MOBY data class, so long as you follow the MOBY Messaging format for the output data</a></strong><br />
+<li><strong><a name="item_you_may_register_2c_for_example_2c_a_service_that_">You may register, for example, a service that consumes a non-MOBY data Class and outputs a MOBY data class, so long as you follow the MOBY Messaging format for the output data</a></strong><br />
</li>
<li><strong>You may register, for example, a service that consumes a MOBY data Class and outputs a non-MOBY data class, so long as you follow the MOBY Messaging format for the input data</strong><br />
</li>
-<li><strong><a name="item_note%3a_nether_of_the_cases_above_are_considered_m">NOTE: Nether of the cases above are considered MOBY services, and are therefore described in the category of ``soap'' service</a></strong><br />
+<li><strong><a name="item_note_3a_nether_of_the_cases_above_are_considered_m">NOTE: Nether of the cases above are considered MOBY services, and are therefore described in the category of ``soap'' service</a></strong><br />
</li>
</ul>
</ul>
-<li><strong><a name="item_secondaryarticles_%2d_not_applicable%3b_should_be_">secondaryArticles - not applicable; should be left out of message.</a></strong><br />
+<li><strong><a name="item_secondaryarticles__2d_not_applicable_3b_should_be_">secondaryArticles - not applicable; should be left out of message.</a></strong><br />
</li>
</ul>
</ul>
@@ -394,14 +394,14 @@
<pre>
There are two forms of Primary articles:</pre>
<ul>
-<li><strong><a name="item_simple_%2d_the_article_consists_of_a_single_moby_o">Simple - the article consists of a single MOBY Object</a></strong><br />
+<li><strong><a name="item_simple__2d_the_article_consists_of_a_single_moby_o">Simple - the article consists of a single MOBY Object</a></strong><br />
</li>
<li><strong><a name="item_collection">Collection - the article consists of a collection (``bag'') of MOBY Objects (not necessarily the same object type).</a></strong><br />
</li>
<ul>
-<li><strong><a name="item_their_number%2forder_is_not_relevant%2c_nor_predic">Their number/order is not relevant, nor predictable</a></strong><br />
+<li><strong><a name="item_their_number_2forder_is_not_relevant_2c_nor_predic">Their number/order is not relevant, nor predictable</a></strong><br />
</li>
-<li><strong><a name="item_if_order_is_important_to_the_service_provider%2c_t">If order is important to the service provider, then a collection should not be used, rather the collection should be broken into named Simple parameters. This may impose limitations on the the types of services that can be registered in MOBY Central. If it becomes a serious problem, a new Primary article type will be added in a future revision.</a></strong><br />
+<li><strong><a name="item_if_order_is_important_to_the_service_provider_2c_t">If order is important to the service provider, then a collection should not be used, rather the collection should be broken into named Simple parameters. This may impose limitations on the the types of services that can be registered in MOBY Central. If it becomes a serious problem, a new Primary article type will be added in a future revision.</a></strong><br />
</li>
<li><strong><a name="item_the_use_of_more_than_one_class_in_a_collection_is_">The use of more than one Class in a collection is difficult to interpret, though it is equally difficult to envision a service that would require this. It is purposely left losely defined since any given Service Instance can tighten up this definition during the registration process.</a></strong><br />
</li>
@@ -416,14 +416,14 @@
<p>An example of the use of each of these might be another BLAST service, where you provide the sequences that make up the Blast database as well as the sequence to Blast against it. The sequences used to construct the database might be passed as a Collection input article containing multiple Sequence Objects, while the sequence to Blast against it would be a Simple input article consisting of a single Sequence Object.</p>
<p>There is currently only one form of Secondary article:</p>
<ul>
-<li><strong><a name="item_secondary_%2d_the_article_may_or_may_not_be_specif">Secondary - the article may or may not be specifically configured by the client as Input, and may or may not be returned by the Service as output.</a></strong><br />
+<li><strong><a name="item_secondary__2d_the_article_may_or_may_not_be_specif">Secondary - the article may or may not be specifically configured by the client as Input, and may or may not be returned by the Service as output.</a></strong><br />
</li>
<ul>
-<li><strong><a name="item_in_the_case_of_inputs%2c_they_are_generally_user%2">In the case of inputs, they are generally user-configurable immediately prior to service invocation.</a></strong><br />
+<li><strong><a name="item_in_the_case_of_inputs_2c_they_are_generally_user_2">In the case of inputs, they are generally user-configurable immediately prior to service invocation.</a></strong><br />
</li>
<li><strong><a name="item_during_service_invocation_a_client_must_send_all_s">During service invocation a Client must send all Secondary articles defined in the Service Instance, even if no value has been provided either as default, or Client-side.</a></strong><br />
</li>
-<li><strong><a name="item_secondary_articles_that_are_considered_%22required">Secondary articles that are considered ``required'' by the Service should be registered with a default value.</a></strong><br />
+<li><strong><a name="item_secondary_articles_that_are_considered__22required">Secondary articles that are considered ``required'' by the Service should be registered with a default value.</a></strong><br />
</li>
<li><strong><a name="item_the_service_may_fail_if_an_unacceptable_value_is_p">The Service may fail if an unacceptable value is passed for any Secondary Article.</a></strong><br />
</li>
@@ -497,20 +497,20 @@
<ul>
<li><strong><a name="item_moby_central_finds_all_services_which_match_the_co">MOBY Central finds all services which match the contents of the Query Object.</a></strong><br />
</li>
-<li><strong><a name="item_all_elements_are_optional%2c_however_at_least_one_">All elements are optional, however at least one must be present.</a></strong><br />
+<li><strong><a name="item_all_elements_are_optional_2c_however_at_least_one_">All elements are optional, however at least one must be present.</a></strong><br />
</li>
<li><strong><a name="item_search">All elements present are considered as increasingly limiting on the search (i.e. ``AND'').</a></strong><br />
</li>
-<li><strong><a name="item_keywords_are%3a">keywords are:</a></strong><br />
+<li><strong><a name="item_keywords_are_3a">keywords are:</a></strong><br />
</li>
<ul>
-<li><strong><a name="item_comma%2ddelimited">comma-delimited</a></strong><br />
+<li><strong><a name="item_comma_2ddelimited">comma-delimited</a></strong><br />
</li>
-<li><strong><a name="item_sentence%2dfragments_are_enclosed_in_double%2dquot">sentence-fragments are enclosed in double-quotes</a></strong><br />
+<li><strong><a name="item_sentence_2dfragments_are_enclosed_in_double_2dquot">sentence-fragments are enclosed in double-quotes</a></strong><br />
</li>
<li><strong><a name="item_fragments">wildcard ``*'' is allowed in combination with keyword fragments and or sentence fragments (lone ``*'' is meaningless and ignored)</a></strong><br />
</li>
-<li><strong><a name="item_multiple_keywords_are_considered_joined_by_%22and%">multiple keywords are considered joined by ``AND''.</a></strong><br />
+<li><strong><a name="item_multiple_keywords_are_considered_joined_by__22and_">multiple keywords are considered joined by ``AND''.</a></strong><br />
</li>
</ul>
</ul>
@@ -520,7 +520,7 @@
</li>
e.g. you might request ``alignment'', and it would discover services such as ``Blast'', ``Smith Waterman'', ``Needleman Wunsch''
<p></p>
-<li><strong><a name="item_expandobjects%3a_this_flag_will_cause_moby_central">expandObjects: 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 parent types or sub-objects of that Object Class.</a></strong><br />
+<li><strong><a name="item_expandobjects_3a_this_flag_will_cause_moby_central">expandObjects: 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 parent types or sub-objects of that Object Class.</a></strong><br />
</li>
e.g. 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
<p></p></ul>
More information about the MOBY-guts
mailing list