[MOBY-dev] Re: [personal] problem with article names?

[rroyo at lsi.upc.edu]

I'm not sure if I understand option 3...

For example, if I have a service whose inputs are 2 GenericSequence I
will name them sequenceA and sequenceB (because they are ambiguous).
Let's imagine I have another service that has one unnamed output (not
ambiguous) which is a GenericSequence. If I want to make a workflow that
connects this output to the 'sequenceA' input of the first service,
shouldn't the "workflow engine" add the correct articleName? And
shouldn't it retrieve such information about the next service?

Thanks,
Romina

> > then the problem already existed, and making them mandatory was an
> > arbitrary decision taken more to keep the coders happy rather than for
> > any solid architectural reason
> >
>    Well, if you knew that mandatory names bring this problem you could
> tell us, and we could discuss it. I admit that I have not seen this before
> David mentioned it this week. But this a history now, let's concentrate
> rather on the solution.
> 
> > existed in MOBY for a long time - well before there was a decision to
> > make them mandatory.
> >
>    The problem might have existed before, but it was not urgent because
> service providers (mostly, if not all, I guess) did not check for the
> missing name because it was not mandatory. Now, when it is mandatory, my
> service may choose to rely on names and may refuse not-named or
> badly-named inputs. So the milk may have been spilled long time ago but we
> were not in the kitchen so we have not noticed it.
>  
> > I can see two options:  1)  we do not support named primary parameters
> > at all, and thereby limit the types of services that can be created in
> > MOBY to only those with unambiguous inputs/outputs; or 2)  we swallow
> > the inconvenience and at least make it consistent that all
> > inputs/outputs are named.
> >
>    I think that the option 2) is harder to achieve. Doable, but harder. It
> means that all the "workflow engines" (Taverna, Ismail, Ahab, those for
> sure) must find first what article name is expected by a service and tag
> the output of one service by a proper name applicable for the next
> service.
>    I do not like option 1 - if I understand it correctly. Are you saying
> that a service that takes two primary inputs, both of type
> GenericSequence, would not be allowed because without naming these inputs
> we cannot distinguis these sequences? If this is the case, I would
> disagree with having option 1.
> 
>    What about an option 3?:
>    * The primary inputs and outputs must be named (and the correct name
> must be used when sending and providing) data when otherwise the input or
> output would be ambiguous.
>    * An unambiguos input can be send un-named and a service has to accept
> it.
>    * But service should refuse input that is named differently than the
> service registered for.
> 
>    To achieve the last point still requires an effort on the "workflow
> engines" software - they still need to change an output, but they need
> only to clear the name, not to add the correct one. So they do not need
> such information about the next service.
>    You can also argue that the last bullet is not necessary at all. But
> then the architecture would be a bit confusing (even though working): we
> are saying (in such case) "a service registers for a name A, but will
> accept any name". So why to register a name at all, in such case?
> 
>    Cheers,
>    Martin
> 
> -- 
> Martin Senger
>    email: martin.senger at gmail.com
>    skype: martinsenger
> consulting for:
>    International Rice Research Institute
>    Biometrics and Bioinformatics Unit
>    DAPO BOX 7777, Metro Manila
>    Philippines, phone: +63-2-580-5600 (ext.2324)
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 


--
-----------------------------------------------------
Romina Royo Garrido

Instituto Nacional de Bioinformatica (INB) Nodo
Computacional GNHC-2
UPC-CIRI
c/. Jordi Girona 1-3
Modul C6-E201           Tel.   : 934 011 650
E-08034 Barcelona       Fax    : 934 017 014
Catalunya (Spain)       e-mail : rroyo at lsi.upc.edu
-----------------------------------------------------