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

Fri Feb 24 19:57:03 UTC 2006

Hi Oswaldo,

On 24-Feb-2006, at 7:04 PM, Oswaldo Trelles wrote:

> Hi all and Pieter in particular:
>
>
>
> This is Oswaldo from the gnv5 -University of Malaga- group at the INB.
> Perhaps Pieter's mail needs some additional information from our  
> group to
> better understand some aspects of the INB architecture.
>
>
>
> The INB project was started in March'04, a major decision was make  
> to use
> BioMOBY as the underlying integration protocol. However, several of  
> the
> desirable functionalities were not available in the protocol,  
> specially
> important from the INB perspective were the ability to launch large- 
> CPU
> tasks using asynchronous messaging; a protocol for error handling  
> (and, in
> the way, some specific rules for dealing with collections; help  
> information,
> DB optimization, etc etc. we expect to propose extensions in these  
> fields.
> soon).

So far those proposals from the INB group have resulted in valuable  
extensions :), so I'm looking forward to any new proposals.

>
>
> However, we design the architecture keeping in mind to maintain full
> compatibility with moby. A good example is our current async  
> implementation
> (see the attached document for a longer description). What can we  
> learn from
> this document? that we extend the protocol -async- even with the  
> double cost
> of maintain moby compatibility: Even more, our current proposal for  
> async
> was born during the INB meeting (July'05) and discussed with Martin  
> and
> Eddie. This proposal is completely new and -if approved- we will  
> need to
> re-write our async code

I understand. Same here. I experimented with some async stuff, which  
is different from what was proposed, so I rewrote them. In fact we  
have course in two weeks where I want to use one of those services,  
so you will see some async stuff popup in the BioMOBY Central next  
week. Those services were rewritten to make them at least partially  
compatible with the current proposal. Rest assured that I will  
rewrite them once more once the proposal is finished and accepted.

> (well, not at all). Thus, once we are part of the
> moby group and our ideas can be taken into account, we will move  
> closer in
> the moby direction to avoid double work from our side (as you can  
> imagine,
> this is what we want).
>
>
>
> On the other hand, our registration procedure -in my opinion- does  
> not break
> our moby compatibility. In fact you can use directly all the  
> services we
> have developed. If you see the new fields, most of them are used to  
> allow
> (user-friendly and self explicative) automatic interface building.  
> SO they
> don't have any influence in the services call protocol.

Ok, that's good to read. I thought it might have broken  
interoperability.

> We of course will be happy to propose a documentation system and other
> extensions, but at this moment there are other priorities.
>
> In sumary; in fact we have our own ideas about a full protocol. For
> strategic reasons we develeop at our own cost, some moby extension  
> (from a
> practical point of view, we took our own decisions because we  
> needed a fast
> development -you know that error handling have spent more than 4  
> months in
> discussion!!!!)

I know it took a while. It was a bit too long I think, but in the end  
the proposal did improve because of the discussion. Just be glad your  
into bioinformatics and not politics, because otherwise the proposal  
would have taken easily 4 years :).

Cheers,

Pi

> . But we dont want to break moby (and we are not going to do
> that).
>
> sorry for this long (and boring) dissertation.
>
> Oswaldo
>
> PS with repect to the registration procedure, it can be done using  
> moby
> functionality, but we request additional information to be used by our
> client (if you want addictional information on our protocol dont  
> hesitate to
> request)
>
>
>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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