[MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification)

Fri Feb 24 14:21:18 UTC 2006

Hi Johan et al.,

On 24-Feb-2006, at 12:44 PM, Johan Karlsson wrote:

> Hi!
>
> As Mark says, description of secondaries is something the INB have  
> been
> requesting for a while now.
>
> Actually, we are already capturing this information together with some
> additional information during service registration. We store this
> information in a separate database, apart from the Moby Central  
> database.
>
> We have recently started a new registration procedure at the INB where
> (as part of the procedure) service providers can add the following
> additional information about their services:
>
> ·    Name of the author.
> ·    For each input and output (primary/collection parameters), a
> description of the parameter, and a data type example.
> ·    For each secondary parameter, a description of the parameter  
> and an
> example value.
> ·    Help file for the service (in XML format)
> ·    Keywords describing the service (we are working on "semantic"  
> searches)
>
> Maybe some of this information can be useful to the BioMoby community?

I read the INB paper "Intelligent client for integrating  
bioinformatics services" published in Bioinformatics. The things  
mentioned above were described there and it made me wonder... For  
asynchronous service calls the INB leads an initiative to extend the  
BioMOBY standard, which is great! This may take a bit longer to get  
accepted and implemented as compared to hacking together some custom  
extension, but it makes sure that your BioMOBY services are  
compatible with the rest of the BioMOBY world. The INB did the same  
for error handling. But for the things mentioned above the INB people  
chose to go their own way. The "extended service registration"  
procedure is INB specific and the additional (help) info is available  
form a "fourth party" server (not the BioMOBY client, nor the service  
provider, nor the INB BioMOBY Central). I think this is bad. The INB  
BioMOBY Central is out of sync with the official BioMOBY Central and  
no longer compatible, because of the modified registration procedure : 
(. Personally I think this is even worse...

Anyway the things mentioned above would definitely be useful! The  
secondary parameter description was just added to the service  
registration call. So that's solved. When I retrieve a service I get  
the BioMOBY WSDL that contains amongst others all the description  
fields. If I have a typical BLAST service that supports all 40+  
parameters it also means that this WSDL will hold the description for  
40+ params. It's getting big...:). So adding additional help in XML  
format and example input and output there (during registration) would  
make the WSDL we send around even longer. Not my favourite solution.

I would rather like to see a solution where this additional  
information is provided by the service (provider) and only when the  
client requests it explicitly. This way it doesn't need to be stored  
in a BioMOBY Central. This could be done for example using an  
additional method [ServiceName]_help. If this would be standardised  
the new RDF agent, might be extended and use this method to get the  
example input, excute the service with this example input and  
validate the results. It can than check:
* whether the service works
* if the input and output are valid as compared to how the service  
was registered.
If these checks fail it might send an automated e-mail to the  
maintainer of that service and eventually if the issues are not  
resolved remove the service from BioMOBY Central. In the "cleaning  
out the registry" thread Mark mentioned that he would contact service  
providers whose services work perfectly well, but were registered  
incorrectly. No matter how efficient Mark might work, sooner or later  
BioMOBY will be so popular and BioMOBY Central so big, that doing  
this manually won't be feasible anymore. So this needs to be  
automated sooner or later anyway. Having example input and output  
might be used for that. So what do the others think...

Just my 2c,

Pi

>
> Kind regards,
> Johan Karlsson
>
> Mark Wilkinson wrote:
>> Absolutely - I believe the INB had also requested this a while  
>> ago, too.
>>
>> Do we need to go through an RFC for this?  I hope not...
>>
>> If nobody objects, I'll add it to the API right away.  It should only
>> take a couple of minutes to code.
>>
>> M
>>
>>
>>
>> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote:
>>
>>> Can we add an optional description field to the secondary article  
>>> tag?
>>> It might help people fill it out if they have a hint *what* they're
>>> filling out besides the articleName. i.e.:
>>>
>>> <Parameter articleName="NameOfArticle">
>>> 	<desc>This field sets the frameshift penalty in the alignment.   
>>> The higher it is set, the less likely frameshifts will be  
>>> detected and corrected.</desc>
>>>         <datatype>Integer|Float|String|DateTime</datatype>
>>>         <default>...</default> <!-- any/all of these -->
>>>         <max>...</max>         <!-- ... -->
>>>         <min>...</min>         <!-- ... -->
>>>         <enum>...</enum>        <!-- ... -->
>>>         <enum>...</enum>        <!-- ... -->
>>>   </Parameter>
>>>
>>> Sound reasonable?  Does this require a RFC?
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://biomoby.org/mailman/listinfo/moby-dev
>>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-dev

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl