[MOBY-l] Biomoby and Taverna 1.2

[Rebecca Ernst]

Hi Mark!

I already understood that noone agrees with us ;-)
Funny thing is that everyone keeps talking about collections of 
collections which Dirk never wanted.

snip from Dirk:

Correct. That's why we did not ask for nested collections. We suggest to allow 
for multiple Simple output as default  - which I think is very appropriate 
because  especially query services will usually return more than one result.
This way we would save the collection concept for semantically related 
entities.


I am still not sure if anyone has really understood why we have problems 
with the collections as they are used now but we are happy to leave them 
as they are .

Although if I think about it I have to ask one more provoking question  
( ;-) ) : Why do we have Simples in BioMoby then? I only have VERY few 
services that give back simples according to the API. From my point of 
view we could also leave Simples away as they make no sense to me. It is 
of no valuable information to me if a service gives back exactly three 
or an unknown number of AGI codes....

But as I said already - if everyone is happy with the current use of 
collections I will be quiet from now on :-)
The problem is then only shiftet to the clients (As seen in Taverna it 
leaves a much bigger job for the clients as they will have to split the 
collections)

Cheers,
Rebecca

And you guys in Vancouver would rather go to bed now :-)




markw at illuminae.com wrote:

>>If noone (except of Heiko Dirk and me) want the collections to be
>>changed in the BioMoby API we will have to change the default behaviour
>>of Taverna back to the old one!
>>    
>>
>
>I think your use-case for wanting the behaviour of collections to change is
>unfounded, since it overloads the intended meaning of the Collection element by
>putting WAAAAAAY too much semantics in it.  The use case of having sets of
>multiple alignments represented as Collections of Collections means that the
>inner-most Collection now not only represents a "bag" of things, but a "bag" of
>things that **DO** have a close semantic relationship to each other - these are
>a set of related sequences, and a set of related sequences **is a useful
>Object** in the context of MOBY, could easily trigger the discovery of a
>particular set of services that can specifically operate on sets of closely
>related sequences (versus sets of unrelated sequences), and therefore should be
>given a class of its own (IMO).
>
>Moreover, if we allow collections of collections, we then have a problem of
>recursion - collections of collections of collections of collections of
>collections....  What a nightmare!
>
>The API change is not a significant one, I agree... and in fact, since people
>are already mis-using the messaging format in this way much of the software out
>there can already handle the situation... but given that particular use-case, I
>think you are losing more semantics than you need to be by refusing to create a
>new Object Class.
>
>M
>
>_______________________________________________
>moby-l mailing list
>moby-l at biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>  
>

-- 
Rebecca Ernst
MIPS, Inst. for Bioinformatics
GSF Research Center for Environment and Health
Ingolstaedter Landstr. 1
85764 Neuherberg
fon: +49 89 3187 3583
email: Rebecca.Ernst at gsf.de