[moby] [MOBY-dev] Re: Problems with Biomoby servicesin Taverna 1.2

Haase, Dirk d.haase at gsf.de
Fri Jul 8 18:45:39 UTC 2005


Hi Mark,

I would not call it inconsistency, they totally contradict ;-)

Consider a service which returns an unpredictable number of database entries. The result set does not form any meaningful construct, each member is just an alternative answer to the query posed.

Once you say (in the reply to Heiko's mail): you can safely return each entry as a Simple element, there can be any number of them in one mobyData block. Moreover, this would actually be a misuse of a collection.

But in the reply to Rebecca's question from February you clearly stated: if the number of results is unpredictable they have to go into a collection.

If I summed up both replies correctly, the contradiction is obvious, isn't it?

dirk

-----Original Message-----
From: moby-dev-bounces at portal.open-bio.org on behalf of Mark Wilkinson
Sent: Fri 7/8/2005 7:22 PM
To: Ernst, Rebecca
Cc: Martin Senger; mobydev
Subject: Re: [moby] [MOBY-dev] Re: Problems with Biomoby servicesin	Taverna 1.2
 
I see no inconsistency between what you quote below and what I said in
my mail from yesterday...

??

M


On Fri, 2005-07-08 at 08:50 +0200, Rebecca Ernst wrote:
> Hi Mark!
> 
> I will have to spank you a lot for either the last email or the one you 
> sent me in February where I asked you how to use collections (see mail 
> below):
> 
> 
> Well... the answer depends on what the generic case of your output will
> look like.  the rule is that you have to register every output object
> that your service produces; i.e. every immediate child tag of a mobyData
> block.  Therefore, if you are going to consistently output exactly 3
> Genbank/gi's, then you would register your service as outputting 3 X
> Object(NCBI_gi).  If you are outputting an indeterminate number of
> objects, then you register it as outputting 1 X Collection.  
> 
> Collections map nicely onto the rdf:Bag structure, if that helps you
> interpret them.
> 
> M
> 
> 
> 
> On Wed, 2005-02-02 at 02:36, Rebecca Ernst wrote:
> 
> >> Hi Mark!
> >> 
> >> We have problems interpreting the BioMoby API for the output objects.
> >> 
> >> The thing is that we have a service that gets ONE input object and 
> >> executes a freetext search over several databases. This service will 
> >> eventually return more that one result.
> >> We don't want to put the result into a collection object because the 
> >> single objects don't build any entity.
> >> We also can't give back more that one mobyData block because we only 
> >> have one query ID and therefore only one queryID to give back.
> >> 
> >> The only solution we can think of is an object like this:
> >> 
> >> <?xml version="1.0" encoding="UTF-8"?>
> >>        <moby:MOBY xmlns:moby="http://www.biomoby.org/moby">
> >>           <moby:mobyContent>
> >>               <moby:mobyData queryID='a1'>
> >>                    <Simple articleName=''>
> >>                       <Object namespace="Genbank/gi" id="163483"/>
> >>                    </Simple>
> >>                    <Simple articleName=''>
> >>                       <Object namespace="Genbank/gi" id="163484"/>
> >>                    </Simple>
> >>                    <Simple articleName=''>
> >>                       <Object namespace="Genbank/gi" id="163485"/>
> >>                    </Simple>
> >>               </moby:mobyData>
> >>           </moby:mobyContent>
> >>        </moby:MOBY>
> >> 
> >> 
> >> 
> >> would this be a legal object or do we have to use collection even if the 
> >> objects don't build an entity ?
> >> 
> >> 
> >> Cheers,
> >> Rebecca
> >  
> >
> -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical 
> Genetics, UBC, Canada
> 
> 
> -----------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> Mark Wilkinson wrote:
> 
> >On Thu, 2005-07-07 at 17:34 +0200, Heiko Schoof wrote:
> >
> >  
> >
> >>I myself am confused about the use of collections. Originally I had in 
> >>my mind that Collections were a construct to allow objects that 
> >>inherently belong together to be "bagged".
> >>    
> >>
> >
> >You are 100% correct here.
> >
> >
> >  
> >
> >>The confusion starts with the output of services. My understanding was 
> >>that ONLY a service that is guaranteed to output exactly one object for 
> >>each query (e.g. an averaging service that outputs the average of a 
> >>list of inputs) is registered as outputting a Simple, all others have 
> >>to output collections
> >>    
> >>
> >
> >No.
> >
> >  
> >
> >> (as there must be exactly one mobyData matching 
> >>the queryID of the input in the response,
> >>    
> >>
> >
> >Yes
> >
> >  
> >
> >> and a mobyData may contain 
> >>multiple Simple elements only if wrapped by a Collection).
> >>    
> >>
> >
> >No.  A mobyData element can wrap any number of outputs, and/or
> >combinations of simples, collections, and secondaries.
> >
> >
> >
> >  
> >
> >>In practice, the Collection tag has been used to indicate when more 
> >>than one Simple occurs, with no "semantic" meaning. This imho is not 
> >>necessary; when more than one Simple occurs, why not put more than one 
> >>Simple? It's easy enough for everyone to figure that out. Then, 
> >>Collection could be used to actually transfer meaning ;-)
> >>    
> >>
> >
> >I think a lot of people are using Collections incorrectly, yes.
> >
> >
> >
> >  
> >
> >>make things clearer, also to e.g. the Taverna developers: Getting back 
> >>many Simple articles in response to a query very intuitively indicates 
> >>to continue on with each one individually, whereas getting back a 
> >>Collection indicates to put the whole thing as input into the next 
> >>service, which is what they implemented. Makes perfect sense, as there 
> >>can and will be services that consume Collections.
> >>    
> >>
> >
> >I don't think that Taverna handled collections correctly in the past,
> >and it would be a shame if that identical functionality was added back
> >in :-)  The functionality does need to go back into Taverna, but
> >correctly this time.
> >
> >
> >
> >  
> >
> >>Maybe I've made myself clear, maybe not. Anyway, the Collection issue 
> >>has led to quite some discussions between Rebecca, Dirk and myself, and 
> >>we are all not happy with the way they are currently handled.
> >>    
> >>
> >
> >I don't know if you are happier with them now that I have pointed out
> >where you are misinterpreting them...??
> >
> >I agree, however, that their usage by many service providers is not
> >correct... but there's no way for MOBY Central to know that it isn't
> >correct, so we can't throw an error on registration of these "wonky"
> >services...
> >
> >M
> >
> >
> >
> >  
> >
> 
-- 
Mark Wilkinson
Asst. Professor
Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics
iCAPTURE Centre
St. Paul's Hospital
Vancouver, BC


_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 6191 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050708/e13cc75c/attachment-0003.bin>


More information about the MOBY-dev mailing list