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

[Mark Wilkinson]

I'm glad to see this issue come up.  It has been on my mind for almost
two years.  Once the can of worms was opened by allowing named (primary)
parameters *at all* - this was my decision in year 1 of the project -
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 (and because I don't want to be accused
of "being in the way" when I propose that rational architecture should
trump convenience ;-) )

Named parameters are necessary only in the case of having multiple
identical inputs; however since a client is going to have to deal with
both single-input services where they are not necessary, as well as
services with multiple inputs where they are, the problem has already
existed in MOBY for a long time - well before there was a decision to
make them mandatory.

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.
 
It seems to me that a workflow designer like Taverna can deal with this
quite easily, since individual outputs are mapped specifically on to
individual inputs in the workflow, and so the switching of articleNames
could be accomplished by the execution engine (I say "could be" not
"is", since I don't think that Taverna does this right now).  I don't
know if the symmetry argument is quite valid, since there is still
symmetry in *datatype*, but Simple and Collection (where the articleName
attribute is attached) are not parts of the data-typing system, they are
parts of the messaging system, which should be designed "on the fly" by
whatever client tool you are using anyway.

I guess what I am trying to say is that the original concept of Unix-
like piping of data from one service to the next disappeared from MOBY
long ago.  It worked beautifully at the time!... but it just wasn't rich
enough to handle the types of services we needed it to handle.  Even
having to collect Simples into a Collection broke that concept, so as I
say, this milk was spilt long long ago.

Martin, do you *really* think that this break workflows as a concept, or
does it just break existing workflow tools?  I really don't see that we
have a choice either way, but I'm concerned about how concerned you are.

M





On Fri, 2005-09-02 at 12:16 +0100, Martin Senger wrote:
> Reading David's email about exception, I noticed an interesting point
> which probably need some clarification (but it is noy about exceptions so
> I have changed the subject):
> 
> > Anyway, I keep on guessing what happens with my articleNames if I gather 
> > several Simples and build a Collection with them (in a workfow), or I 
> > split a Collection into its Simples and send them to other service(s) 
> > one by one (in a workflow), and how those articleNames relate to the 
> > "elementID"?
> > 
>    Well, I do not know how they relate to elementID, but I wonder how we
> can send output from a service to another service (in workflow) at all!
> Because if services start to be behaving strictly according to the new API
> and start to require article names, then we have a problem. Big problem I
> would say.
>    If we want to keep symmetry between input and output (and we want it
> desperately otherwise it would not work in workflows engines) we probably
> cannot insist on the mandatorness of the article name (of the top-level
> Simple, or Collection, I am not talking about article names of object's
> children). Am I right?
>    I am either missing something (which is possible in the heat here), or
> we need to talk again about how mandatory the article names should be.
> 
>    Martin
> 
-- 
"Ontologists do it with the edges!"

Mark Wilkinson
Asst. Professor
Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics
iCAPTURE Centre
St. Paul's Hospital
Rm. 166, 1081 Burrard St.
Vancouver, BC, V6Z 1Y6
tel: 604 682 2344 x62129
fax: 604 806 9274