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

[Mark Wilkinson]

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