From senger at ebi.ac.uk  Thu Sep  1 01:54:05 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep  1 01:43:22 2005
Subject: [MOBY-dev] jMoby: problems with Ant under Windows
In-Reply-To: <43165859.64ac00f0.3259.3e66@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509010653180.1474166-100000@mozart.ebi.ac.uk>

> Don't yell at me, but all that windows needed was a good
> 'clean'ing.
>
   Eddie, what are you talking about? About Ant problems I asked about?
   M.
 
> Thanks.
> 
> Ed
> 
> > -----Original Message-----
> > From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> > dev-bounces@portal.open-bio.org] On Behalf Of Martin
> > Senger
> > Sent: Wednesday, August 31, 2005 6:19 PM
> > To: Moby Developers
> > Subject: [MOBY-dev] jMoby: problems with Ant under Windows
> > 
> > You are a pool of clever and experiences people - would
> > anybody be able to
> > help me to write (actually to fix) the current Ant's
> > build.zml so it works
> > fine also under Windows? I am desperately seeking an
> > advise:
> > 
> > 1) The command-line arguments when using target <java>
> > cannot remain empty
> > (under Windows). For example, the command-line:
> >     java MosesGenerator -e "" -debug
> > means (under Linux) a command-line with three arguments,
> > but (under
> > windows) a command-line with just two arguments (-e and -
> > debug). Is there
> > a solution for this, at all?
> > 
> > 2) The target <javadoc>, when used with rich attributes
> > (like bottom,
> > headre etc.), does not work under windows. First I had to
> > change double
> > quotes into single quotes (okay, Ant should do it, but
> > does not; but it's
> > doable). Second I have to remove newlines from some XML
> > elements - like
> > the 'bottom' one (okay, doable, but annoying, again Any
> > should do it - as
> > it does for unix). But third: the line for javadoc is too
> > long for
> > windows. Well, if you have a windows running, try the
> > current build.xml -
> > try target 'docs' - and you will see what I am talking
> > about, and perhaps
> > you will kniw how to rectiry.
> > 
> >    Many thanks for your help,
> >    Martin
> > 
> > --
> > Martin Senger
> >    email: martin.senger@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@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 

-- 
Martin Senger
   email: martin.senger@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)

From fgibbons at hms.harvard.edu  Thu Sep  1 09:59:14 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Thu Sep  1 10:01:57 2005
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <200508310321.j7V3L7AG014458@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>

Martin,

Thanks for your comments on the API documentation. As I think I pointed out 
earlier, at this point all I've done is to take what was in the wiki, clean 
up the HTML a bit, and check it into CVS. I added a few little bits of 
text, put in some links, and did a little semantic markup, but that's it.

>    The first few comments about the registry API:
>
>    * I think that the first page (with a list of methods) should also have
>(even start with) a list of links to objects used by these methods, such
>as a query object.

If this API is to language-independent, then I'm not so sure we can talk 
about objects, unless the Java and Perl implementations agree on it. My 
personal feeling is that what's needed most is high-level, abstract 
description of the overall scheme. A year ago, newbies had to try and put 
together that picture from the Perl code. While I think the Javadoc is 
really good (especially MOSES), the Perldoc still needs work. And even when 
both are as good as we'd like them to be, it's still useful to specify the 
API in language-independent terms. In Perl, there is not "query object" 
only registry/service objects.

>    * I disagree with labelling the deregisteService as depracated. As far
>as I understood, it will be still around for quick resgiter/unregister
>cycle where I am not conceedrn about security (that somebody can
>deregister my service). So from the API point of view it is a normal
>method, not a deprecated one. Mark?

Well, this is marked as 'deprecated' in the wiki, hence it is so marked 
here too. At some point (perhaps v 0.9?) it would be great to have a code 
freeze, in which we could make sure that the docs and implementation agree, 
so that we could have a product that is internally consistent, even as 
development continues. There's even nothing wrong with writing the API as 
we *wish* it to be (some would say that's how it should be done), and then 
trying to code to that. We can release a version in which the documentation 
makes clear what is implemented, and what is 'to-do'.

>    * service protocol "moby" is actually a service category, not a 
> protocol I think

>    * some details have also categories cgi.soap, some not... I suggest to
>remove all cgi and sopa for now (we will have in in the CVS if we need it
>to re-introsduce it later; surely the 'soap' category bring nothing than a
>confusion (isn't it current moby based on soap? - I know how it is, but
>newbies perhaps not)

Yeah, I tend to agree that this is confusing, since only "moby" exists (not 
"cgi" and "soap"). I agree that they should be culled, but since this is 
what was in the wiki, and I didn't know what the development plans were for 
it, I left it in.

>    * I would move definition of a "A MOBY compliant service" to the
>section about services API (here may be just a link to it).  As I said I
>am really concern that these two APIs are (or were before you enter the
>scene) confusing, so make them as separate as possible.

I agree, I'll try to get greater separation between the registry and 
services APIs.

>    * retrieveResourceURLs has a wrong description (something about providers)

I think is still under development - Mark?

>    And the last (but not an unimportant) general comment: the XML-based
>API should be expressed as DTD (which is more preferable in this context,
>XSD is not so human readable).

I think we'll need a volunteer to help us out on that - I've used DTD/XSDs, 
but never written one. Anyone?

>    Also the details about individual tags and attributes are quitel 
> imited now.

Yeah, we really need to beef up the details.

Thanks for your useful comments, Martin. I look forward to more.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

From senger at ebi.ac.uk  Thu Sep  1 10:31:05 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep  1 10:21:06 2005
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <Pine.OSF.4.21.0509011524240.895262-100000@ice.ebi.ac.uk>

> If this API is to language-independent, then I'm not so sure we can talk 
> about objects
>
   Oh no, no, that's a misunderstanding. Sorry for the confusion. I would
be the first who would shout "Long Live Language Independence!". I said
"query object" because this term is used in the current API. But I meant
the XML, of course.

> Well, this is marked as 'deprecated' in the wiki, hence it is so marked 
> here too.
>
   I understand. It was more to Mark. Just to record my concern and fear
that Mark can one day remove it and say "what are you complaining about,
it was deprecated already for years?". I am quite often scare what Mark
can do suddenly... (well, I wanted to add :-) but I found that it was not
a joke, after all).

> >    * retrieveResourceURLs has a wrong description (something about providers)
> 
> I think is still under development - Mark?
>
   Not as far I know. I have it already implemented in jMoby and it worked
(about a month ago). The only thing stull under discussion was the content
type of this resources (if to provide more or not). And also a clear
definition what is expected from the service providers when they suddenly
become the LSID metadata resolvers.
 
   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Thu Sep  1 08:44:22 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu Sep  1 11:35:56 2005
Subject: [MOBY-dev] jMoby: problems with Ant under Windows
In-Reply-To: <Pine.OSF.4.21.0509010653180.1474166-100000@mozart.ebi.ac.uk>
Message-ID: <4316f7ad.17975dab.1578.1c6c@mx.gmail.com>

I just meant that the clean compile command worked.

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Wednesday, August 31, 2005 10:54 PM
> To: Core developer announcements
> Subject: RE: [MOBY-dev] jMoby: problems with Ant under
> Windows
> 
> > Don't yell at me, but all that windows needed was a good
> > 'clean'ing.
> >
>    Eddie, what are you talking about? About Ant problems I
> asked about?
>    M.
> 
> > Thanks.
> >
> > Ed
> >
> > > -----Original Message-----
> > > From: moby-dev-bounces@portal.open-bio.org
> [mailto:moby-
> > > dev-bounces@portal.open-bio.org] On Behalf Of Martin
> > > Senger
> > > Sent: Wednesday, August 31, 2005 6:19 PM
> > > To: Moby Developers
> > > Subject: [MOBY-dev] jMoby: problems with Ant under
> Windows
> > >
> > > You are a pool of clever and experiences people -
> would
> > > anybody be able to
> > > help me to write (actually to fix) the current Ant's
> > > build.zml so it works
> > > fine also under Windows? I am desperately seeking an
> > > advise:
> > >
> > > 1) The command-line arguments when using target <java>
> > > cannot remain empty
> > > (under Windows). For example, the command-line:
> > >     java MosesGenerator -e "" -debug
> > > means (under Linux) a command-line with three
> arguments,
> > > but (under
> > > windows) a command-line with just two arguments (-e
> and -
> > > debug). Is there
> > > a solution for this, at all?
> > >
> > > 2) The target <javadoc>, when used with rich
> attributes
> > > (like bottom,
> > > headre etc.), does not work under windows. First I had
> to
> > > change double
> > > quotes into single quotes (okay, Ant should do it, but
> > > does not; but it's
> > > doable). Second I have to remove newlines from some
> XML
> > > elements - like
> > > the 'bottom' one (okay, doable, but annoying, again
> Any
> > > should do it - as
> > > it does for unix). But third: the line for javadoc is
> too
> > > long for
> > > windows. Well, if you have a windows running, try the
> > > current build.xml -
> > > try target 'docs' - and you will see what I am talking
> > > about, and perhaps
> > > you will kniw how to rectiry.
> > >
> > >    Many thanks for your help,
> > >    Martin
> > >
> > > --
> > > Martin Senger
> > >    email: martin.senger@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@biomoby.org
> > > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> --
> Martin Senger
>    email: martin.senger@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@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From markw at illuminae.com  Thu Sep  1 12:23:04 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu Sep  1 12:12:32 2005
Subject: [moby] [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <1125591784.28085.50.camel@bioinfo.icapture.ubc.ca>

On Thu, 2005-09-01 at 09:59 -0400, Frank Gibbons wrote:

> >    * I disagree with labelling the deregisteService as depracated. As far
> >as I understood, it will be still around for quick resgiter/unregister
> >cycle where I am not conceedrn about security (that somebody can
> >deregister my service). So from the API point of view it is a normal
> >method, not a deprecated one. Mark?

It was the initial intention to remove it permanently from the API
because of the security problem, and have the agent do the
deregistration when the service provider removes their RDF signature;
however that decision is now in flux because of the need for rapid
register/deregister cycles.  As such, I haven't changed the 'deprecated'
status until this is resolved.

The behaviour right now is that a service can be deregistered using this
call if it was initially registered without a signatureURL.  I think
this is a reasonable way to go forward, but since we haven't turned the
agent on yet, it isn't entirely clear if this behaviour is sufficient to
accommodate the majority of cases.  It should be, so I'm be inclined to
de-deprecate that call and simply update the API to reflect its current
behaviour.


> There's even nothing wrong with writing the API as 
> we *wish* it to be (some would say that's how it should be done),

That's more or less how things have been going since the last MOBY
meeting - the API was being updated ahead of the code. I'm trying (more
successfully now than a couple of months ago) to keep them in sync, but
this is an extremely rapid development phase we are going through as we
approach the 1.0 release at the end of this month, so...  yeah... it's a
bit chaotic right now, and will be for the next few weeks.




> >    * some details have also categories cgi.soap, some not... I suggest to
> >remove all cgi and sopa for now (we will have in in the CVS if we need it
> >to re-introsduce it later; surely the 'soap' category bring nothing than a
> >confusion (isn't it current moby based on soap? - I know how it is, but
> >newbies perhaps not)

Yes, let's remove all references to anything other than "moby" category
from the API.  The code did support CGI GET service registrations after
the Singapore hackathon (and it probably still does, but it isn't being
tested regularly); however until we spend some time fully defining this
behaviour we should take it out.  I will update the code to prevent
anything other than "moby" registrations.



> >    * retrieveResourceURLs has a wrong description (something about providers)
> 
> I think is still under development - Mark?

I think it is working as advertised...??

M


-- 
"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

From tmo at ebi.ac.uk  Thu Sep  1 11:47:33 2005
From: tmo at ebi.ac.uk (Tom Oinn)
Date: Thu Sep  1 12:48:00 2005
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <43172295.8090207@ebi.ac.uk>


>>    And the last (but not an unimportant) general comment: the XML-based
>> API should be expressed as DTD (which is more preferable in this context,
>> XSD is not so human readable).
> 
> 
> I think we'll need a volunteer to help us out on that - I've used 
> DTD/XSDs, but never written one. Anyone?

We've used XMLSpy in the past to produce graphical representations of 
XSD and DTD, this is generally easier to read than the textual ones. 
With some restrictions this can also be used to convert XSD to DTD 
although personally I prefer reading XSD.

Tom
From dgpisano at cnb.uam.es  Fri Sep  2 05:31:49 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri Sep  2 05:28:23 2005
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBYv1.5
	- INB proposal
In-Reply-To: <Pine.OSF.4.21.0509010105240.1462154-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509010105240.1462154-100000@mozart.ebi.ac.uk>
Message-ID: <43181C05.7090508@cnb.uam.es>

Martin Senger escribi?:

>>It isn't entirely clear to me that there is a need to throw errors on a
>>specific Simple within a Collection.
>>    
>>
>   I quite like how Mark explained it, and it makes sense to me. I am just
>not too concerned because this part is just an optional part - so the only
>"mandatory" part in the API (regarding this issue) will/would be "...and
>ignore other possibly present attributes in the Simples in a Collection".
>   But still, I am interested to hear David's argumentation againts Mark's
>explanation. David, do you have a real-life use-case where you expect to
>create such response?
>
>  
>
No, I don't have a real life example with an input collection. But I do 
have one with an output collection that could serve as example. We could 
imagine this kind of problems in input collections. Jose Maria sent it 
to the list months ago, but I can post it again. Is a real service which 
is being used in the PlaNet project (getInteractions).

A given service retrieves information about protein interactions from 
different data sources (a couple of SQL databases and one XML data 
base). Each database is stored in a different server, including the 
corresponding DBMS. The input to the service is a Simple representing a 
protein, while the output is a Collection with all possible interactions 
where that protein is participating.

In some cases, the service is not able to contact with a particular 
DBMS. Under this situation, rather than stopping the whole service 
execution and raise an exception for the whole Collection, the service 
could go ahead to the next server and report an exception with 
severity='warning' (assuming that at least one DBMS responded with 
useful information) for one or more Simples inside the Collection.

Even with only partial results, the service is still interesting enough 
for a client to wish it to continue. These types of situations are 
expected to arise -for example- when working with collections.




>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050902/26e5c58f/dgpisano.vcf
From senger at ebi.ac.uk  Fri Sep  2 07:06:28 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep  2 07:05:17 2005
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBYv1.5
	- INB proposal
In-Reply-To: <43181C05.7090508@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>

> corresponding DBMS. The input to the service is a Simple representing a 
> protein, while the output is a Collection with all possible interactions 
> where that protein is participating.
>
   This is a good example because it nicely illustrates what Mark said,
and not a need for naming Simples in a Collection (IMHO) :-) :

   1) First, you cannot have a service that can return *all* protein
interactions. Such service is a sci-fi. So you go for "all possible"
protein interactions. Well, but when a DBMS source is not available, its
interactions are "not possible".
   2) Also, you do not know what interactions *would* be found in the
non-responding DBMS, so you cannot create any Simple representing such
non-returned interactions.
   3) And last, you can still inform the users about not covering all my
resources (this time) in a general warning in mobyException - but there is
really no sense to put this warniong in a collection itself.

   I must admit that I have not paid much attention to this topic when it
was explained in Malage. Because now, I really do not see why we need it.
(I hate to agree to much with Mark, it's dangerous because it is addictive
:-)).

   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Fri Sep  2 07:16:52 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep  2 07:14:01 2005
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <43182A24.1030800@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>

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

-- 
Martin Senger
   email: martin.senger@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)

From dgpisano at cnb.uam.es  Fri Sep  2 07:46:18 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri Sep  2 07:37:31 2005
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in
	bioMOBYv1.5- INB proposal
In-Reply-To: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
Message-ID: <43183B8A.2010607@cnb.uam.es>

Ok, I admit it was not a good example ;-)

Martin Senger escribi?:

>>corresponding DBMS. The input to the service is a Simple representing a 
>>protein, while the output is a Collection with all possible interactions 
>>where that protein is participating.
>>
>  This is a good example because it nicely illustrates what Mark said,
>and not a need for naming Simples in a Collection (IMHO) :-) :
>
>   1) First, you cannot have a service that can return *all* protein
>interactions. Such service is a sci-fi. So you go for "all possible"
>protein interactions. Well, but when a DBMS source is not available, its
>interactions are "not possible".
>  
>
Obviously. Maybe Jose Mar?a could explain it better, but we are not 
talking about the biology here, and probably the example should say *all 
possible protein interactions stored in my databases", ok. But the topic 
is why should I want to report an error for a Simple in a Collection, 
not if is possible to obtain all interactions for a given protein or not ;-)

The example (like all examples) should help us to extrapolate and 
imagine real use cases. In this case, I can imagine another service 
where I want to annotate an input probe list collection (those present 
in my microarray), for example against several databases with different 
information. Some of them are not available at execution time, or cannot 
find the required information because the query does not accept a given 
input character, so I want to inform the user that I have a warning for 
this specific probe, because I was not able to retrieve the information 
from the db due to whatever problem had happened.

>   2) Also, you do not know what interactions *would* be found in the
>non-responding DBMS, so you cannot create any Simple representing such
>non-returned interactions.
>  
>
Again, let's suppose my Simple needs the name *and* the type and 
description of the interaction, and that pieces of information are 
stored in different DB's. What if I can retrieve the name (ie, not an 
empty simple) but cannot retrieve its type, description, etc... (ie, my 
object is not empty but cannot be completed...)?

>   3) And last, you can still inform the users about not covering all my
>resources (this time) in a general warning in mobyException - but there is
>really no sense to put this warniong in a collection itself.
>  
>
I still think that the general case (a whole resource needed for the 
service or the collection is not available) is different than the 
particular case (a single error, warning or information could be 
generated for a particular Simple inside an input Collection, while the 
other Simples are all right).

>   I must admit that I have not paid much attention to this topic when it
>was explained in Malage. Because now, I really do not see why we need it.
>
Whatever. Is an optional part in the proposal, and depends on a BioMOBY 
specification change to be possible to implement, so there is no problem 
in removing it from the proposal if the community thinks is not 
necessary to specify it. We will save the file for future use if needed ;-)

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050902/8f080999/dgpisano.vcf
From jmfernandez at cnb.uam.es  Fri Sep  2 08:53:54 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Fri Sep  2 08:48:29 2005
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <43184B62.5020606@cnb.uam.es>

> 
>>    And the last (but not an unimportant) general comment: the XML-based
>> API should be expressed as DTD (which is more preferable in this context,
>> XSD is not so human readable).
> 
> 
> I think we'll need a volunteer to help us out on that - I've used 
> DTD/XSDs, but never written one. Anyone?
> 

Well, I have developed many XML based formats, and I have used maaaany 
different tools since I began. I agree with Tom about XSD, . A useful 
open source tool is Pollo (pollo.sourceforge.net). Other ones are 
XMLmind XML Editor (http://www.xmlmind.com/xmleditor/) and oXygen 
(http://www.oxygenxml.com/), which I used to generate the documentation 
for a XML Schema I developed using Pollo (see 
http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).

I'm quite busy now, but if you give me one week I can do that.

	Best Regards,
		Jos? Mar?a

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez@cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From edward.kawas at gmail.com  Fri Sep  2 08:53:47 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri Sep  2 08:50:05 2005
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
Message-ID: <43184b5f.14a53cea.215f.410d@mx.gmail.com>

Martin,

Can you explain this a little more because I don?t
understand what you are trying to say.

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Friday, September 02, 2005 4:17 AM
> To: David Gonz?lez Pisano
> Cc: Mark Wilkinson; Moby Developers
> Subject: [MOBY-dev] problem with article names?
> 
> 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
> 
> --
> Martin Senger
>    email: martin.senger@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@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev


From senger at ebi.ac.uk  Fri Sep  2 09:13:18 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep  2 09:02:33 2005
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <43184b5f.14a53cea.215f.410d@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509021406450.695974-100000@ice.ebi.ac.uk>

> Can you explain this a little more because I don?t
> understand what you are trying to say.
>
   So perhaps I am on a wrong track. But here it is:

   A service has to have article names for its inputs and outputs
(according the new API).
   An example: MyService produces GenericSequence with an article name
"Sequence". YourService is registered as consumig also GenericSequence but
with an article name "QuerySequence".
   I put in Taverna a workflow: MyService --> YourService.
   MyService produces a GenericSequence with a name "Sequence" - because
that's how it was registered. YourSequence gets data from MySequence. It
expect an article name "QuerySequence" but wht it gets is a sequence with
an article name "Sequence". YourService starts to wonder what the hell
should I do with it?
   Because if YourService is able to accept any name, then why we bother
to have them at all?
   Thsi is a situation, most common situation, where a service has only
one input and one output.

   Martin

-- 
Martin Senger
   email: martin.senger@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)


From senger at ebi.ac.uk  Fri Sep  2 09:17:13 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep  2 09:06:21 2005
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <43184B62.5020606@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>

> for a XML Schema I developed using Pollo (see 
> http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).
>
   That's exactly I was hoping in... Good examples.
   Just tell me where the pieces of documentation come from? I guess they
must come from the XSD file itself - is there a "documentation" tag for
it, or what?

   Martin

-- 
Martin Senger
   email: martin.senger@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)

From markw at illuminae.com  Fri Sep  2 11:28:04 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Sep  2 11:17:23 2005
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
Message-ID: <1125674884.29942.26.camel@bioinfo.icapture.ubc.ca>


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

From markw at illuminae.com  Fri Sep  2 11:41:15 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Sep  2 11:30:29 2005
Subject: [moby] Re: [personal] Re: [MOBY-dev] [RFC] Exception Reporting
	in bioMOBYv1.5- INB proposal
In-Reply-To: <43183B8A.2010607@cnb.uam.es>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
	<43183B8A.2010607@cnb.uam.es>
Message-ID: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>

On Fri, 2005-09-02 at 13:46 +0200, David Gonz?lez Pisano wrote:

> Again, let's suppose my Simple needs the name *and* the type and 
> description of the interaction, and that pieces of information are 
> stored in different DB's. What if I can retrieve the name (ie, not an 
> empty simple) but cannot retrieve its type, description, etc... (ie, my 
> object is not empty but cannot be completed...)?

That's a great example, and does make the case quite convincingly...

...but *please* don't use articleName to achieve this!  :-)

M



-- 
"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

From markw at illuminae.com  Fri Sep  2 11:41:15 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri Sep  2 11:30:30 2005
Subject: [moby] Re: [personal] Re: [MOBY-dev] [RFC] Exception Reporting
	in bioMOBYv1.5- INB proposal
In-Reply-To: <43183B8A.2010607@cnb.uam.es>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
	<43183B8A.2010607@cnb.uam.es>
Message-ID: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>

On Fri, 2005-09-02 at 13:46 +0200, David Gonz?lez Pisano wrote:

> Again, let's suppose my Simple needs the name *and* the type and 
> description of the interaction, and that pieces of information are 
> stored in different DB's. What if I can retrieve the name (ie, not an 
> empty simple) but cannot retrieve its type, description, etc... (ie, my 
> object is not empty but cannot be completed...)?

That's a great example, and does make the case quite convincingly...

...but *please* don't use articleName to achieve this!  :-)

M



-- 
"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

From dgpisano at cnb.uam.es  Fri Sep  2 06:32:04 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri Sep  2 11:32:10 2005
Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.7 - INBproposal
In-Reply-To: <Pine.OSF.4.21.0508310222530.1148966-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0508310222530.1148966-100000@mozart.ebi.ac.uk>
Message-ID: <43182A24.1030800@cnb.uam.es>

Martin Senger escribi?:

>Thanks for the updated document. Before I express my comments to it
>here is a few bits regarding RFC procedure for this proposal (assuming
>that we agreed on an RFC procedure as, or close to, suggested in
>previous emails:
>
>1) I second the proposal (so it can become an RFC) 
>
Thanks. Let's move this quickly and go over the asynchony one ;-)

>2) I suggest to resolve it (accept or refuse) before September 15 (so
>this is an RFC calendar). Concretely, I propose that Mark will ask
>selected voters after this date to vote on it. (BTW, I like and
>support his idea to have a year-long tenure on the voting list (that's
>actually very close why OMG has its Architecture Board also with
>rotating, and *dedicated*, people).
>
>Now back to the proposal, here are my comments (I suggest that those
>comments that are acceptable by the INB authors, and that are not in
>contradiction with the email discussion, will be incorporate and a new
>draft will be circulated - perhaps already without reasoning).  
>
Here you have the new draft (version 1.7, version 1.6 was internal review)

>Generally, I like the proposal, my comments are only about details.
>
>1) The attribute names 'Value' and 'Description' are not
>intuitive. They should express more what they are about. What about
>"errorCode" (or only "code") and "errorMessage" (or only "message")? 
>
Changed to "exceptionCode" and "exceptionMessage" so we refer to all 
exceptions (errors, warnings and other information messages). 
"errorCode" sounds to me like "only for errors"...

>2) I know that the article name in Simples in Collection is an
>optional part of the proposal - but I agree with Mark that using there
>again the term "articleName" is bad (too overloaded). What about to
>use there a completely different tag, like "elementId"?
>
>>From this change (if accepted) follows at once that the attribute name
>in mobyException should not be "refArticleName" (because sometimes it
>refers to a non-article name) - so why not to call it just a "ref", or
>"refElement"?
>  
>
Let's name it refElement and keep on mentioning the optional part if 
Mark agrees that naming Simples inside Collections could be possible. 
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"?

>3) I would like to have (in the exception API handling) a remark that
>the clients are obliged to be aware that a service can also raise an
>exception that will be delivered in the SOAP envelope (that is a
>standard way). As I said, good clients have to do it anyway (because
>your service does not have always full control what to return back) -
>so I would keep this option there.
>  
>
Is mentioned in the last part of the document, but there is nothing we 
propose about the structure and content of the SOAP Fail payload... 
Should that be discussed, or better we focus on the MOBY part and just 
mention that the clients should be aware that some exceptions could be 
in the SOAP layers (ie, write your SOAP exception handling code in your 
client for better exception catching in all the layers of the 
communication)?

>4) Just to keep in synch with other software projects, I would add one
>more severity level - a simple "message" (so we would have, errors,
>warnings, messages).
>  
>
That would be, for example:

a. Exception severity (*severity* attribute in *mobyException* tag)
Values: *error*  | *warning *|* information*

>5) The list of codes is not always clear:
>   - should the sub-phrases in 201 be distinguish by a separate code?
>   - 621 (service not available) means actually that the resources the
>service wishes to use are not available (because if it was a service
>itself, it would not have any chance to report it, that would be a
>soap exception mentioned above),
>   - 622 (malformed Moby response) - what is a response here? - and
>anyway, this may be difficult to catch (I know in SOAP::Lite you do
>not get control only when the whole XML is parsed)
>   - why do you call some codes "client-side detected errors"?
>
>   - generally, I would put less codes and rather to define how
>service providers can expressed their own service-specific codes (by
>saying in which range they should put such specific codes)
>  
>
Rewritten the errors part. The main objetive, in our opinion, is to list 
the common errors that could occur in the execution of a web service 
(list taken from LSAE) _and_ the errors common to all bioMOBY services 
(as extension to LSAE). Only the errors that are particular to specific 
services are should not be included. We are using the recommendations in 
LSAE to extend the error codes range.

Note that there are a number of errors (service not available, for 
example) that only the client can report. We can call them client-side 
detected errors and give some codes, or just skip them, reduce to scope 
of this proposal only to the bioMOBY errors reportable by the services, 
and give the clients the freedom to report client-side detected errors 
as they want.

>6) Some typos:
>   - articlename attribute should be articleName
>   - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is
>something else in Biomoby API)
>  
>
Changed that

>7) Attributes in mobyException (refArticleName, or whatever name we
>will agree on, and reqQuery) should be made optional - so an exception
>can refer to the whole response (or to a whole query if only reqQuery
>is present).
>  
>
I agree, that allows us to report an exception for the whole mobyContent 
(it was in the motivations but no clearly stated in the specification 
proposal). Already added.

>   With regards,
>   Martin
>  
>
Thanks for the comments and corrections,

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v1.7.doc
Type: application/msword
Size: 187392 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050902/938c216c/0501INB-ExceptionReporting-v1.7-0001.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050902/938c216c/dgpisano-0001.vcf
From carrere at toulouse.inra.fr  Fri Sep  2 14:28:57 2005
From: carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Fri Sep  2 14:37:31 2005
Subject: [MOBY-dev] Server maintenance: services unreachable
	bioinfo.genopole-toulouse.prd.fr
In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>	<43183B8A.2010607@cnb.uam.es>
	<1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>
Message-ID: <431899E9.3060403@toulouse.inra.fr>

Due to maintenance on our server (inverter change), services provided by 
*bioinfo.genopole-toulouse.prd*.fr will be unreachable next *Tuesday 
(September 6th)* during  5 hours (10 a.m. to 3 p.m. GMT+1).

Sebastien Carrere

-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.18/87 - Release Date: 01/09/2005
From senger at ebi.ac.uk  Fri Sep  2 23:03:03 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep  2 22:59:48 2005
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <1125674884.29942.26.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>

> 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@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)

From senger at ebi.ac.uk  Sun Sep  4 10:45:31 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun Sep  4 10:35:01 2005
Subject: [MOBY-dev] jMoby: third-parties libraries update
Message-ID: <Pine.OSF.4.21.0509041542170.1093336-100000@mozart.ebi.ac.uk>

I have update Axis libraries to its latest version. Also alltools2 were
rebuilt considerably (and alltools.jar removed). Therefore, please start
your next session with jMoby by:
   ./build.sh
which should update your lib directory. After that do:
   ./build-dev.sh clean compile

I tried to test it as much as I was able... If you still find a problem
please report it and I will fix it asap.

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From jmfernandez at cnb.uam.es  Mon Sep  5 11:26:09 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon Sep  5 11:17:15 2005
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>
Message-ID: <431C6391.5080708@cnb.uam.es>



Martin Senger wrote:
>>for a XML Schema I developed using Pollo (see 
>>http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).
>>
> 
>    That's exactly I was hoping in... Good examples.
>    Just tell me where the pieces of documentation come from? I guess they
> must come from the XSD file itself - is there a "documentation" tag for
> it, or what?

Yes, it is. XML Schema allows you to create a xsd:annotation inside 
almost any XML Schema tag (attribute and element declarations, keys, 
etc...), and inside xsd:annotation you can add one or more 
xsd:documentation tags. If you look inside 
http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML.xsd, you will see the 
xsd:documentation tag.

David uses XMLSpy and he has told me that XMLSpy documentation is 
translated to xsd:documentation tags when a XML Schema is generated.

	Best Regards,
		Jos? Mar?a

> 
>    Martin
> 

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez@cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From jmfernandez at cnb.uam.es  Mon Sep  5 16:28:17 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon Sep  5 16:18:04 2005
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>
Message-ID: <431CAA61.8030009@cnb.uam.es>

Hi everybody,
	there is a fourth option, where it is not mandatory to have an article 
name for primary inputs: primary inputs must be submitted in the same 
order as they were declared at service registration, and they are 
expected to arrive so to the service. Even it could happen that no 
primary input had an article name!

	But there is a drawback: service coding should be more coupled to 
service declaration in order to take into account the input parameters 
order, so this option is more error-prone.

	Best Regards,
		Jos? Mar?a

Martin Senger wrote:
>>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
> 

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez@cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From rroyo at lsi.upc.edu  Tue Sep  6 02:43:10 2005
From: rroyo at lsi.upc.edu (rroyo@lsi.upc.edu)
Date: Tue Sep  6 02:39:54 2005
Subject: [MOBY-dev] Re: [personal] problem with article names?
Message-ID: <9177548284rroyo@lsi.upc.es>

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@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@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@lsi.upc.edu
-----------------------------------------------------





From rroyo at lsi.upc.edu  Tue Sep  6 02:43:10 2005
From: rroyo at lsi.upc.edu (rroyo@lsi.upc.edu)
Date: Tue Sep  6 02:39:56 2005
Subject: [MOBY-dev] Re: [personal] problem with article names?
Message-ID: <9177548284rroyo@lsi.upc.es>

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@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@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@lsi.upc.edu
-----------------------------------------------------





From senger at ebi.ac.uk  Tue Sep  6 03:24:47 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep  6 03:15:06 2005
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <9177548284rroyo@lsi.upc.es>
Message-ID: <Pine.OSF.4.21.0509060822110.1434283-100000@mozart.ebi.ac.uk>

> 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?
>
   I said that the option 3 applies only for services with single input
and single output. In your example, the article names are mandatory, and
workflow engine *has* to add them if the services should be connected.
   But because the case with one-one services is the most often, I
considered worth to allow to skip article names.

   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Tue Sep  6 03:24:47 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep  6 03:15:10 2005
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <9177548284rroyo@lsi.upc.es>
Message-ID: <Pine.OSF.4.21.0509060822110.1434283-100000@mozart.ebi.ac.uk>

> 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?
>
   I said that the option 3 applies only for services with single input
and single output. In your example, the article names are mandatory, and
workflow engine *has* to add them if the services should be connected.
   But because the case with one-one services is the most often, I
considered worth to allow to skip article names.

   Martin

-- 
Martin Senger
   email: martin.senger@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)

From Pieter.Neerincx at wur.nl  Tue Sep  6 12:30:46 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue Sep  6 12:26:28 2005
Subject: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <4315524C.6040307@toulouse.inra.fr>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
Message-ID: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>

Hi,

I have some services that query databases. The result can be nothing,  
a single object, or it can be several thousand objects.... I was also  
running into trouble with big XML documents. I'm using the Perl API,  
which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the  
job done for small xml structures, but for big ones it's a mess.  
Firstly, SOAP::Lite loads the entire message in memory as one big  
piece (hence no chunks or streams etc.). Secondly, if you use  
Data::Dumper to have a look at the perl data structures that are  
built, you will see that the same info is copied two, three or more  
times. There's quite a bit of redundancy in there. As a result the  
expansion factor for parsing xml by SOAP::lite is between 10 and 13  
(according to people on the SOAP::Lite mailing list). That means a 10  
MB xml document will become 100-130 MB in memory. Several clients  
accessing several of these services at the same time will simply  
bring our servers on their knees :(. If there are people on the  
mailinglist with experience in handling laaaaaarge inputs and/or  
outputs I'd really appreciate it if you drop a few lines...

So far I have looked at working with attachments. Not really an  
option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy  
combo. xsltproc sounds good. I currently changed my services to send  
only a pointer (URL) as result which the client has to fetch. For a  
quick and dirty workaround it works beautifully, but from a design  
point of view it bad bad bad :( ...

Cheers,

Pi


On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:

> The MOBY message that I wanted to parse was a 12 Megabyte one.
> The web-service concerned is:
>
> name: ImgaGetTigrXMLEntriesFromKeyword
> uri: bioinfo.genopole-toulouse.prd.fr
> input: String
> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of / 
> IMGA_Accession, as IMGA_Accession
>
> I think this is a little bit extreme, but it works fine now.
>
> Sebastien
>
> Chunyan Wang wrote:
>
>
>> Hi,
>> I changed TimeOut from default to 50000 in the Apache config to  
>> fix timeout problem.
>> How big was your XML file when you had problem?
>> Cheers,
>>
>> Joyce
>>
>> Sebastien Carrere wrote:
>>
>>
>>> Hi all,
>>>
>>> I got the same problem when I wanted to parse huge XML files.
>>> That's why I have written a clone of CommonSub.pm using  
>>> "xsltproc" to parse MOBY message.
>>> Then the parsing time problem was removed.
>>>
>>> However, how do you fixed timeout problem ?
>>>
>>> Sebastien
>>>
>>> Chunyan Wang wrote:
>>>
>>>
>>>>
>>>>
>>>> Martin Senger wrote:
>>>>
>>>>
>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   What language are you using, what XML library in that language?
>>>>>
>>>>>
>>>> I am using Perl and XML::DOM. I am using  
>>>> "genericServiceInputParser($data)" to parse the input sequence  
>>>> in my service.
>>>> By the way, I want to let you know I fixed timeout problem.  
>>>> Thanks for your suggestion.
>>>>
>>>> Joyce
>>>>
>>>>
>>>>>   Martin
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev@biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>
> -- 
> __________________________________________________________
>
> Sebastien CARRERE                        LIPM (INRA-CNRS)
>                      B.P.52627 -- 31326 CASTANET TOLOSAN
> tel:(33) 5-61-28-53-29
> fax:(33) 5-61-28-50-61
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From markw at illuminae.com  Tue Sep  6 14:05:19 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Tue Sep  6 13:54:20 2005
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca> <4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
Message-ID: <1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>

This is indeed still an issue, and you are right about the pain of using
SOAP::Lite + MIME::Tools in Perl (though I know that is soon going to be
better, since we are now using an apparently stable combination of
these, plus SOAP attachemnts, for our own LSID resolver!  However these
are not available on CPAN yet AFAIK).

I recall that Lincoln S. wrote to Paul K. several years ago asking if it
would ever be possible to swap-out the DOM parser in SOAP::Lite for a
SAX parser in order to overcome this limitation (and also with an eye to
streaming responses...), but I don't think this even made it on to the
SOAP::Lite radar so I doubt that the solution is going to come from that
community anytime soon.

So... I can't advise anything, but perhaps others in the MOBY community
can!

M


On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
> Hi,
> 
> I have some services that query databases. The result can be nothing,  
> a single object, or it can be several thousand objects.... I was also  
> running into trouble with big XML documents. I'm using the Perl API,  
> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the  
> job done for small xml structures, but for big ones it's a mess.  
> Firstly, SOAP::Lite loads the entire message in memory as one big  
> piece (hence no chunks or streams etc.). Secondly, if you use  
> Data::Dumper to have a look at the perl data structures that are  
> built, you will see that the same info is copied two, three or more  
> times. There's quite a bit of redundancy in there. As a result the  
> expansion factor for parsing xml by SOAP::lite is between 10 and 13  
> (according to people on the SOAP::Lite mailing list). That means a 10  
> MB xml document will become 100-130 MB in memory. Several clients  
> accessing several of these services at the same time will simply  
> bring our servers on their knees :(. If there are people on the  
> mailinglist with experience in handling laaaaaarge inputs and/or  
> outputs I'd really appreciate it if you drop a few lines...
> 
> So far I have looked at working with attachments. Not really an  
> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy  
> combo. xsltproc sounds good. I currently changed my services to send  
> only a pointer (URL) as result which the client has to fetch. For a  
> quick and dirty workaround it works beautifully, but from a design  
> point of view it bad bad bad :( ...
> 
> Cheers,
> 
> Pi
> 
> 
> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
> 
> > The MOBY message that I wanted to parse was a 12 Megabyte one.
> > The web-service concerned is:
> >
> > name: ImgaGetTigrXMLEntriesFromKeyword
> > uri: bioinfo.genopole-toulouse.prd.fr
> > input: String
> > Output(s): /Collection of /text-xml, as TIGRXML and /Collection of / 
> > IMGA_Accession, as IMGA_Accession
> >
> > I think this is a little bit extreme, but it works fine now.
> >
> > Sebastien
> >
> > Chunyan Wang wrote:
> >
> >
> >> Hi,
> >> I changed TimeOut from default to 50000 in the Apache config to  
> >> fix timeout problem.
> >> How big was your XML file when you had problem?
> >> Cheers,
> >>
> >> Joyce
> >>
> >> Sebastien Carrere wrote:
> >>
> >>
> >>> Hi all,
> >>>
> >>> I got the same problem when I wanted to parse huge XML files.
> >>> That's why I have written a clone of CommonSub.pm using  
> >>> "xsltproc" to parse MOBY message.
> >>> Then the parsing time problem was removed.
> >>>
> >>> However, how do you fixed timeout problem ?
> >>>
> >>> Sebastien
> >>>
> >>> Chunyan Wang wrote:
> >>>
> >>>
> >>>>
> >>>>
> >>>> Martin Senger wrote:
> >>>>
> >>>>
> >>>>>> Could anybody explain this "problem" to me? Thanks.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>   What language are you using, what XML library in that language?
> >>>>>
> >>>>>
> >>>> I am using Perl and XML::DOM. I am using  
> >>>> "genericServiceInputParser($data)" to parse the input sequence  
> >>>> in my service.
> >>>> By the way, I want to let you know I fixed timeout problem.  
> >>>> Thanks for your suggestion.
> >>>>
> >>>> Joyce
> >>>>
> >>>>
> >>>>>   Martin
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev@biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev@biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >>
> >>
> >
> > -- 
> > __________________________________________________________
> >
> > Sebastien CARRERE                        LIPM (INRA-CNRS)
> >                      B.P.52627 -- 31326 CASTANET TOLOSAN
> > tel:(33) 5-61-28-53-29
> > fax:(33) 5-61-28-50-61
> >
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
"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

From senger at ebi.ac.uk  Tue Sep  6 19:40:59 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep  6 19:30:06 2005
Subject: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
Message-ID: <Pine.OSF.4.21.0509070038370.1284933-100000@mozart.ebi.ac.uk>

Although I am a Perl programmer I am not a Perl-service provider so my
SOAP::Lite vs. XML parses experiences are limited, but I recall that some
parsing problems (not all) may be overcome by sending data as byte arrays,
not strings (and Biomoby API dictates that both clients and servers
must be ready to accept both such formats). Have you tried that?

Martin

-- 
Martin Senger
   email: martin.senger@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)

From Pieter.Neerincx at wur.nl  Wed Sep  7 07:12:56 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed Sep  7 07:11:52 2005
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
Message-ID: <84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>


On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:

> This is indeed still an issue, and you are right about the pain of  
> using
> SOAP::Lite + MIME::Tools in Perl (though I know that is soon going  
> to be
> better, since we are now using an apparently stable combination of
> these, plus SOAP attachemnts, for our own LSID resolver!  However  
> these
> are not available on CPAN yet AFAIK).

Ok, so there is a combination that really works :). Could you please  
tell me which version of SOAP::Lite and MIME::Tools you are mixing to  
make SOAP with attachments work?


>
> I recall that Lincoln S. wrote to Paul K. several years ago asking  
> if it
> would ever be possible to swap-out the DOM parser in SOAP::Lite for a
> SAX parser in order to overcome this limitation (and also with an  
> eye to
> streaming responses...), but I don't think this even made it on to the
> SOAP::Lite radar so I doubt that the solution is going to come from  
> that
> community anytime soon.

I doubt that as well. If I find some solution to streaming the SOAP  
XML I'll post it to the list...

Thanks,

Pieter

>
> So... I can't advise anything, but perhaps others in the MOBY  
> community
> can!
>
> M
>
>
> On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
>
>> Hi,
>>
>> I have some services that query databases. The result can be nothing,
>> a single object, or it can be several thousand objects.... I was also
>> running into trouble with big XML documents. I'm using the Perl API,
>> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
>> job done for small xml structures, but for big ones it's a mess.
>> Firstly, SOAP::Lite loads the entire message in memory as one big
>> piece (hence no chunks or streams etc.). Secondly, if you use
>> Data::Dumper to have a look at the perl data structures that are
>> built, you will see that the same info is copied two, three or more
>> times. There's quite a bit of redundancy in there. As a result the
>> expansion factor for parsing xml by SOAP::lite is between 10 and 13
>> (according to people on the SOAP::Lite mailing list). That means a 10
>> MB xml document will become 100-130 MB in memory. Several clients
>> accessing several of these services at the same time will simply
>> bring our servers on their knees :(. If there are people on the
>> mailinglist with experience in handling laaaaaarge inputs and/or
>> outputs I'd really appreciate it if you drop a few lines...
>>
>> So far I have looked at working with attachments. Not really an
>> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
>> combo. xsltproc sounds good. I currently changed my services to send
>> only a pointer (URL) as result which the client has to fetch. For a
>> quick and dirty workaround it works beautifully, but from a design
>> point of view it bad bad bad :( ...
>>
>> Cheers,
>>
>> Pi
>>
>>
>> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
>>
>>
>>> The MOBY message that I wanted to parse was a 12 Megabyte one.
>>> The web-service concerned is:
>>>
>>> name: ImgaGetTigrXMLEntriesFromKeyword
>>> uri: bioinfo.genopole-toulouse.prd.fr
>>> input: String
>>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /
>>> IMGA_Accession, as IMGA_Accession
>>>
>>> I think this is a little bit extreme, but it works fine now.
>>>
>>> Sebastien
>>>
>>> Chunyan Wang wrote:
>>>
>>>
>>>
>>>> Hi,
>>>> I changed TimeOut from default to 50000 in the Apache config to
>>>> fix timeout problem.
>>>> How big was your XML file when you had problem?
>>>> Cheers,
>>>>
>>>> Joyce
>>>>
>>>> Sebastien Carrere wrote:
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I got the same problem when I wanted to parse huge XML files.
>>>>> That's why I have written a clone of CommonSub.pm using
>>>>> "xsltproc" to parse MOBY message.
>>>>> Then the parsing time problem was removed.
>>>>>
>>>>> However, how do you fixed timeout problem ?
>>>>>
>>>>> Sebastien
>>>>>
>>>>> Chunyan Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Martin Senger wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   What language are you using, what XML library in that  
>>>>>>> language?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I am using Perl and XML::DOM. I am using
>>>>>> "genericServiceInputParser($data)" to parse the input sequence
>>>>>> in my service.
>>>>>> By the way, I want to let you know I fixed timeout problem.
>>>>>> Thanks for your suggestion.
>>>>>>
>>>>>> Joyce
>>>>>>
>>>>>>
>>>>>>
>>>>>>>   Martin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev@biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev@biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> __________________________________________________________
>>>
>>> Sebastien CARRERE                        LIPM (INRA-CNRS)
>>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
>>> tel:(33) 5-61-28-53-29
>>> fax:(33) 5-61-28-50-61
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev@biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx@wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> -- 
> "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
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From markw at illuminae.com  Wed Sep  7 12:39:59 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep  7 12:29:32 2005
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca> <4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
	<84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
Message-ID: <1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>

SOAP::Lite
$Id: Lite.pm,v 1.11 2003/08/11 05:54:51 paulclinger Exp $

MIME::Tools
$VERSION = "5.417";


M


On Wed, 2005-09-07 at 13:12 +0200, Pieter Neerincx wrote:
> On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:
> 
> > This is indeed still an issue, and you are right about the pain of  
> > using
> > SOAP::Lite + MIME::Tools in Perl (though I know that is soon going  
> > to be
> > better, since we are now using an apparently stable combination of
> > these, plus SOAP attachemnts, for our own LSID resolver!  However  
> > these
> > are not available on CPAN yet AFAIK).
> 
> Ok, so there is a combination that really works :). Could you please  
> tell me which version of SOAP::Lite and MIME::Tools you are mixing to  
> make SOAP with attachments work?
> 
> 
> >
> > I recall that Lincoln S. wrote to Paul K. several years ago asking  
> > if it
> > would ever be possible to swap-out the DOM parser in SOAP::Lite for a
> > SAX parser in order to overcome this limitation (and also with an  
> > eye to
> > streaming responses...), but I don't think this even made it on to the
> > SOAP::Lite radar so I doubt that the solution is going to come from  
> > that
> > community anytime soon.
> 
> I doubt that as well. If I find some solution to streaming the SOAP  
> XML I'll post it to the list...
> 
> Thanks,
> 
> Pieter
> 
> >
> > So... I can't advise anything, but perhaps others in the MOBY  
> > community
> > can!
> >
> > M
> >
> >
> > On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
> >
> >> Hi,
> >>
> >> I have some services that query databases. The result can be nothing,
> >> a single object, or it can be several thousand objects.... I was also
> >> running into trouble with big XML documents. I'm using the Perl API,
> >> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
> >> job done for small xml structures, but for big ones it's a mess.
> >> Firstly, SOAP::Lite loads the entire message in memory as one big
> >> piece (hence no chunks or streams etc.). Secondly, if you use
> >> Data::Dumper to have a look at the perl data structures that are
> >> built, you will see that the same info is copied two, three or more
> >> times. There's quite a bit of redundancy in there. As a result the
> >> expansion factor for parsing xml by SOAP::lite is between 10 and 13
> >> (according to people on the SOAP::Lite mailing list). That means a 10
> >> MB xml document will become 100-130 MB in memory. Several clients
> >> accessing several of these services at the same time will simply
> >> bring our servers on their knees :(. If there are people on the
> >> mailinglist with experience in handling laaaaaarge inputs and/or
> >> outputs I'd really appreciate it if you drop a few lines...
> >>
> >> So far I have looked at working with attachments. Not really an
> >> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
> >> combo. xsltproc sounds good. I currently changed my services to send
> >> only a pointer (URL) as result which the client has to fetch. For a
> >> quick and dirty workaround it works beautifully, but from a design
> >> point of view it bad bad bad :( ...
> >>
> >> Cheers,
> >>
> >> Pi
> >>
> >>
> >> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
> >>
> >>
> >>> The MOBY message that I wanted to parse was a 12 Megabyte one.
> >>> The web-service concerned is:
> >>>
> >>> name: ImgaGetTigrXMLEntriesFromKeyword
> >>> uri: bioinfo.genopole-toulouse.prd.fr
> >>> input: String
> >>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /
> >>> IMGA_Accession, as IMGA_Accession
> >>>
> >>> I think this is a little bit extreme, but it works fine now.
> >>>
> >>> Sebastien
> >>>
> >>> Chunyan Wang wrote:
> >>>
> >>>
> >>>
> >>>> Hi,
> >>>> I changed TimeOut from default to 50000 in the Apache config to
> >>>> fix timeout problem.
> >>>> How big was your XML file when you had problem?
> >>>> Cheers,
> >>>>
> >>>> Joyce
> >>>>
> >>>> Sebastien Carrere wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I got the same problem when I wanted to parse huge XML files.
> >>>>> That's why I have written a clone of CommonSub.pm using
> >>>>> "xsltproc" to parse MOBY message.
> >>>>> Then the parsing time problem was removed.
> >>>>>
> >>>>> However, how do you fixed timeout problem ?
> >>>>>
> >>>>> Sebastien
> >>>>>
> >>>>> Chunyan Wang wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Martin Senger wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> Could anybody explain this "problem" to me? Thanks.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>   What language are you using, what XML library in that  
> >>>>>>> language?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> I am using Perl and XML::DOM. I am using
> >>>>>> "genericServiceInputParser($data)" to parse the input sequence
> >>>>>> in my service.
> >>>>>> By the way, I want to let you know I fixed timeout problem.
> >>>>>> Thanks for your suggestion.
> >>>>>>
> >>>>>> Joyce
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>   Martin
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MOBY-dev mailing list
> >>>>>> MOBY-dev@biomoby.org
> >>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev@biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> -- 
> >>> __________________________________________________________
> >>>
> >>> Sebastien CARRERE                        LIPM (INRA-CNRS)
> >>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
> >>> tel:(33) 5-61-28-53-29
> >>> fax:(33) 5-61-28-50-61
> >>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev@biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx@wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev@biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> > -- 
> > "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
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
"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

From carrere at toulouse.inra.fr  Thu Sep  8 10:49:16 2005
From: carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Thu Sep  8 10:50:12 2005
Subject: [moby] Re: [MOBY-dev] Question on parser
In-Reply-To: <1125414060.19194.26.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>	<431365E1.7080800@cpsc.ucalgary.ca>
	<4313FE70.80308@toulouse.inra.fr>
	<1125414060.19194.26.camel@bioinfo.icapture.ubc.ca>
Message-ID: <43204F6C.1040409@toulouse.inra.fr>

I added the Perl Module (i) we develloped in Toulouse and the mandatory 
XSLT style-sheet (ii) in the CVS repository.

i.  moby-live/Perl/MOBY/MOBYXSLT.pm
ii. moby-live/Perl/MOBY/xsl/parseMobyMessage.xsl

If you want more information (services examples using this module), do 
not hesitate.

Sebastien




Mark Wilkinson wrote:

>On Tue, 2005-08-30 at 08:36 +0200, Sebastien Carrere wrote:
>
>  
>
>>That's why I have written a clone of CommonSub.pm using "xsltproc" to 
>>parse MOBY message.
>>    
>>
>
>Would you be willing to add this to the CVS?
>
>
>  
>
>>However, how do you fixed timeout problem ?
>>    
>>
>
>In the 1.0 release we should have a spec for asynchronous services, so
>this problem will hopefully not be as severe...
>
>M
>
>
>  
>

-- 
__________________________________________________________

Sebastien CARRERE                        LIPM (INRA-CNRS)
                      B.P.52627 -- 31326 CASTANET TOLOSAN
tel:(33) 5-61-28-53-29
fax:(33) 5-61-28-50-61
				

From Pieter.Neerincx at wur.nl  Mon Sep 12 10:56:13 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon Sep 12 10:45:24 2005
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
	<84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
	<1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>
Message-ID: <A66B84DF-2937-4334-B42C-6158A9832B11@wur.nl>

On 7-Sep-2005, at 6:39 PM, Mark Wilkinson wrote:

> SOAP::Lite
> $Id: Lite.pm,v 1.11 2003/08/11 05:54:51 paulclinger Exp $
>
> MIME::Tools
> $VERSION = "5.417";

Did you apply any custom patches? Or are those simply the defaults?

Pi

>
> M
>
>
> On Wed, 2005-09-07 at 13:12 +0200, Pieter Neerincx wrote:
>
>> On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:
>>
>>
>>> This is indeed still an issue, and you are right about the pain of
>>> using
>>> SOAP::Lite + MIME::Tools in Perl (though I know that is soon going
>>> to be
>>> better, since we are now using an apparently stable combination of
>>> these, plus SOAP attachemnts, for our own LSID resolver!  However
>>> these
>>> are not available on CPAN yet AFAIK).
>>>
>>
>> Ok, so there is a combination that really works :). Could you please
>> tell me which version of SOAP::Lite and MIME::Tools you are mixing to
>> make SOAP with attachments work?
>>
>>
>>
>>>
>>> I recall that Lincoln S. wrote to Paul K. several years ago asking
>>> if it
>>> would ever be possible to swap-out the DOM parser in SOAP::Lite  
>>> for a
>>> SAX parser in order to overcome this limitation (and also with an
>>> eye to
>>> streaming responses...), but I don't think this even made it on  
>>> to the
>>> SOAP::Lite radar so I doubt that the solution is going to come from
>>> that
>>> community anytime soon.
>>>
>>
>> I doubt that as well. If I find some solution to streaming the SOAP
>> XML I'll post it to the list...
>>
>> Thanks,
>>
>> Pieter
>>
>>
>>>
>>> So... I can't advise anything, but perhaps others in the MOBY
>>> community
>>> can!
>>>
>>> M
>>>
>>>
>>> On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I have some services that query databases. The result can be  
>>>> nothing,
>>>> a single object, or it can be several thousand objects.... I was  
>>>> also
>>>> running into trouble with big XML documents. I'm using the Perl  
>>>> API,
>>>> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
>>>> job done for small xml structures, but for big ones it's a mess.
>>>> Firstly, SOAP::Lite loads the entire message in memory as one big
>>>> piece (hence no chunks or streams etc.). Secondly, if you use
>>>> Data::Dumper to have a look at the perl data structures that are
>>>> built, you will see that the same info is copied two, three or more
>>>> times. There's quite a bit of redundancy in there. As a result the
>>>> expansion factor for parsing xml by SOAP::lite is between 10 and 13
>>>> (according to people on the SOAP::Lite mailing list). That means  
>>>> a 10
>>>> MB xml document will become 100-130 MB in memory. Several clients
>>>> accessing several of these services at the same time will simply
>>>> bring our servers on their knees :(. If there are people on the
>>>> mailinglist with experience in handling laaaaaarge inputs and/or
>>>> outputs I'd really appreciate it if you drop a few lines...
>>>>
>>>> So far I have looked at working with attachments. Not really an
>>>> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
>>>> combo. xsltproc sounds good. I currently changed my services to  
>>>> send
>>>> only a pointer (URL) as result which the client has to fetch. For a
>>>> quick and dirty workaround it works beautifully, but from a design
>>>> point of view it bad bad bad :( ...
>>>>
>>>> Cheers,
>>>>
>>>> Pi
>>>>
>>>>
>>>> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
>>>>
>>>>
>>>>
>>>>> The MOBY message that I wanted to parse was a 12 Megabyte one.
>>>>> The web-service concerned is:
>>>>>
>>>>> name: ImgaGetTigrXMLEntriesFromKeyword
>>>>> uri: bioinfo.genopole-toulouse.prd.fr
>>>>> input: String
>>>>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection  
>>>>> of /
>>>>> IMGA_Accession, as IMGA_Accession
>>>>>
>>>>> I think this is a little bit extreme, but it works fine now.
>>>>>
>>>>> Sebastien
>>>>>
>>>>> Chunyan Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>> I changed TimeOut from default to 50000 in the Apache config to
>>>>>> fix timeout problem.
>>>>>> How big was your XML file when you had problem?
>>>>>> Cheers,
>>>>>>
>>>>>> Joyce
>>>>>>
>>>>>> Sebastien Carrere wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I got the same problem when I wanted to parse huge XML files.
>>>>>>> That's why I have written a clone of CommonSub.pm using
>>>>>>> "xsltproc" to parse MOBY message.
>>>>>>> Then the parsing time problem was removed.
>>>>>>>
>>>>>>> However, how do you fixed timeout problem ?
>>>>>>>
>>>>>>> Sebastien
>>>>>>>
>>>>>>> Chunyan Wang wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Martin Senger wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   What language are you using, what XML library in that
>>>>>>>>> language?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I am using Perl and XML::DOM. I am using
>>>>>>>> "genericServiceInputParser($data)" to parse the input sequence
>>>>>>>> in my service.
>>>>>>>> By the way, I want to let you know I fixed timeout problem.
>>>>>>>> Thanks for your suggestion.
>>>>>>>>
>>>>>>>> Joyce
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>   Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MOBY-dev mailing list
>>>>>>>> MOBY-dev@biomoby.org
>>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev@biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> __________________________________________________________
>>>>>
>>>>> Sebastien CARRERE                        LIPM (INRA-CNRS)
>>>>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
>>>>> tel:(33) 5-61-28-53-29
>>>>> fax:(33) 5-61-28-50-61
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev@biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx@wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev@biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>> -- 
>>> "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
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev@biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx@wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> -- 
> "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
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From Pieter.Neerincx at wur.nl  Mon Sep 12 11:05:51 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon Sep 12 10:54:47 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
Message-ID: <B35BC13D-D39B-4A67-B009-C91D31B53BDA@wur.nl>

Hi all,

I'm having some trouble to make BioMOBY work with Taverna. I have a  
local development Moby central. When I register both new services and  
new objects I notice that only my custom services are listed in  
Taverna. The list of moby objects is not in sync with what is  
registered in my central. So where does Taverna get those objects  
from and how do I get my own objects in there? Does anyone have a clue?

Cheers,

Pieter

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Mon Sep 12 11:10:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 12 14:54:32 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <B35BC13D-D39B-4A67-B009-C91D31B53BDA@wur.nl>
Message-ID: <43259a80.30867065.1135.ffff8504@mx.gmail.com>

Hi,

The answer basically is that you also need to set up some
servlets (RESOURCES script, types, etc), if you have a
custom registry.

So Taverna is basically reading in your services, and cannot
find the objects, so it probably defaults to the Mobycentral
registry.

Eddie 

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 12, 2005 8:06 AM
> To: Core developer announcements
> Subject: [MOBY-dev] Moby objects in Taverna. Where do they
> come from?
> 
> Hi all,
> 
> I'm having some trouble to make BioMOBY work with Taverna.
> I have a
> local development Moby central. When I register both new
> services and
> new objects I notice that only my custom services are
> listed in
> Taverna. The list of moby objects is not in sync with what
> is
> registered in my central. So where does Taverna get those
> objects
> from and how do I get my own objects in there? Does anyone
> have a clue?
> 
> Cheers,
> 
> Pieter
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From senger at ebi.ac.uk  Mon Sep 12 21:30:38 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 12 21:19:57 2005
Subject: [MOBY-dev] jMOBY DOES NOT COMPILE (again!)
Message-ID: <Pine.OSF.4.21.0509130225110.887285-100000@ice.ebi.ac.uk>

Eddie,
   I am sorry for the upper-case letters but it is really important to
realize that if someone (I suspect you in this case) commits changes
without checking that the whole jMoby is compilable that it may have a bad
impact of the other users. At the moment, I am in the middle of the
Biomoby course (in Japan) and jMoby does not compile. Plenty of errors
from the RDF agent 'test' package.
   I apologize if the problem was caused by someone else - and I am
calling Eddie - but in the past it was usually Eddie :-) (Unless it was
me, of course, that would be a real embarassment.)

   So please fix the problem asap. I will have to remove the offending
classes from the repository if it continues to break the compilation.

   Thanks and with regards,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Mon Sep 12 23:48:07 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 12 23:37:01 2005
Subject: [MOBY-dev] RE: jMOBY DOES NOT COMPILE (again!)
In-Reply-To: <432649ea.64d22026.0f99.5d5f@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509130446380.887285-100000@ice.ebi.ac.uk>

> When I made my changes, I did a ./build.bat clean compile
> and everything was fine.
>
   So perhaps you have some other, not-included, librraies on your
classpath.

> What messages are you getting?
>

    [javac] Found 55 semantic errors compiling
"/net/nfs7/vol4/industry/senger/moby-live/Java/src/main/org/biomoby/registry/rdfagent/test/RDFAgentTestSuite.java":

    [javac]    328.     public void performTest1() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type
"org.biomoby.registry.rdfagent.test.TestException" was not found.


    [javac]    357.     public void performTest2() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    375.     public void performTest3() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    393.     public void performTest4() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    411.     public void performTest5() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.

   ... etc.

   Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Mon Sep 12 23:39:17 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue Sep 13 00:26:54 2005
Subject: [MOBY-dev] RE: jMOBY DOES NOT COMPILE (again!)
In-Reply-To: <Pine.OSF.4.21.0509130225110.887285-100000@ice.ebi.ac.uk>
Message-ID: <432649ea.64d22026.0f99.5d5f@mx.gmail.com>

When I made my changes, I did a ./build.bat clean compile
and everything was fine. What messages are you getting?


Eddie

> -----Original Message-----
> From: Martin Senger [mailto:senger@ebi.ac.uk]
> Sent: Monday, September 12, 2005 6:31 PM
> To: Edward Kawas
> Cc: Moby Developers
> Subject: jMOBY DOES NOT COMPILE (again!)
> 
> Eddie,
>    I am sorry for the upper-case letters but it is really
> important to
> realize that if someone (I suspect you in this case)
> commits changes
> without checking that the whole jMoby is compilable that
> it may have a bad
> impact of the other users. At the moment, I am in the
> middle of the
> Biomoby course (in Japan) and jMoby does not compile.
> Plenty of errors
> from the RDF agent 'test' package.
>    I apologize if the problem was caused by someone else -
> and I am
> calling Eddie - but in the past it was usually Eddie :-)
> (Unless it was
> me, of course, that would be a real embarassment.)
> 
>    So please fix the problem asap. I will have to remove
> the offending
> classes from the repository if it continues to break the
> compilation.
> 
>    Thanks and with regards,
>    Martin
> 
> --
> Martin Senger
>    email: martin.senger@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)

From senger at ebi.ac.uk  Tue Sep 13 03:56:14 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep 13 03:45:03 2005
Subject: [MOBY-dev] jMoby small update & a windows question
Message-ID: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>

I have updated library alltools2.jar - so please when you use jMoby next
time start with: ./build.sh (or ./build.bat).

I wonder if people familiar with windows can answer my question about
windows scripts:

The script is build/run/run-cmdline-client.bat (but the same applies to
all other .bat scripts there). It does not work if your PROJECT_HOME is a
directory with whitespaces, like
   C:\Document and Settings\martin\Desktop\jMoby

I have already added there a lot of double quotes - so it "almost" works
now, but not yet. The problem is the line:

for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i

where I do not know how to put quotes arround the first %PROJECT_HOME%. If
I quote is, the '*.jar' part does not seem to expand as expected.

I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
then I can remove the %PROJECT_HOME% from all other places. But I still
wonder how I should write it without this workaround. Does anybody know
how to do it?

Thanks,
Martin

-- 
Martin Senger
   email: martin.senger@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)

From Pieter.Neerincx at wur.nl  Tue Sep 13 04:34:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue Sep 13 04:27:14 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <43259a80.30867065.1135.ffff8504@mx.gmail.com>
References: <43259a80.30867065.1135.ffff8504@mx.gmail.com>
Message-ID: <A7015A51-2FAA-417D-95C7-E2AF2630F540@wur.nl>

Hi Eddie,

On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:

> Hi,
>
> The answer basically is that you also need to set up some
> servlets (RESOURCES script, types, etc), if you have a
> custom registry.

Thanks for the quick feedback. I was already afraid it would be  
something like that :(.

> So Taverna is basically reading in your services, and cannot
> find the objects, so it probably defaults to the Mobycentral
> registry.

Would it help if I register my objects at THE central mobycentral  
instead of in my local central? Or are the objects hardcoded in some  
jar file (like lib/jmoby.jar perhaps)?

Pieter

>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 12, 2005 8:06 AM
>> To: Core developer announcements
>> Subject: [MOBY-dev] Moby objects in Taverna. Where do they
>> come from?
>>
>> Hi all,
>>
>> I'm having some trouble to make BioMOBY work with Taverna.
>> I have a
>> local development Moby central. When I register both new
>> services and
>> new objects I notice that only my custom services are
>> listed in
>> Taverna. The list of moby objects is not in sync with what
>> is
>> registered in my central. So where does Taverna get those
>> objects
>> from and how do I get my own objects in there? Does anyone
>> have a clue?
>>
>> Cheers,
>>
>> Pieter
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx@wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From ots at ac.uma.es  Tue Sep 13 04:31:01 2005
From: ots at ac.uma.es (Oswaldo Trelles)
Date: Tue Sep 13 04:27:24 2005
Subject: [MOBY-dev] jMoby small update & a windows question
References: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>
Message-ID: <007201c5b83d$797e8de0$346dd696@ac.uma.es>

perhaps it is due to the old MS-DOS format under which the BAT files are
executed
you could try with    C:\Docume~1\martin\Desktop\jMoby

oswaldo

----- Original Message ----- 
From: "Martin Senger" <senger@ebi.ac.uk>
To: "Moby Developers" <moby-dev@biomoby.org>
Sent: Tuesday, September 13, 2005 9:56 AM
Subject: [MOBY-dev] jMoby small update & a windows question


> I have updated library alltools2.jar - so please when you use jMoby next
> time start with: ./build.sh (or ./build.bat).
>
> I wonder if people familiar with windows can answer my question about
> windows scripts:
>
> The script is build/run/run-cmdline-client.bat (but the same applies to
> all other .bat scripts there). It does not work if your PROJECT_HOME is a
> directory with whitespaces, like
>    C:\Document and Settings\martin\Desktop\jMoby
>
> I have already added there a lot of double quotes - so it "almost" works
> now, but not yet. The problem is the line:
>
> for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i
>
> where I do not know how to put quotes arround the first %PROJECT_HOME%. If
> I quote is, the '*.jar' part does not seem to expand as expected.
>
> I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
> then I can remove the %PROJECT_HOME% from all other places. But I still
> wonder how I should write it without this workaround. Does anybody know
> how to do it?
>
> Thanks,
> Martin
>
> -- 
> Martin Senger
>    email: martin.senger@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@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From ots at ac.uma.es  Tue Sep 13 04:31:01 2005
From: ots at ac.uma.es (Oswaldo Trelles)
Date: Tue Sep 13 04:27:26 2005
Subject: [MOBY-dev] jMoby small update & a windows question
References: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>
Message-ID: <007201c5b83d$797e8de0$346dd696@ac.uma.es>

perhaps it is due to the old MS-DOS format under which the BAT files are
executed
you could try with    C:\Docume~1\martin\Desktop\jMoby

oswaldo

----- Original Message ----- 
From: "Martin Senger" <senger@ebi.ac.uk>
To: "Moby Developers" <moby-dev@biomoby.org>
Sent: Tuesday, September 13, 2005 9:56 AM
Subject: [MOBY-dev] jMoby small update & a windows question


> I have updated library alltools2.jar - so please when you use jMoby next
> time start with: ./build.sh (or ./build.bat).
>
> I wonder if people familiar with windows can answer my question about
> windows scripts:
>
> The script is build/run/run-cmdline-client.bat (but the same applies to
> all other .bat scripts there). It does not work if your PROJECT_HOME is a
> directory with whitespaces, like
>    C:\Document and Settings\martin\Desktop\jMoby
>
> I have already added there a lot of double quotes - so it "almost" works
> now, but not yet. The problem is the line:
>
> for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i
>
> where I do not know how to put quotes arround the first %PROJECT_HOME%. If
> I quote is, the '*.jar' part does not seem to expand as expected.
>
> I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
> then I can remove the %PROJECT_HOME% from all other places. But I still
> wonder how I should write it without this workaround. Does anybody know
> how to do it?
>
> Thanks,
> Martin
>
> -- 
> Martin Senger
>    email: martin.senger@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@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From senger at ebi.ac.uk  Tue Sep 13 04:48:16 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep 13 04:38:28 2005
Subject: [MOBY-dev] jMoby small update & a windows question
In-Reply-To: <007201c5b83d$797e8de0$346dd696@ac.uma.es>
Message-ID: <Pine.OSF.4.21.0509130944050.960900-100000@ice.ebi.ac.uk>

Thanks for the help.

> perhaps it is due to the old MS-DOS format under which the BAT files
> are executed
>
   No, they are executed under cmd running in windows XP. But perhaps I
even do not know how to execute them better. An advice is welcome.

> you could try with    C:\Docume~1\martin\Desktop\jMoby
>
   Actually, this seems to me to be the old 8.3 format. And this works
fine because it does not have spaces. But I do not know how to change
programatically the "C:\Document and Settings\martin\Desktop\jMoby" to
"C:\Docume~1\martin\Desktop\jMoby". This is done by Ant, when replacing a
token @PROJECT_HOME@ by a dir name (using a filterset). I cannot do it
manually.

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Tue Sep 13 04:48:16 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep 13 04:38:33 2005
Subject: [MOBY-dev] jMoby small update & a windows question
In-Reply-To: <007201c5b83d$797e8de0$346dd696@ac.uma.es>
Message-ID: <Pine.OSF.4.21.0509130944050.960900-100000@ice.ebi.ac.uk>

Thanks for the help.

> perhaps it is due to the old MS-DOS format under which the BAT files
> are executed
>
   No, they are executed under cmd running in windows XP. But perhaps I
even do not know how to execute them better. An advice is welcome.

> you could try with    C:\Docume~1\martin\Desktop\jMoby
>
   Actually, this seems to me to be the old 8.3 format. And this works
fine because it does not have spaces. But I do not know how to change
programatically the "C:\Document and Settings\martin\Desktop\jMoby" to
"C:\Docume~1\martin\Desktop\jMoby". This is done by Ant, when replacing a
token @PROJECT_HOME@ by a dir name (using a filterset). I cannot do it
manually.

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Tue Sep 13 09:08:20 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue Sep 13 08:57:22 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <A7015A51-2FAA-417D-95C7-E2AF2630F540@wur.nl>
Message-ID: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>

Hi,

Objects aren't hard coded. They just have to be registered
in Mobycentral.

I am not sure if you are up for it, but you could always
install the servlets (I could help you).

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 1:35 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi Eddie,
> 
> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > The answer basically is that you also need to set up
> some
> > servlets (RESOURCES script, types, etc), if you have a
> > custom registry.
> 
> Thanks for the quick feedback. I was already afraid it
> would be
> something like that :(.
> 
> > So Taverna is basically reading in your services, and
> cannot
> > find the objects, so it probably defaults to the
> Mobycentral
> > registry.
> 
> Would it help if I register my objects at THE central
> mobycentral
> instead of in my local central? Or are the objects
> hardcoded in some
> jar file (like lib/jmoby.jar perhaps)?
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces@portal.open-bio.org
> [mailto:moby-
> >> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Monday, September 12, 2005 8:06 AM
> >> To: Core developer announcements
> >> Subject: [MOBY-dev] Moby objects in Taverna. Where do
> they
> >> come from?
> >>
> >> Hi all,
> >>
> >> I'm having some trouble to make BioMOBY work with
> Taverna.
> >> I have a
> >> local development Moby central. When I register both
> new
> >> services and
> >> new objects I notice that only my custom services are
> >> listed in
> >> Taverna. The list of moby objects is not in sync with
> what
> >> is
> >> registered in my central. So where does Taverna get
> those
> >> objects
> >> from and how do I get my own objects in there? Does
> anyone
> >> have a clue?
> >>
> >> Cheers,
> >>
> >> Pieter
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx@wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev@biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From Pieter.Neerincx at wur.nl  Tue Sep 13 10:17:46 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue Sep 13 10:07:45 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>
References: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>
Message-ID: <DB4FF9B0-3BDE-42DA-AB89-8CBDEF8705C5@wur.nl>

Hi Eddie,

On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:

> Hi,
>
> Objects aren't hard coded. They just have to be registered
> in Mobycentral.

Today I fetched the source code for Taverna and 'grep'ed over the  
files. There are several instances where the path to the central  
biomoby central and an RDF file are hardcoded outside the files in  
conf/. Sometime ago I started to work with Taverna and the user  
manual only mentions the path to a biomoby central in the conf/ 
mygrid.properties file. So I appended my local biomoby central to  
this conf file and expected this would allow me to use both services  
and objects registered in my local central. I think that the current  
situation where service info is fetched from a URL in the conf/ 
mygrid.properties file and object info is fetched from a RDF file at  
a different location is very confusing and needlessly complex.  
Especially since I cannot supply an URL to a custom RDF file for my  
objects in the conf/mygrid.properties file. I did see though that I  
can right-click in Taverna to add a scavenger and than I can supply  
both an URL to my local central and an URL to this RDF file for the  
objects.

I also browsed the mailinglist and wiki. Did I understand correctly  
that the current situation is a temporary solution and that  
eventually all info (hence services and objects) will be described  
using RDF? Please correct me if I'm wrong...

> I am not sure if you are up for it, but you could always
> install the servlets

Are those servlets generating this RDF file from the info in a central?
Is this documented somewhere? I couldn't find any reference to  
servlets at http://www.biomoby.org/InstallingMOBYCentral.html ...

> (I could help you).

Your help is much appreciated! Thanks,

Pieter

>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 1:35 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi Eddie,
>>
>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> The answer basically is that you also need to set up
>>>
>> some
>>
>>> servlets (RESOURCES script, types, etc), if you have a
>>> custom registry.
>>>
>>
>> Thanks for the quick feedback. I was already afraid it
>> would be
>> something like that :(.
>>
>>
>>> So Taverna is basically reading in your services, and
>>>
>> cannot
>>
>>> find the objects, so it probably defaults to the
>>>
>> Mobycentral
>>
>>> registry.
>>>
>>
>> Would it help if I register my objects at THE central
>> mobycentral
>> instead of in my local central? Or are the objects
>> hardcoded in some
>> jar file (like lib/jmoby.jar perhaps)?
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces@portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>> To: Core developer announcements
>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
>>>>
>> they
>>
>>>> come from?
>>>>
>>>> Hi all,
>>>>
>>>> I'm having some trouble to make BioMOBY work with
>>>>
>> Taverna.
>>
>>>> I have a
>>>> local development Moby central. When I register both
>>>>
>> new
>>
>>>> services and
>>>> new objects I notice that only my custom services are
>>>> listed in
>>>> Taverna. The list of moby objects is not in sync with
>>>>
>> what
>>
>>>> is
>>>> registered in my central. So where does Taverna get
>>>>
>> those
>>
>>>> objects
>>>> from and how do I get my own objects in there? Does
>>>>
>> anyone
>>
>>>> have a clue?
>>>>
>>>> Cheers,
>>>>
>>>> Pieter
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx@wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev@biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev@biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx@wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Tue Sep 13 10:43:32 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue Sep 13 10:32:42 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <DB4FF9B0-3BDE-42DA-AB89-8CBDEF8705C5@wur.nl>
Message-ID: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>

Hi,

For the Taverna workbench, download it temporarily from
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip
This version contains my changes (the ones that are in the
Taverna CVS).

The Moby api actually now has a method in it called
getResources (or something similar to that) that returns the
locations of these documents for a registry. So in the newly
updated version of the plugin, I have removed the textbox
that asks for this url and replaced it with an api call.
(a description on the Moby plugin can be found at
http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.ht
ml but is being changed to reflect the api calling).

You are correct in saying that we are moving towards having
Services and datatypes described by RDF.

Finally, as for the servlet installation, if you are
interested, I can guide you through this relatively painless
procedure. I would just need to update certain files that
you need to download and you would have to install tomcat.

Eddie



> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 7:18 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi Eddie,
> 
> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > Objects aren't hard coded. They just have to be
> registered
> > in Mobycentral.
> 
> Today I fetched the source code for Taverna and 'grep'ed
> over the
> files. There are several instances where the path to the
> central
> biomoby central and an RDF file are hardcoded outside the
> files in
> conf/. Sometime ago I started to work with Taverna and the
> user
> manual only mentions the path to a biomoby central in the
> conf/
> mygrid.properties file. So I appended my local biomoby
> central to
> this conf file and expected this would allow me to use
> both services
> and objects registered in my local central. I think that
> the current
> situation where service info is fetched from a URL in the
> conf/
> mygrid.properties file and object info is fetched from a
> RDF file at
> a different location is very confusing and needlessly
> complex.
> Especially since I cannot supply an URL to a custom RDF
> file for my
> objects in the conf/mygrid.properties file. I did see
> though that I
> can right-click in Taverna to add a scavenger and than I
> can supply
> both an URL to my local central and an URL to this RDF
> file for the
> objects.
> 
> I also browsed the mailinglist and wiki. Did I understand
> correctly
> that the current situation is a temporary solution and
> that
> eventually all info (hence services and objects) will be
> described
> using RDF? Please correct me if I'm wrong...
> 
> > I am not sure if you are up for it, but you could always
> > install the servlets
> 
> Are those servlets generating this RDF file from the info
> in a central?
> Is this documented somewhere? I couldn't find any
> reference to
> servlets at
> http://www.biomoby.org/InstallingMOBYCentral.html ...
> 
> > (I could help you).
> 
> Your help is much appreciated! Thanks,
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces@portal.open-bio.org
> [mailto:moby-
> >> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Tuesday, September 13, 2005 1:35 AM
> >> To: Core developer announcements
> >> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
> do
> >> they come from?
> >>
> >> Hi Eddie,
> >>
> >> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> The answer basically is that you also need to set up
> >>>
> >> some
> >>
> >>> servlets (RESOURCES script, types, etc), if you have a
> >>> custom registry.
> >>>
> >>
> >> Thanks for the quick feedback. I was already afraid it
> >> would be
> >> something like that :(.
> >>
> >>
> >>> So Taverna is basically reading in your services, and
> >>>
> >> cannot
> >>
> >>> find the objects, so it probably defaults to the
> >>>
> >> Mobycentral
> >>
> >>> registry.
> >>>
> >>
> >> Would it help if I register my objects at THE central
> >> mobycentral
> >> instead of in my local central? Or are the objects
> >> hardcoded in some
> >> jar file (like lib/jmoby.jar perhaps)?
> >>
> >> Pieter
> >>
> >>
> >>>
> >>> Eddie
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: moby-dev-bounces@portal.open-bio.org
> >>>>
> >> [mailto:moby-
> >>
> >>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> >>>> Neerincx
> >>>> Sent: Monday, September 12, 2005 8:06 AM
> >>>> To: Core developer announcements
> >>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
> >>>>
> >> they
> >>
> >>>> come from?
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I'm having some trouble to make BioMOBY work with
> >>>>
> >> Taverna.
> >>
> >>>> I have a
> >>>> local development Moby central. When I register both
> >>>>
> >> new
> >>
> >>>> services and
> >>>> new objects I notice that only my custom services are
> >>>> listed in
> >>>> Taverna. The list of moby objects is not in sync with
> >>>>
> >> what
> >>
> >>>> is
> >>>> registered in my central. So where does Taverna get
> >>>>
> >> those
> >>
> >>>> objects
> >>>> from and how do I get my own objects in there? Does
> >>>>
> >> anyone
> >>
> >>>> have a clue?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Pieter
> >>>>
> >>>> Wageningen University and Research centre (WUR)
> >>>> Laboratory of Bioinformatics
> >>>> Transitorium (building 312) room 1034
> >>>> Dreijenlaan 3
> >>>> 6703 HA Wageningen
> >>>> The Netherlands
> >>>> phone: 0317-483 060
> >>>> fax: 0317-483 584
> >>>> mobile: 06-143 66 783
> >>>> pieter.neerincx@wur.nl
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev@biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev@biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx@wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev@biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From Pieter.Neerincx at wur.nl  Tue Sep 13 11:48:47 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue Sep 13 11:45:37 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>
References: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>
Message-ID: <E56B487A-CAED-4EFE-B0AD-97C3B4F21E6C@wur.nl>

Hi,

On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:

> Hi,
>
> For the Taverna workbench, download it temporarily from
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
> zip

I will...

> This version contains my changes (the ones that are in the
> Taverna CVS).
>
> The Moby api actually now has a method in it called
> getResources (or something similar to that) that returns the
> locations of these documents for a registry.

Ok, that sounds like a much more elegant solution :).

> So in the newly
> updated version of the plugin, I have removed the textbox
> that asks for this url and replaced it with an api call.
> (a description on the Moby plugin can be found at
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.ht
> ml but is being changed to reflect the api calling).
>
> You are correct in saying that we are moving towards having
> Services and datatypes described by RDF.
>
> Finally, as for the servlet installation, if you are
> interested, I can guide you through this relatively painless
> procedure. I would just need to update certain files that
> you need to download and you would have to install tomcat.

Ok, I will start with tomcat tomorrow... and will request further  
advice one I have that one up and running...

Pieter

>
> Eddie
>
>
>
>
>> -----Original Message-----
>> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 7:18 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi Eddie,
>>
>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> Objects aren't hard coded. They just have to be
>>>
>> registered
>>
>>> in Mobycentral.
>>>
>>
>> Today I fetched the source code for Taverna and 'grep'ed
>> over the
>> files. There are several instances where the path to the
>> central
>> biomoby central and an RDF file are hardcoded outside the
>> files in
>> conf/. Sometime ago I started to work with Taverna and the
>> user
>> manual only mentions the path to a biomoby central in the
>> conf/
>> mygrid.properties file. So I appended my local biomoby
>> central to
>> this conf file and expected this would allow me to use
>> both services
>> and objects registered in my local central. I think that
>> the current
>> situation where service info is fetched from a URL in the
>> conf/
>> mygrid.properties file and object info is fetched from a
>> RDF file at
>> a different location is very confusing and needlessly
>> complex.
>> Especially since I cannot supply an URL to a custom RDF
>> file for my
>> objects in the conf/mygrid.properties file. I did see
>> though that I
>> can right-click in Taverna to add a scavenger and than I
>> can supply
>> both an URL to my local central and an URL to this RDF
>> file for the
>> objects.
>>
>> I also browsed the mailinglist and wiki. Did I understand
>> correctly
>> that the current situation is a temporary solution and
>> that
>> eventually all info (hence services and objects) will be
>> described
>> using RDF? Please correct me if I'm wrong...
>>
>>
>>> I am not sure if you are up for it, but you could always
>>> install the servlets
>>>
>>
>> Are those servlets generating this RDF file from the info
>> in a central?
>> Is this documented somewhere? I couldn't find any
>> reference to
>> servlets at
>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>
>>
>>> (I could help you).
>>>
>>
>> Your help is much appreciated! Thanks,
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces@portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>>>
>> do
>>
>>>> they come from?
>>>>
>>>> Hi Eddie,
>>>>
>>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> The answer basically is that you also need to set up
>>>>>
>>>>>
>>>> some
>>>>
>>>>
>>>>> servlets (RESOURCES script, types, etc), if you have a
>>>>> custom registry.
>>>>>
>>>>>
>>>>
>>>> Thanks for the quick feedback. I was already afraid it
>>>> would be
>>>> something like that :(.
>>>>
>>>>
>>>>
>>>>> So Taverna is basically reading in your services, and
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>> find the objects, so it probably defaults to the
>>>>>
>>>>>
>>>> Mobycentral
>>>>
>>>>
>>>>> registry.
>>>>>
>>>>>
>>>>
>>>> Would it help if I register my objects at THE central
>>>> mobycentral
>>>> instead of in my local central? Or are the objects
>>>> hardcoded in some
>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: moby-dev-bounces@portal.open-bio.org
>>>>>>
>>>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>>>>>> Neerincx
>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>> To: Core developer announcements
>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
>>>>>>
>>>>>>
>>>> they
>>>>
>>>>
>>>>>> come from?
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm having some trouble to make BioMOBY work with
>>>>>>
>>>>>>
>>>> Taverna.
>>>>
>>>>
>>>>>> I have a
>>>>>> local development Moby central. When I register both
>>>>>>
>>>>>>
>>>> new
>>>>
>>>>
>>>>>> services and
>>>>>> new objects I notice that only my custom services are
>>>>>> listed in
>>>>>> Taverna. The list of moby objects is not in sync with
>>>>>>
>>>>>>
>>>> what
>>>>
>>>>
>>>>>> is
>>>>>> registered in my central. So where does Taverna get
>>>>>>
>>>>>>
>>>> those
>>>>
>>>>
>>>>>> objects
>>>>>> from and how do I get my own objects in there? Does
>>>>>>
>>>>>>
>>>> anyone
>>>>
>>>>
>>>>>> have a clue?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Pieter
>>>>>>
>>>>>> Wageningen University and Research centre (WUR)
>>>>>> Laboratory of Bioinformatics
>>>>>> Transitorium (building 312) room 1034
>>>>>> Dreijenlaan 3
>>>>>> 6703 HA Wageningen
>>>>>> The Netherlands
>>>>>> phone: 0317-483 060
>>>>>> fax: 0317-483 584
>>>>>> mobile: 06-143 66 783
>>>>>> pieter.neerincx@wur.nl
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev@biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev@biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx@wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev@biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev@biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx@wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Tue Sep 13 11:58:51 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue Sep 13 11:48:12 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <E56B487A-CAED-4EFE-B0AD-97C3B4F21E6C@wur.nl>
Message-ID: <4326f75b.52b7817a.2384.5590@mx.gmail.com>

Great. I will be waiting ;-)

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 8:49 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi,
> 
> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > For the Taverna workbench, download it temporarily from
> > http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
> 1.2.
> > zip
> 
> I will...
> 
> > This version contains my changes (the ones that are in
> the
> > Taverna CVS).
> >
> > The Moby api actually now has a method in it called
> > getResources (or something similar to that) that returns
> the
> > locations of these documents for a registry.
> 
> Ok, that sounds like a much more elegant solution :).
> 
> > So in the newly
> > updated version of the plugin, I have removed the
> textbox
> > that asks for this url and replaced it with an api call.
> > (a description on the Moby plugin can be found at
> >
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
> ht
> > ml but is being changed to reflect the api calling).
> >
> > You are correct in saying that we are moving towards
> having
> > Services and datatypes described by RDF.
> >
> > Finally, as for the servlet installation, if you are
> > interested, I can guide you through this relatively
> painless
> > procedure. I would just need to update certain files
> that
> > you need to download and you would have to install
> tomcat.
> 
> Ok, I will start with tomcat tomorrow... and will request
> further
> advice one I have that one up and running...
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces@portal.open-bio.org
> [mailto:moby-
> >> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Tuesday, September 13, 2005 7:18 AM
> >> To: Core developer announcements
> >> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
> do
> >> they come from?
> >>
> >> Hi Eddie,
> >>
> >> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> Objects aren't hard coded. They just have to be
> >>>
> >> registered
> >>
> >>> in Mobycentral.
> >>>
> >>
> >> Today I fetched the source code for Taverna and
> 'grep'ed
> >> over the
> >> files. There are several instances where the path to
> the
> >> central
> >> biomoby central and an RDF file are hardcoded outside
> the
> >> files in
> >> conf/. Sometime ago I started to work with Taverna and
> the
> >> user
> >> manual only mentions the path to a biomoby central in
> the
> >> conf/
> >> mygrid.properties file. So I appended my local biomoby
> >> central to
> >> this conf file and expected this would allow me to use
> >> both services
> >> and objects registered in my local central. I think
> that
> >> the current
> >> situation where service info is fetched from a URL in
> the
> >> conf/
> >> mygrid.properties file and object info is fetched from
> a
> >> RDF file at
> >> a different location is very confusing and needlessly
> >> complex.
> >> Especially since I cannot supply an URL to a custom RDF
> >> file for my
> >> objects in the conf/mygrid.properties file. I did see
> >> though that I
> >> can right-click in Taverna to add a scavenger and than
> I
> >> can supply
> >> both an URL to my local central and an URL to this RDF
> >> file for the
> >> objects.
> >>
> >> I also browsed the mailinglist and wiki. Did I
> understand
> >> correctly
> >> that the current situation is a temporary solution and
> >> that
> >> eventually all info (hence services and objects) will
> be
> >> described
> >> using RDF? Please correct me if I'm wrong...
> >>
> >>
> >>> I am not sure if you are up for it, but you could
> always
> >>> install the servlets
> >>>
> >>
> >> Are those servlets generating this RDF file from the
> info
> >> in a central?
> >> Is this documented somewhere? I couldn't find any
> >> reference to
> >> servlets at
> >> http://www.biomoby.org/InstallingMOBYCentral.html ...
> >>
> >>
> >>> (I could help you).
> >>>
> >>
> >> Your help is much appreciated! Thanks,
> >>
> >> Pieter
> >>
> >>
> >>>
> >>> Eddie
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: moby-dev-bounces@portal.open-bio.org
> >>>>
> >> [mailto:moby-
> >>
> >>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> >>>> Neerincx
> >>>> Sent: Tuesday, September 13, 2005 1:35 AM
> >>>> To: Core developer announcements
> >>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
> Where
> >>>>
> >> do
> >>
> >>>> they come from?
> >>>>
> >>>> Hi Eddie,
> >>>>
> >>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> The answer basically is that you also need to set up
> >>>>>
> >>>>>
> >>>> some
> >>>>
> >>>>
> >>>>> servlets (RESOURCES script, types, etc), if you have
> a
> >>>>> custom registry.
> >>>>>
> >>>>>
> >>>>
> >>>> Thanks for the quick feedback. I was already afraid
> it
> >>>> would be
> >>>> something like that :(.
> >>>>
> >>>>
> >>>>
> >>>>> So Taverna is basically reading in your services,
> and
> >>>>>
> >>>>>
> >>>> cannot
> >>>>
> >>>>
> >>>>> find the objects, so it probably defaults to the
> >>>>>
> >>>>>
> >>>> Mobycentral
> >>>>
> >>>>
> >>>>> registry.
> >>>>>
> >>>>>
> >>>>
> >>>> Would it help if I register my objects at THE central
> >>>> mobycentral
> >>>> instead of in my local central? Or are the objects
> >>>> hardcoded in some
> >>>> jar file (like lib/jmoby.jar perhaps)?
> >>>>
> >>>> Pieter
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Eddie
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: moby-dev-bounces@portal.open-bio.org
> >>>>>>
> >>>>>>
> >>>> [mailto:moby-
> >>>>
> >>>>
> >>>>>> dev-bounces@portal.open-bio.org] On Behalf Of
> Pieter
> >>>>>> Neerincx
> >>>>>> Sent: Monday, September 12, 2005 8:06 AM
> >>>>>> To: Core developer announcements
> >>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
> do
> >>>>>>
> >>>>>>
> >>>> they
> >>>>
> >>>>
> >>>>>> come from?
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I'm having some trouble to make BioMOBY work with
> >>>>>>
> >>>>>>
> >>>> Taverna.
> >>>>
> >>>>
> >>>>>> I have a
> >>>>>> local development Moby central. When I register
> both
> >>>>>>
> >>>>>>
> >>>> new
> >>>>
> >>>>
> >>>>>> services and
> >>>>>> new objects I notice that only my custom services
> are
> >>>>>> listed in
> >>>>>> Taverna. The list of moby objects is not in sync
> with
> >>>>>>
> >>>>>>
> >>>> what
> >>>>
> >>>>
> >>>>>> is
> >>>>>> registered in my central. So where does Taverna get
> >>>>>>
> >>>>>>
> >>>> those
> >>>>
> >>>>
> >>>>>> objects
> >>>>>> from and how do I get my own objects in there? Does
> >>>>>>
> >>>>>>
> >>>> anyone
> >>>>
> >>>>
> >>>>>> have a clue?
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Pieter
> >>>>>>
> >>>>>> Wageningen University and Research centre (WUR)
> >>>>>> Laboratory of Bioinformatics
> >>>>>> Transitorium (building 312) room 1034
> >>>>>> Dreijenlaan 3
> >>>>>> 6703 HA Wageningen
> >>>>>> The Netherlands
> >>>>>> phone: 0317-483 060
> >>>>>> fax: 0317-483 584
> >>>>>> mobile: 06-143 66 783
> >>>>>> pieter.neerincx@wur.nl
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MOBY-dev mailing list
> >>>>>> MOBY-dev@biomoby.org
> >>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> MOBY-dev mailing list
> >>>>> MOBY-dev@biomoby.org
> >>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> Wageningen University and Research centre (WUR)
> >>>> Laboratory of Bioinformatics
> >>>> Transitorium (building 312) room 1034
> >>>> Dreijenlaan 3
> >>>> 6703 HA Wageningen
> >>>> The Netherlands
> >>>> phone: 0317-483 060
> >>>> fax: 0317-483 584
> >>>> mobile: 06-143 66 783
> >>>> pieter.neerincx@wur.nl
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev@biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev@biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx@wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev@biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From Pieter.Neerincx at wur.nl  Wed Sep 14 07:04:53 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu Sep 15 17:31:17 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326f75b.52b7817a.2384.5590@mx.gmail.com>
References: <4326f75b.52b7817a.2384.5590@mx.gmail.com>
Message-ID: <1ACC63DC-D971-4137-97FA-1D90AD0EE571@wur.nl>

Ok, got Tomcat installed... Please tell me what to download from  
where and where to install it...

Thanks,

Pieter

On 13-Sep-2005, at 5:58 PM, Edward Kawas wrote:

> Great. I will be waiting ;-)
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 8:49 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi,
>>
>> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> For the Taverna workbench, download it temporarily from
>>> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>>>
>> 1.2.
>>
>>> zip
>>>
>>
>> I will...
>>
>>
>>> This version contains my changes (the ones that are in
>>>
>> the
>>
>>> Taverna CVS).
>>>
>>> The Moby api actually now has a method in it called
>>> getResources (or something similar to that) that returns
>>>
>> the
>>
>>> locations of these documents for a registry.
>>>
>>
>> Ok, that sounds like a much more elegant solution :).
>>
>>
>>> So in the newly
>>> updated version of the plugin, I have removed the
>>>
>> textbox
>>
>>> that asks for this url and replaced it with an api call.
>>> (a description on the Moby plugin can be found at
>>>
>>>
>> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
>> ht
>>
>>> ml but is being changed to reflect the api calling).
>>>
>>> You are correct in saying that we are moving towards
>>>
>> having
>>
>>> Services and datatypes described by RDF.
>>>
>>> Finally, as for the servlet installation, if you are
>>> interested, I can guide you through this relatively
>>>
>> painless
>>
>>> procedure. I would just need to update certain files
>>>
>> that
>>
>>> you need to download and you would have to install
>>>
>> tomcat.
>>
>> Ok, I will start with tomcat tomorrow... and will request
>> further
>> advice one I have that one up and running...
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces@portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Tuesday, September 13, 2005 7:18 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>>>
>> do
>>
>>>> they come from?
>>>>
>>>> Hi Eddie,
>>>>
>>>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> Objects aren't hard coded. They just have to be
>>>>>
>>>>>
>>>> registered
>>>>
>>>>
>>>>> in Mobycentral.
>>>>>
>>>>>
>>>>
>>>> Today I fetched the source code for Taverna and
>>>>
>> 'grep'ed
>>
>>>> over the
>>>> files. There are several instances where the path to
>>>>
>> the
>>
>>>> central
>>>> biomoby central and an RDF file are hardcoded outside
>>>>
>> the
>>
>>>> files in
>>>> conf/. Sometime ago I started to work with Taverna and
>>>>
>> the
>>
>>>> user
>>>> manual only mentions the path to a biomoby central in
>>>>
>> the
>>
>>>> conf/
>>>> mygrid.properties file. So I appended my local biomoby
>>>> central to
>>>> this conf file and expected this would allow me to use
>>>> both services
>>>> and objects registered in my local central. I think
>>>>
>> that
>>
>>>> the current
>>>> situation where service info is fetched from a URL in
>>>>
>> the
>>
>>>> conf/
>>>> mygrid.properties file and object info is fetched from
>>>>
>> a
>>
>>>> RDF file at
>>>> a different location is very confusing and needlessly
>>>> complex.
>>>> Especially since I cannot supply an URL to a custom RDF
>>>> file for my
>>>> objects in the conf/mygrid.properties file. I did see
>>>> though that I
>>>> can right-click in Taverna to add a scavenger and than
>>>>
>> I
>>
>>>> can supply
>>>> both an URL to my local central and an URL to this RDF
>>>> file for the
>>>> objects.
>>>>
>>>> I also browsed the mailinglist and wiki. Did I
>>>>
>> understand
>>
>>>> correctly
>>>> that the current situation is a temporary solution and
>>>> that
>>>> eventually all info (hence services and objects) will
>>>>
>> be
>>
>>>> described
>>>> using RDF? Please correct me if I'm wrong...
>>>>
>>>>
>>>>
>>>>> I am not sure if you are up for it, but you could
>>>>>
>> always
>>
>>>>> install the servlets
>>>>>
>>>>>
>>>>
>>>> Are those servlets generating this RDF file from the
>>>>
>> info
>>
>>>> in a central?
>>>> Is this documented somewhere? I couldn't find any
>>>> reference to
>>>> servlets at
>>>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>>>
>>>>
>>>>
>>>>> (I could help you).
>>>>>
>>>>>
>>>>
>>>> Your help is much appreciated! Thanks,
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: moby-dev-bounces@portal.open-bio.org
>>>>>>
>>>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>>>>>> Neerincx
>>>>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>>>> To: Core developer announcements
>>>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
>>>>>>
>> Where
>>
>>>>>>
>>>>>>
>>>> do
>>>>
>>>>
>>>>>> they come from?
>>>>>>
>>>>>> Hi Eddie,
>>>>>>
>>>>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The answer basically is that you also need to set up
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> some
>>>>>>
>>>>>>
>>>>>>
>>>>>>> servlets (RESOURCES script, types, etc), if you have
>>>>>>>
>> a
>>
>>>>>>> custom registry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks for the quick feedback. I was already afraid
>>>>>>
>> it
>>
>>>>>> would be
>>>>>> something like that :(.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> So Taverna is basically reading in your services,
>>>>>>>
>> and
>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> cannot
>>>>>>
>>>>>>
>>>>>>
>>>>>>> find the objects, so it probably defaults to the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Mobycentral
>>>>>>
>>>>>>
>>>>>>
>>>>>>> registry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Would it help if I register my objects at THE central
>>>>>> mobycentral
>>>>>> instead of in my local central? Or are the objects
>>>>>> hardcoded in some
>>>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>>>
>>>>>> Pieter
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Eddie
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: moby-dev-bounces@portal.open-bio.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> [mailto:moby-
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> dev-bounces@portal.open-bio.org] On Behalf Of
>>>>>>>>
>> Pieter
>>
>>>>>>>> Neerincx
>>>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>>>> To: Core developer announcements
>>>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
>>>>>>>>
>> do
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> they
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> come from?
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'm having some trouble to make BioMOBY work with
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> Taverna.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> I have a
>>>>>>>> local development Moby central. When I register
>>>>>>>>
>> both
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> new
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> services and
>>>>>>>> new objects I notice that only my custom services
>>>>>>>>
>> are
>>
>>>>>>>> listed in
>>>>>>>> Taverna. The list of moby objects is not in sync
>>>>>>>>
>> with
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> what
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> is
>>>>>>>> registered in my central. So where does Taverna get
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> those
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> objects
>>>>>>>> from and how do I get my own objects in there? Does
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> anyone
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> have a clue?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Pieter
>>>>>>>>
>>>>>>>> Wageningen University and Research centre (WUR)
>>>>>>>> Laboratory of Bioinformatics
>>>>>>>> Transitorium (building 312) room 1034
>>>>>>>> Dreijenlaan 3
>>>>>>>> 6703 HA Wageningen
>>>>>>>> The Netherlands
>>>>>>>> phone: 0317-483 060
>>>>>>>> fax: 0317-483 584
>>>>>>>> mobile: 06-143 66 783
>>>>>>>> pieter.neerincx@wur.nl
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MOBY-dev mailing list
>>>>>>>> MOBY-dev@biomoby.org
>>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> MOBY-dev mailing list
>>>>>>> MOBY-dev@biomoby.org
>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Wageningen University and Research centre (WUR)
>>>>>> Laboratory of Bioinformatics
>>>>>> Transitorium (building 312) room 1034
>>>>>> Dreijenlaan 3
>>>>>> 6703 HA Wageningen
>>>>>> The Netherlands
>>>>>> phone: 0317-483 060
>>>>>> fax: 0317-483 584
>>>>>> mobile: 06-143 66 783
>>>>>> pieter.neerincx@wur.nl
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev@biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev@biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx@wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev@biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev@biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx@wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Thu Sep 15 18:46:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu Sep 15 18:47:06 2005
Subject: [MOBY-dev] invitation for the RFC committee with a tenure of one
	year
Message-ID: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>



-----Original Message-----
From: mark wilkinson [mailto:markw@illuminae.com] 
Sent: Thursday, September 15, 2005 3:06 PM
To: Frank Gibbons; Eddie Kawas
Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
Error-handling in MOBY-S

Hey Frank! Cc Eddie

Thanks for riding this.  I am on holiday, and not in Net
contact except by blackberry, so I'm not "useful" right now.

I think we should put out an invitation on the -dev list for
the RFC committee with a tenure of one year, but also
specifically invite the main developers/vested interests to
be part of it:  me, you, martin, eddie, simon, heiko, paul,
yan wong, and at least one from the spanish contingent (have
I missed anyone?).

I don't have all their email addresses on my bberry so
unless you or Eddie (cc'd) post this invitation to the dev
list yourselves it may take a week before I am back in
net-world.  Eddie, could you do this? Tomorrow or this
afternoon?  It would be good to get this sorted asap to keep
on schedule.

M


-----Original Message-----
From: Frank Gibbons <fgibbons@hms.harvard.edu>
Date: Thu, 15 Sep 2005 11:21:53 
To:moby-l@biomoby.org
Subject: [MOBY-l] Using bugzilla to continue RFC on
Error-handling in MOBY-S

Hi,

I've just added a few "bugs" to the bugzilla, to try to
preserve the RFC 
momentum built up over the past few weeks. I propose that,
although 
bugzilla is perhaps not ideal for this, it is what it is, it
is what we 
have, and it will do for now.

I'd like to propose that we try to continue development of
this RFC through 
bugzilla (see bug #1863), rather than through the mailing
list. Searching 
through old mail messages (or worse still, through the
digest, with all of 
its repeated messages and long inclusions) is tedious, and I
think 
contributes to the loss in momentum.

So far, in Martin's scheme for RFC-processing, we have
(numbers are those 
used in Martin's original suggestion, now available in the
codebase as 
Docs/MOBY-S_API/RFC.html)

1. Had a suggestion made by INB to add this features. It was
added to 
bugzilla, No. 1863
2. Suggested to resolve it by today (Sep-15)
3. Martin backed up the RFC
4. I think we have the resources to make this change - it
seems an 
essential part of a robust API, which version 1.0 should be.
5a. List members have exchanged several comments back and
forth, resulting 
in amended versions of the RFC being posted to the mailing
list.
5b. We've also gotten a little side-tracked by the related
articleName problem.

So it seems to me that it's time to vote on it (step 6 of
the Senger 
seven-step scheme ;-). Martin suggested that Mark would ask
a limited 
number of people to vote on it after the resolution date
(today). I guess 
those people would self-select, or maybe Mark will select
them. They will 
be requested to make a one-year commitment.

After that comes step 7, the "fun part": implementation,
documentation.

We're pretty close to reaching a conclusion on this. The
fact is that even 
if we do nothing, people want this functionality, and they
WILL implement 
it. It is in everybody's interest that we have a
specification for what the 
functionality should be. It may change over time, but I
think there has 
been enough back-and-forth that we have a reasonable first
draft, and 
should vote on it.

-Frank
P.S. Of course, this message, along with version 1.7.1 of
the RFC is 
attached to the bug on bugzilla

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

_______________________________________________
moby-l mailing list
moby-l@biomoby.org
http://biomoby.org/mailman/listinfo/moby-l

--
Mark Wilkinson
..on the road!

From ed.kawas at gmail.com  Thu Sep 15 20:04:26 2005
From: ed.kawas at gmail.com (Eddie Kawas)
Date: Fri Sep 16 00:18:07 2005
Subject: [MOBY-dev] taverna update
Message-ID: <432a0c0e.0f0001ad.6fb1.4f25@mx.gmail.com>

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie


From markw at illuminae.com  Fri Sep 16 00:20:50 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri Sep 16 00:27:45 2005
Subject: [MOBY-dev] taverna update
Message-ID: <2044406868-1126844547-cardhu_blackberry.rim.net-21354-@engine13-cell01>

This is the kick-ass addition to Taverna that only MOBY can accomplish!  I'm really excited about this!  Lead the biologist by the hand through workflow creation... It isn't quite a "wizard" but getting there!

Thanks Eddie!  Your plugin is bare(bear)able!

M
.
 
-----Original Message-----
From: "Eddie Kawas" <ed.kawas@gmail.com>
Date: Thu, 15 Sep 2005 17:04:26 
To:<moby-l@biomoby.org>, "'Moby Developers'" <moby-dev@biomoby.org>
Subject: [MOBY-dev] taverna update

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie


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

--
Mark Wilkinson
...on the road!
From markw at illuminae.com  Fri Sep 16 00:20:50 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri Sep 16 00:27:48 2005
Subject: [MOBY-dev] taverna update
Message-ID: <2044406868-1126844547-cardhu_blackberry.rim.net-21354-@engine13-cell01>

This is the kick-ass addition to Taverna that only MOBY can accomplish!  I'm really excited about this!  Lead the biologist by the hand through workflow creation... It isn't quite a "wizard" but getting there!

Thanks Eddie!  Your plugin is bare(bear)able!

M
.
 
-----Original Message-----
From: "Eddie Kawas" <ed.kawas@gmail.com>
Date: Thu, 15 Sep 2005 17:04:26 
To:<moby-l@biomoby.org>, "'Moby Developers'" <moby-dev@biomoby.org>
Subject: [MOBY-dev] taverna update

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie


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

--
Mark Wilkinson
...on the road!
From senger at ebi.ac.uk  Fri Sep 16 04:16:49 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 16 04:17:12 2005
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509160914540.1437894-100000@mozart.ebi.ac.uk>

Thank you for your invitation. It will be my pleasure and honour to take
this tenure. I will do my best in the interests of the Biomoby community.

Regards,
Martin

-- 
Martin Senger
   email: martin.senger@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)

From Pieter.Neerincx at wur.nl  Fri Sep 16 09:37:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri Sep 16 09:44:15 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4329bac6.25d8a4f3.6fb1.ffffb832@mx.gmail.com>
References: <4329bac6.25d8a4f3.6fb1.ffffb832@mx.gmail.com>
Message-ID: <D2F9CBDD-C6D9-4644-9267-EF3113A418FB@wur.nl>

Hi Eddie,

Thanks for the tools! Here's my feedback:

On 15-Sep-2005, at 8:17 PM, Edward Kawas wrote:

> Hi Pieter,
>
>
>
> I am sending you a link to a java based installer (GUI) that should  
> make installation very easy. If this is not useful for you, I will  
> create 3 war files and send you the links to them.
>
> http://bioinfo.icapture.ubc.ca/ekawas/servlets/install.jar
>
>
>
> Some people can run the jar file by double clicking it. If that  
> doesn?t work, then type at the command prompt
>
> java ?jar install.jar
This gave me:

     The java class is not found: -jar

Works fine though without the -jar :) So 'java install.jar' was enough.
>
>
> If that doesn?t work, then email me back and I will send you 3 war  
> files and let you know what to do with them.
>
>
>
> Assuming that all goes well, there are a few things for you to do,  
> configuration wise.
>
>
>
> You will have to edit the biomoby.properties file in 3 different  
> locations:
>
>
>
> /tomcat/webapps/RESOURCES/WEB-INF/classes/org/BioMoby/registry/ 
> properties
>
> /tomcat/webapps/types/WEB-INF/classes/org/BioMoby/registry/properties
>
> /tomcat/webapps/authority/WEB-INF/classes/org/BioMoby/registry/ 
> properties
Close, but the installer created ..../biomoby/.... instead of ..../ 
BioMoby/.... .
>
> Open this file in any one of the locations and modify the properties:
>
> ?config?  - this property points to mobycentral.conf(ig)
>
> ?lsid_port?  -  this is the port that tomcat is running on
Ok, that is a bit confusing though. Shouldn't it be labelled  
'tomcat_port' port then?
> ?lsid_domain? ? the domain that you would like your lsids to have
> ?resources_script_domain? ? the domain that the RESOURCES script (a  
> servlet you have installed) uses.
>
>  Save this file in the 3 above stated locations.
Ok, done. Editing one file and copying it 2 times was fast enough. So  
it's not a big deal, but I do wonder you why you would want to have  
this redundancy. Are people ever going to use different settings in  
these 3 locations? If not, then why not have just one file to rule 'm  
all?
>  Restart tomcat and let me know what happens! My fingers are  
> crossed ;-)
Well, nothing yet. At least Tomcat doesn't complain. Seems to be Ok.  
But in Taverna I see my custom services from my local central as  
before and my custom objects are missing as before. You didn't  
mention it, but I assume I need to update my BioMOBY API stuff as  
well. So I tried an cvs up -d of moby-live. When I try make test for  
the Perl stuff I see a lot of tests failing.... Can I safely ignore  
them for now?

Pieter


> Eddie
>
>
>
> From: Pieter Neerincx [mailto:Pieter.Neerincx@wur.nl]
> Sent: Thursday, September 15, 2005 10:19 AM
> To: Edward Kawas
> Subject: Fwd: [MOBY-dev] Moby objects in Taverna. Where do they  
> come from?
>
>
>
> Hi Eddie,
>
>
>
> I suspect some problems with the mailinglist. I send the mail below  
> to the mailinglist yesterday, but so I haven't received it back  
> yet. Haven't received any other mails from the list anymore and one  
> of your mails of on 13-Sep-2005 was the last one showing up in the  
> online archive....
>
>
>
> Anyway, Tomcat is up and running so I'm awaiting further  
> instructions :).
>
>
>
> Cheers,
>
>
>
> Pieter
>
>
>
> Begin forwarded message:
>
>
>
>
> From: Pieter Neerincx <Pieter.Neerincx@wur.nl>
>
> Date: 14-September-2005 1:04:53 PM GMT+02:00
>
> To: Core developer announcements <moby-dev@portal.open-bio.org>
>
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do they come  
> from?
>
>
>
>
>
> Ok, got Tomcat installed... Please tell me what to download from  
> where and where to install it...
>
>
>
> Thanks,
>
>
>
> Pieter
>
>
>
> On 13-Sep-2005, at 5:58 PM, Edward Kawas wrote:
>
>
>
>
>
>
> Great. I will be waiting ;-)
>
>
>
> Eddie
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
>
> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>
> Neerincx
>
> Sent: Tuesday, September 13, 2005 8:49 AM
>
> To: Core developer announcements
>
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>
> they come from?
>
>
>
> Hi,
>
>
>
> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
>
>
>
>
>
>
>
>
> Hi,
>
>
>
> For the Taverna workbench, download it temporarily from
>
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>
>
>
>
>
> 1.2.
>
>
>
>
>
>
> zip
>
>
>
>
>
>
>
> I will...
>
>
>
>
>
>
>
>
> This version contains my changes (the ones that are in
>
>
>
>
>
> the
>
>
>
>
>
>
> Taverna CVS).
>
>
>
> The Moby api actually now has a method in it called
>
> getResources (or something similar to that) that returns
>
>
>
>
>
> the
>
>
>
>
>
>
> locations of these documents for a registry.
>
>
>
>
>
>
>
> Ok, that sounds like a much more elegant solution :).
>
>
>
>
>
>
>
>
> So in the newly
>
> updated version of the plugin, I have removed the
>
>
>
>
>
> textbox
>
>
>
>
>
>
> that asks for this url and replaced it with an api call.
>
> (a description on the Moby plugin can be found at
>
>
>
>
>
>
>
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
>
> ht
>
>
>
>
>
>
> ml but is being changed to reflect the api calling).
>
>
>
> You are correct in saying that we are moving towards
>
>
>
>
>
> having
>
>
>
>
>
>
> Services and datatypes described by RDF.
>
>
>
> Finally, as for the servlet installation, if you are
>
> interested, I can guide you through this relatively
>
>
>
>
>
> painless
>
>
>
>
>
>
> procedure. I would just need to update certain files
>
>
>
>
>
> that
>
>
>
>
>
>
> you need to download and you would have to install
>
>
>
>
>
> tomcat.
>
>
>
> Ok, I will start with tomcat tomorrow... and will request
>
> further
>
> advice one I have that one up and running...
>
>
>
> Pieter
>
>
>
>
>
>
>
>
>
>
> Eddie
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: moby-dev-bounces@portal.open-bio.org
>
>
>
>
>
> [mailto:moby-
>
>
>
>
>
>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>>
>> Neerincx
>>
>> Sent: Tuesday, September 13, 2005 7:18 AM
>>
>> To: Core developer announcements
>>
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>
>>
>>
>>
> do
>
>
>
>
>
>> they come from?
>>
>>
>>
>> Hi Eddie,
>>
>>
>>
>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>>
>>
>> Objects aren't hard coded. They just have to be
>>
>>
>>
>>
>>
>>
>>
>> registered
>>
>>
>>
>>
>>
>>
>>
>>
>> in Mobycentral.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Today I fetched the source code for Taverna and
>>
>>
>>
>>
> 'grep'ed
>
>
>
>
>
>> over the
>>
>> files. There are several instances where the path to
>>
>>
>>
>>
> the
>
>
>
>
>
>> central
>>
>> biomoby central and an RDF file are hardcoded outside
>>
>>
>>
>>
> the
>
>
>
>
>
>> files in
>>
>> conf/. Sometime ago I started to work with Taverna and
>>
>>
>>
>>
> the
>
>
>
>
>
>> user
>>
>> manual only mentions the path to a biomoby central in
>>
>>
>>
>>
> the
>
>
>
>
>
>> conf/
>>
>> mygrid.properties file. So I appended my local biomoby
>>
>> central to
>>
>> this conf file and expected this would allow me to use
>>
>> both services
>>
>> and objects registered in my local central. I think
>>
>>
>>
>>
> that
>
>
>
>
>
>> the current
>>
>> situation where service info is fetched from a URL in
>>
>>
>>
>>
> the
>
>
>
>
>
>> conf/
>>
>> mygrid.properties file and object info is fetched from
>>
>>
>>
>>
> a
>
>
>
>
>
>> RDF file at
>>
>> a different location is very confusing and needlessly
>>
>> complex.
>>
>> Especially since I cannot supply an URL to a custom RDF
>>
>> file for my
>>
>> objects in the conf/mygrid.properties file. I did see
>>
>> though that I
>>
>> can right-click in Taverna to add a scavenger and than
>>
>>
>>
>>
> I
>
>
>
>
>
>> can supply
>>
>> both an URL to my local central and an URL to this RDF
>>
>> file for the
>>
>> objects.
>>
>>
>>
>> I also browsed the mailinglist and wiki. Did I
>>
>>
>>
>>
> understand
>
>
>
>
>
>> correctly
>>
>> that the current situation is a temporary solution and
>>
>> that
>>
>> eventually all info (hence services and objects) will
>>
>>
>>
>>
> be
>
>
>
>
>
>> described
>>
>> using RDF? Please correct me if I'm wrong...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I am not sure if you are up for it, but you could
>>
>>
>>
>>
> always
>
>
>
>
>
>>> install the servlets
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> Are those servlets generating this RDF file from the
>>
>>
>>
>>
> info
>
>
>
>
>
>> in a central?
>>
>> Is this documented somewhere? I couldn't find any
>>
>> reference to
>>
>> servlets at
>>
>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> (I could help you).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Your help is much appreciated! Thanks,
>>
>>
>>
>> Pieter
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Eddie
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>>
>> From: moby-dev-bounces@portal.open-bio.org
>>
>>
>>
>>
>>
>>
>>
>> [mailto:moby-
>>
>>
>>
>>
>>
>>
>>
>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>>>
>>> Neerincx
>>>
>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>
>>> To: Core developer announcements
>>>
>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
>>>
>>>
>>>
>>>
> Where
>
>
>
>
>
>>>>
>>>>
>>>>
>>>>
>>>>
>> do
>>
>>
>>
>>
>>
>>
>>
>>> they come from?
>>>
>>>
>>>
>>> Hi Eddie,
>>>
>>>
>>>
>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> The answer basically is that you also need to set up
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> some
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> servlets (RESOURCES script, types, etc), if you have
>>>
>>>
>>>
>>>
> a
>
>
>
>
>
>>>>> custom registry.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Thanks for the quick feedback. I was already afraid
>>>>
>>>>
>>>>
>>>>
> it
>
>
>
>
>
>>>> would be
>>>>
>>>> something like that :(.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So Taverna is basically reading in your services,
>>>>
>>>>
>>>>
>>>>
> and
>
>
>
>
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> find the objects, so it probably defaults to the
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Mobycentral
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> registry.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Would it help if I register my objects at THE central
>>>>
>>>> mobycentral
>>>>
>>>> instead of in my local central? Or are the objects
>>>>
>>>> hardcoded in some
>>>>
>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>
>>>>
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Eddie
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>> From: moby-dev-bounces@portal.open-bio.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> dev-bounces@portal.open-bio.org] On Behalf Of
>>>>>
>>>>>
>>>>>
>>>>>
> Pieter
>
>
>
>
>
>>>>>> Neerincx
>>>>>>
>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>>
>>>>>> To: Core developer announcements
>>>>>>
>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> do
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> they
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> come from?
>>>>>
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> I'm having some trouble to make BioMOBY work with
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Taverna.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I have a
>>>>>
>>>>> local development Moby central. When I register
>>>>>
>>>>>
>>>>>
>>>>>
> both
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> new
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> services and
>>>>>
>>>>> new objects I notice that only my custom services
>>>>>
>>>>>
>>>>>
>>>>>
> are
>
>
>
>
>
>>>>>> listed in
>>>>>>
>>>>>> Taverna. The list of moby objects is not in sync
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> with
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> what
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> is
>>>>>
>>>>> registered in my central. So where does Taverna get
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> those
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> objects
>>>>>
>>>>> from and how do I get my own objects in there? Does
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> anyone
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> have a clue?
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> Pieter
>>>>>
>>>>>
>>>>>
>>>>> Wageningen University and Research centre (WUR)
>>>>>
>>>>> Laboratory of Bioinformatics
>>>>>
>>>>> Transitorium (building 312) room 1034
>>>>>
>>>>> Dreijenlaan 3
>>>>>
>>>>> 6703 HA Wageningen
>>>>>
>>>>> The Netherlands
>>>>>
>>>>> phone: 0317-483 060
>>>>>
>>>>> fax: 0317-483 584
>>>>>
>>>>> mobile: 06-143 66 783
>>>>>
>>>>> pieter.neerincx@wur.nl
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> MOBY-dev mailing list
>>>>>
>>>>> MOBY-dev@biomoby.org
>>>>>
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> MOBY-dev mailing list
>>>>
>>>> MOBY-dev@biomoby.org
>>>>
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>>
>>>> Laboratory of Bioinformatics
>>>>
>>>> Transitorium (building 312) room 1034
>>>>
>>>> Dreijenlaan 3
>>>>
>>>> 6703 HA Wageningen
>>>>
>>>> The Netherlands
>>>>
>>>> phone: 0317-483 060
>>>>
>>>> fax: 0317-483 584
>>>>
>>>> mobile: 06-143 66 783
>>>>
>>>> pieter.neerincx@wur.nl
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> MOBY-dev mailing list
>>>>
>>>> MOBY-dev@biomoby.org
>>>>
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> MOBY-dev mailing list
>>>
>>> MOBY-dev@biomoby.org
>>>
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> Wageningen University and Research centre (WUR)
>>
>> Laboratory of Bioinformatics
>>
>> Transitorium (building 312) room 1034
>>
>> Dreijenlaan 3
>>
>> 6703 HA Wageningen
>>
>> The Netherlands
>>
>> phone: 0317-483 060
>>
>> fax: 0317-483 584
>>
>> mobile: 06-143 66 783
>>
>> pieter.neerincx@wur.nl
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> MOBY-dev mailing list
>>
>> MOBY-dev@biomoby.org
>>
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev@biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx@wur.nl
>
>
>
>
>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev@biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev@biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx@wur.nl
>
>
>
>
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx@wur.nl
>
>
>
>
>
>
>
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl




From edward.kawas at gmail.com  Fri Sep 16 09:54:24 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri Sep 16 09:55:02 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <D2F9CBDD-C6D9-4644-9267-EF3113A418FB@wur.nl>
Message-ID: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>

>I assume I need to update my BioMOBY API stuff as  
>well. So I tried an cvs up -d of moby-live. When I try make
>test for the Perl stuff I see a lot of tests failing....
>Can I safely ignore them for now?

I am not sure about this question. I know that Mark has a
new test suite but I am not sure if this is the suite that
you are running.

One more thing, if the servlets work, you would be able to
do the following:
http://yourURL:port/types/Objects
http://yourURL:port/RESOURCES/MOBY-S/Objects
http://yourURL:port/authority

These 3 links should show you something meaningful (html, a
file, more html).

Eddie

From Pieter.Neerincx at wur.nl  Fri Sep 16 10:04:24 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri Sep 16 10:06:07 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
References: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
Message-ID: <2474E6AB-0592-4028-B15A-08062062350B@wur.nl>


On 16-Sep-2005, at 3:54 PM, Edward Kawas wrote:

>> I assume I need to update my BioMOBY API stuff as
>> well. So I tried an cvs up -d of moby-live. When I try make
>> test for the Perl stuff I see a lot of tests failing....
>> Can I safely ignore them for now?
>>
>
> I am not sure about this question. I know that Mark has a
> new test suite but I am not sure if this is the suite that
> you are running.

Ok, maybe Mark can shed some light on which version of the API is  
running on the current mobycentral server...

>
> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
> These 3 links should show you something meaningful (html, a
> file, more html).

Yes, works perfectly. I get xml/rdf returned and the first two links  
contain amongst others my custom objects :).


Pieter

>
> Eddie
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From senger at ebi.ac.uk  Fri Sep 16 10:10:38 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 16 10:12:42 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>

> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
   Well, my understanding (Eddie/Mark, correct me if I am mistaken please)
is that you should *not* used these URLs directly (and Eddie should not
advice it :-)). You should use a new API method 'retrieveResourceURLs'
which gives you those URLs.
   This new method is implemented, for example, in jMoby (Java libraries
for biomoby) - in Central.java interface. It is also described in the
biomoby API.
 
   Regards,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Fri Sep 16 10:16:12 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri Sep 16 10:16:20 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad3af.701b5241.51a9.ffffed46@mx.gmail.com>



>    Well, my understanding (Eddie/Mark, correct me if I am
> mistaken please)
> is that you should *not* used these URLs directly (and
> Eddie should not
> advice it :-)). You should use a new API method
> 'retrieveResourceURLs'
> which gives you those URLs.
>    This new method is implemented, for example, in jMoby
> (Java libraries
> for biomoby) - in Central.java interface. It is also
> described in the
> biomoby API.


Relax Martin ;-) Just wanted to ensure that the installation
worked!

Eddie



From senger at ebi.ac.uk  Fri Sep 16 10:22:27 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 16 10:22:36 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad3af.701b5241.51a9.ffffed46@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161521130.1458011-100000@mozart.ebi.ac.uk>

> Relax Martin ;-) Just wanted to ensure that the installation
> worked!
>
   That's exactly my point: How he can be sure that an installation worked
if he does not test all methods that should be supported...

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Fri Sep 16 10:25:04 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri Sep 16 10:25:11 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161521130.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad5c3.1aa4d48b.6fb1.ffffe6f6@mx.gmail.com>

>    That's exactly my point: How he can be sure that an
> installation worked
> if he does not test all methods that should be
supported...

Testing the servlet installation. 

The updated Moby code in Taverna utilizes the new api calls!

From senger at ebi.ac.uk  Fri Sep 16 10:30:46 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 16 10:30:57 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad5c3.1aa4d48b.6fb1.ffffe6f6@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161529570.1458011-100000@mozart.ebi.ac.uk>

> The updated Moby code in Taverna utilizes the new api calls!
>
   That's good.
   Which reminds me: have you reached (with Mark) a conclusion about the
content-type of these resources?

   Martin

-- 
Martin Senger
   email: martin.senger@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)

From Pieter.Neerincx at wur.nl  Fri Sep 16 10:35:13 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri Sep 16 10:35:24 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <106CCC00-6072-41B9-82B5-C031F0E0F380@wur.nl>


On 16-Sep-2005, at 4:10 PM, Martin Senger wrote:

>> One more thing, if the servlets work, you would be able to
>> do the following:
>> http://yourURL:port/types/Objects
>> http://yourURL:port/RESOURCES/MOBY-S/Objects
>> http://yourURL:port/authority
>>
>>
>    Well, my understanding (Eddie/Mark, correct me if I am mistaken  
> please)
> is that you should *not* used these URLs directly (and Eddie should  
> not
> advice it :-)).

That does make sense, but having a quick look at what those URLs  
produce just to get an quick idea whether those servlets are working  
in Tomcat at all can't hurt :)

> You should use a new API method 'retrieveResourceURLs'
> which gives you those URLs.
>    This new method is implemented, for example, in jMoby (Java  
> libraries
> for biomoby) - in Central.java interface. It is also described in the
> biomoby API.

Ok, so I definitely should upgrade my biomoby API as well...

Thanks,

Pieter

>
>    Regards,
>    Martin
>
> -- 
> Martin Senger
>    email: martin.senger@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)
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Fri Sep 16 10:41:22 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri Sep 16 10:42:17 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <106CCC00-6072-41B9-82B5-C031F0E0F380@wur.nl>
Message-ID: <432ad996.18f52057.633b.2430@mx.gmail.com>

> Ok, so I definitely should upgrade my biomoby API as
> well...
Yes. Perhaps others who have done this upgrade could give
you a few pointers. Anyone?!

Thanks,

Ed

From edward.kawas at gmail.com  Fri Sep 16 10:42:35 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri Sep 16 10:49:29 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161529570.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad9de.370ca386.0467.ffffc707@mx.gmail.com>


>    That's good.
>    Which reminds me: have you reached (with Mark) a
> conclusion about the
> content-type of these resources?


If only you could hear me whistling aloud as I look the
other way.

We haven't discussed this yet. Sorry Martin.

Eddie

From Pieter.Neerincx at wur.nl  Fri Sep 16 11:01:12 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri Sep 16 11:01:27 2005
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <6C0F151C-AB25-470F-A8E9-89996DCC051F@wur.nl>

Hi Frank,

On 16-Sep-2005, at 4:26 PM, Gibbons, Francis wrote:

> Pieter,
>
> I wrote many of the tests for the  Perl API. When I run them, I see  
> a 99% pass rate, or better. I'm very interested to know which ones  
> are failing for you, and what your local installation looks like (I  
> guess you have a local registry? what's your OS? Perl version? etc.)

I'm running SuSE Linux Enterprise Server 9 (SLES9) with all the  
latest and greatest updates / patches. My Perl version is 5.8.3  
(default that comes with SLES9) I do have a local biomobycentral, but  
that shouldn't make any difference for the tests. I haven't set  
MOBY_xxx ENV vars, so for the tests  everything should default to the  
central mobycentral.

I see 3/361 subtests failed, 99.17% okay and 8 subtests UNEXPECTEDLY  
SUCCEEDED. The 99.17% might seem not too shabby, but for a user like  
me it's pretty difficult to figure out how essential the failing  
stuff is :(.... I'll just give it try anyway. If it doesn't work I'll  
downgrade again. Keeping my fingers crossed...

Below is what I got from the tests.

Cheers,

Pieter

pieter@bioinfw05:~/moby-live/Perl> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Central...................................ok
t/Client-Central............................NOK 3#     Failed test (t/ 
Client-Central.t at line 73)
#     MOBY::Client::Central->can('retrieveObjectSchema') failed
# Registry failed to supply mandatory methods
t/Client-Central............................ok 134/0# Looks like you  
failed 1 tests of 134.
t/Client-Central............................dubious
         Test returned status 1 (wstat 256, 0x100)
Scalar found where operator expected at (eval 153) line 1, near  
"'int'  $__val"
         (Missing operator before   $__val?)
DIED. FAILED test 3
         Failed 1/134 tests, 99.25% okay
t/Client-CollectionArticle..................ok
t/Client-OntologyServer.....................NOK 2#     Failed test (t/ 
Client-OntologyServer.t at line 36)
#     MOBY::Client::OntologyServer->can('relationshipExists') failed
# OntologyServer doesn't implement full API
t/Client-OntologyServer.....................ok 24/0Use of  
uninitialized value in pattern match (m//) at /mnt/geninf01/home/ 
geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/OntologyServer.pm  
line 98.
Use of uninitialized value in pattern match (m//) at /mnt/geninf01/ 
home/geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/ 
OntologyServer.pm line 98.
t/Client-OntologyServer.....................ok 25/0No such method:  
MOBY::Client::OntologyServer::relationshipExists at t/Client- 
OntologyServer.t line 76
# Looks like you failed 1 tests of 25.
# Looks like your test died just after 25.
t/Client-OntologyServer.....................dubious
         Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED test 2
         Failed 1/25 tests, 96.00% okay
t/Client-Registration.......................ok
t/Client-SecondaryArticle...................ok
t/Client-Service............................NOK 3#     Failed test (t/ 
Client-Service.t at line 36)
#     MOBY::Client::Service->can('serviceName') failed
# MOBY::Client::Service doesn't implement full API.
t/Client-Service............................ok 6/0# Looks like you  
failed 1 tests of 6.
t/Client-Service............................dubious
         Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 3
         Failed 1/6 tests, 83.33% okay
t/Client-ServiceInstance....................ok
t/Client-SimpleArticle......................ok
t/CommonSubs................................ok 18/0MOBY::CommonSubs  
WARNING ** the namespace 'bogus NS' does not exist in the MOBY  
ontology, and does not have a valid LSID
t/CommonSubs................................ok
t/Config....................................skipped
         all skipped: Required only for local MOBY Central
t/CrossReference............................ok
t/dbConnect.................................ok
t/lsid-authority-ClassResolver..............ok
t/lsid-authority-dbConnect..................ok
t/lsid-authority-Error......................ok
t/lsid-authority-NamespaceResolver..........ok
t/lsid-authority-PredicateResolver..........ok
t/lsid-authority-RDFConfigure...............ok
t/lsid-authority-RelationshipResolver.......ok
t/lsid-authority-ServiceInstanceResolver....skipped
         all skipped: Skip until apparent namespace pollution fixed  
in ServiceInstanceResolver
t/lsid-authority-ServiceResolver............ok
t/Template..................................skipped
         all skipped: This is just a template
Failed Test               Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------ 
-------
t/Client-Central.t           1   256   134    1   0.75%  3
t/Client-OntologyServer.t  255 65280    25    1   4.00%  2
t/Client-Service.t           1   256     6    1  16.67%  3
  (8 subtests UNEXPECTEDLY SUCCEEDED), 3 tests skipped.
Failed 3/23 test scripts, 86.96% okay. 3/361 subtests failed, 99.17%  
okay.
make: *** [test_dynamic] Error 255


> Clearly, we should have a test suite that passes for most  
> developers most of the time, so that they can be alerted quickly if  
> they break something. So it's really important for me to know which  
> tests are failing and why: the tests may need to be rewritten.
>
> Thanks for your feedback.
>
> -Frank
> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org on behalf of Edward Kawas
> Sent: Fri 9/16/2005 9:54 AM
> To: 'Core developer announcements'
> Cc: 'Pieter Neerincx'
> Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come  
> from?
>
> >I assume I need to update my BioMOBY API stuff as
> >well. So I tried an cvs up -d of moby-live. When I try make
> >test for the Perl stuff I see a lot of tests failing....
> >Can I safely ignore them for now?
>
> I am not sure about this question. I know that Mark has a
> new test suite but I am not sure if this is the suite that
> you are running.
>
> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
> These 3 links should show you something meaningful (html, a
> file, more html).
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Fri Sep 16 10:14:50 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri Sep 16 11:19:38 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <2474E6AB-0592-4028-B15A-08062062350B@wur.nl>
Message-ID: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>

> Yes, works perfectly. I get xml/rdf returned and the first
> two links
> contain amongst others my custom objects :).

Great! That is good news.

Eddie

From fgibbons at hms.harvard.edu  Fri Sep 16 12:27:30 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri Sep 16 12:39:03 2005
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <6C0F151C-AB25-470F-A8E9-89996DCC051F@wur.nl>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <5.2.1.1.2.20050916121257.0123eca0@email.med.harvard.edu>

Pieter,

Thanks for the quick feedback. In fact, your output is pretty much the same 
as mine, specifically in the tests that failed. There are also some which 
"unexpectedly succeed" for me too, I just haven't had a chance to check 
what they are.

The failing stuff is for the most part, apparently not that important. It 
represents aspects of the stated API (in particularly when it says "failed 
to implement complete API" or similar): methods which the API describes, 
but which are not yet implemented. I just got involved recently as a 
developer, and writing tests has been my way to understand the API, from 
the inside out. I'll modify the tests so that these go on the TO-DO list, 
and no longer generate error messages (it's not clear when they will 
actually be implemented).

There is one failure that concerns me, this one:

t/Client-Central............................dubious
         Test returned status 1 (wstat 256, 0x100)
Scalar found where operator expected at (eval 153) line 1, near
"'int'  $__val"
         (Missing operator before   $__val?)
DIED. FAILED test 3
         Failed 1/134 tests, 99.25% okay

I don't understand what '$__val' is referring to. More importantly, it 
looks like it's causing the entire test to abort ("DIED"), yet it reports 
only 1/134 failed. There are no explicit eval's in the test script, perhaps 
the message is coming from a module that is imported with 'use'.  I've 
searched the MOBY codebase, and there is no variable with that name, so it 
may be coming in from an external module.  If you have any ideas, I'm 
interested in hearing them, since this single script represents about half 
of the current tests, so if it aborts, especially if it aborts reporting 
success, that's a problem.

So thanks again for the feedback. I'll fix most of those problems I 
mentioned, which should make the remaining one (above) stand out more.

-Frank

At 11:01 AM 9/16/2005, you wrote:
>Hi Frank,
>
>On 16-Sep-2005, at 4:26 PM, Gibbons, Francis wrote:
>
>>Pieter,
>>
>>I wrote many of the tests for the  Perl API. When I run them, I see
>>a 99% pass rate, or better. I'm very interested to know which ones
>>are failing for you, and what your local installation looks like (I
>>guess you have a local registry? what's your OS? Perl version? etc.)
>
>I'm running SuSE Linux Enterprise Server 9 (SLES9) with all the
>latest and greatest updates / patches. My Perl version is 5.8.3
>(default that comes with SLES9) I do have a local biomobycentral, but
>that shouldn't make any difference for the tests. I haven't set
>MOBY_xxx ENV vars, so for the tests  everything should default to the
>central mobycentral.
>
>I see 3/361 subtests failed, 99.17% okay and 8 subtests UNEXPECTEDLY
>SUCCEEDED. The 99.17% might seem not too shabby, but for a user like
>me it's pretty difficult to figure out how essential the failing
>stuff is :(.... I'll just give it try anyway. If it doesn't work I'll
>downgrade again. Keeping my fingers crossed...
>
>Below is what I got from the tests.
>
>Cheers,
>
>Pieter
>
>pieter@bioinfw05:~/moby-live/Perl> make test
>PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
>"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
>t/Central...................................ok
>t/Client-Central............................NOK 3#     Failed test (t/ 
>Client-Central.t at line 73)
>#     MOBY::Client::Central->can('retrieveObjectSchema') failed
># Registry failed to supply mandatory methods
>t/Client-Central............................ok 134/0# Looks like you
>failed 1 tests of 134.
>t/Client-Central............................dubious
>         Test returned status 1 (wstat 256, 0x100)
>Scalar found where operator expected at (eval 153) line 1, near
>"'int'  $__val"
>         (Missing operator before   $__val?)
>DIED. FAILED test 3
>         Failed 1/134 tests, 99.25% okay
>t/Client-CollectionArticle..................ok
>t/Client-OntologyServer.....................NOK 2#     Failed test (t/ 
>Client-OntologyServer.t at line 36)
>#     MOBY::Client::OntologyServer->can('relationshipExists') failed
># OntologyServer doesn't implement full API
>t/Client-OntologyServer.....................ok 24/0Use of
>uninitialized value in pattern match (m//) at /mnt/geninf01/home/ 
>geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/OntologyServer.pm
>line 98.
>Use of uninitialized value in pattern match (m//) at /mnt/geninf01/ 
>home/geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/ OntologyServer.pm 
>line 98.
>t/Client-OntologyServer.....................ok 25/0No such method:
>MOBY::Client::OntologyServer::relationshipExists at t/Client- 
>OntologyServer.t line 76
># Looks like you failed 1 tests of 25.
># Looks like your test died just after 25.
>t/Client-OntologyServer.....................dubious
>         Test returned status 255 (wstat 65280, 0xff00)
>DIED. FAILED test 2
>         Failed 1/25 tests, 96.00% okay
>t/Client-Registration.......................ok
>t/Client-SecondaryArticle...................ok
>t/Client-Service............................NOK 3#     Failed test (t/ 
>Client-Service.t at line 36)
>#     MOBY::Client::Service->can('serviceName') failed
># MOBY::Client::Service doesn't implement full API.
>t/Client-Service............................ok 6/0# Looks like you
>failed 1 tests of 6.
>t/Client-Service............................dubious
>         Test returned status 1 (wstat 256, 0x100)
>DIED. FAILED test 3
>         Failed 1/6 tests, 83.33% okay
>t/Client-ServiceInstance....................ok
>t/Client-SimpleArticle......................ok
>t/CommonSubs................................ok 18/0MOBY::CommonSubs
>WARNING ** the namespace 'bogus NS' does not exist in the MOBY
>ontology, and does not have a valid LSID
>t/CommonSubs................................ok
>t/Config....................................skipped
>         all skipped: Required only for local MOBY Central
>t/CrossReference............................ok
>t/dbConnect.................................ok
>t/lsid-authority-ClassResolver..............ok
>t/lsid-authority-dbConnect..................ok
>t/lsid-authority-Error......................ok
>t/lsid-authority-NamespaceResolver..........ok
>t/lsid-authority-PredicateResolver..........ok
>t/lsid-authority-RDFConfigure...............ok
>t/lsid-authority-RelationshipResolver.......ok
>t/lsid-authority-ServiceInstanceResolver....skipped
>         all skipped: Skip until apparent namespace pollution fixed
>in ServiceInstanceResolver
>t/lsid-authority-ServiceResolver............ok
>t/Template..................................skipped
>         all skipped: This is just a template
>Failed Test               Stat Wstat Total Fail  Failed  List of Failed
>------------------------------------------------------------------------ 
>-------
>t/Client-Central.t           1   256   134    1   0.75%  3
>t/Client-OntologyServer.t  255 65280    25    1   4.00%  2
>t/Client-Service.t           1   256     6    1  16.67%  3
>  (8 subtests UNEXPECTEDLY SUCCEEDED), 3 tests skipped.
>Failed 3/23 test scripts, 86.96% okay. 3/361 subtests failed, 99.17%
>okay.
>make: *** [test_dynamic] Error 255
>
>
>>Clearly, we should have a test suite that passes for most
>>developers most of the time, so that they can be alerted quickly if
>>they break something. So it's really important for me to know which
>>tests are failing and why: the tests may need to be rewritten.
>>
>>Thanks for your feedback.
>>
>>-Frank
>>-----Original Message-----
>>From: moby-dev-bounces@portal.open-bio.org on behalf of Edward Kawas
>>Sent: Fri 9/16/2005 9:54 AM
>>To: 'Core developer announcements'
>>Cc: 'Pieter Neerincx'
>>Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come
>>from?
>>
>> >I assume I need to update my BioMOBY API stuff as
>> >well. So I tried an cvs up -d of moby-live. When I try make
>> >test for the Perl stuff I see a lot of tests failing....
>> >Can I safely ignore them for now?
>>
>>I am not sure about this question. I know that Mark has a
>>new test suite but I am not sure if this is the suite that
>>you are running.
>>
>>One more thing, if the servlets work, you would be able to
>>do the following:
>>http://yourURL:port/types/Objects
>>http://yourURL:port/RESOURCES/MOBY-S/Objects
>>http://yourURL:port/authority
>>
>>These 3 links should show you something meaningful (html, a
>>file, more html).
>>
>>Eddie
>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev@biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>Wageningen University and Research centre (WUR)
>Laboratory of Bioinformatics
>Transitorium (building 312) room 1034
>Dreijenlaan 3
>6703 HA Wageningen
>The Netherlands
>phone: 0317-483 060
>fax: 0317-483 584
>mobile: 06-143 66 783
>pieter.neerincx@wur.nl
>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

From fgibbons at hms.harvard.edu  Fri Sep 16 13:59:10 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri Sep 16 13:58:41 2005
Subject: [MOBY-dev] I have a subscription,
 but I keep getting messages saying I'm not subscribed....
Message-ID: <5.2.1.1.2.20050916135616.027b2030@email.med.harvard.edu>

Can anyone help me with this: I am signed up for MOBY-dev, but every time I 
post, I get a message telling me that I'm not, and that my posting is 
awaiting approval by the moderators. I recently (yesterday) changed from 
digest mode to getting each message as it's posted on MOBY-l, and this 
behavior seemed to coincide with that. Does anyone know what I should do? 
Would unsubscribing and resubscribing be the way to go?

Thanks,

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

From fgibbons at hms.harvard.edu  Fri Sep 16 14:02:24 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri Sep 16 14:14:10 2005
Subject: [MOBY-dev] Schedule? You mean there's a schedule?
In-Reply-To: <200509152247.j8FMlBnq032114@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20050916140030.01161200@email.med.harvard.edu>

Mark,

At 06:47 PM 9/15/2005, moby-dev-request@portal.open-bio.org wrote:
>Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep on schedule.
                                                                                             ^^^^^^^^^^^^

Mark,

So what is thing you call a "schedule"? Where might an interested party 
find it, if so inclined.... :-)

(I know you're on vacay, no rush, just curious/kidding.)

-F


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

From senger at ebi.ac.uk  Fri Sep 16 14:37:50 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 16 14:37:55 2005
Subject: [MOBY-dev] I have a subscription, but I keep getting messages
	saying I'm not subscribed....
In-Reply-To: <5.2.1.1.2.20050916135616.027b2030@email.med.harvard.edu>
Message-ID: <Pine.OSF.4.21.0509161936370.1458011-100000@mozart.ebi.ac.uk>

> behavior seemed to coincide with that. Does anyone know what I should do? 
> Would unsubscribing and resubscribing be the way to go?
>
   Because Mark is on holiday, you may try and ask directly the admin of
the open-bio: Chris Dagdigian <dag@sonsorol.org>.
 
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From simont at mcw.edu  Fri Sep 16 13:50:12 2005
From: simont at mcw.edu (Twigger Simon)
Date: Fri Sep 16 16:00:23 2005
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <A8FC74D9-A5A5-47DB-BC93-8FB52365226B@mcw.edu>

Hi Mark, Eddie,

Thanks for the invite, I am certainly happy to help out on the RFC  
committee. I promise to vote early and often.

Simon,


On Sep 15, 2005, at 5:46 PM, Edward Kawas wrote:

>
>
> -----Original Message-----
> From: mark wilkinson [mailto:markw@illuminae.com]
> Sent: Thursday, September 15, 2005 3:06 PM
> To: Frank Gibbons; Eddie Kawas
> Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
> Error-handling in MOBY-S
>
> Hey Frank! Cc Eddie
>
> Thanks for riding this.  I am on holiday, and not in Net
> contact except by blackberry, so I'm not "useful" right now.
>
> I think we should put out an invitation on the -dev list for
> the RFC committee with a tenure of one year, but also
> specifically invite the main developers/vested interests to
> be part of it:  me, you, martin, eddie, simon, heiko, paul,
> yan wong, and at least one from the spanish contingent (have
> I missed anyone?).
>
> I don't have all their email addresses on my bberry so
> unless you or Eddie (cc'd) post this invitation to the dev
> list yourselves it may take a week before I am back in
> net-world.  Eddie, could you do this? Tomorrow or this
> afternoon?  It would be good to get this sorted asap to keep
> on schedule.
>
> M
>
>
> -----Original Message-----
> From: Frank Gibbons <fgibbons@hms.harvard.edu>
> Date: Thu, 15 Sep 2005 11:21:53
> To:moby-l@biomoby.org
> Subject: [MOBY-l] Using bugzilla to continue RFC on
> Error-handling in MOBY-S
>
> Hi,
>
> I've just added a few "bugs" to the bugzilla, to try to
> preserve the RFC
> momentum built up over the past few weeks. I propose that,
> although
> bugzilla is perhaps not ideal for this, it is what it is, it
> is what we
> have, and it will do for now.
>
> I'd like to propose that we try to continue development of
> this RFC through
> bugzilla (see bug #1863), rather than through the mailing
> list. Searching
> through old mail messages (or worse still, through the
> digest, with all of
> its repeated messages and long inclusions) is tedious, and I
> think
> contributes to the loss in momentum.
>
> So far, in Martin's scheme for RFC-processing, we have
> (numbers are those
> used in Martin's original suggestion, now available in the
> codebase as
> Docs/MOBY-S_API/RFC.html)
>
> 1. Had a suggestion made by INB to add this features. It was
> added to
> bugzilla, No. 1863
> 2. Suggested to resolve it by today (Sep-15)
> 3. Martin backed up the RFC
> 4. I think we have the resources to make this change - it
> seems an
> essential part of a robust API, which version 1.0 should be.
> 5a. List members have exchanged several comments back and
> forth, resulting
> in amended versions of the RFC being posted to the mailing
> list.
> 5b. We've also gotten a little side-tracked by the related
> articleName problem.
>
> So it seems to me that it's time to vote on it (step 6 of
> the Senger
> seven-step scheme ;-). Martin suggested that Mark would ask
> a limited
> number of people to vote on it after the resolution date
> (today). I guess
> those people would self-select, or maybe Mark will select
> them. They will
> be requested to make a one-year commitment.
>
> After that comes step 7, the "fun part": implementation,
> documentation.
>
> We're pretty close to reaching a conclusion on this. The
> fact is that even
> if we do nothing, people want this functionality, and they
> WILL implement
> it. It is in everybody's interest that we have a
> specification for what the
> functionality should be. It may change over time, but I
> think there has
> been enough back-and-forth that we have a reasonable first
> draft, and
> should vote on it.
>
> -Frank
> P.S. Of course, this message, along with version 1.7.1 of
> the RFC is
> attached to the bug on bugzilla
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
> Boston MA 02115, USA.
> Tel: 617-432-3555       Fax:
> 617-432-3557       http://llama.med.harvard.edu/~fgibbons
>
> _______________________________________________
> moby-l mailing list
> moby-l@biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>
> --
> Mark Wilkinson
> ..on the road!
>
>

--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw

From markw at illuminae.com  Fri Sep 16 19:05:49 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri Sep 16 19:14:48 2005
Subject: [MOBY-dev] Schedule? You mean there's a schedule?
Message-ID: <1955319201-1126912049-cardhu_blackberry.rim.net-17094-@engine09-cell01>

I just meant that we had decided to have the vote on the 15th, but the committee has not been assembed yet, so we are a bit behind schedule for that vote :-)

M


-----Original Message-----
From: Frank Gibbons <fgibbons@hms.harvard.edu>
Date: Fri, 16 Sep 2005 14:02:24 
To:moby-dev@biomoby.org
Subject: [MOBY-dev] Schedule? You mean there's a schedule?

Mark,

At 06:47 PM 9/15/2005, moby-dev-request@portal.open-bio.org wrote:
>Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep on schedule.
                                                                                             ^^^^^^^^^^^^

Mark,

So what is thing you call a "schedule"? Where might an interested party 
find it, if so inclined.... :-)

(I know you're on vacay, no rush, just curious/kidding.)

-F


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

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

--
Mark Wilkinson
...on the road!
From senger at ebi.ac.uk  Mon Sep 19 03:30:09 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 19 03:30:23 2005
Subject: [MOBY-dev] jMoby:  caching in CentralImpl
In-Reply-To: <42CEC551.4090108@ucalgary.ca>
Message-ID: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>

Paul (and others),
   I have mentioned in Vancouver that I would like to remove caching from
CentralImpl because we have now probably more powerfull caching in
CentralDigestCachedImpl (which I am improving now), and we will have even
better caching when we implement it based on RDF Resources. You said that
I can go ahead. But I would like to confirm it because removing it from
CentralImpl may break some of your code (or of the others).
   Do I have your green lights?

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Mon Sep 19 03:41:33 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 19 03:41:37 2005
Subject: [MOBY-dev] API for retrieving namespaces insufficient
Message-ID: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>

Mark,
   I know that the registry API can be replaced by its RDF representation,
but it is still an API and we are using it a lot (because for simple
requests it will be always faster than retrieving the whole RDF
document). That's why I would like to make it better. One missing thing
(actually a 'sink' :-)) is that you register some attributes for a
namespace but there is no way to get it back (that's why I said '
sink'). For example, authority. I suggest that you could add it to the
object returned from retrieveNamespaces. Do it for me please...

   Add there something like please:
           <contactEmail>your_name@contact.address.com</contactEmail>
           <authURI>Your.URI.here</authURI>

   Does anybody object?
   If not, could Eddie make it soon please (well, I mean now :-)?

   The same applies, of course, for service types. These two (and, afaik,
only these two) sinks exist in the current API).

   Many thanks,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From dgpisano at cnb.uam.es  Mon Sep 19 05:12:57 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon Sep 19 05:24:50 2005
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <432E8119.4030502@cnb.uam.es>

I'll be glad to represent the INB (aka "The Spanish Contingent") in the 
RFC commitee for a year. Thanks for your invitation,

David

Edward Kawas escribi?:

>-----Original Message-----
>From: mark wilkinson [mailto:markw@illuminae.com] 
>Sent: Thursday, September 15, 2005 3:06 PM
>To: Frank Gibbons; Eddie Kawas
>Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
>Error-handling in MOBY-S
>
>Hey Frank! Cc Eddie
>
>Thanks for riding this.  I am on holiday, and not in Net
>contact except by blackberry, so I'm not "useful" right now.
>
>I think we should put out an invitation on the -dev list for
>the RFC committee with a tenure of one year, but also
>specifically invite the main developers/vested interests to
>be part of it:  me, you, martin, eddie, simon, heiko, paul,
>yan wong, and at least one from the spanish contingent (have
>I missed anyone?).
>
>I don't have all their email addresses on my bberry so
>unless you or Eddie (cc'd) post this invitation to the dev
>list yourselves it may take a week before I am back in
>net-world.  Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep
>on schedule.
>
>M
>
>
>-----Original Message-----
>From: Frank Gibbons <fgibbons@hms.harvard.edu>
>Date: Thu, 15 Sep 2005 11:21:53 
>To:moby-l@biomoby.org
>Subject: [MOBY-l] Using bugzilla to continue RFC on
>Error-handling in MOBY-S
>
>Hi,
>
>I've just added a few "bugs" to the bugzilla, to try to
>preserve the RFC 
>momentum built up over the past few weeks. I propose that,
>although 
>bugzilla is perhaps not ideal for this, it is what it is, it
>is what we 
>have, and it will do for now.
>
>I'd like to propose that we try to continue development of
>this RFC through 
>bugzilla (see bug #1863), rather than through the mailing
>list. Searching 
>through old mail messages (or worse still, through the
>digest, with all of 
>its repeated messages and long inclusions) is tedious, and I
>think 
>contributes to the loss in momentum.
>
>So far, in Martin's scheme for RFC-processing, we have
>(numbers are those 
>used in Martin's original suggestion, now available in the
>codebase as 
>Docs/MOBY-S_API/RFC.html)
>
>1. Had a suggestion made by INB to add this features. It was
>added to 
>bugzilla, No. 1863
>2. Suggested to resolve it by today (Sep-15)
>3. Martin backed up the RFC
>4. I think we have the resources to make this change - it
>seems an 
>essential part of a robust API, which version 1.0 should be.
>5a. List members have exchanged several comments back and
>forth, resulting 
>in amended versions of the RFC being posted to the mailing
>list.
>5b. We've also gotten a little side-tracked by the related
>articleName problem.
>
>So it seems to me that it's time to vote on it (step 6 of
>the Senger 
>seven-step scheme ;-). Martin suggested that Mark would ask
>a limited 
>number of people to vote on it after the resolution date
>(today). I guess 
>those people would self-select, or maybe Mark will select
>them. They will 
>be requested to make a one-year commitment.
>
>After that comes step 7, the "fun part": implementation,
>documentation.
>
>We're pretty close to reaching a conclusion on this. The
>fact is that even 
>if we do nothing, people want this functionality, and they
>WILL implement 
>it. It is in everybody's interest that we have a
>specification for what the 
>functionality should be. It may change over time, but I
>think there has 
>been enough back-and-forth that we have a reasonable first
>draft, and 
>should vote on it.
>
>-Frank
>P.S. Of course, this message, along with version 1.7.1 of
>the RFC is 
>attached to the bug on bugzilla
>
>PhD, Computational Biologist,
>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
>Boston MA 02115, USA.
>Tel: 617-432-3555       Fax: 
>617-432-3557       http://llama.med.harvard.edu/~fgibbons 
>
>_______________________________________________
>moby-l mailing list
>moby-l@biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>--
>Mark Wilkinson
>..on the road!
>
>
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050919/8552b4c0/dgpisano.vcf
From pieter.neerincx at wur.nl  Mon Sep 19 05:41:45 2005
From: pieter.neerincx at wur.nl (Pieter Neerincx)
Date: Mon Sep 19 05:41:54 2005
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
Message-ID: <36612E59-02E5-41BB-842A-EF368649EB2B@wur.nl>

Hi Frank,

On 16-Sep-2005, at 8:04 PM, Frank Gibbons wrote:

> Hi Pieter,
>
> I've updated the tests and some of the Perl code, so that *nothing*  
> should fail now.

Thanks. It's a good thing you already created tests for parts of the  
API that have not been implemented yet. But it's even better that  
those tests don't confuse users anymore :).

> You might see messages about _skip_ped tests, but nothing about  
> "unexpectedly succeed"ing tests, etc. In particular, if Client- 
> Central.t still fails, I'm interested in finding out why.

Client-Central.t is fine now. I also don't know where the '$__val'  
came from. But the tests are not complaining about it anymore :) In  
addition to some messages about skipped tests I do get a warning  
about a non-existing 'bogus NS' in CommonSubs.t. See below for the  
output of the tests. I assume it's safe to ignore that one.

>
> -Frank
>

Cheers,

Pieter


pieter@bioinfw05:~/moby-live/Perl> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Central...................................ok
t/Client-Central............................ok
t/Client-CollectionArticle..................ok
t/Client-OntologyServer.....................ok
         5/39 skipped: relationshipExists not implemented
t/Client-Registration.......................ok
t/Client-SecondaryArticle...................ok
t/Client-Service............................ok
t/Client-ServiceInstance....................ok
t/Client-SimpleArticle......................ok
t/CommonSubs................................ok 18/0MOBY::CommonSubs  
WARNING ** the namespace 'bogus NS' does not exist in the MOBY  
ontology, and does not have a valid LSID
t/CommonSubs................................ok
t/Config....................................skipped
         all skipped: Required only for local MOBY Central
t/CrossReference............................ok
t/dbConnect.................................ok
t/lsid-authority-ClassResolver..............ok
t/lsid-authority-dbConnect..................ok
t/lsid-authority-Error......................ok
t/lsid-authority-NamespaceResolver..........ok
t/lsid-authority-PredicateResolver..........ok
t/lsid-authority-RDFConfigure...............ok
t/lsid-authority-RelationshipResolver.......ok
t/lsid-authority-ServiceInstanceResolver....skipped
         all skipped: Skip until apparent namespace pollution fixed  
in ServiceInstanceResolver
t/lsid-authority-ServiceResolver............ok
t/Template..................................skipped
         all skipped: This is just a template
All tests successful, 3 tests and 5 subtests skipped.
Files=23, Tests=376, 61 wallclock secs ( 4.61 cusr +  0.59 csys =   
5.20 CPU)
From Pieter.Neerincx at wur.nl  Mon Sep 19 09:04:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon Sep 19 09:05:05 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>
References: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>
Message-ID: <7FA8D0EE-81DE-4DF1-95BE-146E5EB55DC6@wur.nl>

Hi Eddie,

I think I'm almost there. When I use the 'old / official' Taverna 1.2  
and manually add a biomoby scavanger for my local central (supplying  
both an URL to my biomoby central registry and my biomoby object RDF  
document) it works. I get both my custom services and custom objects  
listed in Taverna. So the servlets and Tomcat are doing there job.  
But when I use you modified version of Taverna from: http:// 
bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.zip it doesn't  
work. The custom objects are still missing. I updated my biomoby API  
stuff once more today from CVS, but that didn't help.... I was  
wondering if it is necessary to put some additional lines in my  
mobycentral.config file. After browsing the code it seems to me that  
MOBY::Central->retrieveResourceURLs tries to fetch resourceURL and  
allResources lines from that file...

Cheers,

Pieter




On 16-Sep-2005, at 4:14 PM, Edward Kawas wrote:

>> Yes, works perfectly. I get xml/rdf returned and the first
>> two links
>> contain amongst others my custom objects :).
>>
>
> Great! That is good news.
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Mon Sep 19 09:11:25 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 19 09:11:43 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <7FA8D0EE-81DE-4DF1-95BE-146E5EB55DC6@wur.nl>
Message-ID: <432eb8ff.589d431d.4335.2914@mx.gmail.com>

Hi,

> I
> was
> wondering if it is necessary to put some additional lines
> in my
> mobycentral.config file. After browsing the code it seems
> to me that
> MOBY::Central->retrieveResourceURLs tries to fetch
> resourceURL and
> allResources lines from that file...

[mobycentral]
dbname = mobycentral
rdfagent = /usr/local/apache2/MOBY/rdfagent
lsid_authority = biomoby.org
lsid_namespace = serviceinstance
resourceURL =
http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
allResources = http://biomoby.org/RESOURCES/MOBY-S/FULL
 
[mobyobject]
dbname = mobyobject
lsid_authority = biomoby.org
lsid_namespace = objectclass
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Objects

[mobynamespace]
dbname = mobynamespace
lsid_authority = biomoby.org
lsid_namespace = namespacetype
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Namespaces

[mobyservice]
dbname = mobyservice
lsid_authority = biomoby.org
lsid_namespace = servicetype
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Services

[mobyrelationship]
dbname = mobyrelationship
lsid_authority = biomoby.org
#lsid_namespace = relationshiptype

Those are the new lines (as far as I know) that should be
added to the config file.

Eddie

From gordonp at ucalgary.ca  Mon Sep 19 09:02:53 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Mon Sep 19 10:01:01 2005
Subject: [MOBY-dev] jMoby:  caching in CentralImpl
In-Reply-To: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>
Message-ID: <432EB6FD.7070508@ucalgary.ca>

Go ahead.  As long as someone tells me they're going to break my code, 
rather than just doing it, I'm fine :-)

Martin Senger wrote:

>Paul (and others),
>   I have mentioned in Vancouver that I would like to remove caching from
>CentralImpl because we have now probably more powerfull caching in
>CentralDigestCachedImpl (which I am improving now), and we will have even
>better caching when we implement it based on RDF Resources. You said that
>I can go ahead. But I would like to confirm it because removing it from
>CentralImpl may break some of your code (or of the others).
>   Do I have your green lights?
>
>   Cheers,
>   Martin
>
>  
>

From francis_gibbons at hms.harvard.edu  Mon Sep 19 10:44:54 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Mon Sep 19 10:43:51 2005
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <36612E59-02E5-41BB-842A-EF368649EB2B@wur.nl>
References: <5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
Message-ID: <5.2.1.1.2.20050919104414.010eb940@email.med.harvard.edu>

Hi Pieter,

At 05:41 AM 9/19/2005, you wrote:
>Client-Central.t is fine now. I also don't know where the '$__val'
>came from. But the tests are not complaining about it anymore :) In
>addition to some messages about skipped tests I do get a warning
>about a non-existing 'bogus NS' in CommonSubs.t. See below for the
>output of the tests. I assume it's safe to ignore that one.

Yes, it's safe to ignore that one. I'm re-working CommonSubs.pm right now, 
and expect to make that warning message disappear shortly.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

From Pieter.Neerincx at wur.nl  Mon Sep 19 10:46:19 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon Sep 19 10:46:25 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432eb8ff.589d431d.4335.2914@mx.gmail.com>
References: <432eb8ff.589d431d.4335.2914@mx.gmail.com>
Message-ID: <87207568-E348-4B3C-AD12-5F6C69AB1E0D@wur.nl>

Hi Eddie,

On 19-Sep-2005, at 3:11 PM, Edward Kawas wrote:

> Hi,
>
> [mobycentral]
> dbname = mobycentral
> rdfagent = /usr/local/apache2/MOBY/rdfagent
> lsid_authority = biomoby.org
> lsid_namespace = serviceinstance
> resourceURL =
> http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
> allResources = http://biomoby.org/RESOURCES/MOBY-S/FULL
>
> [mobyobject]
> dbname = mobyobject
> lsid_authority = biomoby.org
> lsid_namespace = objectclass
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Objects
>
> [mobynamespace]
> dbname = mobynamespace
> lsid_authority = biomoby.org
> lsid_namespace = namespacetype
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>
> [mobyservice]
> dbname = mobyservice
> lsid_authority = biomoby.org
> lsid_namespace = servicetype
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Services
>
> [mobyrelationship]
> dbname = mobyrelationship
> lsid_authority = biomoby.org
> #lsid_namespace = relationshiptype
>
> Those are the new lines (as far as I know) that should be
> added to the config file.

Thanks, I already guessed some of the URLs, but not all of them :). I  
created a small Perl script to test MOBY::Client::Central- 
 >retrieveResourceURLs. This works now, but unfortunately still no  
fun with Taverna. When I start Taverna with my local central appended  
in the mygrid.properties file, nothing happens: no custom objects  
form my local central and also no error messages. When I add my local  
central manually using right-click->add new biomoby scavanger, I got  
the error below. Taverna complains it can't process the RDF document  
for the biomoby objects :(. So I pointed my browser to the URL for  
the biomoby objects RDF file and had a look: The RDF looks pretty  
normal, but I did notice <cr> elements and the xml parser fails on  
those. (Do you happen to develop on a windows machine?) So I stripped  
the carriage returns from RDF objects file, saved it and changed the  
URL for the objects RDF to this static file: tada.... That finally  
got the show on the road :).

Cheers,

Pieter

Taverna command line error messages:
---------------------------------------
Creating biomoby scavenger : 'https://bioinfw05/phenolink/biomoby/ 
central/cgi-bin/MOBY-Central.pl'
ERROR                                      2005-09-19 16:01:16,854  
(com.hp.hpl.jena.rdf.model.impl.RDFDefaultErrorHandler:44) - http:// 
www.w3.org/TR/html4/loose.dtd[31:3]: {E301} The declaration for the  
entity "HTML.Version" must end with '>'.
Failed: rethrew: com.hp.hpl.jena.rdf.arp.ParseException: {E301} The  
declaration for the entity "HTML.Version" must end with '>'.
[Ljava.lang.StackTraceElement;@c9f71b
org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException:  
Could not retrieve and or process RDF document for BioMoby Objects
         at org.biomoby.client.taverna.plugin.BiomobyScavenger.<init> 
(BiomobyScavenger.java:95)
         at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper 
$2.actionPerformed(BiomobyScavengerHelper.java:83)
         at javax.swing.AbstractButton.fireActionPerformed 
(AbstractButton.java:1786)
         at javax.swing.AbstractButton 
$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
         at javax.swing.DefaultButtonModel.fireActionPerformed 
(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed 
(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased 
(BasicButtonListener.java:245)
         at java.awt.Component.processMouseEvent(Component.java:5100)
         at java.awt.Component.processEvent(Component.java:4897)
         at java.awt.Container.processEvent(Container.java:1569)
         at java.awt.Component.dispatchEventImpl(Component.java:3615)
         at java.awt.Container.dispatchEventImpl(Container.java:1627)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.LightweightDispatcher.retargetMouseEvent 
(Container.java:3483)
         at java.awt.LightweightDispatcher.processMouseEvent 
(Container.java:3198)
         at java.awt.LightweightDispatcher.dispatchEvent 
(Container.java:3128)
         at java.awt.Container.dispatchEventImpl(Container.java:1613)
         at java.awt.Window.dispatchEventImpl(Window.java:1606)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy 
(EventDispatchThread.java:201)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:151)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:141)
         at java.awt.Dialog$1.run(Dialog.java:540)
         at java.awt.Dialog.show(Dialog.java:561)
         at java.awt.Component.show(Component.java:1133)
         at java.awt.Component.setVisible(Component.java:1088)
         at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper 
$1.actionPerformed(BiomobyScavengerHelper.java:119)
         at javax.swing.AbstractButton.fireActionPerformed 
(AbstractButton.java:1786)
         at javax.swing.AbstractButton 
$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
         at javax.swing.DefaultButtonModel.fireActionPerformed 
(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed 
(DefaultButtonModel.java:258)
         at javax.swing.AbstractButton.doClick(AbstractButton.java:289)
         at javax.swing.plaf.basic.BasicMenuItemUI.doClick 
(BasicMenuItemUI.java:1113)
         at javax.swing.plaf.basic.BasicMenuItemUI 
$MouseInputHandler.mouseReleased(BasicMenuItemUI.java:943)
         at java.awt.Component.processMouseEvent(Component.java:5100)
         at java.awt.Component.processEvent(Component.java:4897)
         at java.awt.Container.processEvent(Container.java:1569)
         at java.awt.Component.dispatchEventImpl(Component.java:3615)
         at java.awt.Container.dispatchEventImpl(Container.java:1627)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.LightweightDispatcher.retargetMouseEvent 
(Container.java:3483)
         at java.awt.LightweightDispatcher.processMouseEvent 
(Container.java:3198)
         at java.awt.LightweightDispatcher.dispatchEvent 
(Container.java:3128)
         at java.awt.Container.dispatchEventImpl(Container.java:1613)
         at java.awt.Window.dispatchEventImpl(Window.java:1606)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy 
(EventDispatchThread.java:201)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:151)
         at java.awt.EventDispatchThread.pumpEvents 
(EventDispatchThread.java:145)
         at java.awt.EventDispatchThread.pumpEvents 
(EventDispatchThread.java:137)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java: 
100)
Caused by: java.lang.NullPointerException
         at org.biomoby.client.taverna.plugin.BiomobyScavenger.<init> 
(BiomobyScavenger.java:92)
         ... 52 more
---------------------------------------



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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Mon Sep 19 10:51:38 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 19 10:51:39 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <87207568-E348-4B3C-AD12-5F6C69AB1E0D@wur.nl>
Message-ID: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>

> Could not retrieve and or process RDF document for BioMoby
> Objects
Can I have your Moby endpoint so that I can test this? I am
not sure why the carriage returns are present.

Eddie

From Pieter.Neerincx at wur.nl  Mon Sep 19 11:06:03 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon Sep 19 11:06:28 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>
References: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>
Message-ID: <3794C121-8E2C-4B0B-BC41-3537752A5085@wur.nl>


On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:

>> Could not retrieve and or process RDF document for BioMoby
>> Objects
>>
> Can I have your Moby endpoint so that I can test this?

Sure!

This is what I use on my development box:

     https://bioinfw05/phenolink/biomoby/central/cgi-bin/MOBY-Central.pl

But it doesn't have a DNS entry, so you might try this:

     https://137.224.52.237/phenolink/biomoby/central/cgi-bin/MOBY- 
Central.pl

My RDF for the objects is at (not sure whether this one will work  
from outside our firewall...):

     https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects

Hope this helps.

Pieter


> I am
> not sure why the carriage returns are present.
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Mon Sep 19 11:20:02 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 19 11:47:41 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <3794C121-8E2C-4B0B-BC41-3537752A5085@wur.nl>
Message-ID: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>

Hi,

I can't connect to those URLS or endpoints (I timeout).

I will try to find the bug by eyeballing it. If you can
think of another way that I can access your endpoint, please
let me know.

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 19, 2005 8:06 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> 
> On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:
> 
> >> Could not retrieve and or process RDF document for
> BioMoby
> >> Objects
> >>
> > Can I have your Moby endpoint so that I can test this?
> 
> Sure!
> 
> This is what I use on my development box:
> 
>      https://bioinfw05/phenolink/biomoby/central/cgi-
> bin/MOBY-Central.pl
> 
> But it doesn't have a DNS entry, so you might try this:
> 
>      https://137.224.52.237/phenolink/biomoby/central/cgi-
> bin/MOBY-
> Central.pl
> 
> My RDF for the objects is at (not sure whether this one
> will work
> from outside our firewall...):
> 
>      https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects
> 
> Hope this helps.
> 
> Pieter
> 
> 
> > I am
> > not sure why the carriage returns are present.
> >
> > Eddie
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From markw at illuminae.com  Mon Sep 19 11:02:51 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon Sep 19 15:51:08 2005
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure
	of	one year
In-Reply-To: <432E8119.4030502@cnb.uam.es>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
	<432E8119.4030502@cnb.uam.es>
Message-ID: <432ED31B.8000303@illuminae.com>

Thanks David!

Just to clarify, "the Spanish Contingent" was not meant to be insulting 
in any way (nor even forwarded to the mailing list at all) - there are 
just a lot of you using Moby in Spain, between INB and Alfonso's group, 
etc., so I didn't know who/how many would want to join this committee, 
so I just referred to you as a group in a private message to Eddie, 
which he then forwarded to the mailing list :-)

M



David Gonz?lez Pisano wrote:

> I'll be glad to represent the INB (aka "The Spanish Contingent") in 
> the RFC commitee for a year. Thanks for your invitation,
>
> David
>
> Edward Kawas escribi?:
>
>> -----Original Message-----
>> From: mark wilkinson [mailto:markw@illuminae.com] Sent: Thursday, 
>> September 15, 2005 3:06 PM
>> To: Frank Gibbons; Eddie Kawas
>> Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
>> Error-handling in MOBY-S
>>
>> Hey Frank! Cc Eddie
>>
>> Thanks for riding this.  I am on holiday, and not in Net
>> contact except by blackberry, so I'm not "useful" right now.
>>
>> I think we should put out an invitation on the -dev list for
>> the RFC committee with a tenure of one year, but also
>> specifically invite the main developers/vested interests to
>> be part of it:  me, you, martin, eddie, simon, heiko, paul,
>> yan wong, and at least one from the spanish contingent (have
>> I missed anyone?).
>>
>> I don't have all their email addresses on my bberry so
>> unless you or Eddie (cc'd) post this invitation to the dev
>> list yourselves it may take a week before I am back in
>> net-world.  Eddie, could you do this? Tomorrow or this
>> afternoon?  It would be good to get this sorted asap to keep
>> on schedule.
>>
>> M
>>
>>
>> -----Original Message-----
>> From: Frank Gibbons <fgibbons@hms.harvard.edu>
>> Date: Thu, 15 Sep 2005 11:21:53 To:moby-l@biomoby.org
>> Subject: [MOBY-l] Using bugzilla to continue RFC on
>> Error-handling in MOBY-S
>>
>> Hi,
>>
>> I've just added a few "bugs" to the bugzilla, to try to
>> preserve the RFC momentum built up over the past few weeks. I propose 
>> that,
>> although bugzilla is perhaps not ideal for this, it is what it is, it
>> is what we have, and it will do for now.
>>
>> I'd like to propose that we try to continue development of
>> this RFC through bugzilla (see bug #1863), rather than through the 
>> mailing
>> list. Searching through old mail messages (or worse still, through the
>> digest, with all of its repeated messages and long inclusions) is 
>> tedious, and I
>> think contributes to the loss in momentum.
>>
>> So far, in Martin's scheme for RFC-processing, we have
>> (numbers are those used in Martin's original suggestion, now 
>> available in the
>> codebase as Docs/MOBY-S_API/RFC.html)
>>
>> 1. Had a suggestion made by INB to add this features. It was
>> added to bugzilla, No. 1863
>> 2. Suggested to resolve it by today (Sep-15)
>> 3. Martin backed up the RFC
>> 4. I think we have the resources to make this change - it
>> seems an essential part of a robust API, which version 1.0 should be.
>> 5a. List members have exchanged several comments back and
>> forth, resulting in amended versions of the RFC being posted to the 
>> mailing
>> list.
>> 5b. We've also gotten a little side-tracked by the related
>> articleName problem.
>>
>> So it seems to me that it's time to vote on it (step 6 of
>> the Senger seven-step scheme ;-). Martin suggested that Mark would ask
>> a limited number of people to vote on it after the resolution date
>> (today). I guess those people would self-select, or maybe Mark will 
>> select
>> them. They will be requested to make a one-year commitment.
>>
>> After that comes step 7, the "fun part": implementation,
>> documentation.
>>
>> We're pretty close to reaching a conclusion on this. The
>> fact is that even if we do nothing, people want this functionality, 
>> and they
>> WILL implement it. It is in everybody's interest that we have a
>> specification for what the functionality should be. It may change 
>> over time, but I
>> think there has been enough back-and-forth that we have a reasonable 
>> first
>> draft, and should vote on it.
>>
>> -Frank
>> P.S. Of course, this message, along with version 1.7.1 of
>> the RFC is attached to the bug on bugzilla
>>
>> PhD, Computational Biologist,
>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
>> Boston MA 02115, USA.
>> Tel: 617-432-3555       Fax: 617-432-3557       
>> http://llama.med.harvard.edu/~fgibbons
>> _______________________________________________
>> moby-l mailing list
>> moby-l@biomoby.org
>> http://biomoby.org/mailman/listinfo/moby-l
>>
>> -- 
>> Mark Wilkinson
>> ..on the road!
>>
>>
>>
>>  
>>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>

From senger at ebi.ac.uk  Tue Sep 20 04:50:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Sep 20 04:50:37 2005
Subject: [MOBY-dev] jMoby: new document on Eclipse & jMoby
Message-ID: <Pine.OSF.4.21.0509200948290.851399-100000@ice.ebi.ac.uk>

...is available at
http://biomoby.org/moby-live/Java/docs/EclipseAndJMoby.html. I welcome all
comments and suggestion to improve it, or to correct it.

Cheers,
Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Wed Sep 21 04:55:52 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Sep 21 04:57:27 2005
Subject: [MOBY-dev] jMoby: a new document about jMoby & Windows
Message-ID: <Pine.OSF.4.21.0509210949260.629792-100000@ice.ebi.ac.uk>

...was added:
   http://biomoby.org/moby-live/Java/docs/WindowsAndJMoby.html

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)


From francis_gibbons at hms.harvard.edu  Wed Sep 21 16:41:41 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Wed Sep 21 16:41:05 2005
Subject: [MOBY-dev] Purpose of complexResponse?
Message-ID: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>

Hi,

I'm trying to come up with some tests for complexResponse, part of 
MOBY::CommonSubs.pm. The part that's hard is trying to envisage what kind 
of service might return such a response, since it appears that it contains 
both Simple and Collection items. Anyone got any examples of what that 
might look like?

Also, what's the next step with the RFC on error-reporting? Actually, the 
next step *is* to vote, but the question is "when?"

-Frank


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

From markw at illuminae.com  Wed Sep 21 17:20:35 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 21 18:21:28 2005
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
Message-ID: <4331CEA3.6020205@illuminae.com>

Hello from Montreal!

The RFC committee consists of:

Frank
Martin
Eddie
David
Mark

I don't think we heard from Heiko, Yan, or Paul...  (??)  We also didn't 
get any other volunteers (unless I have missed a message while I was 
away)  In the interim, and just to keep the ball rolling, let's call the 
vote on RFC 1863.   I'll send out a message with the apprpriate subject 
line in a couple of minutes.  If other members join in time, they can 
vote also.

M


>

From edward.kawas at gmail.com  Wed Sep 21 19:58:20 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed Sep 21 20:05:42 2005
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
Message-ID: <4331f39d.2009e53e.6a06.1d2d@mx.gmail.com>

> I'll send out a message with the
> apprpriate subject
> line in a couple of minutes.

Did you forget to press send ;-)

From markw at illuminae.com  Wed Sep 21 20:18:24 2005
From: markw at illuminae.com (mark wilkinson)
Date: Wed Sep 21 20:22:23 2005
Subject: [MOBY-dev] RFC Committee  Membership last call...
Message-ID: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell01>

I don't think so... I'm pretty surer I sent it...??

M


-----Original Message-----
From: "Edward Kawas" <edward.kawas@gmail.com>
Date: Wed, 21 Sep 2005 16:58:20 
To:"'Core developer announcements'" <moby-dev@portal.open-bio.org>
Subject: RE: [MOBY-dev] RFC Committee  Membership last call...

> I'll send out a message with the
> apprpriate subject
> line in a couple of minutes.

Did you forget to press send ;-)

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

--
Mark Wilkinson
...on the road!
From markw at illuminae.com  Wed Sep 21 17:30:44 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 21 20:31:58 2005
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <4331D104.9010308@illuminae.com>

Regarding RFC #1863 Error Handling in MOBY-S

http://bugzilla.open-bio.org/show_bug.cgi?id=1863

The vote has been called.  Voting members may vote by adding their YES 
(accept)  or NO (do not accept) to the comments history  through Bugzilla

Voting ends Sept 26th

M

From Pieter.Neerincx at wur.nl  Thu Sep 22 04:01:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu Sep 22 04:03:37 2005
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <DBF151CE-AA3A-4EF3-97E4-1081641D6AF3@wur.nl>


On  21Sep2005, at 23:20, Mark Wilkinson wrote:

> We also didn't get any other volunteers (unless I have missed a  
> message while I was away)  In the interim, and just to keep the  
> ball rolling, let's call the vote on RFC 1863.   I'll send out a  
> message with the apprpriate subject line in a couple of minutes.   
> If other members join in time, they can vote also.

I'm a big fan of democracy, so where do I join?

I like the proposal :) Found one error in the documentation though.  
In section 3 "Raising exceptions for Simples inside a Collection  
(optional proposal extension)" the text mentions an refarticleName  
attribute that links to the corresponding erroneous Simple inside a  
Collection. If that is correct, the corresponding example in table 6  
is wrong. The example lists refElement tags, but I can not find any  
refarticleName attributes in there...

Pi


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

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1038
Dreijenlaan 3
6703 HA Wageningen
phone: 0317-484 706
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl

From senger at ebi.ac.uk  Thu Sep 22 06:38:14 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 22 06:40:39 2005
Subject: [MOBY-dev] jMoby: deploymnt added to Moses
Message-ID: <Pine.OSF.4.21.0509221132050.1329336-100000@mozart.ebi.ac.uk>

I have added the last remaining piece to the Moses mosaic: the deployment
of services. The new document describing it is:

http://biomoby.org/moby-live/Java/docs/Moses-deploy.html

Recently, I also fixed some bugs in Moses (and in jMoby Ant generally),
mostly solving incompatibility on Windows platform. As far as I am aware,
things now work on Windows as well.

Cheers,
Martin

-- 
Martin Senger
   email: martin.senger@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)

From ywong at infobiogen.fr  Thu Sep 22 09:36:46 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Thu Sep 22 10:06:41 2005
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <51700.170.252.64.1.1127396206.squirrel@170.252.64.1>

Hello from a street near the Eiffel Tower,

  Just let me some time to read the RFC ...

  I am now working for Accenture Technology Solutions. As I am no longer
commited to any biomoby related project or any bioinformatics project,
it has become increasingly difficult to follow the changes (I use the
remain of my spare time :D)

  Anyway, I'll do my best to solve problems (even if I believe the Python
API to be "stable") and update he API but expect progress to be VERY
SLOW .

  Cheers.

Yan


> Hello from Montreal!
>
> The RFC committee consists of:
>
> Frank
> Martin
> Eddie
> David
> Mark
>
> I don't think we heard from Heiko, Yan, or Paul...  (??)  We also didn't
> get any other volunteers (unless I have missed a message while I was
> away)  In the interim, and just to keep the ball rolling, let's call the
> vote on RFC 1863.   I'll send out a message with the apprpriate subject
> line in a couple of minutes.  If other members join in time, they can
> vote also.
>
> M
>
>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


From senger at ebi.ac.uk  Thu Sep 22 10:49:59 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 22 10:50:14 2005
Subject: [MOBY-dev] is findService(0 case sensitive?
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509221545570.1329336-100000@mozart.ebi.ac.uk>

Mark,
   You told me once that everything in Biomoby is case sensitive (that was
in time when I played with idea to allow case insensitivness but then
stepped back because of Blast's secondary parameters 'e' and 'E').
   Now I see that findService seems to be case insensitive. When I ask for
service getProteinSequence I get two services: getProteinSequence and
GetProteinSequence.
   So what is true? Whatever it is could you tell us and add it to the API
please?

   Cheers,
   Martin

PS. Pending answer about retrieving namespaces... :-)
M.

-- 
Martin Senger
   email: martin.senger@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)

From markw at illuminae.com  Thu Sep 22 11:21:07 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu Sep 22 11:23:38 2005
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
Message-ID: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>


MOBY is intended to be case sensitive.  What you are seeing is likely a consequence of mySQL not being case sensitive, and moby central not double-checking the output of the query.

That's a frustrating bug, since it means I need to post-filter every query :-/

I wonder if there is a flag in mysql that makes the searches case sensitive?

I'll look into it when I get back to Vancouver.  For the moment, code on the assumption that it *is* case sensitive, since that's the intention.

M


-----Original Message-----
From: Martin Senger <senger@ebi.ac.uk>
Date: Thu, 22 Sep 2005 15:49:59 
To:Mark Wilkinson <markw@illuminae.com>
Cc:mobydev <moby-dev@biomoby.org>
Subject: is findService(0 case sensitive?

Mark,
   You told me once that everything in Biomoby is case sensitive (that was
in time when I played with idea to allow case insensitivness but then
stepped back because of Blast's secondary parameters 'e' and 'E').
   Now I see that findService seems to be case insensitive. When I ask for
service getProteinSequence I get two services: getProteinSequence and
GetProteinSequence.
   So what is true? Whatever it is could you tell us and add it to the API
please?

   Cheers,
   Martin

PS. Pending answer about retrieving namespaces... :-)
M.

-- 
Martin Senger
   email: martin.senger@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)


--
Mark Wilkinson
...on the road!
From senger at ebi.ac.uk  Thu Sep 22 11:31:34 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 22 11:34:52 2005
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>
Message-ID: <Pine.OSF.4.21.0509221626160.1329336-100000@mozart.ebi.ac.uk>

Thanks for the fast reply and please don't worry now. I forgot that you
were still away. Sorry for that.

Okay, I will be coding as for case sensitivity. Thanks.
Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Thu Sep 22 11:53:13 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu Sep 22 11:53:10 2005
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>
Message-ID: <4332d36b.5ae1c862.28fe.fffff8aa@mx.gmail.com>

Hi Mark,

I spent a while looking around, but the following query is
case sensitive (tested on our db)

select * from service_instance where servicename LIKE binary
'getProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'GetProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'getproteinsequence';

returns empty

Eddie
> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:21 AM
> To: Martin Senger; Mark Wilkinson
> Cc: mobydev
> Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> 
> 
> MOBY is intended to be case sensitive.  What you are
> seeing is likely a consequence of mySQL not being case
> sensitive, and moby central not double-checking the output
> of the query.
> 
> That's a frustrating bug, since it means I need to post-
> filter every query :-/
> 
> I wonder if there is a flag in mysql that makes the
> searches case sensitive?
> 
> I'll look into it when I get back to Vancouver.  For the
> moment, code on the assumption that it *is* case
sensitive,
> since that's the intention.
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger@ebi.ac.uk>
> Date: Thu, 22 Sep 2005 15:49:59
> To:Mark Wilkinson <markw@illuminae.com>
> Cc:mobydev <moby-dev@biomoby.org>
> Subject: is findService(0 case sensitive?
> 
> Mark,
>    You told me once that everything in Biomoby is case
> sensitive (that was
> in time when I played with idea to allow case
> insensitivness but then
> stepped back because of Blast's secondary parameters 'e'
> and 'E').
>    Now I see that findService seems to be case
insensitive.
> When I ask for
> service getProteinSequence I get two services:
> getProteinSequence and
> GetProteinSequence.
>    So what is true? Whatever it is could you tell us and
> add it to the API
> please?
> 
>    Cheers,
>    Martin
> 
> PS. Pending answer about retrieving namespaces... :-)
> M.
> 
> --
> Martin Senger
>    email: martin.senger@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)
> 
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From markw at illuminae.com  Thu Sep 22 11:53:10 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu Sep 22 11:55:17 2005
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
Message-ID: <327837899-1127404527-cardhu_blackberry.rim.net-13073-@engine12-cell01>

Excellent!  Can you look into the adaptor layer (mysql.pm) and add the "binary" tag to that query?

Thanks!

M

-----Original Message-----
From: "Edward Kawas" <edward.kawas@gmail.com>
Date: Thu, 22 Sep 2005 08:53:13 
To:<markw@illuminae.com>,       "'Core developer announcements'" <moby-dev@portal.open-bio.org>
Subject: RE: [MOBY-dev] Re: is findService(0 case sensitive?

Hi Mark,

I spent a while looking around, but the following query is
case sensitive (tested on our db)

select * from service_instance where servicename LIKE binary
'getProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'GetProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'getproteinsequence';

returns empty

Eddie
> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:21 AM
> To: Martin Senger; Mark Wilkinson
> Cc: mobydev
> Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> 
> 
> MOBY is intended to be case sensitive.  What you are
> seeing is likely a consequence of mySQL not being case
> sensitive, and moby central not double-checking the output
> of the query.
> 
> That's a frustrating bug, since it means I need to post-
> filter every query :-/
> 
> I wonder if there is a flag in mysql that makes the
> searches case sensitive?
> 
> I'll look into it when I get back to Vancouver.  For the
> moment, code on the assumption that it *is* case
sensitive,
> since that's the intention.
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger@ebi.ac.uk>
> Date: Thu, 22 Sep 2005 15:49:59
> To:Mark Wilkinson <markw@illuminae.com>
> Cc:mobydev <moby-dev@biomoby.org>
> Subject: is findService(0 case sensitive?
> 
> Mark,
>    You told me once that everything in Biomoby is case
> sensitive (that was
> in time when I played with idea to allow case
> insensitivness but then
> stepped back because of Blast's secondary parameters 'e'
> and 'E').
>    Now I see that findService seems to be case
insensitive.
> When I ask for
> service getProteinSequence I get two services:
> getProteinSequence and
> GetProteinSequence.
>    So what is true? Whatever it is could you tell us and
> add it to the API
> please?
> 
>    Cheers,
>    Martin
> 
> PS. Pending answer about retrieving namespaces... :-)
> M.
> 
> --
> Martin Senger
>    email: martin.senger@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)
> 
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

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

--
Mark Wilkinson
...on the road!
From senger at ebi.ac.uk  Thu Sep 22 11:59:21 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu Sep 22 11:59:16 2005
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <4332d36b.5ae1c862.28fe.fffff8aa@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509221657400.1329336-100000@mozart.ebi.ac.uk>

Well, I think that I was asking a wrong question. I am sorry about
that. It turned out that the two services [g|G]etProteinSequence are from
two different authorities.

Mea culpa, mea maxima culpa.

Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Thu Sep 22 11:57:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu Sep 22 12:05:40 2005
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <327837899-1127404527-cardhu_blackberry.rim.net-13073-@engine12-cell01>
Message-ID: <4332d483.555cc870.2d33.0d85@mx.gmail.com>

Sure, the only query is for getting service instance names
right?

Eddie



> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:53 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Re: is findService(0 case
> sensitive?
> 
> Excellent!  Can you look into the adaptor layer (mysql.pm)
> and add the "binary" tag to that query?
> 
> Thanks!
> 
> M
> 
> -----Original Message-----
> From: "Edward Kawas" <edward.kawas@gmail.com>
> Date: Thu, 22 Sep 2005 08:53:13
> To:<markw@illuminae.com>,       "'Core developer
> announcements'" <moby-dev@portal.open-bio.org>
> Subject: RE: [MOBY-dev] Re: is findService(0 case
> sensitive?
> 
> Hi Mark,
> 
> I spent a while looking around, but the following query is
> case sensitive (tested on our db)
> 
> select * from service_instance where servicename LIKE
> binary
> 'getProteinSequence';
> 
> returns 1 instance
> 
> select * from service_instance where servicename LIKE
> binary
> 'GetProteinSequence';
> 
> returns 1 instance
> 
> select * from service_instance where servicename LIKE
> binary
> 'getproteinsequence';
> 
> returns empty
> 
> Eddie
> > -----Original Message-----
> > From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> > dev-bounces@portal.open-bio.org] On Behalf Of mark
> > wilkinson
> > Sent: Thursday, September 22, 2005 8:21 AM
> > To: Martin Senger; Mark Wilkinson
> > Cc: mobydev
> > Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> >
> >
> > MOBY is intended to be case sensitive.  What you are
> > seeing is likely a consequence of mySQL not being case
> > sensitive, and moby central not double-checking the
> output
> > of the query.
> >
> > That's a frustrating bug, since it means I need to post-
> > filter every query :-/
> >
> > I wonder if there is a flag in mysql that makes the
> > searches case sensitive?
> >
> > I'll look into it when I get back to Vancouver.  For the
> > moment, code on the assumption that it *is* case
> sensitive,
> > since that's the intention.
> >
> > M
> >
> >
> > -----Original Message-----
> > From: Martin Senger <senger@ebi.ac.uk>
> > Date: Thu, 22 Sep 2005 15:49:59
> > To:Mark Wilkinson <markw@illuminae.com>
> > Cc:mobydev <moby-dev@biomoby.org>
> > Subject: is findService(0 case sensitive?
> >
> > Mark,
> >    You told me once that everything in Biomoby is case
> > sensitive (that was
> > in time when I played with idea to allow case
> > insensitivness but then
> > stepped back because of Blast's secondary parameters 'e'
> > and 'E').
> >    Now I see that findService seems to be case
> insensitive.
> > When I ask for
> > service getProteinSequence I get two services:
> > getProteinSequence and
> > GetProteinSequence.
> >    So what is true? Whatever it is could you tell us and
> > add it to the API
> > please?
> >
> >    Cheers,
> >    Martin
> >
> > PS. Pending answer about retrieving namespaces... :-)
> > M.
> >
> > --
> > Martin Senger
> >    email: martin.senger@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)
> >
> >
> > --
> > Mark Wilkinson
> > ...on the road!
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From senger at ebi.ac.uk  Fri Sep 23 12:32:07 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 23 12:31:58 2005
Subject: [MOBY-dev] adding Comparable to MobyDataType class
Message-ID: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>

Eddie (and the others),
   I plan to add 'implements Comparable' to MobyDataType (and perhaps also
to MobyService and MobyNamespace) - just to make it easier to sort.
   I noticed that your Registration class inherits from MobyDataType. I do
not think that this new interface would harm it - but better to ask
first. Do you know about any bad consequences if I add there this
interface?

   Thanks,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Fri Sep 23 12:34:31 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri Sep 23 12:58:32 2005
Subject: [MOBY-dev] RE: adding Comparable to MobyDataType class
In-Reply-To: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
Message-ID: <43342e9a.335a05df.2465.6864@mx.gmail.com>

Hi Martin,

I don't thnk that it will hurt me.

Eddie

> -----Original Message-----
> From: Martin Senger [mailto:senger@ebi.ac.uk]
> Sent: Friday, September 23, 2005 9:32 AM
> To: Edward Kawas
> Cc: Moby Developers
> Subject: adding Comparable to MobyDataType class
> 
> Eddie (and the others),
>    I plan to add 'implements Comparable' to MobyDataType
> (and perhaps also
> to MobyService and MobyNamespace) - just to make it easier
> to sort.
>    I noticed that your Registration class inherits from
> MobyDataType. I do
> not think that this new interface would harm it - but
> better to ask
> first. Do you know about any bad consequences if I add
> there this
> interface?
> 
>    Thanks,
>    Martin
> 
> --
> Martin Senger
>    email: martin.senger@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)

From francis_gibbons at hms.harvard.edu  Fri Sep 16 08:47:10 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Fri Sep 23 13:36:24 2005
Subject: [MOBY-dev] RE: invitation for the RFC committee with a tenure of
	one year
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C01@MAILSERVER02.MED.HARVARD.EDU>

Thanks for the invitation, Eddie & Mark. I'm glad to be part of this, excited that we've gotten this far and looking to completing our first formal RFC.
 
-Frank

	-----Original Message----- 
	From: Edward Kawas [mailto:edward.kawas@gmail.com] 
	Sent: Thu 9/15/2005 6:46 PM 
	To: 'Moby Developers' 
	Cc: 'Martin Senger'; 'Eddie Kawas'; 'Twigger Simon'; 'Paul Gordon'; ywong@infobiogen.fr; schoof@mpiz-koeln.mpg.de; Gibbons, Francis ; dgpisano@cnb.uam.es 
	Subject: invitation for the RFC committee with a tenure of one year
	
	



	-----Original Message-----
	From: mark wilkinson [mailto:markw@illuminae.com]
	Sent: Thursday, September 15, 2005 3:06 PM
	To: Frank Gibbons; Eddie Kawas
	Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
	Error-handling in MOBY-S
	
	Hey Frank! Cc Eddie
	
	Thanks for riding this.  I am on holiday, and not in Net
	contact except by blackberry, so I'm not "useful" right now.
	
	I think we should put out an invitation on the -dev list for
	the RFC committee with a tenure of one year, but also
	specifically invite the main developers/vested interests to
	be part of it:  me, you, martin, eddie, simon, heiko, paul,
	yan wong, and at least one from the spanish contingent (have
	I missed anyone?).
	
	I don't have all their email addresses on my bberry so
	unless you or Eddie (cc'd) post this invitation to the dev
	list yourselves it may take a week before I am back in
	net-world.  Eddie, could you do this? Tomorrow or this
	afternoon?  It would be good to get this sorted asap to keep
	on schedule.
	
	M
	
	
	-----Original Message-----
	From: Frank Gibbons <fgibbons@hms.harvard.edu>
	Date: Thu, 15 Sep 2005 11:21:53
	To:moby-l@biomoby.org
	Subject: [MOBY-l] Using bugzilla to continue RFC on
	Error-handling in MOBY-S
	
	Hi,
	
	I've just added a few "bugs" to the bugzilla, to try to
	preserve the RFC
	momentum built up over the past few weeks. I propose that,
	although
	bugzilla is perhaps not ideal for this, it is what it is, it
	is what we
	have, and it will do for now.
	
	I'd like to propose that we try to continue development of
	this RFC through
	bugzilla (see bug #1863), rather than through the mailing
	list. Searching
	through old mail messages (or worse still, through the
	digest, with all of
	its repeated messages and long inclusions) is tedious, and I
	think
	contributes to the loss in momentum.
	
	So far, in Martin's scheme for RFC-processing, we have
	(numbers are those
	used in Martin's original suggestion, now available in the
	codebase as
	Docs/MOBY-S_API/RFC.html)
	
	1. Had a suggestion made by INB to add this features. It was
	added to
	bugzilla, No. 1863
	2. Suggested to resolve it by today (Sep-15)
	3. Martin backed up the RFC
	4. I think we have the resources to make this change - it
	seems an
	essential part of a robust API, which version 1.0 should be.
	5a. List members have exchanged several comments back and
	forth, resulting
	in amended versions of the RFC being posted to the mailing
	list.
	5b. We've also gotten a little side-tracked by the related
	articleName problem.
	
	So it seems to me that it's time to vote on it (step 6 of
	the Senger
	seven-step scheme ;-). Martin suggested that Mark would ask
	a limited
	number of people to vote on it after the resolution date
	(today). I guess
	those people would self-select, or maybe Mark will select
	them. They will
	be requested to make a one-year commitment.
	
	After that comes step 7, the "fun part": implementation,
	documentation.
	
	We're pretty close to reaching a conclusion on this. The
	fact is that even
	if we do nothing, people want this functionality, and they
	WILL implement
	it. It is in everybody's interest that we have a
	specification for what the
	functionality should be. It may change over time, but I
	think there has
	been enough back-and-forth that we have a reasonable first
	draft, and
	should vote on it.
	
	-Frank
	P.S. Of course, this message, along with version 1.7.1 of
	the RFC is
	attached to the bug on bugzilla
	
	PhD, Computational Biologist,
	Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
	Boston MA 02115, USA.
	Tel: 617-432-3555       Fax:
	617-432-3557       http://llama.med.harvard.edu/~fgibbons
	
	_______________________________________________
	moby-l mailing list
	moby-l@biomoby.org
	http://biomoby.org/mailman/listinfo/moby-l
	
	--
	Mark Wilkinson
	..on the road!
	
	


From francis_gibbons at hms.harvard.edu  Fri Sep 16 10:26:56 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Fri Sep 23 13:36:27 2005
Subject: [MOBY-dev] Failing tests in the Perl API.
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>

Pieter,
 
I wrote many of the tests for the  Perl API. When I run them, I see a 99% pass rate, or better. I'm very interested to know which ones are failing for you, and what your local installation looks like (I guess you have a local registry? what's your OS? Perl version? etc.) Clearly, we should have a test suite that passes for most developers most of the time, so that they can be alerted quickly if they break something. So it's really important for me to know which tests are failing and why: the tests may need to be rewritten.
 
Thanks for your feedback.
 
-Frank

	-----Original Message----- 
	From: moby-dev-bounces@portal.open-bio.org on behalf of Edward Kawas 
	Sent: Fri 9/16/2005 9:54 AM 
	To: 'Core developer announcements' 
	Cc: 'Pieter Neerincx' 
	Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come from?
	
	

	>I assume I need to update my BioMOBY API stuff as 
	>well. So I tried an cvs up -d of moby-live. When I try make
	>test for the Perl stuff I see a lot of tests failing....
	>Can I safely ignore them for now?
	
	I am not sure about this question. I know that Mark has a
	new test suite but I am not sure if this is the suite that
	you are running.
	
	One more thing, if the servlets work, you would be able to
	do the following:
	http://yourURL:port/types/Objects
	http://yourURL:port/RESOURCES/MOBY-S/Objects
	http://yourURL:port/authority
	
	These 3 links should show you something meaningful (html, a
	file, more html).
	
	Eddie
	
	_______________________________________________
	MOBY-dev mailing list
	MOBY-dev@biomoby.org
	http://www.biomoby.org/mailman/listinfo/moby-dev
	


From simont at post.its.mcw.edu  Thu Sep 22 10:04:18 2005
From: simont at post.its.mcw.edu (Simon Twigger)
Date: Fri Sep 23 13:36:28 2005
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell0
	1>
References: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell01>
Message-ID: <58021.69.210.117.185.1127397858.squirrel@webmail.mcw.edu>

Hi Mark,

I thought I had sent a reply volunteering for the committee a little while
ago but perhaps it forgot to hit send. If there is still time, I would
like to help out by serving.

Simon.


> I don't think so... I'm pretty surer I sent it...??
>
> M
>
>
> -----Original Message-----
> From: "Edward Kawas" <edward.kawas@gmail.com>
> Date: Wed, 21 Sep 2005 16:58:20
> To:"'Core developer announcements'" <moby-dev@portal.open-bio.org>
> Subject: RE: [MOBY-dev] RFC Committee  Membership last call...
>
>> I'll send out a message with the
>> apprpriate subject
>> line in a couple of minutes.
>
> Did you forget to press send ;-)
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>

From gordonp at ucalgary.ca  Fri Sep 23 15:13:06 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Fri Sep 23 15:13:52 2005
Subject: [MOBY-dev] adding Comparable to MobyDataType class
In-Reply-To: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
Message-ID: <433453C2.9030206@ucalgary.ca>

If you do so, please let me know, as all object classes in the 
org.biomoby.shared data package already implements Comparable, and we 
should have the same ordering rules.

>Eddie (and the others),
>   I plan to add 'implements Comparable' to MobyDataType (and perhaps also
>to MobyService and MobyNamespace) - just to make it easier to sort.
>   I noticed that your Registration class inherits from MobyDataType. I do
>not think that this new interface would harm it - but better to ask
>first. Do you know about any bad consequences if I add there this
>interface?
>
>   Thanks,
>   Martin
>
>  
>

From senger at ebi.ac.uk  Fri Sep 23 23:18:45 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri Sep 23 23:19:45 2005
Subject: [MOBY-dev] adding Comparable to MobyDataType class
In-Reply-To: <433453C2.9030206@ucalgary.ca>
Message-ID: <Pine.OSF.4.21.0509240413570.839150-100000@ice.ebi.ac.uk>

> If you do so, please let me know, as all object classes in the 
> org.biomoby.shared data package already implements Comparable, and we 
> should have the same ordering rules.
>
   Well, of course, but I do not see what you mean. Perhaps I overlooked
something. I see the hierarchy:

   MobyDataObject -> MobyPrimaryDataSimple -> MobyData

where MobyDataObject implements Comparable. I wonder how it can be
influenced by adding Comparable to MobyDataType, MobyService and
MobyNamespace?
   Do you think that I can go ahead and put there Comparable?

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Sun Sep 25 02:41:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun Sep 25 02:42:05 2005
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>

> The vote has been called.  Voting members may vote by adding their YES 
> (accept)  or NO (do not accept) to the comments history  through Bugzilla
> 
> Voting ends Sept 26th
>
    I propose to extend the vote deadline to October 15th. Reasons are:

   1) The proposal (as available from Bugzilla) is still too complex, full
of explanaition, and it is not clear what is a discussion and what is a
proposal. I recommend that the authors take away most of the reasoning and
just state what is the new API. (The reasoning can come later back to the
documentation, if Frank, as a document-manager, decides so.)

   2) The proposal is in the format which is not readable for everyone
(for example, using OpenOffice mixes the tables on the first page, so I do
not understand what they mean and why they are there). Open source API
should use open documentation tools, as much as it can. The whole Biomoby
API/docs is, so far, written in non-proprietary document format, so I
suggest to continue with it.

   3) The error codes are still not explained enough. I suggest either
remove (some of) them, or document them better. Especially the client-side
errors are still obscure to me.

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.

   5) The proposal should clearly suggest what (if anything) should be
removed from the current Biomoby API. I mean the fact that the current API
(even perhasp not literally, but surely by spirit) expects (allows) an
empty result in case of an error (e.g. an ID cannot be found in a target
database). Will this still be valid, or should serviceNotes be returned
instead?

   I already said that I liked the new proposal and I am going to support
it - but I want to introduce new things into Biomoby API as precisely as
we can. Therefore, I am not ready to vote yet. But just in case, my
suggestion described above, will not be accepted, and the vote deadline
announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
do it on Bugzilla, because (a) I think that this NO is only temporary and
conditionally, and (b) I did not found any "history comments" there so I
would not know how to use Bugzilla for that.)

   Regards,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Sun Sep 25 02:41:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun Sep 25 02:42:08 2005
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>

> The vote has been called.  Voting members may vote by adding their YES 
> (accept)  or NO (do not accept) to the comments history  through Bugzilla
> 
> Voting ends Sept 26th
>
    I propose to extend the vote deadline to October 15th. Reasons are:

   1) The proposal (as available from Bugzilla) is still too complex, full
of explanaition, and it is not clear what is a discussion and what is a
proposal. I recommend that the authors take away most of the reasoning and
just state what is the new API. (The reasoning can come later back to the
documentation, if Frank, as a document-manager, decides so.)

   2) The proposal is in the format which is not readable for everyone
(for example, using OpenOffice mixes the tables on the first page, so I do
not understand what they mean and why they are there). Open source API
should use open documentation tools, as much as it can. The whole Biomoby
API/docs is, so far, written in non-proprietary document format, so I
suggest to continue with it.

   3) The error codes are still not explained enough. I suggest either
remove (some of) them, or document them better. Especially the client-side
errors are still obscure to me.

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.

   5) The proposal should clearly suggest what (if anything) should be
removed from the current Biomoby API. I mean the fact that the current API
(even perhasp not literally, but surely by spirit) expects (allows) an
empty result in case of an error (e.g. an ID cannot be found in a target
database). Will this still be valid, or should serviceNotes be returned
instead?

   I already said that I liked the new proposal and I am going to support
it - but I want to introduce new things into Biomoby API as precisely as
we can. Therefore, I am not ready to vote yet. But just in case, my
suggestion described above, will not be accepted, and the vote deadline
announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
do it on Bugzilla, because (a) I think that this NO is only temporary and
conditionally, and (b) I did not found any "history comments" there so I
would not know how to use Bugzilla for that.)

   Regards,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From Pieter.Neerincx at wur.nl  Mon Sep 26 07:40:20 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon Sep 26 07:40:35 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>
References: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>
Message-ID: <1A427D71-2573-4920-8465-17843E0E3A02@wur.nl>

Hi Eddie,

I've got it up and running. I have now idea what went wrong exactly,  
but I suspect some misconfiguration in Tomcat. I also switched from  
IBM's Java implemntation to Sun's. Had apparently both installed by  
default, but my Tomcat was out of the box using IBM's Java stuff. Now  
with Sun's Java I do have to type 'java -jar install.jar' for the  
servlets installer, just like you documented. Furthermore I have  
Apache configured as frontend for Tomcat now, so I can use port 443  
for https making the whole work again through our firewall. I have  
only one issue left:

When I append my local central to my mygrid.properties file for  
Taverna, I have the old behaviour: hence services from my local  
central, but objects from  the central central. When I remove my  
local central and add it again using right-click -> add biomoby  
scavanger, I get the desired behaviour with both services and objects  
from my local central. It's a bit inconvenient to have to load your  
mobycentral manually all the time :(, but apart from that  
inconvenience it works :). Very nice to see this code in action,  
thanks for the help!

I will document my experience and propose this as an update for the  
page at: http://www.biomoby.org/InstallingMOBYCentral.html if this is  
Ok with you.

Cheers,

Pieter



On 19-Sep-2005, at 5:20 PM, Edward Kawas wrote:

> Hi,
>
> I can't connect to those URLS or endpoints (I timeout).
>
> I will try to find the bug by eyeballing it. If you can
> think of another way that I can access your endpoint, please
> let me know.
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 19, 2005 8:06 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>>
>> On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:
>>
>>
>>>> Could not retrieve and or process RDF document for
>>>>
>> BioMoby
>>
>>>> Objects
>>>>
>>>>
>>> Can I have your Moby endpoint so that I can test this?
>>>
>>
>> Sure!
>>
>> This is what I use on my development box:
>>
>>      https://bioinfw05/phenolink/biomoby/central/cgi-
>> bin/MOBY-Central.pl
>>
>> But it doesn't have a DNS entry, so you might try this:
>>
>>      https://137.224.52.237/phenolink/biomoby/central/cgi-
>> bin/MOBY-
>> Central.pl
>>
>> My RDF for the objects is at (not sure whether this one
>> will work
>> from outside our firewall...):
>>
>>      https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects
>>
>> Hope this helps.
>>
>> Pieter
>>
>>
>>
>>> I am
>>> not sure why the carriage returns are present.
>>>
>>> Eddie
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev@biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx@wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From dgpisano at cnb.uam.es  Mon Sep 26 09:55:45 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon Sep 26 10:21:05 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
Message-ID: <4337FDE1.1080201@cnb.uam.es>

I think we can still vote today, as far as Martin's objections are not 
really about the proposal itself, but about the aesthetics and 
presentation of the proposal. My solutions below

Martin Senger escribi?:

>>The vote has been called.  Voting members may vote by adding their YES 
>>(accept)  or NO (do not accept) to the comments history  through Bugzilla
>>
>>Voting ends Sept 26th
>>
>>    
>>
>    I propose to extend the vote deadline to October 15th. Reasons are:
>
>   1) The proposal (as available from Bugzilla) is still too complex, full
>of explanaition, and it is not clear what is a discussion and what is a
>proposal. I recommend that the authors take away most of the reasoning and
>just state what is the new API. (The reasoning can come later back to the
>documentation, if Frank, as a document-manager, decides so.)
>
>  
>
Explanations would not make the document *more* difficult to understand 
(unless the explanations are wrong)? Probably you are refering to the 
motivation / discussion parts, that we understand we needed to explain 
our reasons to expand MOBY-S specification. I've rewritten the proposal 
so now is just a specification extension proposal (still not an API 
proposal, that's the next implementation step).

>   2) The proposal is in the format which is not readable for everyone
>(for example, using OpenOffice mixes the tables on the first page, so I do
>not understand what they mean and why they are there). Open source API
>should use open documentation tools, as much as it can. The whole Biomoby
>API/docs is, so far, written in non-proprietary document format, so I
>suggest to continue with it.
>  
>
See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
format... We've never talked about this before, and the document can 
easily be exported to whatever format we agree. I am not really 
concerned about using open or closed tools, OMG publishes specifications 
in Word format -between other- and schema documentation using XML Spy 
and nobody objects using commercial tools as far as everybody can 
understand them. Never mind.

Anyway I don't have access to the bugzilla, and I think we still not 
agreed on any format, so please let me what format do you want and I'll 
be happy to send it to Frank to attach it to bugzilla. BTW, how do i 
access to the bugzilla? :-)

>   3) The error codes are still not explained enough. I suggest either
>remove (some of) them, or document them better. Especially the client-side
>errors are still obscure to me.
>  
>
Do you have any specific proposal here? We don't see any major problems, 
but probably we are missing something. Just for clarity, I've removed 
the 800 section (client errors). The proposal (like the LSAE one) is 
open to add new error codes, so this is expandable in the future if we 
agree that we need (or not) specific error codes.

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>  
>
Added a new optional Notes element under serviceNotes to separate human 
readable free text from structured XML mobyException. This way we can 
maintain old functionality into serviceNotes. API changes proposed too.

>   5) The proposal should clearly suggest what (if anything) should be
>removed from the current Biomoby API. I mean the fact that the current API
>(even perhasp not literally, but surely by spirit) expects (allows) an
>empty result in case of an error (e.g. an ID cannot be found in a target
>database). Will this still be valid, or should serviceNotes be returned
>instead?
>  
>
Added a new section with API changes needed. Your question was answered 
in the proposal which is in the bugzilla but in short yes, still an 
empty result has to be sent and (optionally) a serviceNotes with an 
exception be reported with it. This allows the error handling system to 
be compatible with old clients.

>   I already said that I liked the new proposal and I am going to support
>it - but I want to introduce new things into Biomoby API as precisely as
>we can. Therefore, I am not ready to vote yet. But just in case, my
>suggestion described above, will not be accepted, and the vote deadline
>announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
>do it on Bugzilla, because (a) I think that this NO is only temporary and
>conditionally, and (b) I did not found any "history comments" there so I
>would not know how to use Bugzilla for that.)
>
>  
>
Hope that you change your mind. As soon as you tell me which document 
format you want, I'll send the latest version with the changes commented 
above.

>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050926/ab68c498/dgpisano.vcf
From dgpisano at cnb.uam.es  Mon Sep 26 09:55:45 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon Sep 26 10:21:16 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
Message-ID: <4337FDE1.1080201@cnb.uam.es>

I think we can still vote today, as far as Martin's objections are not 
really about the proposal itself, but about the aesthetics and 
presentation of the proposal. My solutions below

Martin Senger escribi?:

>>The vote has been called.  Voting members may vote by adding their YES 
>>(accept)  or NO (do not accept) to the comments history  through Bugzilla
>>
>>Voting ends Sept 26th
>>
>>    
>>
>    I propose to extend the vote deadline to October 15th. Reasons are:
>
>   1) The proposal (as available from Bugzilla) is still too complex, full
>of explanaition, and it is not clear what is a discussion and what is a
>proposal. I recommend that the authors take away most of the reasoning and
>just state what is the new API. (The reasoning can come later back to the
>documentation, if Frank, as a document-manager, decides so.)
>
>  
>
Explanations would not make the document *more* difficult to understand 
(unless the explanations are wrong)? Probably you are refering to the 
motivation / discussion parts, that we understand we needed to explain 
our reasons to expand MOBY-S specification. I've rewritten the proposal 
so now is just a specification extension proposal (still not an API 
proposal, that's the next implementation step).

>   2) The proposal is in the format which is not readable for everyone
>(for example, using OpenOffice mixes the tables on the first page, so I do
>not understand what they mean and why they are there). Open source API
>should use open documentation tools, as much as it can. The whole Biomoby
>API/docs is, so far, written in non-proprietary document format, so I
>suggest to continue with it.
>  
>
See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
format... We've never talked about this before, and the document can 
easily be exported to whatever format we agree. I am not really 
concerned about using open or closed tools, OMG publishes specifications 
in Word format -between other- and schema documentation using XML Spy 
and nobody objects using commercial tools as far as everybody can 
understand them. Never mind.

Anyway I don't have access to the bugzilla, and I think we still not 
agreed on any format, so please let me what format do you want and I'll 
be happy to send it to Frank to attach it to bugzilla. BTW, how do i 
access to the bugzilla? :-)

>   3) The error codes are still not explained enough. I suggest either
>remove (some of) them, or document them better. Especially the client-side
>errors are still obscure to me.
>  
>
Do you have any specific proposal here? We don't see any major problems, 
but probably we are missing something. Just for clarity, I've removed 
the 800 section (client errors). The proposal (like the LSAE one) is 
open to add new error codes, so this is expandable in the future if we 
agree that we need (or not) specific error codes.

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>  
>
Added a new optional Notes element under serviceNotes to separate human 
readable free text from structured XML mobyException. This way we can 
maintain old functionality into serviceNotes. API changes proposed too.

>   5) The proposal should clearly suggest what (if anything) should be
>removed from the current Biomoby API. I mean the fact that the current API
>(even perhasp not literally, but surely by spirit) expects (allows) an
>empty result in case of an error (e.g. an ID cannot be found in a target
>database). Will this still be valid, or should serviceNotes be returned
>instead?
>  
>
Added a new section with API changes needed. Your question was answered 
in the proposal which is in the bugzilla but in short yes, still an 
empty result has to be sent and (optionally) a serviceNotes with an 
exception be reported with it. This allows the error handling system to 
be compatible with old clients.

>   I already said that I liked the new proposal and I am going to support
>it - but I want to introduce new things into Biomoby API as precisely as
>we can. Therefore, I am not ready to vote yet. But just in case, my
>suggestion described above, will not be accepted, and the vote deadline
>announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
>do it on Bugzilla, because (a) I think that this NO is only temporary and
>conditionally, and (b) I did not found any "history comments" there so I
>would not know how to use Bugzilla for that.)
>
>  
>
Hope that you change your mind. As soon as you tell me which document 
format you want, I'll send the latest version with the changes commented 
above.

>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050926/ab68c498/dgpisano-0003.vcf
From edward.kawas at gmail.com  Mon Sep 26 10:56:55 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 26 10:56:45 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <1A427D71-2573-4920-8465-17843E0E3A02@wur.nl>
Message-ID: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>

Hi Pieter,

>When I append my local central to my mygrid.properties file
>for Taverna, I have the old behaviour: hence services from
>my local central, but objects from  the central central.

Where did you get this version of Taverna? Is it the one
from their homepage? If so, have you tried downloading the
one that I put up at
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip?

Also, is it possible to post your Mobycentral endpoint so
that I could see how things work?

Thanks,

Eddie

From senger at ebi.ac.uk  Mon Sep 26 10:59:44 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 26 11:07:46 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>

> I think we can still vote today, as far as Martin's objections are not 
> really about the proposal itself, but about the aesthetics and 
> presentation of the proposal
>
   No, I disagree. The proposal is correct in the spirit, but incorrect or
unclear in details (which I named in my email). The only aesthetics part
was about the format. That on its own would not give me right to suggest
to postpone the vote.

> Explanations would not make the document *more* difficult to understand 
>
   well the document has about ten pages; but it introduces only few XML
tags, plus a page of error codes; I think that having it more consice
helps to make sure that we are not overlooking some missing or
contradicting point.

> See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
> format...
>
   As I said, this was not my major concern. So do as you wish. I would
probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
API is written now.

> concerned about using open or closed tools, OMG publishes specifications 
> in Word format
>
   Talking about OMG, it is even worse that you think. The submissions
must be in FrameMaker which is completely close format. This is a
long-time living issue on the OMG table... But that's not our cup of tea.

> Anyway I don't have access to the bugzilla
>
   My personal opinion: don't even try - it's easy to be lost there. I did
not find how to vote there anyway.

> Do you have any specific proposal here?
>
   I just wanted to have the codes explained. The last version I saw (the
one from bugzilla) still has the client codes there. And I do not
understand what they mean.

> Added a new optional Notes element under serviceNotes to separate human 
> readable free text from structured XML mobyException. This way we can 
> maintain old functionality into serviceNotes. API changes proposed too.
>
   How can I see the new version?
 
> Added a new section with API changes needed. Your question was answered 
> in the proposal which is in the bugzilla but in short yes, still an 
> empty result has to be sent
>
   But that was under-documented from the beginning. Because the API does
not say what an "empty integer" means. I hoped that we will use this
chnage to clarify this.

> Hope that you change your mind. As soon as you tell me which document 
> format you want, I'll send the latest version with the changes commented 
> above.
> 
   Please send it. I will try to read it as it arrives - (but it's already
close to midnight here so I do not know if I manage it :-)).

   Regards,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Mon Sep 26 10:59:44 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 26 11:07:51 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>

> I think we can still vote today, as far as Martin's objections are not 
> really about the proposal itself, but about the aesthetics and 
> presentation of the proposal
>
   No, I disagree. The proposal is correct in the spirit, but incorrect or
unclear in details (which I named in my email). The only aesthetics part
was about the format. That on its own would not give me right to suggest
to postpone the vote.

> Explanations would not make the document *more* difficult to understand 
>
   well the document has about ten pages; but it introduces only few XML
tags, plus a page of error codes; I think that having it more consice
helps to make sure that we are not overlooking some missing or
contradicting point.

> See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
> format...
>
   As I said, this was not my major concern. So do as you wish. I would
probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
API is written now.

> concerned about using open or closed tools, OMG publishes specifications 
> in Word format
>
   Talking about OMG, it is even worse that you think. The submissions
must be in FrameMaker which is completely close format. This is a
long-time living issue on the OMG table... But that's not our cup of tea.

> Anyway I don't have access to the bugzilla
>
   My personal opinion: don't even try - it's easy to be lost there. I did
not find how to vote there anyway.

> Do you have any specific proposal here?
>
   I just wanted to have the codes explained. The last version I saw (the
one from bugzilla) still has the client codes there. And I do not
understand what they mean.

> Added a new optional Notes element under serviceNotes to separate human 
> readable free text from structured XML mobyException. This way we can 
> maintain old functionality into serviceNotes. API changes proposed too.
>
   How can I see the new version?
 
> Added a new section with API changes needed. Your question was answered 
> in the proposal which is in the bugzilla but in short yes, still an 
> empty result has to be sent
>
   But that was under-documented from the beginning. Because the API does
not say what an "empty integer" means. I hoped that we will use this
chnage to clarify this.

> Hope that you change your mind. As soon as you tell me which document 
> format you want, I'll send the latest version with the changes commented 
> above.
> 
   Please send it. I will try to read it as it arrives - (but it's already
close to midnight here so I do not know if I manage it :-)).

   Regards,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From edward.kawas at gmail.com  Mon Sep 26 10:43:07 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 26 11:08:15 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <433808ff.43a593e0.0674.1289@mx.gmail.com>

> Anyway I don't have access to the bugzilla
http://bugzilla.open-bio.org/ 
you may need to register first though.
 

From markw at illuminae.com  Mon Sep 26 17:56:56 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon Sep 26 18:24:36 2005
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>

The RDF committee now consists of:

Frank
Martin
Eddie
David
Mark
Simon
Pieter


I am assuming from Yan's message that he wont have time to participate
(please correct me if I am wrong, Yan :-) ), and I have not yet heard
from Paul Gordon.

In any case, that's a great group!  Thanks all!  Let's close the
committee for now.

So, Martin, how does OMG run its democracy?  Unanimity, or majority
rules?

Mark


From Pieter.Neerincx at wur.nl  Mon Sep 26 19:27:57 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon Sep 26 19:39:58 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>
References: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>
Message-ID: <AE4E0C93-0C74-4404-AD40-D9759336D133@wur.nl>


On  26Sep2005, at 16:56, Edward Kawas wrote:

> Hi Pieter,
>
>
>> When I append my local central to my mygrid.properties file
>> for Taverna, I have the old behaviour: hence services from
>> my local central, but objects from  the central central.
>>
>
> Where did you get this version of Taverna? Is it the one
> from their homepage?

No, I've been testing with the version you put up at the URL  
mentioned below.

> If so, have you tried downloading the
> one that I put up at
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.zip?
> Also, is it possible to post your Mobycentral endpoint so
> that I could see how things work?

Yes, sure. I have now temporarily disabled the SSL requirement, so  
everything should work nicely over our firewall using port 80 :). as  
long as I'm testing I don't need the HTTPS, but some of the people  
that are using my services on a production server do.

My test MOBY Central endpoint is at: http://137.224.52.237/phenolink/ 
biomoby/central/cgi-bin/MOBY-Central.pl
My test RESOURCES script is at: http://137.224.52.237/RESOURCES/MOBY-S/

Hope this helps,

Pieter

>
> Thanks,
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1038
Dreijenlaan 3
6703 HA Wageningen
phone: 0317-484 706
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl

From dgpisano at cnb.uam.es  Mon Sep 26 19:11:21 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon Sep 26 19:45:36 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
Message-ID: <43388019.9040308@cnb.uam.es>

I am attaching a PDF file (faster conversion from Word, the HTML is 
generating is too MS-centric, but we can publish the final approved 
version in HTML). Is as strong rewrite (version 2), but I am still 
maintaining the proposal basics and the specification changes. Basically 
the document is organized in a different way.

Hope this help everybody to take a decision or further improve the  
specification (or both) ;-)

David
(about to dissapear some days for ECCB05)

Martin Senger escribi?:

>>I think we can still vote today, as far as Martin's objections are not 
>>really about the proposal itself, but about the aesthetics and 
>>presentation of the proposal
>>
>>    
>>
>   No, I disagree. The proposal is correct in the spirit, but incorrect or
>unclear in details (which I named in my email). The only aesthetics part
>was about the format. That on its own would not give me right to suggest
>to postpone the vote.
>
>  
>
>>Explanations would not make the document *more* difficult to understand 
>>
>>    
>>
>   well the document has about ten pages; but it introduces only few XML
>tags, plus a page of error codes; I think that having it more consice
>helps to make sure that we are not overlooking some missing or
>contradicting point.
>
>  
>
>>See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
>>format...
>>
>>    
>>
>   As I said, this was not my major concern. So do as you wish. I would
>probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
>API is written now.
>
>  
>
>>concerned about using open or closed tools, OMG publishes specifications 
>>in Word format
>>
>>    
>>
>   Talking about OMG, it is even worse that you think. The submissions
>must be in FrameMaker which is completely close format. This is a
>long-time living issue on the OMG table... But that's not our cup of tea.
>
>  
>
>>Anyway I don't have access to the bugzilla
>>
>>    
>>
>   My personal opinion: don't even try - it's easy to be lost there. I did
>not find how to vote there anyway.
>
>  
>
>>Do you have any specific proposal here?
>>
>>    
>>
>   I just wanted to have the codes explained. The last version I saw (the
>one from bugzilla) still has the client codes there. And I do not
>understand what they mean.
>
>  
>
>>Added a new optional Notes element under serviceNotes to separate human 
>>readable free text from structured XML mobyException. This way we can 
>>maintain old functionality into serviceNotes. API changes proposed too.
>>
>>    
>>
>   How can I see the new version?
> 
>  
>
>>Added a new section with API changes needed. Your question was answered 
>>in the proposal which is in the bugzilla but in short yes, still an 
>>empty result has to be sent
>>
>>    
>>
>   But that was under-documented from the beginning. Because the API does
>not say what an "empty integer" means. I hoped that we will use this
>chnage to clarify this.
>
>  
>
>>Hope that you change your mind. As soon as you tell me which document 
>>format you want, I'll send the latest version with the changes commented 
>>above.
>>
>>    
>>
>   Please send it. I will try to read it as it arrives - (but it's already
>close to midnight here so I do not know if I manage it :-)).
>
>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v2.0.pdf
Type: application/pdf
Size: 106970 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/0501INB-ExceptionReporting-v2.0-0002.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/dgpisano-0002.vcf
From dgpisano at cnb.uam.es  Mon Sep 26 19:11:21 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon Sep 26 19:45:38 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
Message-ID: <43388019.9040308@cnb.uam.es>

I am attaching a PDF file (faster conversion from Word, the HTML is 
generating is too MS-centric, but we can publish the final approved 
version in HTML). Is as strong rewrite (version 2), but I am still 
maintaining the proposal basics and the specification changes. Basically 
the document is organized in a different way.

Hope this help everybody to take a decision or further improve the  
specification (or both) ;-)

David
(about to dissapear some days for ECCB05)

Martin Senger escribi?:

>>I think we can still vote today, as far as Martin's objections are not 
>>really about the proposal itself, but about the aesthetics and 
>>presentation of the proposal
>>
>>    
>>
>   No, I disagree. The proposal is correct in the spirit, but incorrect or
>unclear in details (which I named in my email). The only aesthetics part
>was about the format. That on its own would not give me right to suggest
>to postpone the vote.
>
>  
>
>>Explanations would not make the document *more* difficult to understand 
>>
>>    
>>
>   well the document has about ten pages; but it introduces only few XML
>tags, plus a page of error codes; I think that having it more consice
>helps to make sure that we are not overlooking some missing or
>contradicting point.
>
>  
>
>>See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
>>format...
>>
>>    
>>
>   As I said, this was not my major concern. So do as you wish. I would
>probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
>API is written now.
>
>  
>
>>concerned about using open or closed tools, OMG publishes specifications 
>>in Word format
>>
>>    
>>
>   Talking about OMG, it is even worse that you think. The submissions
>must be in FrameMaker which is completely close format. This is a
>long-time living issue on the OMG table... But that's not our cup of tea.
>
>  
>
>>Anyway I don't have access to the bugzilla
>>
>>    
>>
>   My personal opinion: don't even try - it's easy to be lost there. I did
>not find how to vote there anyway.
>
>  
>
>>Do you have any specific proposal here?
>>
>>    
>>
>   I just wanted to have the codes explained. The last version I saw (the
>one from bugzilla) still has the client codes there. And I do not
>understand what they mean.
>
>  
>
>>Added a new optional Notes element under serviceNotes to separate human 
>>readable free text from structured XML mobyException. This way we can 
>>maintain old functionality into serviceNotes. API changes proposed too.
>>
>>    
>>
>   How can I see the new version?
> 
>  
>
>>Added a new section with API changes needed. Your question was answered 
>>in the proposal which is in the bugzilla but in short yes, still an 
>>empty result has to be sent
>>
>>    
>>
>   But that was under-documented from the beginning. Because the API does
>not say what an "empty integer" means. I hoped that we will use this
>chnage to clarify this.
>
>  
>
>>Hope that you change your mind. As soon as you tell me which document 
>>format you want, I'll send the latest version with the changes commented 
>>above.
>>
>>    
>>
>   Please send it. I will try to read it as it arrives - (but it's already
>close to midnight here so I do not know if I manage it :-)).
>
>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v2.0.pdf
Type: application/pdf
Size: 106970 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/0501INB-ExceptionReporting-v2.0-0003.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/dgpisano-0003.vcf
From senger at ebi.ac.uk  Mon Sep 26 19:43:40 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 26 19:50:13 2005
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509270043090.1185944-100000@mozart.ebi.ac.uk>

> So, Martin, how does OMG run its democracy?  Unanimity, or majority
> rules?
>
   Majority.
   M.

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Mon Sep 26 21:12:45 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 26 21:15:07 2005
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient
In-Reply-To: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509270211020.1185944-100000@mozart.ebi.ac.uk>

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
Martin Senger
   email: martin.senger@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)

From markw at illuminae.com  Mon Sep 26 21:17:11 2005
From: markw at illuminae.com (mark wilkinson)
Date: Mon Sep 26 21:27:12 2005
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
Message-ID: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>

You need to thank Eddie and Dennis (my co-op student this summer).  They had already coded this fix, but I had to commit and restart the server :-)

M


-----Original Message-----
From: Martin Senger <senger@ebi.ac.uk>
Date: Tue, 27 Sep 2005 02:12:45 
To:Mark Wilkinson <markw@illuminae.com>
Cc:Moby Developers <moby-dev@biomoby.org>
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
Martin Senger
   email: martin.senger@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@biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

--
Mark Wilkinson
...on the road!
From markw at illuminae.com  Mon Sep 26 21:02:45 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon Sep 26 21:27:45 2005
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient
In-Reply-To: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>
Message-ID: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>

The SINK should no longer be a SOURCE of frustration :-)

M


-- 
"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

From markw at illuminae.com  Mon Sep 26 21:17:11 2005
From: markw at illuminae.com (mark wilkinson)
Date: Mon Sep 26 21:29:05 2005
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
Message-ID: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>

You need to thank Eddie and Dennis (my co-op student this summer).  They had already coded this fix, but I had to commit and restart the server :-)

M


-----Original Message-----
From: Martin Senger <senger@ebi.ac.uk>
Date: Tue, 27 Sep 2005 02:12:45 
To:Mark Wilkinson <markw@illuminae.com>
Cc:Moby Developers <moby-dev@biomoby.org>
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
Martin Senger
   email: martin.senger@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@biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

--
Mark Wilkinson
...on the road!
From edward.kawas at gmail.com  Mon Sep 26 21:31:19 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 26 21:38:15 2005
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
In-Reply-To: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>
Message-ID: <4338a0ea.6bd81a7a.1e34.ffffdbb1@mx.gmail.com>

 
> The SINK should no longer be a SOURCE of frustration :-)

You see Mark, that was what I was talking about!

From edward.kawas at gmail.com  Mon Sep 26 21:40:53 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 26 21:47:33 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <AE4E0C93-0C74-4404-AD40-D9759336D133@wur.nl>
Message-ID: <4338a329.70df3d00.2781.71d9@mx.gmail.com>

Hi Pieter,

I have been toying around with your endpoint. I noticed that
the URL you gave earlier for the Object RDF was inconsistent
with what was retrieved from the API call
getResourceLocation(or something like that ...). 

I think that this occurred when you opened up your endpoint
and perhaps forgot to modify it in your mobycentral.conf
file (does https://bioinfw05:somePort/... resolve on your
machine?). 

The plugin utilizes the API call and hence wouldn't be able
to create a personalized Mobycentral processor (Moby
services and data types) list in Taverna without it.

Once I utilized the URLs that you specified in this message,
everything went as it should. I was able to use your
processors, etc.

I am uploading another version (I tweaked some of the logic)
of the plugin in about 5 minutes. Word on the street is that
Taverna 1.3 is going to be available later on this week
(Friday?) and so that version most likely would be the one
you would want to use. 

In addition, if you notice anything out of the ordinary,
please let me know ASAP so that I can correct it in time for
the much anticipated release.

Thanks,

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 26, 2005 4:28 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> 
> On  26Sep2005, at 16:56, Edward Kawas wrote:
> 
> > Hi Pieter,
> >
> >
> >> When I append my local central to my mygrid.properties
> file
> >> for Taverna, I have the old behaviour: hence services
> from
> >> my local central, but objects from  the central
central.
> >>
> >
> > Where did you get this version of Taverna? Is it the one
> > from their homepage?
> 
> No, I've been testing with the version you put up at the
> URL
> mentioned below.
> 
> > If so, have you tried downloading the
> > one that I put up at
> > http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
> 1.2.zip?
> > Also, is it possible to post your Mobycentral endpoint
> so
> > that I could see how things work?
> 
> Yes, sure. I have now temporarily disabled the SSL
> requirement, so
> everything should work nicely over our firewall using port
> 80 :). as
> long as I'm testing I don't need the HTTPS, but some of
> the people
> that are using my services on a production server do.
> 
> My test MOBY Central endpoint is at:
> http://137.224.52.237/phenolink/
> biomoby/central/cgi-bin/MOBY-Central.pl
> My test RESOURCES script is at:
> http://137.224.52.237/RESOURCES/MOBY-S/
> 
> Hope this helps,
> 
> Pieter
> 
> >
> > Thanks,
> >
> > Eddie
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1038
> Dreijenlaan 3
> 6703 HA Wageningen
> phone: 0317-484 706
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From edward.kawas at gmail.com  Mon Sep 26 22:01:54 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon Sep 26 22:01:40 2005
Subject: [MOBY-dev] Re: [personal] API for retrieving
	namespacesinsufficient
In-Reply-To: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>
Message-ID: <4338a814.6d9c8408.538c.ffffe8e3@mx.gmail.com>

Mark, I noticed that the retrieve service type fix was not
'uncommented', like the namespace one was. Is this because
you don't want to implement that suggestion?

Lines >= 2615 of Central.pm

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Monday, September 26, 2005 6:17 PM
> To: Core developer announcements; Mark Wilkinson
> Cc: Moby Developers
> Subject: Re: [MOBY-dev] Re: [personal] API for retrieving
> namespacesinsufficient
> 
> You need to thank Eddie and Dennis (my co-op student this
> summer).  They had already coded this fix, but I had to
> commit and restart the server :-)
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger@ebi.ac.uk>
> Date: Tue, 27 Sep 2005 02:12:45
> To:Mark Wilkinson <markw@illuminae.com>
> Cc:Moby Developers <moby-dev@biomoby.org>
> Subject: [MOBY-dev] Re: [personal] API for retrieving
> namespaces insufficient
> 
> > The SINK should no longer be a SOURCE of frustration :-)
> >
>    WONDERFUL!!!! You are my best pal!
>    Thanks 1000x, Martin
> 
> (Just a pity is that I have to leave in few hours, so the
> jMoby
> implementation of this new feature must wait when I am
> back.)
> 
> M.
> 
> 
> --
> Martin Senger
>    email: martin.senger@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@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From senger at ebi.ac.uk  Mon Sep 26 22:06:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 26 22:15:13 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <43388019.9040308@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509270301380.1214670-100000@mozart.ebi.ac.uk>

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From senger at ebi.ac.uk  Mon Sep 26 22:06:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Sep 26 22:15:15 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <43388019.9040308@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509270301380.1214670-100000@mozart.ebi.ac.uk>

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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)

From markw at illuminae.com  Mon Sep 26 22:20:21 2005
From: markw at illuminae.com (mark wilkinson)
Date: Mon Sep 26 22:21:09 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
Message-ID: <1032375145-1127787656-cardhu_blackberry.rim.net-23779-@engine12-cell01>

It seems that my suggestion to use bugzilla's comment feature was not a winning idea v.v. voting on RFC's...  Would people prefer to just use the mailing list?

M



-----Original Message-----
From: Martin Senger <senger@ebi.ac.uk>
Date: Tue, 27 Sep 2005 03:06:19 
To:David Gonz?lez Pisano <dgpisano@cnb.uam.es>
Cc:Core developer announcements <moby-dev@portal.open-bio.org>,       mobydev <moby-dev@biomoby.org>
Subject: Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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@biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

--
Mark Wilkinson
...on the road!

From markw at illuminae.com  Mon Sep 26 22:20:21 2005
From: markw at illuminae.com (mark wilkinson)
Date: Mon Sep 26 22:28:26 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
Message-ID: <1032375145-1127787656-cardhu_blackberry.rim.net-23779-@engine12-cell01>

It seems that my suggestion to use bugzilla's comment feature was not a winning idea v.v. voting on RFC's...  Would people prefer to just use the mailing list?

M



-----Original Message-----
From: Martin Senger <senger@ebi.ac.uk>
Date: Tue, 27 Sep 2005 03:06:19 
To:David Gonz?lez Pisano <dgpisano@cnb.uam.es>
Cc:Core developer announcements <moby-dev@portal.open-bio.org>,       mobydev <moby-dev@biomoby.org>
Subject: Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger@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@biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

--
Mark Wilkinson
...on the road!

From Pieter.Neerincx at wur.nl  Tue Sep 27 05:31:05 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue Sep 27 05:32:38 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4338a329.70df3d00.2781.71d9@mx.gmail.com>
References: <4338a329.70df3d00.2781.71d9@mx.gmail.com>
Message-ID: <6EC9FF1D-1762-4CDD-BE3F-D05415A3457E@wur.nl>

Hi Eddie,

On 27-Sep-2005, at 3:40 AM, Edward Kawas wrote:

> Hi Pieter,
>
> I have been toying around with your endpoint. I noticed that
> the URL you gave earlier for the Object RDF was inconsistent
> with what was retrieved from the API call
> getResourceLocation(or something like that ...).
>
> I think that this occurred when you opened up your endpoint
> and perhaps forgot to modify it in your mobycentral.conf
> file (does https://bioinfw05:somePort/... resolve on your
> machine?).

Ooops, you are right I forgot to change the hostname into an IP  
address in that conf file. It does resolve in our LAN because the  
hostname is added to the hosts file on all the machines, but it  
doesn't resolve outside our LAN. I've fixed it now.

>
> The plugin utilizes the API call and hence wouldn't be able
> to create a personalized Mobycentral processor (Moby
> services and data types) list in Taverna without it.
>
> Once I utilized the URLs that you specified in this message,
> everything went as it should. I was able to use your
> processors, etc.

The behaviour I described is still the same for me. It works fine as  
long as I manually add my local central, but simply specifying my  
local central in the taverna/conf/mygrid.properties file doesn't  
work. There must be a difference in the way the BioMOBY scavanger is  
constructed during startup of Taverna and when you manually add a  
BioMOBY scavanger...

>
> I am uploading another version (I tweaked some of the logic)
> of the plugin in about 5 minutes. Word on the street is that
> Taverna 1.3 is going to be available later on this week
> (Friday?) and so that version most likely would be the one
> you would want to use.

Nice! I'll get myself a cup of coffee and try the new version ...

Cheers,

Pieter

> In addition, if you notice anything out of the ordinary,
> please let me know ASAP so that I can correct it in time for
> the much anticipated release.
>
> Thanks,
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 26, 2005 4:28 PM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>>
>> On  26Sep2005, at 16:56, Edward Kawas wrote:
>>
>>
>>> Hi Pieter,
>>>
>>>
>>>
>>>> When I append my local central to my mygrid.properties
>>>>
>> file
>>
>>>> for Taverna, I have the old behaviour: hence services
>>>>
>> from
>>
>>>> my local central, but objects from  the central
>>>>
> central.
>
>>>>
>>>>
>>>
>>> Where did you get this version of Taverna? Is it the one
>>> from their homepage?
>>>
>>
>> No, I've been testing with the version you put up at the
>> URL
>> mentioned below.
>>
>>
>>> If so, have you tried downloading the
>>> one that I put up at
>>> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>>>
>> 1.2.zip?
>>
>>> Also, is it possible to post your Mobycentral endpoint
>>>
>> so
>>
>>> that I could see how things work?
>>>
>>
>> Yes, sure. I have now temporarily disabled the SSL
>> requirement, so
>> everything should work nicely over our firewall using port
>> 80 :). as
>> long as I'm testing I don't need the HTTPS, but some of
>> the people
>> that are using my services on a production server do.
>>
>> My test MOBY Central endpoint is at:
>> http://137.224.52.237/phenolink/
>> biomoby/central/cgi-bin/MOBY-Central.pl
>> My test RESOURCES script is at:
>> http://137.224.52.237/RESOURCES/MOBY-S/
>>
>> Hope this helps,
>>
>> Pieter
>>
>>
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev@biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1038
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> phone: 0317-484 706
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx@wur.nl
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From markw at illuminae.com  Mon Sep 26 22:56:56 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue Sep 27 10:07:07 2005
Subject: [MOBY-dev] Move to the new website
Message-ID: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>

Hi all,

I am going to try to migrate to the new website this week (biomoby.open-bio.org).  Once we're satisfied with it, I'll get the biomoby.org DNS to resolve to that server.

There's a lot of migration to do, but I think I can manage much of that on my own.  It will be fun!

I'm not sure where people are keeping all of the new documents... Can we make a concerted effort to move them on to that server over the next few days?

Cheers all!  This has been an amazing four months since the last dev meeting!!!

M

--
Mark Wilkinson
...on the road!
From edward.kawas at gmail.com  Tue Sep 27 10:26:45 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue Sep 27 10:33:05 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <6EC9FF1D-1762-4CDD-BE3F-D05415A3457E@wur.nl>
Message-ID: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>

> The behavior I described is still the same for me. It
> works fine as
> long as I manually add my local central, but simply
> specifying my
> local central in the taverna/conf/mygrid.properties file
> doesn't
> work. There must be a difference in the way the BioMOBY
> scavanger is
> constructed during startup of Taverna and when you
> manually add a
> BioMOBY scavenger...

Hi Pieter,

I found out what you were talking about and you were right
on all accounts. I have fixed this *bug* and I created a new
version that I am in the process of uploading.

Actually, I did notice that I am unable to add services
using your endpoint!?! I looked at your service instance rdf
and I noticed that you have the descriptions of services
available, but all find service calls don't seem to be
working. Is this true?

Eddie

From Pieter.Neerincx at wur.nl  Tue Sep 27 10:55:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue Sep 27 10:55:26 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
References: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
Message-ID: <9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>


On 27-Sep-2005, at 4:26 PM, Edward Kawas wrote:

>> The behavior I described is still the same for me. It
>> works fine as
>> long as I manually add my local central, but simply
>> specifying my
>> local central in the taverna/conf/mygrid.properties file
>> doesn't
>> work. There must be a difference in the way the BioMOBY
>> scavanger is
>> constructed during startup of Taverna and when you
>> manually add a
>> BioMOBY scavenger...
>>
>
> Hi Pieter,
>
> I found out what you were talking about and you were right
> on all accounts. I have fixed this *bug* and I created a new
> version that I am in the process of uploading.

Super, will test it at the end of the day.

> Actually, I did notice that I am unable to add services
> using your endpoint!?! I looked at your service instance rdf
> and I noticed that you have the descriptions of services
> available, but all find service calls don't seem to be
> working. Is this true?

I'll look into it. Might be a problem that I switched off https for  
my local central, but not for the services themselves. I've been  
switching between ports, 80, 443, 8080 and 8443 for the past days.  
Maybe some of my config files are not in sync...

Pieter


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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From gss at ncgr.org  Tue Sep 27 13:18:43 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue Sep 27 13:28:58 2005
Subject: [MOBY-dev] Move to the new website
In-Reply-To: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
Message-ID: <43397EF3.50509@ncgr.org>

I hope that it is planned to keep the website content under CVS control.

// Gary

mark wilkinson wrote:
> Hi all,
> 
> I am going to try to migrate to the new website this week (biomoby.open-bio.org).  Once we're satisfied with it, I'll get the biomoby.org DNS to resolve to that server.
> 
> There's a lot of migration to do, but I think I can manage much of that on my own.  It will be fun!
> 
> I'm not sure where people are keeping all of the new documents... Can we make a concerted effort to move them on to that server over the next few days?
> 
> Cheers all!  This has been an amazing four months since the last dev meeting!!!
> 
> M
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> 
From francis_gibbons at hms.harvard.edu  Tue Sep 27 21:27:53 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Tue Sep 27 21:27:43 2005
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.


Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
 
Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
 
-Frank

From francis_gibbons at hms.harvard.edu  Tue Sep 27 21:27:53 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Tue Sep 27 21:39:35 2005
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.


Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
 
Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
 
-Frank

From dgpisano at cnb.uam.es  Wed Sep 28 05:33:05 2005
From: dgpisano at cnb.uam.es (=?UTF-8?B?RGF2aWQgR29uesOhbGV6IFBpc2Fubw==?=)
Date: Wed Sep 28 05:33:30 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <433A6351.1080907@cnb.uam.es>

Frank,

Probably the main problem with the PIB is its location, inside the 
Object structure. One of the initial options we considered was to report 
exceptions inside mobyData, but mixing "data" with "what happened while 
computing the data" information didn't look like the best idea. Using 
the PIB also brings up again the problem of what is an empty object: can 
we report back a "not so empty object", ie, an object with no data but 
PIB data? What about an object with no data but CrossReferences? Is not 
really clear to me. Given the examples about the PIB in the 
specification, I always thought it was a good place to fill with static 
data associated to my results (like software version, database release, 
etc..), not really about why the service didn't work.

The last proposal  we uploaded includes a possible solution to avoid 
XML-mixed elements, basically permiting serviceNotes to have two 
elements: mobyException and Notes. This solution allows to extend the 
servicNotes element with other uses/schemas in the future.

David

Gibbons, Francis escribi?:

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>
>
>Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
> 
>Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
> 
>-Frank
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 349 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050928/31f7573e/dgpisano.vcf
From dgpisano at cnb.uam.es  Wed Sep 28 05:33:05 2005
From: dgpisano at cnb.uam.es (=?UTF-8?B?RGF2aWQgR29uesOhbGV6IFBpc2Fubw==?=)
Date: Wed Sep 28 05:33:45 2005
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <433A6351.1080907@cnb.uam.es>

Frank,

Probably the main problem with the PIB is its location, inside the 
Object structure. One of the initial options we considered was to report 
exceptions inside mobyData, but mixing "data" with "what happened while 
computing the data" information didn't look like the best idea. Using 
the PIB also brings up again the problem of what is an empty object: can 
we report back a "not so empty object", ie, an object with no data but 
PIB data? What about an object with no data but CrossReferences? Is not 
really clear to me. Given the examples about the PIB in the 
specification, I always thought it was a good place to fill with static 
data associated to my results (like software version, database release, 
etc..), not really about why the service didn't work.

The last proposal  we uploaded includes a possible solution to avoid 
XML-mixed elements, basically permiting serviceNotes to have two 
elements: mobyException and Notes. This solution allows to extend the 
servicNotes element with other uses/schemas in the future.

David

Gibbons, Francis escribi?:

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>
>
>Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
> 
>Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
> 
>-Frank
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 349 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050928/31f7573e/dgpisano-0001.vcf
From Pieter.Neerincx at wur.nl  Wed Sep 28 10:01:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed Sep 28 10:02:25 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>
References: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
	<9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>
Message-ID: <8E698684-29C3-43C0-B9A1-58188958D7B5@wur.nl>

Hi Eddie,

On 27-Sep-2005, at 4:55 PM, Pieter Neerincx wrote:
>>
>> Hi Pieter,
>>
>> I found out what you were talking about and you were right
>> on all accounts. I have fixed this *bug* and I created a new
>> version that I am in the process of uploading.
>>
>
> Super, will test it at the end of the day.

Check, it works! Taverna now uses my local central when added to  
taverna/conf/mygrid.porperties.

Ran into a few small other problems though. I'm not sure whether  
these are the result of your custom mod of taverna or whether these  
are generic Taverna bugs...

1. The ~taverna-workbench/runme.sh script to start Taverna was in the  
wrong encoding. It contains windows CR LF line endings. After I  
dos2unix-ed the file it works.

2. I can only add 1 processor to a workflow by "drag and drop".  
Taverna refuses to add any other processor I drag and drop. It  
doesn't matter what kind of processor it is: biomoby service, object,  
local java widget, etc.. I can add more processors to a workflow  
using right-click -> add to workflow.

>
>> Actually, I did notice that I am unable to add services
>> using your endpoint!?! I looked at your service instance rdf
>> and I noticed that you have the descriptions of services
>> available, but all find service calls don't seem to be
>> working. Is this true?
>>
>
> I'll look into it. Might be a problem that I switched off https for  
> my local central, but not for the services themselves. I've been  
> switching between ports, 80, 443, 8080 and 8443 for the past days.  
> Maybe some of my config files are not in sync...

Got that nailed down as well. Wasn't a port problem. I turned on  
debugging in path/to/perl/modules/MOBY/Central.pm this used to simply  
write debug info to /tmp/CentralRegistryLogOut.txt , but with the new  
code base this also generates an "Error 500, internal server error".  
This doesn't happen for all calls to MOBY Central, but it did mess up  
the find services call. The following line:

     $debug && &_LOG("found id $_->{service_instance_id}\n");

occurs several times. Not all of them are fatal, but the ones on line  
1992, 2010, 2028 and 2046 result in the internal server error...  
Don't know how to fix it yet. Turning debugging off must have been  
the easiest work around I applied ever :)

Cheers,

Pieter

>
> Pieter
>
>
>
>>
>> Eddie
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>
>
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx@wur.nl
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From gordonp at ucalgary.ca  Wed Sep 28 10:02:35 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed Sep 28 10:02:33 2005
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>	<4331CEA3.6020205@illuminae.com>
	<1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
Message-ID: <433AA27B.3050602@ucalgary.ca>

Actually, I did reply "Yes" to Eddie since he e-mailed me directly, but 
I guess it slipped his mind...

>The RDF committee now consists of:
>
>Frank
>Martin
>Eddie
>David
>Mark
>Simon
>Pieter
>
>
>I am assuming from Yan's message that he wont have time to participate
>(please correct me if I am wrong, Yan :-) ), and I have not yet heard
>from Paul Gordon.
>
>In any case, that's a great group!  Thanks all!  Let's close the
>committee for now.
>
>So, Martin, how does OMG run its democracy?  Unanimity, or majority
>rules?
>
>Mark
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>

From markw at illuminae.com  Wed Sep 28 10:03:43 2005
From: markw at illuminae.com (mark wilkinson)
Date: Wed Sep 28 10:04:10 2005
Subject: [MOBY-dev] RFC Committee  Membership
Message-ID: <489633558-1127916263-cardhu_blackberry.rim.net-9027-@engine09-cell01>

Excellent - thanks!

-----Original Message-----
From: Paul Gordon <gordonp@ucalgary.ca>
Date: Wed, 28 Sep 2005 08:02:35 
To:markw@illuminae.com,       Core developer announcements <moby-dev@portal.open-bio.org>
Subject: Re: [MOBY-dev] RFC Committee  Membership

Actually, I did reply "Yes" to Eddie since he e-mailed me directly, but 
I guess it slipped his mind...

>The RDF committee now consists of:
>
>Frank
>Martin
>Eddie
>David
>Mark
>Simon
>Pieter
>
>
>I am assuming from Yan's message that he wont have time to participate
>(please correct me if I am wrong, Yan :-) ), and I have not yet heard
>from Paul Gordon.
>
>In any case, that's a great group!  Thanks all!  Let's close the
>committee for now.
>
>So, Martin, how does OMG run its democracy?  Unanimity, or majority
>rules?
>
>Mark
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>

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

--
Mark Wilkinson
...on the road!
From Pieter.Neerincx at wur.nl  Wed Sep 28 10:12:54 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed Sep 28 10:13:22 2005
Subject: [MOBY-dev] Move to the new website
In-Reply-To: <43397EF3.50509@ncgr.org>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
Message-ID: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>

First of all: OMG that new site is so much nicer than the old one!  
That will a big plus for BioMOBY PR.

On 27-Sep-2005, at 7:18 PM, Gary Schiltz wrote:

> I hope that it is planned to keep the website content under CVS  
> control.

That would be cool. Can't find any website stuff in the CVS that  
contains the code though. I already registered at the new site, but  
as far as I get it, that is only to add comments to news posts or  
something. So how do I contribute to this wonderful new site?

>
> // Gary
>
> mark wilkinson wrote:
>
>> Hi all,
>> I am going to try to migrate to the new website this week  
>> (biomoby.open-bio.org).  Once we're satisfied with it, I'll get  
>> the biomoby.org DNS to resolve to that server.
>> There's a lot of migration to do, but I think I can manage much of  
>> that on my own.  It will be fun!
>> I'm not sure where people are keeping all of the new documents...  
>> Can we make a concerted effort to move them on to that server over  
>> the next few days?
>> Cheers all!  This has been an amazing four months since the last  
>> dev meeting!!!

It sure has been. The core dev mailing list is officially described  
as "low volume for announcements only", but after I take I few days  
of I always have to do quite a bit of catching up :)

Cheers,

Pi

>> M
>> --
>> Mark Wilkinson
>> ...on the road!
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Wed Sep 28 11:04:18 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed Sep 28 11:06:16 2005
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <8E698684-29C3-43C0-B9A1-58188958D7B5@wur.nl>
Message-ID: <433ab0f4.7e3a8bd0.47fe.ffffb878@mx.gmail.com>

> 1. The ~taverna-workbench/runme.sh script to start Taverna
> was in the
> wrong encoding. It contains windows CR LF line endings.
> After I
> dos2unix-ed the file it works.
That was my fault. I live in a windows world and created the
archive on windows after I built it with windows.



> 2. I can only add 1 processor to a workflow by "drag and
> drop".
> Taverna refuses to add any other processor I drag and
drop.
> It
> doesn't matter what kind of processor it is: biomoby
> service, object,
> local java widget, etc.. I can add more processors to a
> workflow
> using right-click -> add to workflow.
I wonder if this is because the version you ran was compiled
on my windows machine? I couldn't reproduce this behavior.

Thanks,

Eddie

From markw at illuminae.com  Wed Sep 28 11:11:30 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 28 11:11:45 2005
Subject: [moby] Re: [MOBY-dev] Move to the new website
In-Reply-To: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org> <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
Message-ID: <1127920290.13392.7.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 16:12 +0200, Pieter Neerincx wrote:

> It sure has been. The core dev mailing list is officially described  
> as "low volume for announcements only", but after I take I few days  
> of I always have to do quite a bit of catching up :)

Yeah... there are more developers than users ;-)

I guess at this stage in MOBY development, most users eventually become
developers anyway.  Once the 1.0 API is out and coded up, we can start
to "market" MOBY as a tool rather than a toy...  This was one of the
discussions at the last MOBY meeting.

Cheers!

M


From markw at illuminae.com  Wed Sep 28 11:12:45 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 28 11:17:00 2005
Subject: [moby] Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S --
	Vote Called
In-Reply-To: <433A6351.1080907@cnb.uam.es>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
	<433A6351.1080907@cnb.uam.es>
Message-ID: <1127920365.13392.10.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 11:33 +0200, David Gonz?lez Pisano wrote:

> Using 
> the PIB also brings up again the problem of what is an empty object: can 
> we report back a "not so empty object", ie, an object with no data but 
> PIB data? What about an object with no data but CrossReferences? Is not 
> really clear to me. Given the examples about the PIB in the 
> specification, I always thought it was a good place to fill with static 
> data associated to my results (like software version, database release, 
> etc..), not really about why the service didn't work.

I agree with this interpretation of the API.  If a service fails, the
mobyData object should have the associated queryID filled in, but
otherwise have NO CONTENT.  This precludes the use of CrossRef's and/or
PIB's for error reporting.


> The last proposal  we uploaded includes a possible solution to avoid 
> XML-mixed elements, basically permiting serviceNotes to have two 
> elements: mobyException and Notes. This solution allows to extend the 
> servicNotes element with other uses/schemas in the future.

I think this is a great idea.  The serviceNotes block was stuck into the
original API just because it seemed so obviously useful, but was
intentionally left "undefined" until someone had time to think of how
best to structure it.  Looks like now someone has found the time!

M


From markw at illuminae.com  Wed Sep 28 12:09:30 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 28 12:09:40 2005
Subject: [moby] Re: [MOBY-dev] Move to the new website
In-Reply-To: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org> <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
Message-ID: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 16:12 +0200, Pieter Neerincx wrote:
> First of all: OMG that new site is so much nicer than the old one!  
> That will a big plus for BioMOBY PR.

Yeah, we were all pretty blown away by what Simon did there!  Kudo's to
him!!


> That would be cool. Can't find any website stuff in the CVS that  
> contains the code though. I already registered at the new site, but  
> as far as I get it, that is only to add comments to news posts or  
> something. So how do I contribute to this wonderful new site?

The website is under WordPress control, so anyone who wants an account
can get one and edit the site as they desire.  We have a better
granularity of control with WordPress, such that we can prevent people
from changing e.g. the site templates, or certain "domains", while
allowing them to change other domains to their hearts content.  It isn't
CVS (i,e, there's no back-out of mistakes!) but it's quite nice!

To get a WordPress account ask Simon.  I don't think I have permissions
to create new accounts, so don't ask me :-)

There's a lot of work left to do on it, but I made some headway
yesterday in getting the client information moved over.  It's just a lot
of tedious HTML coding left to do, so I'll likely do the aesthetic stuff
in the pub just to make it tolerable ;-)

I'm planning to do a CVS checkout of the moby-live repository into the
web folder and then link into the new HTML docs that Frank has been
writing for the past few weeks.  Hopefully I'll be able to set up a cron
that updates that folder every day or so to keep the website docs
current.

Cheers all!

M


-- 
"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

From Pieter.Neerincx at wur.nl  Wed Sep 28 14:01:57 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed Sep 28 14:02:03 2005
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
Message-ID: <C666C785-3B69-4CCA-89A7-0F59865E3D35@wur.nl>

Hi Mark and Eddie,

With Eddie's help I managed to get a local BioMOBY Central (using the  
new code base) up and running and make it work with Taverna :). The  
documentation at:
http://www.biomoby.org/InstallingMOBYCentral.html
is a bit outdated and incomplete. So I upgraded that info with my  
experience. I have a temporary copy online at:
http://137.224.52.237/InstallingLocalMOBYCentral.html
Let me know what you think... and if you like it: either copy it to  
the BioMOBY website or wait for Simon to give me an account for the  
new site.

Pi

From francis_gibbons at hms.harvard.edu  Wed Sep 28 15:01:01 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Wed Sep 28 14:59:48 2005
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <C666C785-3B69-4CCA-89A7-0F59865E3D35@wur.nl>
References: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
Message-ID: <5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>

Pieter,

At 02:01 PM 9/28/2005, you wrote:
>Hi Mark and Eddie,
>
>With Eddie's help I managed to get a local BioMOBY Central (using the
>new code base) up and running and make it work with Taverna :). The
>documentation at:
>http://www.biomoby.org/InstallingMOBYCentral.html
>is a bit outdated and incomplete. So I upgraded that info with my
>experience. I have a temporary copy online at:
>http://137.224.52.237/InstallingLocalMOBYCentral.html
>Let me know what you think... and if you like it: either copy it to
>the BioMOBY website or wait for Simon to give me an account for the
>new site.

I think this belongs in the CVS repository at least, to which I guess you 
already have access. Of course, it needs to go on the website too, but the 
entire content of the website should itself be available from CVS, with the 
website updated automatically from CVS.

-F

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

From markw at illuminae.com  Wed Sep 28 18:19:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 28 18:19:28 2005
Subject: [MOBY-dev] API docs up on the new site
Message-ID: <1127945980.13392.144.camel@bioinfo.icapture.ubc.ca>

Hi all, 

I've got Frank's new API docs up on the new biomoby site (click on the
"For Developers" link).  It's in a CVS checkout, but I just need to work
out how to put cvs update on a cron...  

Cheers!

M



-- 
"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

From markw at illuminae.com  Wed Sep 28 18:39:23 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Sep 28 18:39:03 2005
Subject: [MOBY-dev] RFC #1863 - change request & question
Message-ID: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>

Hi David, 

I have a question:  Have you now lost interest in raising exceptions to
individual simples in a collection?  I notice that your RFC no longer
handles this case (though I came to realize that it was a good idea
after you explained it to me :-) )

Also a request for change:  

Change 1

FROM
In the case of Retrieve calls, failure will be silent and an empty
object of the associated output
type will be returned.

TO
In the case of Retrieve calls, failure will be silent should rise an
exception and an empty object
of the associated output type will be returned.

TO (REVISED)
In the case of an error, failure should raise an exception and an empty
mobyData block with the appropriate queryID will be returned.


Comments:  the wording in the original API are wrong - the object is no
empty, the mobyData block is empty.



-- 
"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

From Pieter.Neerincx at wur.nl  Thu Sep 29 11:11:49 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu Sep 29 11:14:25 2005
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>
References: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>
Message-ID: <C540F3D5-9F4C-4C81-9E6D-BED23048B33A@wur.nl>


On 28-Sep-2005, at 9:01 PM, Frank Gibbons wrote:

> Pieter,
>
> At 02:01 PM 9/28/2005, you wrote:
>
>> Hi Mark and Eddie,
>>
>> With Eddie's help I managed to get a local BioMOBY Central (using the
>> new code base) up and running and make it work with Taverna :). The
>> documentation at:
>> http://www.biomoby.org/InstallingMOBYCentral.html
>> is a bit outdated and incomplete. So I upgraded that info with my
>> experience. I have a temporary copy online at:
>> http://137.224.52.237/InstallingLocalMOBYCentral.html
>> Let me know what you think... and if you like it: either copy it to
>> the BioMOBY website or wait for Simon to give me an account for the
>> new site.
>>
>
> I think this belongs in the CVS repository at least, to which I  
> guess you already have access. Of course, it needs to go on the  
> website too, but the entire content of the website should itself be  
> available from CVS, with the website updated automatically from CVS.

I agree, so I moved it into the CVS. Haven't heard back Mark or Eddie  
if the info is Ok, but they can now easily improve it if they run  
into wrong or missing information :).

For Eddie: the page links to the downloads of your servlets installer  
and custom Taverna version. If this is not Ok with you, please let me  
know.

I didn't find any templates for pages of the new site, so I had a  
look at the source and tried to compile something that is close to  
the new looks...

Pi

> -F
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA  
> 02115, USA.
> Tel: 617-432-3555       Fax: 617-432-3557       http:// 
> llama.med.harvard.edu/~fgibbons
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From edward.kawas at gmail.com  Thu Sep 29 11:18:18 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu Sep 29 11:18:10 2005
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <C540F3D5-9F4C-4C81-9E6D-BED23048B33A@wur.nl>
Message-ID: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>

> For Eddie: the page links to the downloads of your
> servlets installer
> and custom Taverna version.

I recently removed the Taverna link because tomorrow (I
think) people can download it from Taverna's homepage.

Eddie



From Pieter.Neerincx at wur.nl  Thu Sep 29 11:43:04 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu Sep 29 11:43:00 2005
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>
References: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>
Message-ID: <4DDBA090-1A2F-4F23-832E-D52DB04CB406@wur.nl>


On 29-Sep-2005, at 5:18 PM, Edward Kawas wrote:

>> For Eddie: the page links to the downloads of your
>> servlets installer
>> and custom Taverna version.
>>
>
> I recently removed the Taverna link because tomorrow (I
> think) people can download it from Taverna's homepage.

Ok, I'll remove that note about getting a custom version of taverna  
then.

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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx@wur.nl



From dgpisano at cnb.uam.es  Fri Sep 30 05:37:06 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri Sep 30 05:37:37 2005
Subject: [MOBY-dev] RFC #1863 - change request & question
In-Reply-To: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>
References: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>
Message-ID: <433D0742.4050708@cnb.uam.es>

Mark Wilkinson escribi?:

>Hi David, 
>
>I have a question:  Have you now lost interest in raising exceptions to
>individual simples in a collection?  I notice that your RFC no longer
>handles this case (though I came to realize that it was a good idea
>after you explained it to me :-) )
>  
>
Well, we didn't lost interest, but thought about it and decided to 
postpone the opening of the can of worms. After the next proposal 
(asynchrony) we are thinking about a third one for dealing with 
Collections, and Simples inside Collections. The main problematic point 
will be to (re)define namespaces (or parameter labels) and propose 
unique identifiers for Simples inside Collections, so we can refer to 
them. That means that quite a lot of things in the current MOBY 
specification could be discussed and changed, and we think is better not 
to mix the discussion about the errors with the discussion about the 
namespaces/collections. The latests proposals consider referring to the 
exception raising element using elementID tag (instead of the original 
namespaceID), so it can be easily extended to refer to Simples inside 
Collections if in the future we propose a way to identify them

>Also a request for change:  
>
>Change 1
>
>FROM
>In the case of Retrieve calls, failure will be silent and an empty
>object of the associated output
>type will be returned.
>
>TO
>In the case of Retrieve calls, failure will be silent should rise an
>exception and an empty object
>of the associated output type will be returned.
>
>TO (REVISED)
>In the case of an error, failure should raise an exception and an empty
>mobyData block with the appropriate queryID will be returned.
>
>
>Comments:  the wording in the original API are wrong - the object is no
>empty, the mobyData block is empty.
>
>  
>
I think it makes much more sense, will update the document and will send 
it again when is voted. BTW, I obviously vote YES, but don't know about 
the rest of the voters, or even if we postponed the voting date to the 
one suggested by Martin in October.

>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050930/900e212c/dgpisano.vcf
From senger at ebi.ac.uk  Thu Sep  1 01:54:05 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 1 Sep 2005 06:54:05 +0100 (BST)
Subject: [MOBY-dev] jMoby: problems with Ant under Windows
In-Reply-To: <43165859.64ac00f0.3259.3e66@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509010653180.1474166-100000@mozart.ebi.ac.uk>

> Don't yell at me, but all that windows needed was a good
> 'clean'ing.
>
   Eddie, what are you talking about? About Ant problems I asked about?
   M.
 
> Thanks.
> 
> Ed
> 
> > -----Original Message-----
> > From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> > dev-bounces at portal.open-bio.org] On Behalf Of Martin
> > Senger
> > Sent: Wednesday, August 31, 2005 6:19 PM
> > To: Moby Developers
> > Subject: [MOBY-dev] jMoby: problems with Ant under Windows
> > 
> > You are a pool of clever and experiences people - would
> > anybody be able to
> > help me to write (actually to fix) the current Ant's
> > build.zml so it works
> > fine also under Windows? I am desperately seeking an
> > advise:
> > 
> > 1) The command-line arguments when using target <java>
> > cannot remain empty
> > (under Windows). For example, the command-line:
> >     java MosesGenerator -e "" -debug
> > means (under Linux) a command-line with three arguments,
> > but (under
> > windows) a command-line with just two arguments (-e and -
> > debug). Is there
> > a solution for this, at all?
> > 
> > 2) The target <javadoc>, when used with rich attributes
> > (like bottom,
> > headre etc.), does not work under windows. First I had to
> > change double
> > quotes into single quotes (okay, Ant should do it, but
> > does not; but it's
> > doable). Second I have to remove newlines from some XML
> > elements - like
> > the 'bottom' one (okay, doable, but annoying, again Any
> > should do it - as
> > it does for unix). But third: the line for javadoc is too
> > long for
> > windows. Well, if you have a windows running, try the
> > current build.xml -
> > try target 'docs' - and you will see what I am talking
> > about, and perhaps
> > you will kniw how to rectiry.
> > 
> >    Many thanks for your help,
> >    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
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 

-- 
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)



From fgibbons at hms.harvard.edu  Thu Sep  1 09:59:14 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Thu, 01 Sep 2005 09:59:14 -0400
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <200508310321.j7V3L7AG014458@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>

Martin,

Thanks for your comments on the API documentation. As I think I pointed out 
earlier, at this point all I've done is to take what was in the wiki, clean 
up the HTML a bit, and check it into CVS. I added a few little bits of 
text, put in some links, and did a little semantic markup, but that's it.

>    The first few comments about the registry API:
>
>    * I think that the first page (with a list of methods) should also have
>(even start with) a list of links to objects used by these methods, such
>as a query object.

If this API is to language-independent, then I'm not so sure we can talk 
about objects, unless the Java and Perl implementations agree on it. My 
personal feeling is that what's needed most is high-level, abstract 
description of the overall scheme. A year ago, newbies had to try and put 
together that picture from the Perl code. While I think the Javadoc is 
really good (especially MOSES), the Perldoc still needs work. And even when 
both are as good as we'd like them to be, it's still useful to specify the 
API in language-independent terms. In Perl, there is not "query object" 
only registry/service objects.

>    * I disagree with labelling the deregisteService as depracated. As far
>as I understood, it will be still around for quick resgiter/unregister
>cycle where I am not conceedrn about security (that somebody can
>deregister my service). So from the API point of view it is a normal
>method, not a deprecated one. Mark?

Well, this is marked as 'deprecated' in the wiki, hence it is so marked 
here too. At some point (perhaps v 0.9?) it would be great to have a code 
freeze, in which we could make sure that the docs and implementation agree, 
so that we could have a product that is internally consistent, even as 
development continues. There's even nothing wrong with writing the API as 
we *wish* it to be (some would say that's how it should be done), and then 
trying to code to that. We can release a version in which the documentation 
makes clear what is implemented, and what is 'to-do'.

>    * service protocol "moby" is actually a service category, not a 
> protocol I think

>    * some details have also categories cgi.soap, some not... I suggest to
>remove all cgi and sopa for now (we will have in in the CVS if we need it
>to re-introsduce it later; surely the 'soap' category bring nothing than a
>confusion (isn't it current moby based on soap? - I know how it is, but
>newbies perhaps not)

Yeah, I tend to agree that this is confusing, since only "moby" exists (not 
"cgi" and "soap"). I agree that they should be culled, but since this is 
what was in the wiki, and I didn't know what the development plans were for 
it, I left it in.

>    * I would move definition of a "A MOBY compliant service" to the
>section about services API (here may be just a link to it).  As I said I
>am really concern that these two APIs are (or were before you enter the
>scene) confusing, so make them as separate as possible.

I agree, I'll try to get greater separation between the registry and 
services APIs.

>    * retrieveResourceURLs has a wrong description (something about providers)

I think is still under development - Mark?

>    And the last (but not an unimportant) general comment: the XML-based
>API should be expressed as DTD (which is more preferable in this context,
>XSD is not so human readable).

I think we'll need a volunteer to help us out on that - I've used DTD/XSDs, 
but never written one. Anyone?

>    Also the details about individual tags and attributes are quitel 
> imited now.

Yeah, we really need to beef up the details.

Thanks for your useful comments, Martin. I look forward to more.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From senger at ebi.ac.uk  Thu Sep  1 10:31:05 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 1 Sep 2005 15:31:05 +0100 (BST)
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <Pine.OSF.4.21.0509011524240.895262-100000@ice.ebi.ac.uk>

> If this API is to language-independent, then I'm not so sure we can talk 
> about objects
>
   Oh no, no, that's a misunderstanding. Sorry for the confusion. I would
be the first who would shout "Long Live Language Independence!". I said
"query object" because this term is used in the current API. But I meant
the XML, of course.

> Well, this is marked as 'deprecated' in the wiki, hence it is so marked 
> here too.
>
   I understand. It was more to Mark. Just to record my concern and fear
that Mark can one day remove it and say "what are you complaining about,
it was deprecated already for years?". I am quite often scare what Mark
can do suddenly... (well, I wanted to add :-) but I found that it was not
a joke, after all).

> >    * retrieveResourceURLs has a wrong description (something about providers)
> 
> I think is still under development - Mark?
>
   Not as far I know. I have it already implemented in jMoby and it worked
(about a month ago). The only thing stull under discussion was the content
type of this resources (if to provide more or not). And also a clear
definition what is expected from the service providers when they suddenly
become the LSID metadata resolvers.
 
   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)



From edward.kawas at gmail.com  Thu Sep  1 08:44:22 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 1 Sep 2005 05:44:22 -0700
Subject: [MOBY-dev] jMoby: problems with Ant under Windows
In-Reply-To: <Pine.OSF.4.21.0509010653180.1474166-100000@mozart.ebi.ac.uk>
Message-ID: <4316f7ad.17975dab.1578.1c6c@mx.gmail.com>

I just meant that the clean compile command worked.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Wednesday, August 31, 2005 10:54 PM
> To: Core developer announcements
> Subject: RE: [MOBY-dev] jMoby: problems with Ant under
> Windows
> 
> > Don't yell at me, but all that windows needed was a good
> > 'clean'ing.
> >
>    Eddie, what are you talking about? About Ant problems I
> asked about?
>    M.
> 
> > Thanks.
> >
> > Ed
> >
> > > -----Original Message-----
> > > From: moby-dev-bounces at portal.open-bio.org
> [mailto:moby-
> > > dev-bounces at portal.open-bio.org] On Behalf Of Martin
> > > Senger
> > > Sent: Wednesday, August 31, 2005 6:19 PM
> > > To: Moby Developers
> > > Subject: [MOBY-dev] jMoby: problems with Ant under
> Windows
> > >
> > > You are a pool of clever and experiences people -
> would
> > > anybody be able to
> > > help me to write (actually to fix) the current Ant's
> > > build.zml so it works
> > > fine also under Windows? I am desperately seeking an
> > > advise:
> > >
> > > 1) The command-line arguments when using target <java>
> > > cannot remain empty
> > > (under Windows). For example, the command-line:
> > >     java MosesGenerator -e "" -debug
> > > means (under Linux) a command-line with three
> arguments,
> > > but (under
> > > windows) a command-line with just two arguments (-e
> and -
> > > debug). Is there
> > > a solution for this, at all?
> > >
> > > 2) The target <javadoc>, when used with rich
> attributes
> > > (like bottom,
> > > headre etc.), does not work under windows. First I had
> to
> > > change double
> > > quotes into single quotes (okay, Ant should do it, but
> > > does not; but it's
> > > doable). Second I have to remove newlines from some
> XML
> > > elements - like
> > > the 'bottom' one (okay, doable, but annoying, again
> Any
> > > should do it - as
> > > it does for unix). But third: the line for javadoc is
> too
> > > long for
> > > windows. Well, if you have a windows running, try the
> > > current build.xml -
> > > try target 'docs' - and you will see what I am talking
> > > about, and perhaps
> > > you will kniw how to rectiry.
> > >
> > >    Many thanks for your help,
> > >    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
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> --
> 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



From markw at illuminae.com  Thu Sep  1 12:23:04 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 01 Sep 2005 09:23:04 -0700
Subject: [moby] [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <1125591784.28085.50.camel@bioinfo.icapture.ubc.ca>

On Thu, 2005-09-01 at 09:59 -0400, Frank Gibbons wrote:

> >    * I disagree with labelling the deregisteService as depracated. As far
> >as I understood, it will be still around for quick resgiter/unregister
> >cycle where I am not conceedrn about security (that somebody can
> >deregister my service). So from the API point of view it is a normal
> >method, not a deprecated one. Mark?

It was the initial intention to remove it permanently from the API
because of the security problem, and have the agent do the
deregistration when the service provider removes their RDF signature;
however that decision is now in flux because of the need for rapid
register/deregister cycles.  As such, I haven't changed the 'deprecated'
status until this is resolved.

The behaviour right now is that a service can be deregistered using this
call if it was initially registered without a signatureURL.  I think
this is a reasonable way to go forward, but since we haven't turned the
agent on yet, it isn't entirely clear if this behaviour is sufficient to
accommodate the majority of cases.  It should be, so I'm be inclined to
de-deprecate that call and simply update the API to reflect its current
behaviour.


> There's even nothing wrong with writing the API as 
> we *wish* it to be (some would say that's how it should be done),

That's more or less how things have been going since the last MOBY
meeting - the API was being updated ahead of the code. I'm trying (more
successfully now than a couple of months ago) to keep them in sync, but
this is an extremely rapid development phase we are going through as we
approach the 1.0 release at the end of this month, so...  yeah... it's a
bit chaotic right now, and will be for the next few weeks.




> >    * some details have also categories cgi.soap, some not... I suggest to
> >remove all cgi and sopa for now (we will have in in the CVS if we need it
> >to re-introsduce it later; surely the 'soap' category bring nothing than a
> >confusion (isn't it current moby based on soap? - I know how it is, but
> >newbies perhaps not)

Yes, let's remove all references to anything other than "moby" category
from the API.  The code did support CGI GET service registrations after
the Singapore hackathon (and it probably still does, but it isn't being
tested regularly); however until we spend some time fully defining this
behaviour we should take it out.  I will update the code to prevent
anything other than "moby" registrations.



> >    * retrieveResourceURLs has a wrong description (something about providers)
> 
> I think is still under development - Mark?

I think it is working as advertised...??

M


-- 
"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



From tmo at ebi.ac.uk  Thu Sep  1 11:47:33 2005
From: tmo at ebi.ac.uk (Tom Oinn)
Date: Thu, 01 Sep 2005 16:47:33 +0100
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <43172295.8090207@ebi.ac.uk>


>>    And the last (but not an unimportant) general comment: the XML-based
>> API should be expressed as DTD (which is more preferable in this context,
>> XSD is not so human readable).
> 
> 
> I think we'll need a volunteer to help us out on that - I've used 
> DTD/XSDs, but never written one. Anyone?

We've used XMLSpy in the past to produce graphical representations of 
XSD and DTD, this is generally easier to read than the textual ones. 
With some restrictions this can also be used to convert XSD to DTD 
although personally I prefer reading XSD.

Tom


From dgpisano at cnb.uam.es  Fri Sep  2 05:31:49 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri, 02 Sep 2005 11:31:49 +0200
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBYv1.5
	- INB proposal
In-Reply-To: <Pine.OSF.4.21.0509010105240.1462154-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509010105240.1462154-100000@mozart.ebi.ac.uk>
Message-ID: <43181C05.7090508@cnb.uam.es>

Martin Senger escribi?:

>>It isn't entirely clear to me that there is a need to throw errors on a
>>specific Simple within a Collection.
>>    
>>
>   I quite like how Mark explained it, and it makes sense to me. I am just
>not too concerned because this part is just an optional part - so the only
>"mandatory" part in the API (regarding this issue) will/would be "...and
>ignore other possibly present attributes in the Simples in a Collection".
>   But still, I am interested to hear David's argumentation againts Mark's
>explanation. David, do you have a real-life use-case where you expect to
>create such response?
>
>  
>
No, I don't have a real life example with an input collection. But I do 
have one with an output collection that could serve as example. We could 
imagine this kind of problems in input collections. Jose Maria sent it 
to the list months ago, but I can post it again. Is a real service which 
is being used in the PlaNet project (getInteractions).

A given service retrieves information about protein interactions from 
different data sources (a couple of SQL databases and one XML data 
base). Each database is stored in a different server, including the 
corresponding DBMS. The input to the service is a Simple representing a 
protein, while the output is a Collection with all possible interactions 
where that protein is participating.

In some cases, the service is not able to contact with a particular 
DBMS. Under this situation, rather than stopping the whole service 
execution and raise an exception for the whole Collection, the service 
could go ahead to the next server and report an exception with 
severity='warning' (assuming that at least one DBMS responded with 
useful information) for one or more Simples inside the Collection.

Even with only partial results, the service is still interesting enough 
for a client to wish it to continue. These types of situations are 
expected to arise -for example- when working with collections.




>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050902/26e5c58f/dgpisano-0002.vcf

From senger at ebi.ac.uk  Fri Sep  2 07:06:28 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 2 Sep 2005 12:06:28 +0100 (BST)
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBYv1.5
	- INB proposal
In-Reply-To: <43181C05.7090508@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>

> corresponding DBMS. The input to the service is a Simple representing a 
> protein, while the output is a Collection with all possible interactions 
> where that protein is participating.
>
   This is a good example because it nicely illustrates what Mark said,
and not a need for naming Simples in a Collection (IMHO) :-) :

   1) First, you cannot have a service that can return *all* protein
interactions. Such service is a sci-fi. So you go for "all possible"
protein interactions. Well, but when a DBMS source is not available, its
interactions are "not possible".
   2) Also, you do not know what interactions *would* be found in the
non-responding DBMS, so you cannot create any Simple representing such
non-returned interactions.
   3) And last, you can still inform the users about not covering all my
resources (this time) in a general warning in mobyException - but there is
really no sense to put this warniong in a collection itself.

   I must admit that I have not paid much attention to this topic when it
was explained in Malage. Because now, I really do not see why we need it.
(I hate to agree to much with Mark, it's dangerous because it is addictive
:-)).

   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)



From senger at ebi.ac.uk  Fri Sep  2 07:16:52 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 2 Sep 2005 12:16:52 +0100 (BST)
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <43182A24.1030800@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>

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

-- 
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)



From dgpisano at cnb.uam.es  Fri Sep  2 07:46:18 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri, 02 Sep 2005 13:46:18 +0200
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in
	bioMOBYv1.5- INB proposal
In-Reply-To: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
Message-ID: <43183B8A.2010607@cnb.uam.es>

Ok, I admit it was not a good example ;-)

Martin Senger escribi?:

>>corresponding DBMS. The input to the service is a Simple representing a 
>>protein, while the output is a Collection with all possible interactions 
>>where that protein is participating.
>>
>  This is a good example because it nicely illustrates what Mark said,
>and not a need for naming Simples in a Collection (IMHO) :-) :
>
>   1) First, you cannot have a service that can return *all* protein
>interactions. Such service is a sci-fi. So you go for "all possible"
>protein interactions. Well, but when a DBMS source is not available, its
>interactions are "not possible".
>  
>
Obviously. Maybe Jose Mar?a could explain it better, but we are not 
talking about the biology here, and probably the example should say *all 
possible protein interactions stored in my databases", ok. But the topic 
is why should I want to report an error for a Simple in a Collection, 
not if is possible to obtain all interactions for a given protein or not ;-)

The example (like all examples) should help us to extrapolate and 
imagine real use cases. In this case, I can imagine another service 
where I want to annotate an input probe list collection (those present 
in my microarray), for example against several databases with different 
information. Some of them are not available at execution time, or cannot 
find the required information because the query does not accept a given 
input character, so I want to inform the user that I have a warning for 
this specific probe, because I was not able to retrieve the information 
from the db due to whatever problem had happened.

>   2) Also, you do not know what interactions *would* be found in the
>non-responding DBMS, so you cannot create any Simple representing such
>non-returned interactions.
>  
>
Again, let's suppose my Simple needs the name *and* the type and 
description of the interaction, and that pieces of information are 
stored in different DB's. What if I can retrieve the name (ie, not an 
empty simple) but cannot retrieve its type, description, etc... (ie, my 
object is not empty but cannot be completed...)?

>   3) And last, you can still inform the users about not covering all my
>resources (this time) in a general warning in mobyException - but there is
>really no sense to put this warniong in a collection itself.
>  
>
I still think that the general case (a whole resource needed for the 
service or the collection is not available) is different than the 
particular case (a single error, warning or information could be 
generated for a particular Simple inside an input Collection, while the 
other Simples are all right).

>   I must admit that I have not paid much attention to this topic when it
>was explained in Malage. Because now, I really do not see why we need it.
>
Whatever. Is an optional part in the proposal, and depends on a BioMOBY 
specification change to be possible to implement, so there is no problem 
in removing it from the proposal if the community thinks is not 
necessary to specify it. We will save the file for future use if needed ;-)

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050902/8f080999/dgpisano-0002.vcf

From jmfernandez at cnb.uam.es  Fri Sep  2 08:53:54 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Fri, 02 Sep 2005 14:53:54 +0200
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <43184B62.5020606@cnb.uam.es>

> 
>>    And the last (but not an unimportant) general comment: the XML-based
>> API should be expressed as DTD (which is more preferable in this context,
>> XSD is not so human readable).
> 
> 
> I think we'll need a volunteer to help us out on that - I've used 
> DTD/XSDs, but never written one. Anyone?
> 

Well, I have developed many XML based formats, and I have used maaaany 
different tools since I began. I agree with Tom about XSD, . A useful 
open source tool is Pollo (pollo.sourceforge.net). Other ones are 
XMLmind XML Editor (http://www.xmlmind.com/xmleditor/) and oXygen 
(http://www.oxygenxml.com/), which I used to generate the documentation 
for a XML Schema I developed using Pollo (see 
http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).

I'm quite busy now, but if you give me one week I can do that.

	Best Regards,
		Jos? Mar?a

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)


From edward.kawas at gmail.com  Fri Sep  2 08:53:47 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 2 Sep 2005 05:53:47 -0700
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
Message-ID: <43184b5f.14a53cea.215f.410d@mx.gmail.com>

Martin,

Can you explain this a little more because I don?t
understand what you are trying to say.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Friday, September 02, 2005 4:17 AM
> To: David Gonz?lez Pisano
> Cc: Mark Wilkinson; Moby Developers
> Subject: [MOBY-dev] problem with article names?
> 
> 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
> 
> --
> 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




From senger at ebi.ac.uk  Fri Sep  2 09:13:18 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 2 Sep 2005 14:13:18 +0100 (BST)
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <43184b5f.14a53cea.215f.410d@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509021406450.695974-100000@ice.ebi.ac.uk>

> Can you explain this a little more because I don?t
> understand what you are trying to say.
>
   So perhaps I am on a wrong track. But here it is:

   A service has to have article names for its inputs and outputs
(according the new API).
   An example: MyService produces GenericSequence with an article name
"Sequence". YourService is registered as consumig also GenericSequence but
with an article name "QuerySequence".
   I put in Taverna a workflow: MyService --> YourService.
   MyService produces a GenericSequence with a name "Sequence" - because
that's how it was registered. YourSequence gets data from MySequence. It
expect an article name "QuerySequence" but wht it gets is a sequence with
an article name "Sequence". YourService starts to wonder what the hell
should I do with it?
   Because if YourService is able to accept any name, then why we bother
to have them at all?
   Thsi is a situation, most common situation, where a service has only
one input and one output.

   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)




From senger at ebi.ac.uk  Fri Sep  2 09:17:13 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 2 Sep 2005 14:17:13 +0100 (BST)
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <43184B62.5020606@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>

> for a XML Schema I developed using Pollo (see 
> http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).
>
   That's exactly I was hoping in... Good examples.
   Just tell me where the pieces of documentation come from? I guess they
must come from the XSD file itself - is there a "documentation" tag for
it, or what?

   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)



From markw at illuminae.com  Fri Sep  2 11:28:04 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 02 Sep 2005 08:28:04 -0700
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
Message-ID: <1125674884.29942.26.camel@bioinfo.icapture.ubc.ca>


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



From markw at illuminae.com  Fri Sep  2 11:41:15 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 02 Sep 2005 08:41:15 -0700
Subject: [moby] Re: [personal] Re: [MOBY-dev] [RFC] Exception Reporting
	in bioMOBYv1.5- INB proposal
In-Reply-To: <43183B8A.2010607@cnb.uam.es>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
	<43183B8A.2010607@cnb.uam.es>
Message-ID: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>

On Fri, 2005-09-02 at 13:46 +0200, David Gonz?lez Pisano wrote:

> Again, let's suppose my Simple needs the name *and* the type and 
> description of the interaction, and that pieces of information are 
> stored in different DB's. What if I can retrieve the name (ie, not an 
> empty simple) but cannot retrieve its type, description, etc... (ie, my 
> object is not empty but cannot be completed...)?

That's a great example, and does make the case quite convincingly...

...but *please* don't use articleName to achieve this!  :-)

M



-- 
"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



From markw at illuminae.com  Fri Sep  2 11:41:15 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 02 Sep 2005 08:41:15 -0700
Subject: [moby] Re: [personal] Re: [MOBY-dev] [RFC] Exception Reporting
	in bioMOBYv1.5- INB proposal
In-Reply-To: <43183B8A.2010607@cnb.uam.es>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
	<43183B8A.2010607@cnb.uam.es>
Message-ID: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>

On Fri, 2005-09-02 at 13:46 +0200, David Gonz?lez Pisano wrote:

> Again, let's suppose my Simple needs the name *and* the type and 
> description of the interaction, and that pieces of information are 
> stored in different DB's. What if I can retrieve the name (ie, not an 
> empty simple) but cannot retrieve its type, description, etc... (ie, my 
> object is not empty but cannot be completed...)?

That's a great example, and does make the case quite convincingly...

...but *please* don't use articleName to achieve this!  :-)

M



-- 
"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



From dgpisano at cnb.uam.es  Fri Sep  2 06:32:04 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri, 02 Sep 2005 12:32:04 +0200
Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.7 - INBproposal
In-Reply-To: <Pine.OSF.4.21.0508310222530.1148966-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0508310222530.1148966-100000@mozart.ebi.ac.uk>
Message-ID: <43182A24.1030800@cnb.uam.es>

Martin Senger escribi?:

>Thanks for the updated document. Before I express my comments to it
>here is a few bits regarding RFC procedure for this proposal (assuming
>that we agreed on an RFC procedure as, or close to, suggested in
>previous emails:
>
>1) I second the proposal (so it can become an RFC) 
>
Thanks. Let's move this quickly and go over the asynchony one ;-)

>2) I suggest to resolve it (accept or refuse) before September 15 (so
>this is an RFC calendar). Concretely, I propose that Mark will ask
>selected voters after this date to vote on it. (BTW, I like and
>support his idea to have a year-long tenure on the voting list (that's
>actually very close why OMG has its Architecture Board also with
>rotating, and *dedicated*, people).
>
>Now back to the proposal, here are my comments (I suggest that those
>comments that are acceptable by the INB authors, and that are not in
>contradiction with the email discussion, will be incorporate and a new
>draft will be circulated - perhaps already without reasoning).  
>
Here you have the new draft (version 1.7, version 1.6 was internal review)

>Generally, I like the proposal, my comments are only about details.
>
>1) The attribute names 'Value' and 'Description' are not
>intuitive. They should express more what they are about. What about
>"errorCode" (or only "code") and "errorMessage" (or only "message")? 
>
Changed to "exceptionCode" and "exceptionMessage" so we refer to all 
exceptions (errors, warnings and other information messages). 
"errorCode" sounds to me like "only for errors"...

>2) I know that the article name in Simples in Collection is an
>optional part of the proposal - but I agree with Mark that using there
>again the term "articleName" is bad (too overloaded). What about to
>use there a completely different tag, like "elementId"?
>
>>From this change (if accepted) follows at once that the attribute name
>in mobyException should not be "refArticleName" (because sometimes it
>refers to a non-article name) - so why not to call it just a "ref", or
>"refElement"?
>  
>
Let's name it refElement and keep on mentioning the optional part if 
Mark agrees that naming Simples inside Collections could be possible. 
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"?

>3) I would like to have (in the exception API handling) a remark that
>the clients are obliged to be aware that a service can also raise an
>exception that will be delivered in the SOAP envelope (that is a
>standard way). As I said, good clients have to do it anyway (because
>your service does not have always full control what to return back) -
>so I would keep this option there.
>  
>
Is mentioned in the last part of the document, but there is nothing we 
propose about the structure and content of the SOAP Fail payload... 
Should that be discussed, or better we focus on the MOBY part and just 
mention that the clients should be aware that some exceptions could be 
in the SOAP layers (ie, write your SOAP exception handling code in your 
client for better exception catching in all the layers of the 
communication)?

>4) Just to keep in synch with other software projects, I would add one
>more severity level - a simple "message" (so we would have, errors,
>warnings, messages).
>  
>
That would be, for example:

a. Exception severity (*severity* attribute in *mobyException* tag)
Values: *error*  | *warning *|* information*

>5) The list of codes is not always clear:
>   - should the sub-phrases in 201 be distinguish by a separate code?
>   - 621 (service not available) means actually that the resources the
>service wishes to use are not available (because if it was a service
>itself, it would not have any chance to report it, that would be a
>soap exception mentioned above),
>   - 622 (malformed Moby response) - what is a response here? - and
>anyway, this may be difficult to catch (I know in SOAP::Lite you do
>not get control only when the whole XML is parsed)
>   - why do you call some codes "client-side detected errors"?
>
>   - generally, I would put less codes and rather to define how
>service providers can expressed their own service-specific codes (by
>saying in which range they should put such specific codes)
>  
>
Rewritten the errors part. The main objetive, in our opinion, is to list 
the common errors that could occur in the execution of a web service 
(list taken from LSAE) _and_ the errors common to all bioMOBY services 
(as extension to LSAE). Only the errors that are particular to specific 
services are should not be included. We are using the recommendations in 
LSAE to extend the error codes range.

Note that there are a number of errors (service not available, for 
example) that only the client can report. We can call them client-side 
detected errors and give some codes, or just skip them, reduce to scope 
of this proposal only to the bioMOBY errors reportable by the services, 
and give the clients the freedom to report client-side detected errors 
as they want.

>6) Some typos:
>   - articlename attribute should be articleName
>   - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is
>something else in Biomoby API)
>  
>
Changed that

>7) Attributes in mobyException (refArticleName, or whatever name we
>will agree on, and reqQuery) should be made optional - so an exception
>can refer to the whole response (or to a whole query if only reqQuery
>is present).
>  
>
I agree, that allows us to report an exception for the whole mobyContent 
(it was in the motivations but no clearly stated in the specification 
proposal). Already added.

>   With regards,
>   Martin
>  
>
Thanks for the comments and corrections,

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v1.7.doc
Type: application/msword
Size: 187392 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050902/938c216c/0501INB-ExceptionReporting-v1.7-0002.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050902/938c216c/dgpisano-0002.vcf

From carrere at toulouse.inra.fr  Fri Sep  2 14:28:57 2005
From: carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Fri, 02 Sep 2005 20:28:57 +0200
Subject: [MOBY-dev] Server maintenance: services unreachable
	bioinfo.genopole-toulouse.prd.fr
In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>	<43183B8A.2010607@cnb.uam.es>
	<1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>
Message-ID: <431899E9.3060403@toulouse.inra.fr>

Due to maintenance on our server (inverter change), services provided by 
*bioinfo.genopole-toulouse.prd*.fr will be unreachable next *Tuesday 
(September 6th)* during  5 hours (10 a.m. to 3 p.m. GMT+1).

Sebastien Carrere

-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.18/87 - Release Date: 01/09/2005

From senger at ebi.ac.uk  Fri Sep  2 23:03:03 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sat, 3 Sep 2005 04:03:03 +0100 (BST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <1125674884.29942.26.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>

> 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)



From senger at ebi.ac.uk  Sun Sep  4 10:45:31 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun, 4 Sep 2005 15:45:31 +0100 (BST)
Subject: [MOBY-dev] jMoby: third-parties libraries update
Message-ID: <Pine.OSF.4.21.0509041542170.1093336-100000@mozart.ebi.ac.uk>

I have update Axis libraries to its latest version. Also alltools2 were
rebuilt considerably (and alltools.jar removed). Therefore, please start
your next session with jMoby by:
   ./build.sh
which should update your lib directory. After that do:
   ./build-dev.sh clean compile

I tried to test it as much as I was able... If you still find a problem
please report it and I will fix it asap.

   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)



From jmfernandez at cnb.uam.es  Mon Sep  5 11:26:09 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 05 Sep 2005 17:26:09 +0200
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>
Message-ID: <431C6391.5080708@cnb.uam.es>



Martin Senger wrote:
>>for a XML Schema I developed using Pollo (see 
>>http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).
>>
> 
>    That's exactly I was hoping in... Good examples.
>    Just tell me where the pieces of documentation come from? I guess they
> must come from the XSD file itself - is there a "documentation" tag for
> it, or what?

Yes, it is. XML Schema allows you to create a xsd:annotation inside 
almost any XML Schema tag (attribute and element declarations, keys, 
etc...), and inside xsd:annotation you can add one or more 
xsd:documentation tags. If you look inside 
http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML.xsd, you will see the 
xsd:documentation tag.

David uses XMLSpy and he has told me that XMLSpy documentation is 
translated to xsd:documentation tags when a XML Schema is generated.

	Best Regards,
		Jos? Mar?a

> 
>    Martin
> 

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)


From jmfernandez at cnb.uam.es  Mon Sep  5 16:28:17 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 05 Sep 2005 22:28:17 +0200
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>
Message-ID: <431CAA61.8030009@cnb.uam.es>

Hi everybody,
	there is a fourth option, where it is not mandatory to have an article 
name for primary inputs: primary inputs must be submitted in the same 
order as they were declared at service registration, and they are 
expected to arrive so to the service. Even it could happen that no 
primary input had an article name!

	But there is a drawback: service coding should be more coupled to 
service declaration in order to take into account the input parameters 
order, so this option is more error-prone.

	Best Regards,
		Jos? Mar?a

Martin Senger wrote:
>>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
> 

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)


From rroyo at lsi.upc.edu  Tue Sep  6 02:43:10 2005
From: rroyo at lsi.upc.edu (rroyo@lsi.upc.edu)
Date: Tue, 6 Sep 2005 08:43:10 +0200 (MET DST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
Message-ID: <9177548284rroyo@lsi.upc.es>

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
-----------------------------------------------------







From rroyo at lsi.upc.edu  Tue Sep  6 02:43:10 2005
From: rroyo at lsi.upc.edu (rroyo@lsi.upc.edu)
Date: Tue, 6 Sep 2005 08:43:10 +0200 (MET DST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
Message-ID: <9177548284rroyo@lsi.upc.es>

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
-----------------------------------------------------







From senger at ebi.ac.uk  Tue Sep  6 03:24:47 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 6 Sep 2005 08:24:47 +0100 (BST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <9177548284rroyo@lsi.upc.es>
Message-ID: <Pine.OSF.4.21.0509060822110.1434283-100000@mozart.ebi.ac.uk>

> 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?
>
   I said that the option 3 applies only for services with single input
and single output. In your example, the article names are mandatory, and
workflow engine *has* to add them if the services should be connected.
   But because the case with one-one services is the most often, I
considered worth to allow to skip article names.

   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)



From senger at ebi.ac.uk  Tue Sep  6 03:24:47 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 6 Sep 2005 08:24:47 +0100 (BST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <9177548284rroyo@lsi.upc.es>
Message-ID: <Pine.OSF.4.21.0509060822110.1434283-100000@mozart.ebi.ac.uk>

> 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?
>
   I said that the option 3 applies only for services with single input
and single output. In your example, the article names are mandatory, and
workflow engine *has* to add them if the services should be connected.
   But because the case with one-one services is the most often, I
considered worth to allow to skip article names.

   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)



From Pieter.Neerincx at wur.nl  Tue Sep  6 12:30:46 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 6 Sep 2005 18:30:46 +0200
Subject: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <4315524C.6040307@toulouse.inra.fr>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
Message-ID: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>

Hi,

I have some services that query databases. The result can be nothing,  
a single object, or it can be several thousand objects.... I was also  
running into trouble with big XML documents. I'm using the Perl API,  
which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the  
job done for small xml structures, but for big ones it's a mess.  
Firstly, SOAP::Lite loads the entire message in memory as one big  
piece (hence no chunks or streams etc.). Secondly, if you use  
Data::Dumper to have a look at the perl data structures that are  
built, you will see that the same info is copied two, three or more  
times. There's quite a bit of redundancy in there. As a result the  
expansion factor for parsing xml by SOAP::lite is between 10 and 13  
(according to people on the SOAP::Lite mailing list). That means a 10  
MB xml document will become 100-130 MB in memory. Several clients  
accessing several of these services at the same time will simply  
bring our servers on their knees :(. If there are people on the  
mailinglist with experience in handling laaaaaarge inputs and/or  
outputs I'd really appreciate it if you drop a few lines...

So far I have looked at working with attachments. Not really an  
option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy  
combo. xsltproc sounds good. I currently changed my services to send  
only a pointer (URL) as result which the client has to fetch. For a  
quick and dirty workaround it works beautifully, but from a design  
point of view it bad bad bad :( ...

Cheers,

Pi


On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:

> The MOBY message that I wanted to parse was a 12 Megabyte one.
> The web-service concerned is:
>
> name: ImgaGetTigrXMLEntriesFromKeyword
> uri: bioinfo.genopole-toulouse.prd.fr
> input: String
> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of / 
> IMGA_Accession, as IMGA_Accession
>
> I think this is a little bit extreme, but it works fine now.
>
> Sebastien
>
> Chunyan Wang wrote:
>
>
>> Hi,
>> I changed TimeOut from default to 50000 in the Apache config to  
>> fix timeout problem.
>> How big was your XML file when you had problem?
>> Cheers,
>>
>> Joyce
>>
>> Sebastien Carrere wrote:
>>
>>
>>> Hi all,
>>>
>>> I got the same problem when I wanted to parse huge XML files.
>>> That's why I have written a clone of CommonSub.pm using  
>>> "xsltproc" to parse MOBY message.
>>> Then the parsing time problem was removed.
>>>
>>> However, how do you fixed timeout problem ?
>>>
>>> Sebastien
>>>
>>> Chunyan Wang wrote:
>>>
>>>
>>>>
>>>>
>>>> Martin Senger wrote:
>>>>
>>>>
>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   What language are you using, what XML library in that language?
>>>>>
>>>>>
>>>> I am using Perl and XML::DOM. I am using  
>>>> "genericServiceInputParser($data)" to parse the input sequence  
>>>> in my service.
>>>> By the way, I want to let you know I fixed timeout problem.  
>>>> Thanks for your suggestion.
>>>>
>>>> Joyce
>>>>
>>>>
>>>>>   Martin
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>
> -- 
> __________________________________________________________
>
> Sebastien CARRERE                        LIPM (INRA-CNRS)
>                      B.P.52627 -- 31326 CASTANET TOLOSAN
> tel:(33) 5-61-28-53-29
> fax:(33) 5-61-28-50-61
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From markw at illuminae.com  Tue Sep  6 14:05:19 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Tue, 06 Sep 2005 11:05:19 -0700
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca> <4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
Message-ID: <1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>

This is indeed still an issue, and you are right about the pain of using
SOAP::Lite + MIME::Tools in Perl (though I know that is soon going to be
better, since we are now using an apparently stable combination of
these, plus SOAP attachemnts, for our own LSID resolver!  However these
are not available on CPAN yet AFAIK).

I recall that Lincoln S. wrote to Paul K. several years ago asking if it
would ever be possible to swap-out the DOM parser in SOAP::Lite for a
SAX parser in order to overcome this limitation (and also with an eye to
streaming responses...), but I don't think this even made it on to the
SOAP::Lite radar so I doubt that the solution is going to come from that
community anytime soon.

So... I can't advise anything, but perhaps others in the MOBY community
can!

M


On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
> Hi,
> 
> I have some services that query databases. The result can be nothing,  
> a single object, or it can be several thousand objects.... I was also  
> running into trouble with big XML documents. I'm using the Perl API,  
> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the  
> job done for small xml structures, but for big ones it's a mess.  
> Firstly, SOAP::Lite loads the entire message in memory as one big  
> piece (hence no chunks or streams etc.). Secondly, if you use  
> Data::Dumper to have a look at the perl data structures that are  
> built, you will see that the same info is copied two, three or more  
> times. There's quite a bit of redundancy in there. As a result the  
> expansion factor for parsing xml by SOAP::lite is between 10 and 13  
> (according to people on the SOAP::Lite mailing list). That means a 10  
> MB xml document will become 100-130 MB in memory. Several clients  
> accessing several of these services at the same time will simply  
> bring our servers on their knees :(. If there are people on the  
> mailinglist with experience in handling laaaaaarge inputs and/or  
> outputs I'd really appreciate it if you drop a few lines...
> 
> So far I have looked at working with attachments. Not really an  
> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy  
> combo. xsltproc sounds good. I currently changed my services to send  
> only a pointer (URL) as result which the client has to fetch. For a  
> quick and dirty workaround it works beautifully, but from a design  
> point of view it bad bad bad :( ...
> 
> Cheers,
> 
> Pi
> 
> 
> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
> 
> > The MOBY message that I wanted to parse was a 12 Megabyte one.
> > The web-service concerned is:
> >
> > name: ImgaGetTigrXMLEntriesFromKeyword
> > uri: bioinfo.genopole-toulouse.prd.fr
> > input: String
> > Output(s): /Collection of /text-xml, as TIGRXML and /Collection of / 
> > IMGA_Accession, as IMGA_Accession
> >
> > I think this is a little bit extreme, but it works fine now.
> >
> > Sebastien
> >
> > Chunyan Wang wrote:
> >
> >
> >> Hi,
> >> I changed TimeOut from default to 50000 in the Apache config to  
> >> fix timeout problem.
> >> How big was your XML file when you had problem?
> >> Cheers,
> >>
> >> Joyce
> >>
> >> Sebastien Carrere wrote:
> >>
> >>
> >>> Hi all,
> >>>
> >>> I got the same problem when I wanted to parse huge XML files.
> >>> That's why I have written a clone of CommonSub.pm using  
> >>> "xsltproc" to parse MOBY message.
> >>> Then the parsing time problem was removed.
> >>>
> >>> However, how do you fixed timeout problem ?
> >>>
> >>> Sebastien
> >>>
> >>> Chunyan Wang wrote:
> >>>
> >>>
> >>>>
> >>>>
> >>>> Martin Senger wrote:
> >>>>
> >>>>
> >>>>>> Could anybody explain this "problem" to me? Thanks.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>   What language are you using, what XML library in that language?
> >>>>>
> >>>>>
> >>>> I am using Perl and XML::DOM. I am using  
> >>>> "genericServiceInputParser($data)" to parse the input sequence  
> >>>> in my service.
> >>>> By the way, I want to let you know I fixed timeout problem.  
> >>>> Thanks for your suggestion.
> >>>>
> >>>> Joyce
> >>>>
> >>>>
> >>>>>   Martin
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev at biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >>
> >>
> >
> > -- 
> > __________________________________________________________
> >
> > Sebastien CARRERE                        LIPM (INRA-CNRS)
> >                      B.P.52627 -- 31326 CASTANET TOLOSAN
> > tel:(33) 5-61-28-53-29
> > fax:(33) 5-61-28-50-61
> >
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
"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



From senger at ebi.ac.uk  Tue Sep  6 19:40:59 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 7 Sep 2005 00:40:59 +0100 (BST)
Subject: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
Message-ID: <Pine.OSF.4.21.0509070038370.1284933-100000@mozart.ebi.ac.uk>

Although I am a Perl programmer I am not a Perl-service provider so my
SOAP::Lite vs. XML parses experiences are limited, but I recall that some
parsing problems (not all) may be overcome by sending data as byte arrays,
not strings (and Biomoby API dictates that both clients and servers
must be ready to accept both such formats). Have you tried that?

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)



From Pieter.Neerincx at wur.nl  Wed Sep  7 07:12:56 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 7 Sep 2005 13:12:56 +0200
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
Message-ID: <84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>


On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:

> This is indeed still an issue, and you are right about the pain of  
> using
> SOAP::Lite + MIME::Tools in Perl (though I know that is soon going  
> to be
> better, since we are now using an apparently stable combination of
> these, plus SOAP attachemnts, for our own LSID resolver!  However  
> these
> are not available on CPAN yet AFAIK).

Ok, so there is a combination that really works :). Could you please  
tell me which version of SOAP::Lite and MIME::Tools you are mixing to  
make SOAP with attachments work?


>
> I recall that Lincoln S. wrote to Paul K. several years ago asking  
> if it
> would ever be possible to swap-out the DOM parser in SOAP::Lite for a
> SAX parser in order to overcome this limitation (and also with an  
> eye to
> streaming responses...), but I don't think this even made it on to the
> SOAP::Lite radar so I doubt that the solution is going to come from  
> that
> community anytime soon.

I doubt that as well. If I find some solution to streaming the SOAP  
XML I'll post it to the list...

Thanks,

Pieter

>
> So... I can't advise anything, but perhaps others in the MOBY  
> community
> can!
>
> M
>
>
> On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
>
>> Hi,
>>
>> I have some services that query databases. The result can be nothing,
>> a single object, or it can be several thousand objects.... I was also
>> running into trouble with big XML documents. I'm using the Perl API,
>> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
>> job done for small xml structures, but for big ones it's a mess.
>> Firstly, SOAP::Lite loads the entire message in memory as one big
>> piece (hence no chunks or streams etc.). Secondly, if you use
>> Data::Dumper to have a look at the perl data structures that are
>> built, you will see that the same info is copied two, three or more
>> times. There's quite a bit of redundancy in there. As a result the
>> expansion factor for parsing xml by SOAP::lite is between 10 and 13
>> (according to people on the SOAP::Lite mailing list). That means a 10
>> MB xml document will become 100-130 MB in memory. Several clients
>> accessing several of these services at the same time will simply
>> bring our servers on their knees :(. If there are people on the
>> mailinglist with experience in handling laaaaaarge inputs and/or
>> outputs I'd really appreciate it if you drop a few lines...
>>
>> So far I have looked at working with attachments. Not really an
>> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
>> combo. xsltproc sounds good. I currently changed my services to send
>> only a pointer (URL) as result which the client has to fetch. For a
>> quick and dirty workaround it works beautifully, but from a design
>> point of view it bad bad bad :( ...
>>
>> Cheers,
>>
>> Pi
>>
>>
>> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
>>
>>
>>> The MOBY message that I wanted to parse was a 12 Megabyte one.
>>> The web-service concerned is:
>>>
>>> name: ImgaGetTigrXMLEntriesFromKeyword
>>> uri: bioinfo.genopole-toulouse.prd.fr
>>> input: String
>>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /
>>> IMGA_Accession, as IMGA_Accession
>>>
>>> I think this is a little bit extreme, but it works fine now.
>>>
>>> Sebastien
>>>
>>> Chunyan Wang wrote:
>>>
>>>
>>>
>>>> Hi,
>>>> I changed TimeOut from default to 50000 in the Apache config to
>>>> fix timeout problem.
>>>> How big was your XML file when you had problem?
>>>> Cheers,
>>>>
>>>> Joyce
>>>>
>>>> Sebastien Carrere wrote:
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I got the same problem when I wanted to parse huge XML files.
>>>>> That's why I have written a clone of CommonSub.pm using
>>>>> "xsltproc" to parse MOBY message.
>>>>> Then the parsing time problem was removed.
>>>>>
>>>>> However, how do you fixed timeout problem ?
>>>>>
>>>>> Sebastien
>>>>>
>>>>> Chunyan Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Martin Senger wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   What language are you using, what XML library in that  
>>>>>>> language?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I am using Perl and XML::DOM. I am using
>>>>>> "genericServiceInputParser($data)" to parse the input sequence
>>>>>> in my service.
>>>>>> By the way, I want to let you know I fixed timeout problem.
>>>>>> Thanks for your suggestion.
>>>>>>
>>>>>> Joyce
>>>>>>
>>>>>>
>>>>>>
>>>>>>>   Martin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> __________________________________________________________
>>>
>>> Sebastien CARRERE                        LIPM (INRA-CNRS)
>>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
>>> tel:(33) 5-61-28-53-29
>>> fax:(33) 5-61-28-50-61
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> -- 
> "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
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From markw at illuminae.com  Wed Sep  7 12:39:59 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 07 Sep 2005 09:39:59 -0700
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca> <4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
	<84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
Message-ID: <1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>

SOAP::Lite
$Id: Lite.pm,v 1.11 2003/08/11 05:54:51 paulclinger Exp $

MIME::Tools
$VERSION = "5.417";


M


On Wed, 2005-09-07 at 13:12 +0200, Pieter Neerincx wrote:
> On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:
> 
> > This is indeed still an issue, and you are right about the pain of  
> > using
> > SOAP::Lite + MIME::Tools in Perl (though I know that is soon going  
> > to be
> > better, since we are now using an apparently stable combination of
> > these, plus SOAP attachemnts, for our own LSID resolver!  However  
> > these
> > are not available on CPAN yet AFAIK).
> 
> Ok, so there is a combination that really works :). Could you please  
> tell me which version of SOAP::Lite and MIME::Tools you are mixing to  
> make SOAP with attachments work?
> 
> 
> >
> > I recall that Lincoln S. wrote to Paul K. several years ago asking  
> > if it
> > would ever be possible to swap-out the DOM parser in SOAP::Lite for a
> > SAX parser in order to overcome this limitation (and also with an  
> > eye to
> > streaming responses...), but I don't think this even made it on to the
> > SOAP::Lite radar so I doubt that the solution is going to come from  
> > that
> > community anytime soon.
> 
> I doubt that as well. If I find some solution to streaming the SOAP  
> XML I'll post it to the list...
> 
> Thanks,
> 
> Pieter
> 
> >
> > So... I can't advise anything, but perhaps others in the MOBY  
> > community
> > can!
> >
> > M
> >
> >
> > On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
> >
> >> Hi,
> >>
> >> I have some services that query databases. The result can be nothing,
> >> a single object, or it can be several thousand objects.... I was also
> >> running into trouble with big XML documents. I'm using the Perl API,
> >> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
> >> job done for small xml structures, but for big ones it's a mess.
> >> Firstly, SOAP::Lite loads the entire message in memory as one big
> >> piece (hence no chunks or streams etc.). Secondly, if you use
> >> Data::Dumper to have a look at the perl data structures that are
> >> built, you will see that the same info is copied two, three or more
> >> times. There's quite a bit of redundancy in there. As a result the
> >> expansion factor for parsing xml by SOAP::lite is between 10 and 13
> >> (according to people on the SOAP::Lite mailing list). That means a 10
> >> MB xml document will become 100-130 MB in memory. Several clients
> >> accessing several of these services at the same time will simply
> >> bring our servers on their knees :(. If there are people on the
> >> mailinglist with experience in handling laaaaaarge inputs and/or
> >> outputs I'd really appreciate it if you drop a few lines...
> >>
> >> So far I have looked at working with attachments. Not really an
> >> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
> >> combo. xsltproc sounds good. I currently changed my services to send
> >> only a pointer (URL) as result which the client has to fetch. For a
> >> quick and dirty workaround it works beautifully, but from a design
> >> point of view it bad bad bad :( ...
> >>
> >> Cheers,
> >>
> >> Pi
> >>
> >>
> >> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
> >>
> >>
> >>> The MOBY message that I wanted to parse was a 12 Megabyte one.
> >>> The web-service concerned is:
> >>>
> >>> name: ImgaGetTigrXMLEntriesFromKeyword
> >>> uri: bioinfo.genopole-toulouse.prd.fr
> >>> input: String
> >>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /
> >>> IMGA_Accession, as IMGA_Accession
> >>>
> >>> I think this is a little bit extreme, but it works fine now.
> >>>
> >>> Sebastien
> >>>
> >>> Chunyan Wang wrote:
> >>>
> >>>
> >>>
> >>>> Hi,
> >>>> I changed TimeOut from default to 50000 in the Apache config to
> >>>> fix timeout problem.
> >>>> How big was your XML file when you had problem?
> >>>> Cheers,
> >>>>
> >>>> Joyce
> >>>>
> >>>> Sebastien Carrere wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I got the same problem when I wanted to parse huge XML files.
> >>>>> That's why I have written a clone of CommonSub.pm using
> >>>>> "xsltproc" to parse MOBY message.
> >>>>> Then the parsing time problem was removed.
> >>>>>
> >>>>> However, how do you fixed timeout problem ?
> >>>>>
> >>>>> Sebastien
> >>>>>
> >>>>> Chunyan Wang wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Martin Senger wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> Could anybody explain this "problem" to me? Thanks.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>   What language are you using, what XML library in that  
> >>>>>>> language?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> I am using Perl and XML::DOM. I am using
> >>>>>> "genericServiceInputParser($data)" to parse the input sequence
> >>>>>> in my service.
> >>>>>> By the way, I want to let you know I fixed timeout problem.
> >>>>>> Thanks for your suggestion.
> >>>>>>
> >>>>>> Joyce
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>   Martin
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MOBY-dev mailing list
> >>>>>> MOBY-dev at biomoby.org
> >>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev at biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> -- 
> >>> __________________________________________________________
> >>>
> >>> Sebastien CARRERE                        LIPM (INRA-CNRS)
> >>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
> >>> tel:(33) 5-61-28-53-29
> >>> fax:(33) 5-61-28-50-61
> >>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev at biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx at wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> > -- 
> > "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
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
"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



From carrere at toulouse.inra.fr  Thu Sep  8 10:49:16 2005
From: carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Thu, 08 Sep 2005 16:49:16 +0200
Subject: [moby] Re: [MOBY-dev] Question on parser
In-Reply-To: <1125414060.19194.26.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>	<431365E1.7080800@cpsc.ucalgary.ca>
	<4313FE70.80308@toulouse.inra.fr>
	<1125414060.19194.26.camel@bioinfo.icapture.ubc.ca>
Message-ID: <43204F6C.1040409@toulouse.inra.fr>

I added the Perl Module (i) we develloped in Toulouse and the mandatory 
XSLT style-sheet (ii) in the CVS repository.

i.  moby-live/Perl/MOBY/MOBYXSLT.pm
ii. moby-live/Perl/MOBY/xsl/parseMobyMessage.xsl

If you want more information (services examples using this module), do 
not hesitate.

Sebastien




Mark Wilkinson wrote:

>On Tue, 2005-08-30 at 08:36 +0200, Sebastien Carrere wrote:
>
>  
>
>>That's why I have written a clone of CommonSub.pm using "xsltproc" to 
>>parse MOBY message.
>>    
>>
>
>Would you be willing to add this to the CVS?
>
>
>  
>
>>However, how do you fixed timeout problem ?
>>    
>>
>
>In the 1.0 release we should have a spec for asynchronous services, so
>this problem will hopefully not be as severe...
>
>M
>
>
>  
>

-- 
__________________________________________________________

Sebastien CARRERE                        LIPM (INRA-CNRS)
                      B.P.52627 -- 31326 CASTANET TOLOSAN
tel:(33) 5-61-28-53-29
fax:(33) 5-61-28-50-61
				



From Pieter.Neerincx at wur.nl  Mon Sep 12 10:56:13 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 12 Sep 2005 16:56:13 +0200
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
	<84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
	<1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>
Message-ID: <A66B84DF-2937-4334-B42C-6158A9832B11@wur.nl>

On 7-Sep-2005, at 6:39 PM, Mark Wilkinson wrote:

> SOAP::Lite
> $Id: Lite.pm,v 1.11 2003/08/11 05:54:51 paulclinger Exp $
>
> MIME::Tools
> $VERSION = "5.417";

Did you apply any custom patches? Or are those simply the defaults?

Pi

>
> M
>
>
> On Wed, 2005-09-07 at 13:12 +0200, Pieter Neerincx wrote:
>
>> On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:
>>
>>
>>> This is indeed still an issue, and you are right about the pain of
>>> using
>>> SOAP::Lite + MIME::Tools in Perl (though I know that is soon going
>>> to be
>>> better, since we are now using an apparently stable combination of
>>> these, plus SOAP attachemnts, for our own LSID resolver!  However
>>> these
>>> are not available on CPAN yet AFAIK).
>>>
>>
>> Ok, so there is a combination that really works :). Could you please
>> tell me which version of SOAP::Lite and MIME::Tools you are mixing to
>> make SOAP with attachments work?
>>
>>
>>
>>>
>>> I recall that Lincoln S. wrote to Paul K. several years ago asking
>>> if it
>>> would ever be possible to swap-out the DOM parser in SOAP::Lite  
>>> for a
>>> SAX parser in order to overcome this limitation (and also with an
>>> eye to
>>> streaming responses...), but I don't think this even made it on  
>>> to the
>>> SOAP::Lite radar so I doubt that the solution is going to come from
>>> that
>>> community anytime soon.
>>>
>>
>> I doubt that as well. If I find some solution to streaming the SOAP
>> XML I'll post it to the list...
>>
>> Thanks,
>>
>> Pieter
>>
>>
>>>
>>> So... I can't advise anything, but perhaps others in the MOBY
>>> community
>>> can!
>>>
>>> M
>>>
>>>
>>> On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I have some services that query databases. The result can be  
>>>> nothing,
>>>> a single object, or it can be several thousand objects.... I was  
>>>> also
>>>> running into trouble with big XML documents. I'm using the Perl  
>>>> API,
>>>> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
>>>> job done for small xml structures, but for big ones it's a mess.
>>>> Firstly, SOAP::Lite loads the entire message in memory as one big
>>>> piece (hence no chunks or streams etc.). Secondly, if you use
>>>> Data::Dumper to have a look at the perl data structures that are
>>>> built, you will see that the same info is copied two, three or more
>>>> times. There's quite a bit of redundancy in there. As a result the
>>>> expansion factor for parsing xml by SOAP::lite is between 10 and 13
>>>> (according to people on the SOAP::Lite mailing list). That means  
>>>> a 10
>>>> MB xml document will become 100-130 MB in memory. Several clients
>>>> accessing several of these services at the same time will simply
>>>> bring our servers on their knees :(. If there are people on the
>>>> mailinglist with experience in handling laaaaaarge inputs and/or
>>>> outputs I'd really appreciate it if you drop a few lines...
>>>>
>>>> So far I have looked at working with attachments. Not really an
>>>> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
>>>> combo. xsltproc sounds good. I currently changed my services to  
>>>> send
>>>> only a pointer (URL) as result which the client has to fetch. For a
>>>> quick and dirty workaround it works beautifully, but from a design
>>>> point of view it bad bad bad :( ...
>>>>
>>>> Cheers,
>>>>
>>>> Pi
>>>>
>>>>
>>>> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
>>>>
>>>>
>>>>
>>>>> The MOBY message that I wanted to parse was a 12 Megabyte one.
>>>>> The web-service concerned is:
>>>>>
>>>>> name: ImgaGetTigrXMLEntriesFromKeyword
>>>>> uri: bioinfo.genopole-toulouse.prd.fr
>>>>> input: String
>>>>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection  
>>>>> of /
>>>>> IMGA_Accession, as IMGA_Accession
>>>>>
>>>>> I think this is a little bit extreme, but it works fine now.
>>>>>
>>>>> Sebastien
>>>>>
>>>>> Chunyan Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>> I changed TimeOut from default to 50000 in the Apache config to
>>>>>> fix timeout problem.
>>>>>> How big was your XML file when you had problem?
>>>>>> Cheers,
>>>>>>
>>>>>> Joyce
>>>>>>
>>>>>> Sebastien Carrere wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I got the same problem when I wanted to parse huge XML files.
>>>>>>> That's why I have written a clone of CommonSub.pm using
>>>>>>> "xsltproc" to parse MOBY message.
>>>>>>> Then the parsing time problem was removed.
>>>>>>>
>>>>>>> However, how do you fixed timeout problem ?
>>>>>>>
>>>>>>> Sebastien
>>>>>>>
>>>>>>> Chunyan Wang wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Martin Senger wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   What language are you using, what XML library in that
>>>>>>>>> language?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I am using Perl and XML::DOM. I am using
>>>>>>>> "genericServiceInputParser($data)" to parse the input sequence
>>>>>>>> in my service.
>>>>>>>> By the way, I want to let you know I fixed timeout problem.
>>>>>>>> Thanks for your suggestion.
>>>>>>>>
>>>>>>>> Joyce
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>   Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MOBY-dev mailing list
>>>>>>>> MOBY-dev at biomoby.org
>>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> __________________________________________________________
>>>>>
>>>>> Sebastien CARRERE                        LIPM (INRA-CNRS)
>>>>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
>>>>> tel:(33) 5-61-28-53-29
>>>>> fax:(33) 5-61-28-50-61
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>> -- 
>>> "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
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> -- 
> "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
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From Pieter.Neerincx at wur.nl  Mon Sep 12 11:05:51 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 12 Sep 2005 17:05:51 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
Message-ID: <B35BC13D-D39B-4A67-B009-C91D31B53BDA@wur.nl>

Hi all,

I'm having some trouble to make BioMOBY work with Taverna. I have a  
local development Moby central. When I register both new services and  
new objects I notice that only my custom services are listed in  
Taverna. The list of moby objects is not in sync with what is  
registered in my central. So where does Taverna get those objects  
from and how do I get my own objects in there? Does anyone have a clue?

Cheers,

Pieter

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Mon Sep 12 11:10:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 12 Sep 2005 08:10:52 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <B35BC13D-D39B-4A67-B009-C91D31B53BDA@wur.nl>
Message-ID: <43259a80.30867065.1135.ffff8504@mx.gmail.com>

Hi,

The answer basically is that you also need to set up some
servlets (RESOURCES script, types, etc), if you have a
custom registry.

So Taverna is basically reading in your services, and cannot
find the objects, so it probably defaults to the Mobycentral
registry.

Eddie 

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 12, 2005 8:06 AM
> To: Core developer announcements
> Subject: [MOBY-dev] Moby objects in Taverna. Where do they
> come from?
> 
> Hi all,
> 
> I'm having some trouble to make BioMOBY work with Taverna.
> I have a
> local development Moby central. When I register both new
> services and
> new objects I notice that only my custom services are
> listed in
> Taverna. The list of moby objects is not in sync with what
> is
> registered in my central. So where does Taverna get those
> objects
> from and how do I get my own objects in there? Does anyone
> have a clue?
> 
> Cheers,
> 
> Pieter
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From senger at ebi.ac.uk  Mon Sep 12 21:30:38 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 02:30:38 +0100 (BST)
Subject: [MOBY-dev] jMOBY DOES NOT COMPILE (again!)
Message-ID: <Pine.OSF.4.21.0509130225110.887285-100000@ice.ebi.ac.uk>

Eddie,
   I am sorry for the upper-case letters but it is really important to
realize that if someone (I suspect you in this case) commits changes
without checking that the whole jMoby is compilable that it may have a bad
impact of the other users. At the moment, I am in the middle of the
Biomoby course (in Japan) and jMoby does not compile. Plenty of errors
from the RDF agent 'test' package.
   I apologize if the problem was caused by someone else - and I am
calling Eddie - but in the past it was usually Eddie :-) (Unless it was
me, of course, that would be a real embarassment.)

   So please fix the problem asap. I will have to remove the offending
classes from the repository if it continues to break the compilation.

   Thanks and with regards,
   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)



From senger at ebi.ac.uk  Mon Sep 12 23:48:07 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 04:48:07 +0100 (BST)
Subject: [MOBY-dev] RE: jMOBY DOES NOT COMPILE (again!)
In-Reply-To: <432649ea.64d22026.0f99.5d5f@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509130446380.887285-100000@ice.ebi.ac.uk>

> When I made my changes, I did a ./build.bat clean compile
> and everything was fine.
>
   So perhaps you have some other, not-included, librraies on your
classpath.

> What messages are you getting?
>

    [javac] Found 55 semantic errors compiling
"/net/nfs7/vol4/industry/senger/moby-live/Java/src/main/org/biomoby/registry/rdfagent/test/RDFAgentTestSuite.java":

    [javac]    328.     public void performTest1() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type
"org.biomoby.registry.rdfagent.test.TestException" was not found.


    [javac]    357.     public void performTest2() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    375.     public void performTest3() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    393.     public void performTest4() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    411.     public void performTest5() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.

   ... etc.

   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)



From edward.kawas at gmail.com  Mon Sep 12 23:39:17 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 12 Sep 2005 20:39:17 -0700
Subject: [MOBY-dev] RE: jMOBY DOES NOT COMPILE (again!)
In-Reply-To: <Pine.OSF.4.21.0509130225110.887285-100000@ice.ebi.ac.uk>
Message-ID: <432649ea.64d22026.0f99.5d5f@mx.gmail.com>

When I made my changes, I did a ./build.bat clean compile
and everything was fine. What messages are you getting?


Eddie

> -----Original Message-----
> From: Martin Senger [mailto:senger at ebi.ac.uk]
> Sent: Monday, September 12, 2005 6:31 PM
> To: Edward Kawas
> Cc: Moby Developers
> Subject: jMOBY DOES NOT COMPILE (again!)
> 
> Eddie,
>    I am sorry for the upper-case letters but it is really
> important to
> realize that if someone (I suspect you in this case)
> commits changes
> without checking that the whole jMoby is compilable that
> it may have a bad
> impact of the other users. At the moment, I am in the
> middle of the
> Biomoby course (in Japan) and jMoby does not compile.
> Plenty of errors
> from the RDF agent 'test' package.
>    I apologize if the problem was caused by someone else -
> and I am
> calling Eddie - but in the past it was usually Eddie :-)
> (Unless it was
> me, of course, that would be a real embarassment.)
> 
>    So please fix the problem asap. I will have to remove
> the offending
> classes from the repository if it continues to break the
> compilation.
> 
>    Thanks and with regards,
>    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)



From senger at ebi.ac.uk  Tue Sep 13 03:56:14 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 08:56:14 +0100 (BST)
Subject: [MOBY-dev] jMoby small update & a windows question
Message-ID: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>

I have updated library alltools2.jar - so please when you use jMoby next
time start with: ./build.sh (or ./build.bat).

I wonder if people familiar with windows can answer my question about
windows scripts:

The script is build/run/run-cmdline-client.bat (but the same applies to
all other .bat scripts there). It does not work if your PROJECT_HOME is a
directory with whitespaces, like
   C:\Document and Settings\martin\Desktop\jMoby

I have already added there a lot of double quotes - so it "almost" works
now, but not yet. The problem is the line:

for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i

where I do not know how to put quotes arround the first %PROJECT_HOME%. If
I quote is, the '*.jar' part does not seem to expand as expected.

I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
then I can remove the %PROJECT_HOME% from all other places. But I still
wonder how I should write it without this workaround. Does anybody know
how to do it?

Thanks,
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)



From Pieter.Neerincx at wur.nl  Tue Sep 13 04:34:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 13 Sep 2005 10:34:42 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <43259a80.30867065.1135.ffff8504@mx.gmail.com>
References: <43259a80.30867065.1135.ffff8504@mx.gmail.com>
Message-ID: <A7015A51-2FAA-417D-95C7-E2AF2630F540@wur.nl>

Hi Eddie,

On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:

> Hi,
>
> The answer basically is that you also need to set up some
> servlets (RESOURCES script, types, etc), if you have a
> custom registry.

Thanks for the quick feedback. I was already afraid it would be  
something like that :(.

> So Taverna is basically reading in your services, and cannot
> find the objects, so it probably defaults to the Mobycentral
> registry.

Would it help if I register my objects at THE central mobycentral  
instead of in my local central? Or are the objects hardcoded in some  
jar file (like lib/jmoby.jar perhaps)?

Pieter

>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 12, 2005 8:06 AM
>> To: Core developer announcements
>> Subject: [MOBY-dev] Moby objects in Taverna. Where do they
>> come from?
>>
>> Hi all,
>>
>> I'm having some trouble to make BioMOBY work with Taverna.
>> I have a
>> local development Moby central. When I register both new
>> services and
>> new objects I notice that only my custom services are
>> listed in
>> Taverna. The list of moby objects is not in sync with what
>> is
>> registered in my central. So where does Taverna get those
>> objects
>> from and how do I get my own objects in there? Does anyone
>> have a clue?
>>
>> Cheers,
>>
>> Pieter
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From ots at ac.uma.es  Tue Sep 13 04:31:01 2005
From: ots at ac.uma.es (Oswaldo Trelles)
Date: Tue, 13 Sep 2005 10:31:01 +0200
Subject: [MOBY-dev] jMoby small update & a windows question
References: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>
Message-ID: <007201c5b83d$797e8de0$346dd696@ac.uma.es>

perhaps it is due to the old MS-DOS format under which the BAT files are
executed
you could try with    C:\Docume~1\martin\Desktop\jMoby

oswaldo

----- Original Message ----- 
From: "Martin Senger" <senger at ebi.ac.uk>
To: "Moby Developers" <moby-dev at biomoby.org>
Sent: Tuesday, September 13, 2005 9:56 AM
Subject: [MOBY-dev] jMoby small update & a windows question


> I have updated library alltools2.jar - so please when you use jMoby next
> time start with: ./build.sh (or ./build.bat).
>
> I wonder if people familiar with windows can answer my question about
> windows scripts:
>
> The script is build/run/run-cmdline-client.bat (but the same applies to
> all other .bat scripts there). It does not work if your PROJECT_HOME is a
> directory with whitespaces, like
>    C:\Document and Settings\martin\Desktop\jMoby
>
> I have already added there a lot of double quotes - so it "almost" works
> now, but not yet. The problem is the line:
>
> for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i
>
> where I do not know how to put quotes arround the first %PROJECT_HOME%. If
> I quote is, the '*.jar' part does not seem to expand as expected.
>
> I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
> then I can remove the %PROJECT_HOME% from all other places. But I still
> wonder how I should write it without this workaround. Does anybody know
> how to do it?
>
> Thanks,
> 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



From ots at ac.uma.es  Tue Sep 13 04:31:01 2005
From: ots at ac.uma.es (Oswaldo Trelles)
Date: Tue, 13 Sep 2005 10:31:01 +0200
Subject: [MOBY-dev] jMoby small update & a windows question
References: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>
Message-ID: <007201c5b83d$797e8de0$346dd696@ac.uma.es>

perhaps it is due to the old MS-DOS format under which the BAT files are
executed
you could try with    C:\Docume~1\martin\Desktop\jMoby

oswaldo

----- Original Message ----- 
From: "Martin Senger" <senger at ebi.ac.uk>
To: "Moby Developers" <moby-dev at biomoby.org>
Sent: Tuesday, September 13, 2005 9:56 AM
Subject: [MOBY-dev] jMoby small update & a windows question


> I have updated library alltools2.jar - so please when you use jMoby next
> time start with: ./build.sh (or ./build.bat).
>
> I wonder if people familiar with windows can answer my question about
> windows scripts:
>
> The script is build/run/run-cmdline-client.bat (but the same applies to
> all other .bat scripts there). It does not work if your PROJECT_HOME is a
> directory with whitespaces, like
>    C:\Document and Settings\martin\Desktop\jMoby
>
> I have already added there a lot of double quotes - so it "almost" works
> now, but not yet. The problem is the line:
>
> for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i
>
> where I do not know how to put quotes arround the first %PROJECT_HOME%. If
> I quote is, the '*.jar' part does not seem to expand as expected.
>
> I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
> then I can remove the %PROJECT_HOME% from all other places. But I still
> wonder how I should write it without this workaround. Does anybody know
> how to do it?
>
> Thanks,
> 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



From senger at ebi.ac.uk  Tue Sep 13 04:48:16 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 09:48:16 +0100 (BST)
Subject: [MOBY-dev] jMoby small update & a windows question
In-Reply-To: <007201c5b83d$797e8de0$346dd696@ac.uma.es>
Message-ID: <Pine.OSF.4.21.0509130944050.960900-100000@ice.ebi.ac.uk>

Thanks for the help.

> perhaps it is due to the old MS-DOS format under which the BAT files
> are executed
>
   No, they are executed under cmd running in windows XP. But perhaps I
even do not know how to execute them better. An advice is welcome.

> you could try with    C:\Docume~1\martin\Desktop\jMoby
>
   Actually, this seems to me to be the old 8.3 format. And this works
fine because it does not have spaces. But I do not know how to change
programatically the "C:\Document and Settings\martin\Desktop\jMoby" to
"C:\Docume~1\martin\Desktop\jMoby". This is done by Ant, when replacing a
token @PROJECT_HOME@ by a dir name (using a filterset). I cannot do it
manually.

   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)



From senger at ebi.ac.uk  Tue Sep 13 04:48:16 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 09:48:16 +0100 (BST)
Subject: [MOBY-dev] jMoby small update & a windows question
In-Reply-To: <007201c5b83d$797e8de0$346dd696@ac.uma.es>
Message-ID: <Pine.OSF.4.21.0509130944050.960900-100000@ice.ebi.ac.uk>

Thanks for the help.

> perhaps it is due to the old MS-DOS format under which the BAT files
> are executed
>
   No, they are executed under cmd running in windows XP. But perhaps I
even do not know how to execute them better. An advice is welcome.

> you could try with    C:\Docume~1\martin\Desktop\jMoby
>
   Actually, this seems to me to be the old 8.3 format. And this works
fine because it does not have spaces. But I do not know how to change
programatically the "C:\Document and Settings\martin\Desktop\jMoby" to
"C:\Docume~1\martin\Desktop\jMoby". This is done by Ant, when replacing a
token @PROJECT_HOME@ by a dir name (using a filterset). I cannot do it
manually.

   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)



From edward.kawas at gmail.com  Tue Sep 13 09:08:20 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 13 Sep 2005 06:08:20 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <A7015A51-2FAA-417D-95C7-E2AF2630F540@wur.nl>
Message-ID: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>

Hi,

Objects aren't hard coded. They just have to be registered
in Mobycentral.

I am not sure if you are up for it, but you could always
install the servlets (I could help you).

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 1:35 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi Eddie,
> 
> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > The answer basically is that you also need to set up
> some
> > servlets (RESOURCES script, types, etc), if you have a
> > custom registry.
> 
> Thanks for the quick feedback. I was already afraid it
> would be
> something like that :(.
> 
> > So Taverna is basically reading in your services, and
> cannot
> > find the objects, so it probably defaults to the
> Mobycentral
> > registry.
> 
> Would it help if I register my objects at THE central
> mobycentral
> instead of in my local central? Or are the objects
> hardcoded in some
> jar file (like lib/jmoby.jar perhaps)?
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces at portal.open-bio.org
> [mailto:moby-
> >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Monday, September 12, 2005 8:06 AM
> >> To: Core developer announcements
> >> Subject: [MOBY-dev] Moby objects in Taverna. Where do
> they
> >> come from?
> >>
> >> Hi all,
> >>
> >> I'm having some trouble to make BioMOBY work with
> Taverna.
> >> I have a
> >> local development Moby central. When I register both
> new
> >> services and
> >> new objects I notice that only my custom services are
> >> listed in
> >> Taverna. The list of moby objects is not in sync with
> what
> >> is
> >> registered in my central. So where does Taverna get
> those
> >> objects
> >> from and how do I get my own objects in there? Does
> anyone
> >> have a clue?
> >>
> >> Cheers,
> >>
> >> Pieter
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx at wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From Pieter.Neerincx at wur.nl  Tue Sep 13 10:17:46 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 13 Sep 2005 16:17:46 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>
References: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>
Message-ID: <DB4FF9B0-3BDE-42DA-AB89-8CBDEF8705C5@wur.nl>

Hi Eddie,

On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:

> Hi,
>
> Objects aren't hard coded. They just have to be registered
> in Mobycentral.

Today I fetched the source code for Taverna and 'grep'ed over the  
files. There are several instances where the path to the central  
biomoby central and an RDF file are hardcoded outside the files in  
conf/. Sometime ago I started to work with Taverna and the user  
manual only mentions the path to a biomoby central in the conf/ 
mygrid.properties file. So I appended my local biomoby central to  
this conf file and expected this would allow me to use both services  
and objects registered in my local central. I think that the current  
situation where service info is fetched from a URL in the conf/ 
mygrid.properties file and object info is fetched from a RDF file at  
a different location is very confusing and needlessly complex.  
Especially since I cannot supply an URL to a custom RDF file for my  
objects in the conf/mygrid.properties file. I did see though that I  
can right-click in Taverna to add a scavenger and than I can supply  
both an URL to my local central and an URL to this RDF file for the  
objects.

I also browsed the mailinglist and wiki. Did I understand correctly  
that the current situation is a temporary solution and that  
eventually all info (hence services and objects) will be described  
using RDF? Please correct me if I'm wrong...

> I am not sure if you are up for it, but you could always
> install the servlets

Are those servlets generating this RDF file from the info in a central?
Is this documented somewhere? I couldn't find any reference to  
servlets at http://www.biomoby.org/InstallingMOBYCentral.html ...

> (I could help you).

Your help is much appreciated! Thanks,

Pieter

>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 1:35 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi Eddie,
>>
>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> The answer basically is that you also need to set up
>>>
>> some
>>
>>> servlets (RESOURCES script, types, etc), if you have a
>>> custom registry.
>>>
>>
>> Thanks for the quick feedback. I was already afraid it
>> would be
>> something like that :(.
>>
>>
>>> So Taverna is basically reading in your services, and
>>>
>> cannot
>>
>>> find the objects, so it probably defaults to the
>>>
>> Mobycentral
>>
>>> registry.
>>>
>>
>> Would it help if I register my objects at THE central
>> mobycentral
>> instead of in my local central? Or are the objects
>> hardcoded in some
>> jar file (like lib/jmoby.jar perhaps)?
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>> To: Core developer announcements
>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
>>>>
>> they
>>
>>>> come from?
>>>>
>>>> Hi all,
>>>>
>>>> I'm having some trouble to make BioMOBY work with
>>>>
>> Taverna.
>>
>>>> I have a
>>>> local development Moby central. When I register both
>>>>
>> new
>>
>>>> services and
>>>> new objects I notice that only my custom services are
>>>> listed in
>>>> Taverna. The list of moby objects is not in sync with
>>>>
>> what
>>
>>>> is
>>>> registered in my central. So where does Taverna get
>>>>
>> those
>>
>>>> objects
>>>> from and how do I get my own objects in there? Does
>>>>
>> anyone
>>
>>>> have a clue?
>>>>
>>>> Cheers,
>>>>
>>>> Pieter
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Tue Sep 13 10:43:32 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 13 Sep 2005 07:43:32 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <DB4FF9B0-3BDE-42DA-AB89-8CBDEF8705C5@wur.nl>
Message-ID: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>

Hi,

For the Taverna workbench, download it temporarily from
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip
This version contains my changes (the ones that are in the
Taverna CVS).

The Moby api actually now has a method in it called
getResources (or something similar to that) that returns the
locations of these documents for a registry. So in the newly
updated version of the plugin, I have removed the textbox
that asks for this url and replaced it with an api call.
(a description on the Moby plugin can be found at
http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.ht
ml but is being changed to reflect the api calling).

You are correct in saying that we are moving towards having
Services and datatypes described by RDF.

Finally, as for the servlet installation, if you are
interested, I can guide you through this relatively painless
procedure. I would just need to update certain files that
you need to download and you would have to install tomcat.

Eddie



> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 7:18 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi Eddie,
> 
> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > Objects aren't hard coded. They just have to be
> registered
> > in Mobycentral.
> 
> Today I fetched the source code for Taverna and 'grep'ed
> over the
> files. There are several instances where the path to the
> central
> biomoby central and an RDF file are hardcoded outside the
> files in
> conf/. Sometime ago I started to work with Taverna and the
> user
> manual only mentions the path to a biomoby central in the
> conf/
> mygrid.properties file. So I appended my local biomoby
> central to
> this conf file and expected this would allow me to use
> both services
> and objects registered in my local central. I think that
> the current
> situation where service info is fetched from a URL in the
> conf/
> mygrid.properties file and object info is fetched from a
> RDF file at
> a different location is very confusing and needlessly
> complex.
> Especially since I cannot supply an URL to a custom RDF
> file for my
> objects in the conf/mygrid.properties file. I did see
> though that I
> can right-click in Taverna to add a scavenger and than I
> can supply
> both an URL to my local central and an URL to this RDF
> file for the
> objects.
> 
> I also browsed the mailinglist and wiki. Did I understand
> correctly
> that the current situation is a temporary solution and
> that
> eventually all info (hence services and objects) will be
> described
> using RDF? Please correct me if I'm wrong...
> 
> > I am not sure if you are up for it, but you could always
> > install the servlets
> 
> Are those servlets generating this RDF file from the info
> in a central?
> Is this documented somewhere? I couldn't find any
> reference to
> servlets at
> http://www.biomoby.org/InstallingMOBYCentral.html ...
> 
> > (I could help you).
> 
> Your help is much appreciated! Thanks,
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces at portal.open-bio.org
> [mailto:moby-
> >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Tuesday, September 13, 2005 1:35 AM
> >> To: Core developer announcements
> >> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
> do
> >> they come from?
> >>
> >> Hi Eddie,
> >>
> >> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> The answer basically is that you also need to set up
> >>>
> >> some
> >>
> >>> servlets (RESOURCES script, types, etc), if you have a
> >>> custom registry.
> >>>
> >>
> >> Thanks for the quick feedback. I was already afraid it
> >> would be
> >> something like that :(.
> >>
> >>
> >>> So Taverna is basically reading in your services, and
> >>>
> >> cannot
> >>
> >>> find the objects, so it probably defaults to the
> >>>
> >> Mobycentral
> >>
> >>> registry.
> >>>
> >>
> >> Would it help if I register my objects at THE central
> >> mobycentral
> >> instead of in my local central? Or are the objects
> >> hardcoded in some
> >> jar file (like lib/jmoby.jar perhaps)?
> >>
> >> Pieter
> >>
> >>
> >>>
> >>> Eddie
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: moby-dev-bounces at portal.open-bio.org
> >>>>
> >> [mailto:moby-
> >>
> >>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >>>> Neerincx
> >>>> Sent: Monday, September 12, 2005 8:06 AM
> >>>> To: Core developer announcements
> >>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
> >>>>
> >> they
> >>
> >>>> come from?
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I'm having some trouble to make BioMOBY work with
> >>>>
> >> Taverna.
> >>
> >>>> I have a
> >>>> local development Moby central. When I register both
> >>>>
> >> new
> >>
> >>>> services and
> >>>> new objects I notice that only my custom services are
> >>>> listed in
> >>>> Taverna. The list of moby objects is not in sync with
> >>>>
> >> what
> >>
> >>>> is
> >>>> registered in my central. So where does Taverna get
> >>>>
> >> those
> >>
> >>>> objects
> >>>> from and how do I get my own objects in there? Does
> >>>>
> >> anyone
> >>
> >>>> have a clue?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Pieter
> >>>>
> >>>> Wageningen University and Research centre (WUR)
> >>>> Laboratory of Bioinformatics
> >>>> Transitorium (building 312) room 1034
> >>>> Dreijenlaan 3
> >>>> 6703 HA Wageningen
> >>>> The Netherlands
> >>>> phone: 0317-483 060
> >>>> fax: 0317-483 584
> >>>> mobile: 06-143 66 783
> >>>> pieter.neerincx at wur.nl
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev at biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev at biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx at wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From Pieter.Neerincx at wur.nl  Tue Sep 13 11:48:47 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 13 Sep 2005 17:48:47 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>
References: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>
Message-ID: <E56B487A-CAED-4EFE-B0AD-97C3B4F21E6C@wur.nl>

Hi,

On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:

> Hi,
>
> For the Taverna workbench, download it temporarily from
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
> zip

I will...

> This version contains my changes (the ones that are in the
> Taverna CVS).
>
> The Moby api actually now has a method in it called
> getResources (or something similar to that) that returns the
> locations of these documents for a registry.

Ok, that sounds like a much more elegant solution :).

> So in the newly
> updated version of the plugin, I have removed the textbox
> that asks for this url and replaced it with an api call.
> (a description on the Moby plugin can be found at
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.ht
> ml but is being changed to reflect the api calling).
>
> You are correct in saying that we are moving towards having
> Services and datatypes described by RDF.
>
> Finally, as for the servlet installation, if you are
> interested, I can guide you through this relatively painless
> procedure. I would just need to update certain files that
> you need to download and you would have to install tomcat.

Ok, I will start with tomcat tomorrow... and will request further  
advice one I have that one up and running...

Pieter

>
> Eddie
>
>
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 7:18 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi Eddie,
>>
>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> Objects aren't hard coded. They just have to be
>>>
>> registered
>>
>>> in Mobycentral.
>>>
>>
>> Today I fetched the source code for Taverna and 'grep'ed
>> over the
>> files. There are several instances where the path to the
>> central
>> biomoby central and an RDF file are hardcoded outside the
>> files in
>> conf/. Sometime ago I started to work with Taverna and the
>> user
>> manual only mentions the path to a biomoby central in the
>> conf/
>> mygrid.properties file. So I appended my local biomoby
>> central to
>> this conf file and expected this would allow me to use
>> both services
>> and objects registered in my local central. I think that
>> the current
>> situation where service info is fetched from a URL in the
>> conf/
>> mygrid.properties file and object info is fetched from a
>> RDF file at
>> a different location is very confusing and needlessly
>> complex.
>> Especially since I cannot supply an URL to a custom RDF
>> file for my
>> objects in the conf/mygrid.properties file. I did see
>> though that I
>> can right-click in Taverna to add a scavenger and than I
>> can supply
>> both an URL to my local central and an URL to this RDF
>> file for the
>> objects.
>>
>> I also browsed the mailinglist and wiki. Did I understand
>> correctly
>> that the current situation is a temporary solution and
>> that
>> eventually all info (hence services and objects) will be
>> described
>> using RDF? Please correct me if I'm wrong...
>>
>>
>>> I am not sure if you are up for it, but you could always
>>> install the servlets
>>>
>>
>> Are those servlets generating this RDF file from the info
>> in a central?
>> Is this documented somewhere? I couldn't find any
>> reference to
>> servlets at
>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>
>>
>>> (I could help you).
>>>
>>
>> Your help is much appreciated! Thanks,
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>>>
>> do
>>
>>>> they come from?
>>>>
>>>> Hi Eddie,
>>>>
>>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> The answer basically is that you also need to set up
>>>>>
>>>>>
>>>> some
>>>>
>>>>
>>>>> servlets (RESOURCES script, types, etc), if you have a
>>>>> custom registry.
>>>>>
>>>>>
>>>>
>>>> Thanks for the quick feedback. I was already afraid it
>>>> would be
>>>> something like that :(.
>>>>
>>>>
>>>>
>>>>> So Taverna is basically reading in your services, and
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>> find the objects, so it probably defaults to the
>>>>>
>>>>>
>>>> Mobycentral
>>>>
>>>>
>>>>> registry.
>>>>>
>>>>>
>>>>
>>>> Would it help if I register my objects at THE central
>>>> mobycentral
>>>> instead of in my local central? Or are the objects
>>>> hardcoded in some
>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>>>
>>>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>>>> Neerincx
>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>> To: Core developer announcements
>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
>>>>>>
>>>>>>
>>>> they
>>>>
>>>>
>>>>>> come from?
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm having some trouble to make BioMOBY work with
>>>>>>
>>>>>>
>>>> Taverna.
>>>>
>>>>
>>>>>> I have a
>>>>>> local development Moby central. When I register both
>>>>>>
>>>>>>
>>>> new
>>>>
>>>>
>>>>>> services and
>>>>>> new objects I notice that only my custom services are
>>>>>> listed in
>>>>>> Taverna. The list of moby objects is not in sync with
>>>>>>
>>>>>>
>>>> what
>>>>
>>>>
>>>>>> is
>>>>>> registered in my central. So where does Taverna get
>>>>>>
>>>>>>
>>>> those
>>>>
>>>>
>>>>>> objects
>>>>>> from and how do I get my own objects in there? Does
>>>>>>
>>>>>>
>>>> anyone
>>>>
>>>>
>>>>>> have a clue?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Pieter
>>>>>>
>>>>>> Wageningen University and Research centre (WUR)
>>>>>> Laboratory of Bioinformatics
>>>>>> Transitorium (building 312) room 1034
>>>>>> Dreijenlaan 3
>>>>>> 6703 HA Wageningen
>>>>>> The Netherlands
>>>>>> phone: 0317-483 060
>>>>>> fax: 0317-483 584
>>>>>> mobile: 06-143 66 783
>>>>>> pieter.neerincx at wur.nl
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Tue Sep 13 11:58:51 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 13 Sep 2005 08:58:51 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <E56B487A-CAED-4EFE-B0AD-97C3B4F21E6C@wur.nl>
Message-ID: <4326f75b.52b7817a.2384.5590@mx.gmail.com>

Great. I will be waiting ;-)

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 8:49 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi,
> 
> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > For the Taverna workbench, download it temporarily from
> > http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
> 1.2.
> > zip
> 
> I will...
> 
> > This version contains my changes (the ones that are in
> the
> > Taverna CVS).
> >
> > The Moby api actually now has a method in it called
> > getResources (or something similar to that) that returns
> the
> > locations of these documents for a registry.
> 
> Ok, that sounds like a much more elegant solution :).
> 
> > So in the newly
> > updated version of the plugin, I have removed the
> textbox
> > that asks for this url and replaced it with an api call.
> > (a description on the Moby plugin can be found at
> >
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
> ht
> > ml but is being changed to reflect the api calling).
> >
> > You are correct in saying that we are moving towards
> having
> > Services and datatypes described by RDF.
> >
> > Finally, as for the servlet installation, if you are
> > interested, I can guide you through this relatively
> painless
> > procedure. I would just need to update certain files
> that
> > you need to download and you would have to install
> tomcat.
> 
> Ok, I will start with tomcat tomorrow... and will request
> further
> advice one I have that one up and running...
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces at portal.open-bio.org
> [mailto:moby-
> >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Tuesday, September 13, 2005 7:18 AM
> >> To: Core developer announcements
> >> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
> do
> >> they come from?
> >>
> >> Hi Eddie,
> >>
> >> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> Objects aren't hard coded. They just have to be
> >>>
> >> registered
> >>
> >>> in Mobycentral.
> >>>
> >>
> >> Today I fetched the source code for Taverna and
> 'grep'ed
> >> over the
> >> files. There are several instances where the path to
> the
> >> central
> >> biomoby central and an RDF file are hardcoded outside
> the
> >> files in
> >> conf/. Sometime ago I started to work with Taverna and
> the
> >> user
> >> manual only mentions the path to a biomoby central in
> the
> >> conf/
> >> mygrid.properties file. So I appended my local biomoby
> >> central to
> >> this conf file and expected this would allow me to use
> >> both services
> >> and objects registered in my local central. I think
> that
> >> the current
> >> situation where service info is fetched from a URL in
> the
> >> conf/
> >> mygrid.properties file and object info is fetched from
> a
> >> RDF file at
> >> a different location is very confusing and needlessly
> >> complex.
> >> Especially since I cannot supply an URL to a custom RDF
> >> file for my
> >> objects in the conf/mygrid.properties file. I did see
> >> though that I
> >> can right-click in Taverna to add a scavenger and than
> I
> >> can supply
> >> both an URL to my local central and an URL to this RDF
> >> file for the
> >> objects.
> >>
> >> I also browsed the mailinglist and wiki. Did I
> understand
> >> correctly
> >> that the current situation is a temporary solution and
> >> that
> >> eventually all info (hence services and objects) will
> be
> >> described
> >> using RDF? Please correct me if I'm wrong...
> >>
> >>
> >>> I am not sure if you are up for it, but you could
> always
> >>> install the servlets
> >>>
> >>
> >> Are those servlets generating this RDF file from the
> info
> >> in a central?
> >> Is this documented somewhere? I couldn't find any
> >> reference to
> >> servlets at
> >> http://www.biomoby.org/InstallingMOBYCentral.html ...
> >>
> >>
> >>> (I could help you).
> >>>
> >>
> >> Your help is much appreciated! Thanks,
> >>
> >> Pieter
> >>
> >>
> >>>
> >>> Eddie
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: moby-dev-bounces at portal.open-bio.org
> >>>>
> >> [mailto:moby-
> >>
> >>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >>>> Neerincx
> >>>> Sent: Tuesday, September 13, 2005 1:35 AM
> >>>> To: Core developer announcements
> >>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
> Where
> >>>>
> >> do
> >>
> >>>> they come from?
> >>>>
> >>>> Hi Eddie,
> >>>>
> >>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> The answer basically is that you also need to set up
> >>>>>
> >>>>>
> >>>> some
> >>>>
> >>>>
> >>>>> servlets (RESOURCES script, types, etc), if you have
> a
> >>>>> custom registry.
> >>>>>
> >>>>>
> >>>>
> >>>> Thanks for the quick feedback. I was already afraid
> it
> >>>> would be
> >>>> something like that :(.
> >>>>
> >>>>
> >>>>
> >>>>> So Taverna is basically reading in your services,
> and
> >>>>>
> >>>>>
> >>>> cannot
> >>>>
> >>>>
> >>>>> find the objects, so it probably defaults to the
> >>>>>
> >>>>>
> >>>> Mobycentral
> >>>>
> >>>>
> >>>>> registry.
> >>>>>
> >>>>>
> >>>>
> >>>> Would it help if I register my objects at THE central
> >>>> mobycentral
> >>>> instead of in my local central? Or are the objects
> >>>> hardcoded in some
> >>>> jar file (like lib/jmoby.jar perhaps)?
> >>>>
> >>>> Pieter
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Eddie
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: moby-dev-bounces at portal.open-bio.org
> >>>>>>
> >>>>>>
> >>>> [mailto:moby-
> >>>>
> >>>>
> >>>>>> dev-bounces at portal.open-bio.org] On Behalf Of
> Pieter
> >>>>>> Neerincx
> >>>>>> Sent: Monday, September 12, 2005 8:06 AM
> >>>>>> To: Core developer announcements
> >>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
> do
> >>>>>>
> >>>>>>
> >>>> they
> >>>>
> >>>>
> >>>>>> come from?
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I'm having some trouble to make BioMOBY work with
> >>>>>>
> >>>>>>
> >>>> Taverna.
> >>>>
> >>>>
> >>>>>> I have a
> >>>>>> local development Moby central. When I register
> both
> >>>>>>
> >>>>>>
> >>>> new
> >>>>
> >>>>
> >>>>>> services and
> >>>>>> new objects I notice that only my custom services
> are
> >>>>>> listed in
> >>>>>> Taverna. The list of moby objects is not in sync
> with
> >>>>>>
> >>>>>>
> >>>> what
> >>>>
> >>>>
> >>>>>> is
> >>>>>> registered in my central. So where does Taverna get
> >>>>>>
> >>>>>>
> >>>> those
> >>>>
> >>>>
> >>>>>> objects
> >>>>>> from and how do I get my own objects in there? Does
> >>>>>>
> >>>>>>
> >>>> anyone
> >>>>
> >>>>
> >>>>>> have a clue?
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Pieter
> >>>>>>
> >>>>>> Wageningen University and Research centre (WUR)
> >>>>>> Laboratory of Bioinformatics
> >>>>>> Transitorium (building 312) room 1034
> >>>>>> Dreijenlaan 3
> >>>>>> 6703 HA Wageningen
> >>>>>> The Netherlands
> >>>>>> phone: 0317-483 060
> >>>>>> fax: 0317-483 584
> >>>>>> mobile: 06-143 66 783
> >>>>>> pieter.neerincx at wur.nl
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MOBY-dev mailing list
> >>>>>> MOBY-dev at biomoby.org
> >>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> MOBY-dev mailing list
> >>>>> MOBY-dev at biomoby.org
> >>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> Wageningen University and Research centre (WUR)
> >>>> Laboratory of Bioinformatics
> >>>> Transitorium (building 312) room 1034
> >>>> Dreijenlaan 3
> >>>> 6703 HA Wageningen
> >>>> The Netherlands
> >>>> phone: 0317-483 060
> >>>> fax: 0317-483 584
> >>>> mobile: 06-143 66 783
> >>>> pieter.neerincx at wur.nl
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev at biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev at biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx at wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From Pieter.Neerincx at wur.nl  Wed Sep 14 07:04:53 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 14 Sep 2005 13:04:53 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326f75b.52b7817a.2384.5590@mx.gmail.com>
References: <4326f75b.52b7817a.2384.5590@mx.gmail.com>
Message-ID: <1ACC63DC-D971-4137-97FA-1D90AD0EE571@wur.nl>

Ok, got Tomcat installed... Please tell me what to download from  
where and where to install it...

Thanks,

Pieter

On 13-Sep-2005, at 5:58 PM, Edward Kawas wrote:

> Great. I will be waiting ;-)
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 8:49 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi,
>>
>> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> For the Taverna workbench, download it temporarily from
>>> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>>>
>> 1.2.
>>
>>> zip
>>>
>>
>> I will...
>>
>>
>>> This version contains my changes (the ones that are in
>>>
>> the
>>
>>> Taverna CVS).
>>>
>>> The Moby api actually now has a method in it called
>>> getResources (or something similar to that) that returns
>>>
>> the
>>
>>> locations of these documents for a registry.
>>>
>>
>> Ok, that sounds like a much more elegant solution :).
>>
>>
>>> So in the newly
>>> updated version of the plugin, I have removed the
>>>
>> textbox
>>
>>> that asks for this url and replaced it with an api call.
>>> (a description on the Moby plugin can be found at
>>>
>>>
>> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
>> ht
>>
>>> ml but is being changed to reflect the api calling).
>>>
>>> You are correct in saying that we are moving towards
>>>
>> having
>>
>>> Services and datatypes described by RDF.
>>>
>>> Finally, as for the servlet installation, if you are
>>> interested, I can guide you through this relatively
>>>
>> painless
>>
>>> procedure. I would just need to update certain files
>>>
>> that
>>
>>> you need to download and you would have to install
>>>
>> tomcat.
>>
>> Ok, I will start with tomcat tomorrow... and will request
>> further
>> advice one I have that one up and running...
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Tuesday, September 13, 2005 7:18 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>>>
>> do
>>
>>>> they come from?
>>>>
>>>> Hi Eddie,
>>>>
>>>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> Objects aren't hard coded. They just have to be
>>>>>
>>>>>
>>>> registered
>>>>
>>>>
>>>>> in Mobycentral.
>>>>>
>>>>>
>>>>
>>>> Today I fetched the source code for Taverna and
>>>>
>> 'grep'ed
>>
>>>> over the
>>>> files. There are several instances where the path to
>>>>
>> the
>>
>>>> central
>>>> biomoby central and an RDF file are hardcoded outside
>>>>
>> the
>>
>>>> files in
>>>> conf/. Sometime ago I started to work with Taverna and
>>>>
>> the
>>
>>>> user
>>>> manual only mentions the path to a biomoby central in
>>>>
>> the
>>
>>>> conf/
>>>> mygrid.properties file. So I appended my local biomoby
>>>> central to
>>>> this conf file and expected this would allow me to use
>>>> both services
>>>> and objects registered in my local central. I think
>>>>
>> that
>>
>>>> the current
>>>> situation where service info is fetched from a URL in
>>>>
>> the
>>
>>>> conf/
>>>> mygrid.properties file and object info is fetched from
>>>>
>> a
>>
>>>> RDF file at
>>>> a different location is very confusing and needlessly
>>>> complex.
>>>> Especially since I cannot supply an URL to a custom RDF
>>>> file for my
>>>> objects in the conf/mygrid.properties file. I did see
>>>> though that I
>>>> can right-click in Taverna to add a scavenger and than
>>>>
>> I
>>
>>>> can supply
>>>> both an URL to my local central and an URL to this RDF
>>>> file for the
>>>> objects.
>>>>
>>>> I also browsed the mailinglist and wiki. Did I
>>>>
>> understand
>>
>>>> correctly
>>>> that the current situation is a temporary solution and
>>>> that
>>>> eventually all info (hence services and objects) will
>>>>
>> be
>>
>>>> described
>>>> using RDF? Please correct me if I'm wrong...
>>>>
>>>>
>>>>
>>>>> I am not sure if you are up for it, but you could
>>>>>
>> always
>>
>>>>> install the servlets
>>>>>
>>>>>
>>>>
>>>> Are those servlets generating this RDF file from the
>>>>
>> info
>>
>>>> in a central?
>>>> Is this documented somewhere? I couldn't find any
>>>> reference to
>>>> servlets at
>>>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>>>
>>>>
>>>>
>>>>> (I could help you).
>>>>>
>>>>>
>>>>
>>>> Your help is much appreciated! Thanks,
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>>>
>>>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>>>> Neerincx
>>>>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>>>> To: Core developer announcements
>>>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
>>>>>>
>> Where
>>
>>>>>>
>>>>>>
>>>> do
>>>>
>>>>
>>>>>> they come from?
>>>>>>
>>>>>> Hi Eddie,
>>>>>>
>>>>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The answer basically is that you also need to set up
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> some
>>>>>>
>>>>>>
>>>>>>
>>>>>>> servlets (RESOURCES script, types, etc), if you have
>>>>>>>
>> a
>>
>>>>>>> custom registry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks for the quick feedback. I was already afraid
>>>>>>
>> it
>>
>>>>>> would be
>>>>>> something like that :(.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> So Taverna is basically reading in your services,
>>>>>>>
>> and
>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> cannot
>>>>>>
>>>>>>
>>>>>>
>>>>>>> find the objects, so it probably defaults to the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Mobycentral
>>>>>>
>>>>>>
>>>>>>
>>>>>>> registry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Would it help if I register my objects at THE central
>>>>>> mobycentral
>>>>>> instead of in my local central? Or are the objects
>>>>>> hardcoded in some
>>>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>>>
>>>>>> Pieter
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Eddie
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> [mailto:moby-
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> dev-bounces at portal.open-bio.org] On Behalf Of
>>>>>>>>
>> Pieter
>>
>>>>>>>> Neerincx
>>>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>>>> To: Core developer announcements
>>>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
>>>>>>>>
>> do
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> they
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> come from?
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'm having some trouble to make BioMOBY work with
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> Taverna.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> I have a
>>>>>>>> local development Moby central. When I register
>>>>>>>>
>> both
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> new
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> services and
>>>>>>>> new objects I notice that only my custom services
>>>>>>>>
>> are
>>
>>>>>>>> listed in
>>>>>>>> Taverna. The list of moby objects is not in sync
>>>>>>>>
>> with
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> what
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> is
>>>>>>>> registered in my central. So where does Taverna get
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> those
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> objects
>>>>>>>> from and how do I get my own objects in there? Does
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> anyone
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> have a clue?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Pieter
>>>>>>>>
>>>>>>>> Wageningen University and Research centre (WUR)
>>>>>>>> Laboratory of Bioinformatics
>>>>>>>> Transitorium (building 312) room 1034
>>>>>>>> Dreijenlaan 3
>>>>>>>> 6703 HA Wageningen
>>>>>>>> The Netherlands
>>>>>>>> phone: 0317-483 060
>>>>>>>> fax: 0317-483 584
>>>>>>>> mobile: 06-143 66 783
>>>>>>>> pieter.neerincx at wur.nl
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MOBY-dev mailing list
>>>>>>>> MOBY-dev at biomoby.org
>>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> MOBY-dev mailing list
>>>>>>> MOBY-dev at biomoby.org
>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Wageningen University and Research centre (WUR)
>>>>>> Laboratory of Bioinformatics
>>>>>> Transitorium (building 312) room 1034
>>>>>> Dreijenlaan 3
>>>>>> 6703 HA Wageningen
>>>>>> The Netherlands
>>>>>> phone: 0317-483 060
>>>>>> fax: 0317-483 584
>>>>>> mobile: 06-143 66 783
>>>>>> pieter.neerincx at wur.nl
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Thu Sep 15 18:46:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 15 Sep 2005 15:46:52 -0700
Subject: [MOBY-dev] invitation for the RFC committee with a tenure of one
	year
Message-ID: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>



-----Original Message-----
From: mark wilkinson [mailto:markw at illuminae.com] 
Sent: Thursday, September 15, 2005 3:06 PM
To: Frank Gibbons; Eddie Kawas
Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
Error-handling in MOBY-S

Hey Frank! Cc Eddie

Thanks for riding this.  I am on holiday, and not in Net
contact except by blackberry, so I'm not "useful" right now.

I think we should put out an invitation on the -dev list for
the RFC committee with a tenure of one year, but also
specifically invite the main developers/vested interests to
be part of it:  me, you, martin, eddie, simon, heiko, paul,
yan wong, and at least one from the spanish contingent (have
I missed anyone?).

I don't have all their email addresses on my bberry so
unless you or Eddie (cc'd) post this invitation to the dev
list yourselves it may take a week before I am back in
net-world.  Eddie, could you do this? Tomorrow or this
afternoon?  It would be good to get this sorted asap to keep
on schedule.

M


-----Original Message-----
From: Frank Gibbons <fgibbons at hms.harvard.edu>
Date: Thu, 15 Sep 2005 11:21:53 
To:moby-l at biomoby.org
Subject: [MOBY-l] Using bugzilla to continue RFC on
Error-handling in MOBY-S

Hi,

I've just added a few "bugs" to the bugzilla, to try to
preserve the RFC 
momentum built up over the past few weeks. I propose that,
although 
bugzilla is perhaps not ideal for this, it is what it is, it
is what we 
have, and it will do for now.

I'd like to propose that we try to continue development of
this RFC through 
bugzilla (see bug #1863), rather than through the mailing
list. Searching 
through old mail messages (or worse still, through the
digest, with all of 
its repeated messages and long inclusions) is tedious, and I
think 
contributes to the loss in momentum.

So far, in Martin's scheme for RFC-processing, we have
(numbers are those 
used in Martin's original suggestion, now available in the
codebase as 
Docs/MOBY-S_API/RFC.html)

1. Had a suggestion made by INB to add this features. It was
added to 
bugzilla, No. 1863
2. Suggested to resolve it by today (Sep-15)
3. Martin backed up the RFC
4. I think we have the resources to make this change - it
seems an 
essential part of a robust API, which version 1.0 should be.
5a. List members have exchanged several comments back and
forth, resulting 
in amended versions of the RFC being posted to the mailing
list.
5b. We've also gotten a little side-tracked by the related
articleName problem.

So it seems to me that it's time to vote on it (step 6 of
the Senger 
seven-step scheme ;-). Martin suggested that Mark would ask
a limited 
number of people to vote on it after the resolution date
(today). I guess 
those people would self-select, or maybe Mark will select
them. They will 
be requested to make a one-year commitment.

After that comes step 7, the "fun part": implementation,
documentation.

We're pretty close to reaching a conclusion on this. The
fact is that even 
if we do nothing, people want this functionality, and they
WILL implement 
it. It is in everybody's interest that we have a
specification for what the 
functionality should be. It may change over time, but I
think there has 
been enough back-and-forth that we have a reasonable first
draft, and 
should vote on it.

-Frank
P.S. Of course, this message, along with version 1.7.1 of
the RFC is 
attached to the bug on bugzilla

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

_______________________________________________
moby-l mailing list
moby-l at biomoby.org
http://biomoby.org/mailman/listinfo/moby-l

--
Mark Wilkinson
..on the road!



From ed.kawas at gmail.com  Thu Sep 15 20:04:26 2005
From: ed.kawas at gmail.com (Eddie Kawas)
Date: Thu, 15 Sep 2005 17:04:26 -0700
Subject: [MOBY-dev] taverna update
Message-ID: <432a0c0e.0f0001ad.6fb1.4f25@mx.gmail.com>

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie




From markw at illuminae.com  Fri Sep 16 00:20:50 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri, 16 Sep 2005 04:20:50 +0000 GMT
Subject: [MOBY-dev] taverna update
Message-ID: <2044406868-1126844547-cardhu_blackberry.rim.net-21354-@engine13-cell01>

This is the kick-ass addition to Taverna that only MOBY can accomplish!  I'm really excited about this!  Lead the biologist by the hand through workflow creation... It isn't quite a "wizard" but getting there!

Thanks Eddie!  Your plugin is bare(bear)able!

M
.
 
-----Original Message-----
From: "Eddie Kawas" <ed.kawas at gmail.com>
Date: Thu, 15 Sep 2005 17:04:26 
To:<moby-l at biomoby.org>, "'Moby Developers'" <moby-dev at biomoby.org>
Subject: [MOBY-dev] taverna update

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie


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

--
Mark Wilkinson
...on the road!


From markw at illuminae.com  Fri Sep 16 00:20:50 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri, 16 Sep 2005 04:20:50 +0000 GMT
Subject: [MOBY-dev] taverna update
Message-ID: <2044406868-1126844547-cardhu_blackberry.rim.net-21354-@engine13-cell01>

This is the kick-ass addition to Taverna that only MOBY can accomplish!  I'm really excited about this!  Lead the biologist by the hand through workflow creation... It isn't quite a "wizard" but getting there!

Thanks Eddie!  Your plugin is bare(bear)able!

M
.
 
-----Original Message-----
From: "Eddie Kawas" <ed.kawas at gmail.com>
Date: Thu, 15 Sep 2005 17:04:26 
To:<moby-l at biomoby.org>, "'Moby Developers'" <moby-dev at biomoby.org>
Subject: [MOBY-dev] taverna update

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie


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

--
Mark Wilkinson
...on the road!


From senger at ebi.ac.uk  Fri Sep 16 04:16:49 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 09:16:49 +0100 (BST)
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509160914540.1437894-100000@mozart.ebi.ac.uk>

Thank you for your invitation. It will be my pleasure and honour to take
this tenure. I will do my best in the interests of the Biomoby community.

Regards,
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)



From Pieter.Neerincx at wur.nl  Fri Sep 16 09:37:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri, 16 Sep 2005 15:37:33 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4329bac6.25d8a4f3.6fb1.ffffb832@mx.gmail.com>
References: <4329bac6.25d8a4f3.6fb1.ffffb832@mx.gmail.com>
Message-ID: <D2F9CBDD-C6D9-4644-9267-EF3113A418FB@wur.nl>

Hi Eddie,

Thanks for the tools! Here's my feedback:

On 15-Sep-2005, at 8:17 PM, Edward Kawas wrote:

> Hi Pieter,
>
>
>
> I am sending you a link to a java based installer (GUI) that should  
> make installation very easy. If this is not useful for you, I will  
> create 3 war files and send you the links to them.
>
> http://bioinfo.icapture.ubc.ca/ekawas/servlets/install.jar
>
>
>
> Some people can run the jar file by double clicking it. If that  
> doesn?t work, then type at the command prompt
>
> java ?jar install.jar
This gave me:

     The java class is not found: -jar

Works fine though without the -jar :) So 'java install.jar' was enough.
>
>
> If that doesn?t work, then email me back and I will send you 3 war  
> files and let you know what to do with them.
>
>
>
> Assuming that all goes well, there are a few things for you to do,  
> configuration wise.
>
>
>
> You will have to edit the biomoby.properties file in 3 different  
> locations:
>
>
>
> /tomcat/webapps/RESOURCES/WEB-INF/classes/org/BioMoby/registry/ 
> properties
>
> /tomcat/webapps/types/WEB-INF/classes/org/BioMoby/registry/properties
>
> /tomcat/webapps/authority/WEB-INF/classes/org/BioMoby/registry/ 
> properties
Close, but the installer created ..../biomoby/.... instead of ..../ 
BioMoby/.... .
>
> Open this file in any one of the locations and modify the properties:
>
> ?config?  - this property points to mobycentral.conf(ig)
>
> ?lsid_port?  -  this is the port that tomcat is running on
Ok, that is a bit confusing though. Shouldn't it be labelled  
'tomcat_port' port then?
> ?lsid_domain? ? the domain that you would like your lsids to have
> ?resources_script_domain? ? the domain that the RESOURCES script (a  
> servlet you have installed) uses.
>
>  Save this file in the 3 above stated locations.
Ok, done. Editing one file and copying it 2 times was fast enough. So  
it's not a big deal, but I do wonder you why you would want to have  
this redundancy. Are people ever going to use different settings in  
these 3 locations? If not, then why not have just one file to rule 'm  
all?
>  Restart tomcat and let me know what happens! My fingers are  
> crossed ;-)
Well, nothing yet. At least Tomcat doesn't complain. Seems to be Ok.  
But in Taverna I see my custom services from my local central as  
before and my custom objects are missing as before. You didn't  
mention it, but I assume I need to update my BioMOBY API stuff as  
well. So I tried an cvs up -d of moby-live. When I try make test for  
the Perl stuff I see a lot of tests failing.... Can I safely ignore  
them for now?

Pieter


> Eddie
>
>
>
> From: Pieter Neerincx [mailto:Pieter.Neerincx at wur.nl]
> Sent: Thursday, September 15, 2005 10:19 AM
> To: Edward Kawas
> Subject: Fwd: [MOBY-dev] Moby objects in Taverna. Where do they  
> come from?
>
>
>
> Hi Eddie,
>
>
>
> I suspect some problems with the mailinglist. I send the mail below  
> to the mailinglist yesterday, but so I haven't received it back  
> yet. Haven't received any other mails from the list anymore and one  
> of your mails of on 13-Sep-2005 was the last one showing up in the  
> online archive....
>
>
>
> Anyway, Tomcat is up and running so I'm awaiting further  
> instructions :).
>
>
>
> Cheers,
>
>
>
> Pieter
>
>
>
> Begin forwarded message:
>
>
>
>
> From: Pieter Neerincx <Pieter.Neerincx at wur.nl>
>
> Date: 14-September-2005 1:04:53 PM GMT+02:00
>
> To: Core developer announcements <moby-dev at portal.open-bio.org>
>
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do they come  
> from?
>
>
>
>
>
> Ok, got Tomcat installed... Please tell me what to download from  
> where and where to install it...
>
>
>
> Thanks,
>
>
>
> Pieter
>
>
>
> On 13-Sep-2005, at 5:58 PM, Edward Kawas wrote:
>
>
>
>
>
>
> Great. I will be waiting ;-)
>
>
>
> Eddie
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>
> Neerincx
>
> Sent: Tuesday, September 13, 2005 8:49 AM
>
> To: Core developer announcements
>
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>
> they come from?
>
>
>
> Hi,
>
>
>
> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
>
>
>
>
>
>
>
>
> Hi,
>
>
>
> For the Taverna workbench, download it temporarily from
>
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>
>
>
>
>
> 1.2.
>
>
>
>
>
>
> zip
>
>
>
>
>
>
>
> I will...
>
>
>
>
>
>
>
>
> This version contains my changes (the ones that are in
>
>
>
>
>
> the
>
>
>
>
>
>
> Taverna CVS).
>
>
>
> The Moby api actually now has a method in it called
>
> getResources (or something similar to that) that returns
>
>
>
>
>
> the
>
>
>
>
>
>
> locations of these documents for a registry.
>
>
>
>
>
>
>
> Ok, that sounds like a much more elegant solution :).
>
>
>
>
>
>
>
>
> So in the newly
>
> updated version of the plugin, I have removed the
>
>
>
>
>
> textbox
>
>
>
>
>
>
> that asks for this url and replaced it with an api call.
>
> (a description on the Moby plugin can be found at
>
>
>
>
>
>
>
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
>
> ht
>
>
>
>
>
>
> ml but is being changed to reflect the api calling).
>
>
>
> You are correct in saying that we are moving towards
>
>
>
>
>
> having
>
>
>
>
>
>
> Services and datatypes described by RDF.
>
>
>
> Finally, as for the servlet installation, if you are
>
> interested, I can guide you through this relatively
>
>
>
>
>
> painless
>
>
>
>
>
>
> procedure. I would just need to update certain files
>
>
>
>
>
> that
>
>
>
>
>
>
> you need to download and you would have to install
>
>
>
>
>
> tomcat.
>
>
>
> Ok, I will start with tomcat tomorrow... and will request
>
> further
>
> advice one I have that one up and running...
>
>
>
> Pieter
>
>
>
>
>
>
>
>
>
>
> Eddie
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: moby-dev-bounces at portal.open-bio.org
>
>
>
>
>
> [mailto:moby-
>
>
>
>
>
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>
>> Neerincx
>>
>> Sent: Tuesday, September 13, 2005 7:18 AM
>>
>> To: Core developer announcements
>>
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>
>>
>>
>>
> do
>
>
>
>
>
>> they come from?
>>
>>
>>
>> Hi Eddie,
>>
>>
>>
>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>>
>>
>> Objects aren't hard coded. They just have to be
>>
>>
>>
>>
>>
>>
>>
>> registered
>>
>>
>>
>>
>>
>>
>>
>>
>> in Mobycentral.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Today I fetched the source code for Taverna and
>>
>>
>>
>>
> 'grep'ed
>
>
>
>
>
>> over the
>>
>> files. There are several instances where the path to
>>
>>
>>
>>
> the
>
>
>
>
>
>> central
>>
>> biomoby central and an RDF file are hardcoded outside
>>
>>
>>
>>
> the
>
>
>
>
>
>> files in
>>
>> conf/. Sometime ago I started to work with Taverna and
>>
>>
>>
>>
> the
>
>
>
>
>
>> user
>>
>> manual only mentions the path to a biomoby central in
>>
>>
>>
>>
> the
>
>
>
>
>
>> conf/
>>
>> mygrid.properties file. So I appended my local biomoby
>>
>> central to
>>
>> this conf file and expected this would allow me to use
>>
>> both services
>>
>> and objects registered in my local central. I think
>>
>>
>>
>>
> that
>
>
>
>
>
>> the current
>>
>> situation where service info is fetched from a URL in
>>
>>
>>
>>
> the
>
>
>
>
>
>> conf/
>>
>> mygrid.properties file and object info is fetched from
>>
>>
>>
>>
> a
>
>
>
>
>
>> RDF file at
>>
>> a different location is very confusing and needlessly
>>
>> complex.
>>
>> Especially since I cannot supply an URL to a custom RDF
>>
>> file for my
>>
>> objects in the conf/mygrid.properties file. I did see
>>
>> though that I
>>
>> can right-click in Taverna to add a scavenger and than
>>
>>
>>
>>
> I
>
>
>
>
>
>> can supply
>>
>> both an URL to my local central and an URL to this RDF
>>
>> file for the
>>
>> objects.
>>
>>
>>
>> I also browsed the mailinglist and wiki. Did I
>>
>>
>>
>>
> understand
>
>
>
>
>
>> correctly
>>
>> that the current situation is a temporary solution and
>>
>> that
>>
>> eventually all info (hence services and objects) will
>>
>>
>>
>>
> be
>
>
>
>
>
>> described
>>
>> using RDF? Please correct me if I'm wrong...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I am not sure if you are up for it, but you could
>>
>>
>>
>>
> always
>
>
>
>
>
>>> install the servlets
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> Are those servlets generating this RDF file from the
>>
>>
>>
>>
> info
>
>
>
>
>
>> in a central?
>>
>> Is this documented somewhere? I couldn't find any
>>
>> reference to
>>
>> servlets at
>>
>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> (I could help you).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Your help is much appreciated! Thanks,
>>
>>
>>
>> Pieter
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Eddie
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>>
>> From: moby-dev-bounces at portal.open-bio.org
>>
>>
>>
>>
>>
>>
>>
>> [mailto:moby-
>>
>>
>>
>>
>>
>>
>>
>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>
>>> Neerincx
>>>
>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>
>>> To: Core developer announcements
>>>
>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
>>>
>>>
>>>
>>>
> Where
>
>
>
>
>
>>>>
>>>>
>>>>
>>>>
>>>>
>> do
>>
>>
>>
>>
>>
>>
>>
>>> they come from?
>>>
>>>
>>>
>>> Hi Eddie,
>>>
>>>
>>>
>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> The answer basically is that you also need to set up
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> some
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> servlets (RESOURCES script, types, etc), if you have
>>>
>>>
>>>
>>>
> a
>
>
>
>
>
>>>>> custom registry.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Thanks for the quick feedback. I was already afraid
>>>>
>>>>
>>>>
>>>>
> it
>
>
>
>
>
>>>> would be
>>>>
>>>> something like that :(.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So Taverna is basically reading in your services,
>>>>
>>>>
>>>>
>>>>
> and
>
>
>
>
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> find the objects, so it probably defaults to the
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Mobycentral
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> registry.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Would it help if I register my objects at THE central
>>>>
>>>> mobycentral
>>>>
>>>> instead of in my local central? Or are the objects
>>>>
>>>> hardcoded in some
>>>>
>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>
>>>>
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Eddie
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> dev-bounces at portal.open-bio.org] On Behalf Of
>>>>>
>>>>>
>>>>>
>>>>>
> Pieter
>
>
>
>
>
>>>>>> Neerincx
>>>>>>
>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>>
>>>>>> To: Core developer announcements
>>>>>>
>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> do
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> they
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> come from?
>>>>>
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> I'm having some trouble to make BioMOBY work with
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Taverna.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I have a
>>>>>
>>>>> local development Moby central. When I register
>>>>>
>>>>>
>>>>>
>>>>>
> both
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> new
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> services and
>>>>>
>>>>> new objects I notice that only my custom services
>>>>>
>>>>>
>>>>>
>>>>>
> are
>
>
>
>
>
>>>>>> listed in
>>>>>>
>>>>>> Taverna. The list of moby objects is not in sync
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> with
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> what
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> is
>>>>>
>>>>> registered in my central. So where does Taverna get
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> those
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> objects
>>>>>
>>>>> from and how do I get my own objects in there? Does
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> anyone
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> have a clue?
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> Pieter
>>>>>
>>>>>
>>>>>
>>>>> Wageningen University and Research centre (WUR)
>>>>>
>>>>> Laboratory of Bioinformatics
>>>>>
>>>>> Transitorium (building 312) room 1034
>>>>>
>>>>> Dreijenlaan 3
>>>>>
>>>>> 6703 HA Wageningen
>>>>>
>>>>> The Netherlands
>>>>>
>>>>> phone: 0317-483 060
>>>>>
>>>>> fax: 0317-483 584
>>>>>
>>>>> mobile: 06-143 66 783
>>>>>
>>>>> pieter.neerincx at wur.nl
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> MOBY-dev mailing list
>>>>>
>>>>> MOBY-dev at biomoby.org
>>>>>
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> MOBY-dev mailing list
>>>>
>>>> MOBY-dev at biomoby.org
>>>>
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>>
>>>> Laboratory of Bioinformatics
>>>>
>>>> Transitorium (building 312) room 1034
>>>>
>>>> Dreijenlaan 3
>>>>
>>>> 6703 HA Wageningen
>>>>
>>>> The Netherlands
>>>>
>>>> phone: 0317-483 060
>>>>
>>>> fax: 0317-483 584
>>>>
>>>> mobile: 06-143 66 783
>>>>
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> MOBY-dev mailing list
>>>>
>>>> MOBY-dev at biomoby.org
>>>>
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> MOBY-dev mailing list
>>>
>>> MOBY-dev at biomoby.org
>>>
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> Wageningen University and Research centre (WUR)
>>
>> Laboratory of Bioinformatics
>>
>> Transitorium (building 312) room 1034
>>
>> Dreijenlaan 3
>>
>> 6703 HA Wageningen
>>
>> The Netherlands
>>
>> phone: 0317-483 060
>>
>> fax: 0317-483 584
>>
>> mobile: 06-143 66 783
>>
>> pieter.neerincx at wur.nl
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> MOBY-dev mailing list
>>
>> MOBY-dev at biomoby.org
>>
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev at biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx at wur.nl
>
>
>
>
>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev at biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev at biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx at wur.nl
>
>
>
>
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx at wur.nl
>
>
>
>
>
>
>
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl






From edward.kawas at gmail.com  Fri Sep 16 09:54:24 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 06:54:24 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <D2F9CBDD-C6D9-4644-9267-EF3113A418FB@wur.nl>
Message-ID: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>

>I assume I need to update my BioMOBY API stuff as  
>well. So I tried an cvs up -d of moby-live. When I try make
>test for the Perl stuff I see a lot of tests failing....
>Can I safely ignore them for now?

I am not sure about this question. I know that Mark has a
new test suite but I am not sure if this is the suite that
you are running.

One more thing, if the servlets work, you would be able to
do the following:
http://yourURL:port/types/Objects
http://yourURL:port/RESOURCES/MOBY-S/Objects
http://yourURL:port/authority

These 3 links should show you something meaningful (html, a
file, more html).

Eddie



From Pieter.Neerincx at wur.nl  Fri Sep 16 10:04:24 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri, 16 Sep 2005 16:04:24 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
References: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
Message-ID: <2474E6AB-0592-4028-B15A-08062062350B@wur.nl>


On 16-Sep-2005, at 3:54 PM, Edward Kawas wrote:

>> I assume I need to update my BioMOBY API stuff as
>> well. So I tried an cvs up -d of moby-live. When I try make
>> test for the Perl stuff I see a lot of tests failing....
>> Can I safely ignore them for now?
>>
>
> I am not sure about this question. I know that Mark has a
> new test suite but I am not sure if this is the suite that
> you are running.

Ok, maybe Mark can shed some light on which version of the API is  
running on the current mobycentral server...

>
> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
> These 3 links should show you something meaningful (html, a
> file, more html).

Yes, works perfectly. I get xml/rdf returned and the first two links  
contain amongst others my custom objects :).


Pieter

>
> Eddie
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From senger at ebi.ac.uk  Fri Sep 16 10:10:38 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 15:10:38 +0100 (BST)
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>

> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
   Well, my understanding (Eddie/Mark, correct me if I am mistaken please)
is that you should *not* used these URLs directly (and Eddie should not
advice it :-)). You should use a new API method 'retrieveResourceURLs'
which gives you those URLs.
   This new method is implemented, for example, in jMoby (Java libraries
for biomoby) - in Central.java interface. It is also described in the
biomoby API.
 
   Regards,
   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)



From edward.kawas at gmail.com  Fri Sep 16 10:16:12 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:16:12 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad3af.701b5241.51a9.ffffed46@mx.gmail.com>



>    Well, my understanding (Eddie/Mark, correct me if I am
> mistaken please)
> is that you should *not* used these URLs directly (and
> Eddie should not
> advice it :-)). You should use a new API method
> 'retrieveResourceURLs'
> which gives you those URLs.
>    This new method is implemented, for example, in jMoby
> (Java libraries
> for biomoby) - in Central.java interface. It is also
> described in the
> biomoby API.


Relax Martin ;-) Just wanted to ensure that the installation
worked!

Eddie





From senger at ebi.ac.uk  Fri Sep 16 10:22:27 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 15:22:27 +0100 (BST)
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad3af.701b5241.51a9.ffffed46@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161521130.1458011-100000@mozart.ebi.ac.uk>

> Relax Martin ;-) Just wanted to ensure that the installation
> worked!
>
   That's exactly my point: How he can be sure that an installation worked
if he does not test all methods that should be supported...

   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)



From edward.kawas at gmail.com  Fri Sep 16 10:25:04 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:25:04 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161521130.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad5c3.1aa4d48b.6fb1.ffffe6f6@mx.gmail.com>

>    That's exactly my point: How he can be sure that an
> installation worked
> if he does not test all methods that should be
supported...

Testing the servlet installation. 

The updated Moby code in Taverna utilizes the new api calls!



From senger at ebi.ac.uk  Fri Sep 16 10:30:46 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 15:30:46 +0100 (BST)
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad5c3.1aa4d48b.6fb1.ffffe6f6@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161529570.1458011-100000@mozart.ebi.ac.uk>

> The updated Moby code in Taverna utilizes the new api calls!
>
   That's good.
   Which reminds me: have you reached (with Mark) a conclusion about the
content-type of these resources?

   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)



From Pieter.Neerincx at wur.nl  Fri Sep 16 10:35:13 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri, 16 Sep 2005 16:35:13 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <106CCC00-6072-41B9-82B5-C031F0E0F380@wur.nl>


On 16-Sep-2005, at 4:10 PM, Martin Senger wrote:

>> One more thing, if the servlets work, you would be able to
>> do the following:
>> http://yourURL:port/types/Objects
>> http://yourURL:port/RESOURCES/MOBY-S/Objects
>> http://yourURL:port/authority
>>
>>
>    Well, my understanding (Eddie/Mark, correct me if I am mistaken  
> please)
> is that you should *not* used these URLs directly (and Eddie should  
> not
> advice it :-)).

That does make sense, but having a quick look at what those URLs  
produce just to get an quick idea whether those servlets are working  
in Tomcat at all can't hurt :)

> You should use a new API method 'retrieveResourceURLs'
> which gives you those URLs.
>    This new method is implemented, for example, in jMoby (Java  
> libraries
> for biomoby) - in Central.java interface. It is also described in the
> biomoby API.

Ok, so I definitely should upgrade my biomoby API as well...

Thanks,

Pieter

>
>    Regards,
>    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)
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Fri Sep 16 10:41:22 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:41:22 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <106CCC00-6072-41B9-82B5-C031F0E0F380@wur.nl>
Message-ID: <432ad996.18f52057.633b.2430@mx.gmail.com>

> Ok, so I definitely should upgrade my biomoby API as
> well...
Yes. Perhaps others who have done this upgrade could give
you a few pointers. Anyone?!

Thanks,

Ed



From edward.kawas at gmail.com  Fri Sep 16 10:42:35 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:42:35 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161529570.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad9de.370ca386.0467.ffffc707@mx.gmail.com>


>    That's good.
>    Which reminds me: have you reached (with Mark) a
> conclusion about the
> content-type of these resources?


If only you could hear me whistling aloud as I look the
other way.

We haven't discussed this yet. Sorry Martin.

Eddie



From Pieter.Neerincx at wur.nl  Fri Sep 16 11:01:12 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri, 16 Sep 2005 17:01:12 +0200
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <6C0F151C-AB25-470F-A8E9-89996DCC051F@wur.nl>

Hi Frank,

On 16-Sep-2005, at 4:26 PM, Gibbons, Francis wrote:

> Pieter,
>
> I wrote many of the tests for the  Perl API. When I run them, I see  
> a 99% pass rate, or better. I'm very interested to know which ones  
> are failing for you, and what your local installation looks like (I  
> guess you have a local registry? what's your OS? Perl version? etc.)

I'm running SuSE Linux Enterprise Server 9 (SLES9) with all the  
latest and greatest updates / patches. My Perl version is 5.8.3  
(default that comes with SLES9) I do have a local biomobycentral, but  
that shouldn't make any difference for the tests. I haven't set  
MOBY_xxx ENV vars, so for the tests  everything should default to the  
central mobycentral.

I see 3/361 subtests failed, 99.17% okay and 8 subtests UNEXPECTEDLY  
SUCCEEDED. The 99.17% might seem not too shabby, but for a user like  
me it's pretty difficult to figure out how essential the failing  
stuff is :(.... I'll just give it try anyway. If it doesn't work I'll  
downgrade again. Keeping my fingers crossed...

Below is what I got from the tests.

Cheers,

Pieter

pieter at bioinfw05:~/moby-live/Perl> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Central...................................ok
t/Client-Central............................NOK 3#     Failed test (t/ 
Client-Central.t at line 73)
#     MOBY::Client::Central->can('retrieveObjectSchema') failed
# Registry failed to supply mandatory methods
t/Client-Central............................ok 134/0# Looks like you  
failed 1 tests of 134.
t/Client-Central............................dubious
         Test returned status 1 (wstat 256, 0x100)
Scalar found where operator expected at (eval 153) line 1, near  
"'int'  $__val"
         (Missing operator before   $__val?)
DIED. FAILED test 3
         Failed 1/134 tests, 99.25% okay
t/Client-CollectionArticle..................ok
t/Client-OntologyServer.....................NOK 2#     Failed test (t/ 
Client-OntologyServer.t at line 36)
#     MOBY::Client::OntologyServer->can('relationshipExists') failed
# OntologyServer doesn't implement full API
t/Client-OntologyServer.....................ok 24/0Use of  
uninitialized value in pattern match (m//) at /mnt/geninf01/home/ 
geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/OntologyServer.pm  
line 98.
Use of uninitialized value in pattern match (m//) at /mnt/geninf01/ 
home/geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/ 
OntologyServer.pm line 98.
t/Client-OntologyServer.....................ok 25/0No such method:  
MOBY::Client::OntologyServer::relationshipExists at t/Client- 
OntologyServer.t line 76
# Looks like you failed 1 tests of 25.
# Looks like your test died just after 25.
t/Client-OntologyServer.....................dubious
         Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED test 2
         Failed 1/25 tests, 96.00% okay
t/Client-Registration.......................ok
t/Client-SecondaryArticle...................ok
t/Client-Service............................NOK 3#     Failed test (t/ 
Client-Service.t at line 36)
#     MOBY::Client::Service->can('serviceName') failed
# MOBY::Client::Service doesn't implement full API.
t/Client-Service............................ok 6/0# Looks like you  
failed 1 tests of 6.
t/Client-Service............................dubious
         Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 3
         Failed 1/6 tests, 83.33% okay
t/Client-ServiceInstance....................ok
t/Client-SimpleArticle......................ok
t/CommonSubs................................ok 18/0MOBY::CommonSubs  
WARNING ** the namespace 'bogus NS' does not exist in the MOBY  
ontology, and does not have a valid LSID
t/CommonSubs................................ok
t/Config....................................skipped
         all skipped: Required only for local MOBY Central
t/CrossReference............................ok
t/dbConnect.................................ok
t/lsid-authority-ClassResolver..............ok
t/lsid-authority-dbConnect..................ok
t/lsid-authority-Error......................ok
t/lsid-authority-NamespaceResolver..........ok
t/lsid-authority-PredicateResolver..........ok
t/lsid-authority-RDFConfigure...............ok
t/lsid-authority-RelationshipResolver.......ok
t/lsid-authority-ServiceInstanceResolver....skipped
         all skipped: Skip until apparent namespace pollution fixed  
in ServiceInstanceResolver
t/lsid-authority-ServiceResolver............ok
t/Template..................................skipped
         all skipped: This is just a template
Failed Test               Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------ 
-------
t/Client-Central.t           1   256   134    1   0.75%  3
t/Client-OntologyServer.t  255 65280    25    1   4.00%  2
t/Client-Service.t           1   256     6    1  16.67%  3
  (8 subtests UNEXPECTEDLY SUCCEEDED), 3 tests skipped.
Failed 3/23 test scripts, 86.96% okay. 3/361 subtests failed, 99.17%  
okay.
make: *** [test_dynamic] Error 255


> Clearly, we should have a test suite that passes for most  
> developers most of the time, so that they can be alerted quickly if  
> they break something. So it's really important for me to know which  
> tests are failing and why: the tests may need to be rewritten.
>
> Thanks for your feedback.
>
> -Frank
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org on behalf of Edward Kawas
> Sent: Fri 9/16/2005 9:54 AM
> To: 'Core developer announcements'
> Cc: 'Pieter Neerincx'
> Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come  
> from?
>
> >I assume I need to update my BioMOBY API stuff as
> >well. So I tried an cvs up -d of moby-live. When I try make
> >test for the Perl stuff I see a lot of tests failing....
> >Can I safely ignore them for now?
>
> I am not sure about this question. I know that Mark has a
> new test suite but I am not sure if this is the suite that
> you are running.
>
> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
> These 3 links should show you something meaningful (html, a
> file, more html).
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Fri Sep 16 10:14:50 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:14:50 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <2474E6AB-0592-4028-B15A-08062062350B@wur.nl>
Message-ID: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>

> Yes, works perfectly. I get xml/rdf returned and the first
> two links
> contain amongst others my custom objects :).

Great! That is good news.

Eddie



From fgibbons at hms.harvard.edu  Fri Sep 16 12:27:30 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri, 16 Sep 2005 12:27:30 -0400
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <6C0F151C-AB25-470F-A8E9-89996DCC051F@wur.nl>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <5.2.1.1.2.20050916121257.0123eca0@email.med.harvard.edu>

Pieter,

Thanks for the quick feedback. In fact, your output is pretty much the same 
as mine, specifically in the tests that failed. There are also some which 
"unexpectedly succeed" for me too, I just haven't had a chance to check 
what they are.

The failing stuff is for the most part, apparently not that important. It 
represents aspects of the stated API (in particularly when it says "failed 
to implement complete API" or similar): methods which the API describes, 
but which are not yet implemented. I just got involved recently as a 
developer, and writing tests has been my way to understand the API, from 
the inside out. I'll modify the tests so that these go on the TO-DO list, 
and no longer generate error messages (it's not clear when they will 
actually be implemented).

There is one failure that concerns me, this one:

t/Client-Central............................dubious
         Test returned status 1 (wstat 256, 0x100)
Scalar found where operator expected at (eval 153) line 1, near
"'int'  $__val"
         (Missing operator before   $__val?)
DIED. FAILED test 3
         Failed 1/134 tests, 99.25% okay

I don't understand what '$__val' is referring to. More importantly, it 
looks like it's causing the entire test to abort ("DIED"), yet it reports 
only 1/134 failed. There are no explicit eval's in the test script, perhaps 
the message is coming from a module that is imported with 'use'.  I've 
searched the MOBY codebase, and there is no variable with that name, so it 
may be coming in from an external module.  If you have any ideas, I'm 
interested in hearing them, since this single script represents about half 
of the current tests, so if it aborts, especially if it aborts reporting 
success, that's a problem.

So thanks again for the feedback. I'll fix most of those problems I 
mentioned, which should make the remaining one (above) stand out more.

-Frank

At 11:01 AM 9/16/2005, you wrote:
>Hi Frank,
>
>On 16-Sep-2005, at 4:26 PM, Gibbons, Francis wrote:
>
>>Pieter,
>>
>>I wrote many of the tests for the  Perl API. When I run them, I see
>>a 99% pass rate, or better. I'm very interested to know which ones
>>are failing for you, and what your local installation looks like (I
>>guess you have a local registry? what's your OS? Perl version? etc.)
>
>I'm running SuSE Linux Enterprise Server 9 (SLES9) with all the
>latest and greatest updates / patches. My Perl version is 5.8.3
>(default that comes with SLES9) I do have a local biomobycentral, but
>that shouldn't make any difference for the tests. I haven't set
>MOBY_xxx ENV vars, so for the tests  everything should default to the
>central mobycentral.
>
>I see 3/361 subtests failed, 99.17% okay and 8 subtests UNEXPECTEDLY
>SUCCEEDED. The 99.17% might seem not too shabby, but for a user like
>me it's pretty difficult to figure out how essential the failing
>stuff is :(.... I'll just give it try anyway. If it doesn't work I'll
>downgrade again. Keeping my fingers crossed...
>
>Below is what I got from the tests.
>
>Cheers,
>
>Pieter
>
>pieter at bioinfw05:~/moby-live/Perl> make test
>PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
>"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
>t/Central...................................ok
>t/Client-Central............................NOK 3#     Failed test (t/ 
>Client-Central.t at line 73)
>#     MOBY::Client::Central->can('retrieveObjectSchema') failed
># Registry failed to supply mandatory methods
>t/Client-Central............................ok 134/0# Looks like you
>failed 1 tests of 134.
>t/Client-Central............................dubious
>         Test returned status 1 (wstat 256, 0x100)
>Scalar found where operator expected at (eval 153) line 1, near
>"'int'  $__val"
>         (Missing operator before   $__val?)
>DIED. FAILED test 3
>         Failed 1/134 tests, 99.25% okay
>t/Client-CollectionArticle..................ok
>t/Client-OntologyServer.....................NOK 2#     Failed test (t/ 
>Client-OntologyServer.t at line 36)
>#     MOBY::Client::OntologyServer->can('relationshipExists') failed
># OntologyServer doesn't implement full API
>t/Client-OntologyServer.....................ok 24/0Use of
>uninitialized value in pattern match (m//) at /mnt/geninf01/home/ 
>geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/OntologyServer.pm
>line 98.
>Use of uninitialized value in pattern match (m//) at /mnt/geninf01/ 
>home/geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/ OntologyServer.pm 
>line 98.
>t/Client-OntologyServer.....................ok 25/0No such method:
>MOBY::Client::OntologyServer::relationshipExists at t/Client- 
>OntologyServer.t line 76
># Looks like you failed 1 tests of 25.
># Looks like your test died just after 25.
>t/Client-OntologyServer.....................dubious
>         Test returned status 255 (wstat 65280, 0xff00)
>DIED. FAILED test 2
>         Failed 1/25 tests, 96.00% okay
>t/Client-Registration.......................ok
>t/Client-SecondaryArticle...................ok
>t/Client-Service............................NOK 3#     Failed test (t/ 
>Client-Service.t at line 36)
>#     MOBY::Client::Service->can('serviceName') failed
># MOBY::Client::Service doesn't implement full API.
>t/Client-Service............................ok 6/0# Looks like you
>failed 1 tests of 6.
>t/Client-Service............................dubious
>         Test returned status 1 (wstat 256, 0x100)
>DIED. FAILED test 3
>         Failed 1/6 tests, 83.33% okay
>t/Client-ServiceInstance....................ok
>t/Client-SimpleArticle......................ok
>t/CommonSubs................................ok 18/0MOBY::CommonSubs
>WARNING ** the namespace 'bogus NS' does not exist in the MOBY
>ontology, and does not have a valid LSID
>t/CommonSubs................................ok
>t/Config....................................skipped
>         all skipped: Required only for local MOBY Central
>t/CrossReference............................ok
>t/dbConnect.................................ok
>t/lsid-authority-ClassResolver..............ok
>t/lsid-authority-dbConnect..................ok
>t/lsid-authority-Error......................ok
>t/lsid-authority-NamespaceResolver..........ok
>t/lsid-authority-PredicateResolver..........ok
>t/lsid-authority-RDFConfigure...............ok
>t/lsid-authority-RelationshipResolver.......ok
>t/lsid-authority-ServiceInstanceResolver....skipped
>         all skipped: Skip until apparent namespace pollution fixed
>in ServiceInstanceResolver
>t/lsid-authority-ServiceResolver............ok
>t/Template..................................skipped
>         all skipped: This is just a template
>Failed Test               Stat Wstat Total Fail  Failed  List of Failed
>------------------------------------------------------------------------ 
>-------
>t/Client-Central.t           1   256   134    1   0.75%  3
>t/Client-OntologyServer.t  255 65280    25    1   4.00%  2
>t/Client-Service.t           1   256     6    1  16.67%  3
>  (8 subtests UNEXPECTEDLY SUCCEEDED), 3 tests skipped.
>Failed 3/23 test scripts, 86.96% okay. 3/361 subtests failed, 99.17%
>okay.
>make: *** [test_dynamic] Error 255
>
>
>>Clearly, we should have a test suite that passes for most
>>developers most of the time, so that they can be alerted quickly if
>>they break something. So it's really important for me to know which
>>tests are failing and why: the tests may need to be rewritten.
>>
>>Thanks for your feedback.
>>
>>-Frank
>>-----Original Message-----
>>From: moby-dev-bounces at portal.open-bio.org on behalf of Edward Kawas
>>Sent: Fri 9/16/2005 9:54 AM
>>To: 'Core developer announcements'
>>Cc: 'Pieter Neerincx'
>>Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come
>>from?
>>
>> >I assume I need to update my BioMOBY API stuff as
>> >well. So I tried an cvs up -d of moby-live. When I try make
>> >test for the Perl stuff I see a lot of tests failing....
>> >Can I safely ignore them for now?
>>
>>I am not sure about this question. I know that Mark has a
>>new test suite but I am not sure if this is the suite that
>>you are running.
>>
>>One more thing, if the servlets work, you would be able to
>>do the following:
>>http://yourURL:port/types/Objects
>>http://yourURL:port/RESOURCES/MOBY-S/Objects
>>http://yourURL:port/authority
>>
>>These 3 links should show you something meaningful (html, a
>>file, more html).
>>
>>Eddie
>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>Wageningen University and Research centre (WUR)
>Laboratory of Bioinformatics
>Transitorium (building 312) room 1034
>Dreijenlaan 3
>6703 HA Wageningen
>The Netherlands
>phone: 0317-483 060
>fax: 0317-483 584
>mobile: 06-143 66 783
>pieter.neerincx at wur.nl
>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From fgibbons at hms.harvard.edu  Fri Sep 16 13:59:10 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri, 16 Sep 2005 13:59:10 -0400
Subject: [MOBY-dev] I have a subscription,
 but I keep getting messages saying I'm not subscribed....
Message-ID: <5.2.1.1.2.20050916135616.027b2030@email.med.harvard.edu>

Can anyone help me with this: I am signed up for MOBY-dev, but every time I 
post, I get a message telling me that I'm not, and that my posting is 
awaiting approval by the moderators. I recently (yesterday) changed from 
digest mode to getting each message as it's posted on MOBY-l, and this 
behavior seemed to coincide with that. Does anyone know what I should do? 
Would unsubscribing and resubscribing be the way to go?

Thanks,

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From fgibbons at hms.harvard.edu  Fri Sep 16 14:02:24 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri, 16 Sep 2005 14:02:24 -0400
Subject: [MOBY-dev] Schedule? You mean there's a schedule?
In-Reply-To: <200509152247.j8FMlBnq032114@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20050916140030.01161200@email.med.harvard.edu>

Mark,

At 06:47 PM 9/15/2005, moby-dev-request at portal.open-bio.org wrote:
>Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep on schedule.
                                                                                             ^^^^^^^^^^^^

Mark,

So what is thing you call a "schedule"? Where might an interested party 
find it, if so inclined.... :-)

(I know you're on vacay, no rush, just curious/kidding.)

-F


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From senger at ebi.ac.uk  Fri Sep 16 14:37:50 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 19:37:50 +0100 (BST)
Subject: [MOBY-dev] I have a subscription, but I keep getting messages
	saying I'm not subscribed....
In-Reply-To: <5.2.1.1.2.20050916135616.027b2030@email.med.harvard.edu>
Message-ID: <Pine.OSF.4.21.0509161936370.1458011-100000@mozart.ebi.ac.uk>

> behavior seemed to coincide with that. Does anyone know what I should do? 
> Would unsubscribing and resubscribing be the way to go?
>
   Because Mark is on holiday, you may try and ask directly the admin of
the open-bio: Chris Dagdigian <dag at sonsorol.org>.
 
   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)



From simont at mcw.edu  Fri Sep 16 13:50:12 2005
From: simont at mcw.edu (Twigger Simon)
Date: Fri, 16 Sep 2005 12:50:12 -0500
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <A8FC74D9-A5A5-47DB-BC93-8FB52365226B@mcw.edu>

Hi Mark, Eddie,

Thanks for the invite, I am certainly happy to help out on the RFC  
committee. I promise to vote early and often.

Simon,


On Sep 15, 2005, at 5:46 PM, Edward Kawas wrote:

>
>
> -----Original Message-----
> From: mark wilkinson [mailto:markw at illuminae.com]
> Sent: Thursday, September 15, 2005 3:06 PM
> To: Frank Gibbons; Eddie Kawas
> Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
> Error-handling in MOBY-S
>
> Hey Frank! Cc Eddie
>
> Thanks for riding this.  I am on holiday, and not in Net
> contact except by blackberry, so I'm not "useful" right now.
>
> I think we should put out an invitation on the -dev list for
> the RFC committee with a tenure of one year, but also
> specifically invite the main developers/vested interests to
> be part of it:  me, you, martin, eddie, simon, heiko, paul,
> yan wong, and at least one from the spanish contingent (have
> I missed anyone?).
>
> I don't have all their email addresses on my bberry so
> unless you or Eddie (cc'd) post this invitation to the dev
> list yourselves it may take a week before I am back in
> net-world.  Eddie, could you do this? Tomorrow or this
> afternoon?  It would be good to get this sorted asap to keep
> on schedule.
>
> M
>
>
> -----Original Message-----
> From: Frank Gibbons <fgibbons at hms.harvard.edu>
> Date: Thu, 15 Sep 2005 11:21:53
> To:moby-l at biomoby.org
> Subject: [MOBY-l] Using bugzilla to continue RFC on
> Error-handling in MOBY-S
>
> Hi,
>
> I've just added a few "bugs" to the bugzilla, to try to
> preserve the RFC
> momentum built up over the past few weeks. I propose that,
> although
> bugzilla is perhaps not ideal for this, it is what it is, it
> is what we
> have, and it will do for now.
>
> I'd like to propose that we try to continue development of
> this RFC through
> bugzilla (see bug #1863), rather than through the mailing
> list. Searching
> through old mail messages (or worse still, through the
> digest, with all of
> its repeated messages and long inclusions) is tedious, and I
> think
> contributes to the loss in momentum.
>
> So far, in Martin's scheme for RFC-processing, we have
> (numbers are those
> used in Martin's original suggestion, now available in the
> codebase as
> Docs/MOBY-S_API/RFC.html)
>
> 1. Had a suggestion made by INB to add this features. It was
> added to
> bugzilla, No. 1863
> 2. Suggested to resolve it by today (Sep-15)
> 3. Martin backed up the RFC
> 4. I think we have the resources to make this change - it
> seems an
> essential part of a robust API, which version 1.0 should be.
> 5a. List members have exchanged several comments back and
> forth, resulting
> in amended versions of the RFC being posted to the mailing
> list.
> 5b. We've also gotten a little side-tracked by the related
> articleName problem.
>
> So it seems to me that it's time to vote on it (step 6 of
> the Senger
> seven-step scheme ;-). Martin suggested that Mark would ask
> a limited
> number of people to vote on it after the resolution date
> (today). I guess
> those people would self-select, or maybe Mark will select
> them. They will
> be requested to make a one-year commitment.
>
> After that comes step 7, the "fun part": implementation,
> documentation.
>
> We're pretty close to reaching a conclusion on this. The
> fact is that even
> if we do nothing, people want this functionality, and they
> WILL implement
> it. It is in everybody's interest that we have a
> specification for what the
> functionality should be. It may change over time, but I
> think there has
> been enough back-and-forth that we have a reasonable first
> draft, and
> should vote on it.
>
> -Frank
> P.S. Of course, this message, along with version 1.7.1 of
> the RFC is
> attached to the bug on bugzilla
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
> Boston MA 02115, USA.
> Tel: 617-432-3555       Fax:
> 617-432-3557       http://llama.med.harvard.edu/~fgibbons
>
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>
> --
> Mark Wilkinson
> ..on the road!
>
>

--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw



From markw at illuminae.com  Fri Sep 16 19:05:49 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri, 16 Sep 2005 23:05:49 +0000 GMT
Subject: [MOBY-dev] Schedule? You mean there's a schedule?
Message-ID: <1955319201-1126912049-cardhu_blackberry.rim.net-17094-@engine09-cell01>

I just meant that we had decided to have the vote on the 15th, but the committee has not been assembed yet, so we are a bit behind schedule for that vote :-)

M


-----Original Message-----
From: Frank Gibbons <fgibbons at hms.harvard.edu>
Date: Fri, 16 Sep 2005 14:02:24 
To:moby-dev at biomoby.org
Subject: [MOBY-dev] Schedule? You mean there's a schedule?

Mark,

At 06:47 PM 9/15/2005, moby-dev-request at portal.open-bio.org wrote:
>Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep on schedule.
                                                                                             ^^^^^^^^^^^^

Mark,

So what is thing you call a "schedule"? Where might an interested party 
find it, if so inclined.... :-)

(I know you're on vacay, no rush, just curious/kidding.)

-F


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

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

--
Mark Wilkinson
...on the road!


From senger at ebi.ac.uk  Mon Sep 19 03:30:09 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 19 Sep 2005 08:30:09 +0100 (BST)
Subject: [MOBY-dev] jMoby:  caching in CentralImpl
In-Reply-To: <42CEC551.4090108@ucalgary.ca>
Message-ID: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>

Paul (and others),
   I have mentioned in Vancouver that I would like to remove caching from
CentralImpl because we have now probably more powerfull caching in
CentralDigestCachedImpl (which I am improving now), and we will have even
better caching when we implement it based on RDF Resources. You said that
I can go ahead. But I would like to confirm it because removing it from
CentralImpl may break some of your code (or of the others).
   Do I have your green lights?

   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)



From senger at ebi.ac.uk  Mon Sep 19 03:41:33 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 19 Sep 2005 08:41:33 +0100 (BST)
Subject: [MOBY-dev] API for retrieving namespaces insufficient
Message-ID: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>

Mark,
   I know that the registry API can be replaced by its RDF representation,
but it is still an API and we are using it a lot (because for simple
requests it will be always faster than retrieving the whole RDF
document). That's why I would like to make it better. One missing thing
(actually a 'sink' :-)) is that you register some attributes for a
namespace but there is no way to get it back (that's why I said '
sink'). For example, authority. I suggest that you could add it to the
object returned from retrieveNamespaces. Do it for me please...

   Add there something like please:
           <contactEmail>your_name at contact.address.com</contactEmail>
           <authURI>Your.URI.here</authURI>

   Does anybody object?
   If not, could Eddie make it soon please (well, I mean now :-)?

   The same applies, of course, for service types. These two (and, afaik,
only these two) sinks exist in the current API).

   Many thanks,
   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)



From dgpisano at cnb.uam.es  Mon Sep 19 05:12:57 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon, 19 Sep 2005 11:12:57 +0200
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <432E8119.4030502@cnb.uam.es>

I'll be glad to represent the INB (aka "The Spanish Contingent") in the 
RFC commitee for a year. Thanks for your invitation,

David

Edward Kawas escribi?:

>-----Original Message-----
>From: mark wilkinson [mailto:markw at illuminae.com] 
>Sent: Thursday, September 15, 2005 3:06 PM
>To: Frank Gibbons; Eddie Kawas
>Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
>Error-handling in MOBY-S
>
>Hey Frank! Cc Eddie
>
>Thanks for riding this.  I am on holiday, and not in Net
>contact except by blackberry, so I'm not "useful" right now.
>
>I think we should put out an invitation on the -dev list for
>the RFC committee with a tenure of one year, but also
>specifically invite the main developers/vested interests to
>be part of it:  me, you, martin, eddie, simon, heiko, paul,
>yan wong, and at least one from the spanish contingent (have
>I missed anyone?).
>
>I don't have all their email addresses on my bberry so
>unless you or Eddie (cc'd) post this invitation to the dev
>list yourselves it may take a week before I am back in
>net-world.  Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep
>on schedule.
>
>M
>
>
>-----Original Message-----
>From: Frank Gibbons <fgibbons at hms.harvard.edu>
>Date: Thu, 15 Sep 2005 11:21:53 
>To:moby-l at biomoby.org
>Subject: [MOBY-l] Using bugzilla to continue RFC on
>Error-handling in MOBY-S
>
>Hi,
>
>I've just added a few "bugs" to the bugzilla, to try to
>preserve the RFC 
>momentum built up over the past few weeks. I propose that,
>although 
>bugzilla is perhaps not ideal for this, it is what it is, it
>is what we 
>have, and it will do for now.
>
>I'd like to propose that we try to continue development of
>this RFC through 
>bugzilla (see bug #1863), rather than through the mailing
>list. Searching 
>through old mail messages (or worse still, through the
>digest, with all of 
>its repeated messages and long inclusions) is tedious, and I
>think 
>contributes to the loss in momentum.
>
>So far, in Martin's scheme for RFC-processing, we have
>(numbers are those 
>used in Martin's original suggestion, now available in the
>codebase as 
>Docs/MOBY-S_API/RFC.html)
>
>1. Had a suggestion made by INB to add this features. It was
>added to 
>bugzilla, No. 1863
>2. Suggested to resolve it by today (Sep-15)
>3. Martin backed up the RFC
>4. I think we have the resources to make this change - it
>seems an 
>essential part of a robust API, which version 1.0 should be.
>5a. List members have exchanged several comments back and
>forth, resulting 
>in amended versions of the RFC being posted to the mailing
>list.
>5b. We've also gotten a little side-tracked by the related
>articleName problem.
>
>So it seems to me that it's time to vote on it (step 6 of
>the Senger 
>seven-step scheme ;-). Martin suggested that Mark would ask
>a limited 
>number of people to vote on it after the resolution date
>(today). I guess 
>those people would self-select, or maybe Mark will select
>them. They will 
>be requested to make a one-year commitment.
>
>After that comes step 7, the "fun part": implementation,
>documentation.
>
>We're pretty close to reaching a conclusion on this. The
>fact is that even 
>if we do nothing, people want this functionality, and they
>WILL implement 
>it. It is in everybody's interest that we have a
>specification for what the 
>functionality should be. It may change over time, but I
>think there has 
>been enough back-and-forth that we have a reasonable first
>draft, and 
>should vote on it.
>
>-Frank
>P.S. Of course, this message, along with version 1.7.1 of
>the RFC is 
>attached to the bug on bugzilla
>
>PhD, Computational Biologist,
>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
>Boston MA 02115, USA.
>Tel: 617-432-3555       Fax: 
>617-432-3557       http://llama.med.harvard.edu/~fgibbons 
>
>_______________________________________________
>moby-l mailing list
>moby-l at biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>--
>Mark Wilkinson
>..on the road!
>
>
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050919/8552b4c0/dgpisano-0002.vcf

From pieter.neerincx at wur.nl  Mon Sep 19 05:41:45 2005
From: pieter.neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 19 Sep 2005 11:41:45 +0200
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
Message-ID: <36612E59-02E5-41BB-842A-EF368649EB2B@wur.nl>

Hi Frank,

On 16-Sep-2005, at 8:04 PM, Frank Gibbons wrote:

> Hi Pieter,
>
> I've updated the tests and some of the Perl code, so that *nothing*  
> should fail now.

Thanks. It's a good thing you already created tests for parts of the  
API that have not been implemented yet. But it's even better that  
those tests don't confuse users anymore :).

> You might see messages about _skip_ped tests, but nothing about  
> "unexpectedly succeed"ing tests, etc. In particular, if Client- 
> Central.t still fails, I'm interested in finding out why.

Client-Central.t is fine now. I also don't know where the '$__val'  
came from. But the tests are not complaining about it anymore :) In  
addition to some messages about skipped tests I do get a warning  
about a non-existing 'bogus NS' in CommonSubs.t. See below for the  
output of the tests. I assume it's safe to ignore that one.

>
> -Frank
>

Cheers,

Pieter


pieter at bioinfw05:~/moby-live/Perl> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Central...................................ok
t/Client-Central............................ok
t/Client-CollectionArticle..................ok
t/Client-OntologyServer.....................ok
         5/39 skipped: relationshipExists not implemented
t/Client-Registration.......................ok
t/Client-SecondaryArticle...................ok
t/Client-Service............................ok
t/Client-ServiceInstance....................ok
t/Client-SimpleArticle......................ok
t/CommonSubs................................ok 18/0MOBY::CommonSubs  
WARNING ** the namespace 'bogus NS' does not exist in the MOBY  
ontology, and does not have a valid LSID
t/CommonSubs................................ok
t/Config....................................skipped
         all skipped: Required only for local MOBY Central
t/CrossReference............................ok
t/dbConnect.................................ok
t/lsid-authority-ClassResolver..............ok
t/lsid-authority-dbConnect..................ok
t/lsid-authority-Error......................ok
t/lsid-authority-NamespaceResolver..........ok
t/lsid-authority-PredicateResolver..........ok
t/lsid-authority-RDFConfigure...............ok
t/lsid-authority-RelationshipResolver.......ok
t/lsid-authority-ServiceInstanceResolver....skipped
         all skipped: Skip until apparent namespace pollution fixed  
in ServiceInstanceResolver
t/lsid-authority-ServiceResolver............ok
t/Template..................................skipped
         all skipped: This is just a template
All tests successful, 3 tests and 5 subtests skipped.
Files=23, Tests=376, 61 wallclock secs ( 4.61 cusr +  0.59 csys =   
5.20 CPU)


From Pieter.Neerincx at wur.nl  Mon Sep 19 09:04:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 19 Sep 2005 15:04:33 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>
References: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>
Message-ID: <7FA8D0EE-81DE-4DF1-95BE-146E5EB55DC6@wur.nl>

Hi Eddie,

I think I'm almost there. When I use the 'old / official' Taverna 1.2  
and manually add a biomoby scavanger for my local central (supplying  
both an URL to my biomoby central registry and my biomoby object RDF  
document) it works. I get both my custom services and custom objects  
listed in Taverna. So the servlets and Tomcat are doing there job.  
But when I use you modified version of Taverna from: http:// 
bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.zip it doesn't  
work. The custom objects are still missing. I updated my biomoby API  
stuff once more today from CVS, but that didn't help.... I was  
wondering if it is necessary to put some additional lines in my  
mobycentral.config file. After browsing the code it seems to me that  
MOBY::Central->retrieveResourceURLs tries to fetch resourceURL and  
allResources lines from that file...

Cheers,

Pieter




On 16-Sep-2005, at 4:14 PM, Edward Kawas wrote:

>> Yes, works perfectly. I get xml/rdf returned and the first
>> two links
>> contain amongst others my custom objects :).
>>
>
> Great! That is good news.
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Mon Sep 19 09:11:25 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 19 Sep 2005 06:11:25 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <7FA8D0EE-81DE-4DF1-95BE-146E5EB55DC6@wur.nl>
Message-ID: <432eb8ff.589d431d.4335.2914@mx.gmail.com>

Hi,

> I
> was
> wondering if it is necessary to put some additional lines
> in my
> mobycentral.config file. After browsing the code it seems
> to me that
> MOBY::Central->retrieveResourceURLs tries to fetch
> resourceURL and
> allResources lines from that file...

[mobycentral]
dbname = mobycentral
rdfagent = /usr/local/apache2/MOBY/rdfagent
lsid_authority = biomoby.org
lsid_namespace = serviceinstance
resourceURL =
http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
allResources = http://biomoby.org/RESOURCES/MOBY-S/FULL
 
[mobyobject]
dbname = mobyobject
lsid_authority = biomoby.org
lsid_namespace = objectclass
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Objects

[mobynamespace]
dbname = mobynamespace
lsid_authority = biomoby.org
lsid_namespace = namespacetype
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Namespaces

[mobyservice]
dbname = mobyservice
lsid_authority = biomoby.org
lsid_namespace = servicetype
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Services

[mobyrelationship]
dbname = mobyrelationship
lsid_authority = biomoby.org
#lsid_namespace = relationshiptype

Those are the new lines (as far as I know) that should be
added to the config file.

Eddie



From gordonp at ucalgary.ca  Mon Sep 19 09:02:53 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Mon, 19 Sep 2005 07:02:53 -0600
Subject: [MOBY-dev] jMoby:  caching in CentralImpl
In-Reply-To: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>
Message-ID: <432EB6FD.7070508@ucalgary.ca>

Go ahead.  As long as someone tells me they're going to break my code, 
rather than just doing it, I'm fine :-)

Martin Senger wrote:

>Paul (and others),
>   I have mentioned in Vancouver that I would like to remove caching from
>CentralImpl because we have now probably more powerfull caching in
>CentralDigestCachedImpl (which I am improving now), and we will have even
>better caching when we implement it based on RDF Resources. You said that
>I can go ahead. But I would like to confirm it because removing it from
>CentralImpl may break some of your code (or of the others).
>   Do I have your green lights?
>
>   Cheers,
>   Martin
>
>  
>



From francis_gibbons at hms.harvard.edu  Mon Sep 19 10:44:54 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Mon, 19 Sep 2005 10:44:54 -0400
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <36612E59-02E5-41BB-842A-EF368649EB2B@wur.nl>
References: <5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
Message-ID: <5.2.1.1.2.20050919104414.010eb940@email.med.harvard.edu>

Hi Pieter,

At 05:41 AM 9/19/2005, you wrote:
>Client-Central.t is fine now. I also don't know where the '$__val'
>came from. But the tests are not complaining about it anymore :) In
>addition to some messages about skipped tests I do get a warning
>about a non-existing 'bogus NS' in CommonSubs.t. See below for the
>output of the tests. I assume it's safe to ignore that one.

Yes, it's safe to ignore that one. I'm re-working CommonSubs.pm right now, 
and expect to make that warning message disappear shortly.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From Pieter.Neerincx at wur.nl  Mon Sep 19 10:46:19 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 19 Sep 2005 16:46:19 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432eb8ff.589d431d.4335.2914@mx.gmail.com>
References: <432eb8ff.589d431d.4335.2914@mx.gmail.com>
Message-ID: <87207568-E348-4B3C-AD12-5F6C69AB1E0D@wur.nl>

Hi Eddie,

On 19-Sep-2005, at 3:11 PM, Edward Kawas wrote:

> Hi,
>
> [mobycentral]
> dbname = mobycentral
> rdfagent = /usr/local/apache2/MOBY/rdfagent
> lsid_authority = biomoby.org
> lsid_namespace = serviceinstance
> resourceURL =
> http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
> allResources = http://biomoby.org/RESOURCES/MOBY-S/FULL
>
> [mobyobject]
> dbname = mobyobject
> lsid_authority = biomoby.org
> lsid_namespace = objectclass
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Objects
>
> [mobynamespace]
> dbname = mobynamespace
> lsid_authority = biomoby.org
> lsid_namespace = namespacetype
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>
> [mobyservice]
> dbname = mobyservice
> lsid_authority = biomoby.org
> lsid_namespace = servicetype
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Services
>
> [mobyrelationship]
> dbname = mobyrelationship
> lsid_authority = biomoby.org
> #lsid_namespace = relationshiptype
>
> Those are the new lines (as far as I know) that should be
> added to the config file.

Thanks, I already guessed some of the URLs, but not all of them :). I  
created a small Perl script to test MOBY::Client::Central- 
 >retrieveResourceURLs. This works now, but unfortunately still no  
fun with Taverna. When I start Taverna with my local central appended  
in the mygrid.properties file, nothing happens: no custom objects  
form my local central and also no error messages. When I add my local  
central manually using right-click->add new biomoby scavanger, I got  
the error below. Taverna complains it can't process the RDF document  
for the biomoby objects :(. So I pointed my browser to the URL for  
the biomoby objects RDF file and had a look: The RDF looks pretty  
normal, but I did notice <cr> elements and the xml parser fails on  
those. (Do you happen to develop on a windows machine?) So I stripped  
the carriage returns from RDF objects file, saved it and changed the  
URL for the objects RDF to this static file: tada.... That finally  
got the show on the road :).

Cheers,

Pieter

Taverna command line error messages:
---------------------------------------
Creating biomoby scavenger : 'https://bioinfw05/phenolink/biomoby/ 
central/cgi-bin/MOBY-Central.pl'
ERROR                                      2005-09-19 16:01:16,854  
(com.hp.hpl.jena.rdf.model.impl.RDFDefaultErrorHandler:44) - http:// 
www.w3.org/TR/html4/loose.dtd[31:3]: {E301} The declaration for the  
entity "HTML.Version" must end with '>'.
Failed: rethrew: com.hp.hpl.jena.rdf.arp.ParseException: {E301} The  
declaration for the entity "HTML.Version" must end with '>'.
[Ljava.lang.StackTraceElement;@c9f71b
org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException:  
Could not retrieve and or process RDF document for BioMoby Objects
         at org.biomoby.client.taverna.plugin.BiomobyScavenger.<init> 
(BiomobyScavenger.java:95)
         at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper 
$2.actionPerformed(BiomobyScavengerHelper.java:83)
         at javax.swing.AbstractButton.fireActionPerformed 
(AbstractButton.java:1786)
         at javax.swing.AbstractButton 
$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
         at javax.swing.DefaultButtonModel.fireActionPerformed 
(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed 
(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased 
(BasicButtonListener.java:245)
         at java.awt.Component.processMouseEvent(Component.java:5100)
         at java.awt.Component.processEvent(Component.java:4897)
         at java.awt.Container.processEvent(Container.java:1569)
         at java.awt.Component.dispatchEventImpl(Component.java:3615)
         at java.awt.Container.dispatchEventImpl(Container.java:1627)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.LightweightDispatcher.retargetMouseEvent 
(Container.java:3483)
         at java.awt.LightweightDispatcher.processMouseEvent 
(Container.java:3198)
         at java.awt.LightweightDispatcher.dispatchEvent 
(Container.java:3128)
         at java.awt.Container.dispatchEventImpl(Container.java:1613)
         at java.awt.Window.dispatchEventImpl(Window.java:1606)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy 
(EventDispatchThread.java:201)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:151)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:141)
         at java.awt.Dialog$1.run(Dialog.java:540)
         at java.awt.Dialog.show(Dialog.java:561)
         at java.awt.Component.show(Component.java:1133)
         at java.awt.Component.setVisible(Component.java:1088)
         at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper 
$1.actionPerformed(BiomobyScavengerHelper.java:119)
         at javax.swing.AbstractButton.fireActionPerformed 
(AbstractButton.java:1786)
         at javax.swing.AbstractButton 
$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
         at javax.swing.DefaultButtonModel.fireActionPerformed 
(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed 
(DefaultButtonModel.java:258)
         at javax.swing.AbstractButton.doClick(AbstractButton.java:289)
         at javax.swing.plaf.basic.BasicMenuItemUI.doClick 
(BasicMenuItemUI.java:1113)
         at javax.swing.plaf.basic.BasicMenuItemUI 
$MouseInputHandler.mouseReleased(BasicMenuItemUI.java:943)
         at java.awt.Component.processMouseEvent(Component.java:5100)
         at java.awt.Component.processEvent(Component.java:4897)
         at java.awt.Container.processEvent(Container.java:1569)
         at java.awt.Component.dispatchEventImpl(Component.java:3615)
         at java.awt.Container.dispatchEventImpl(Container.java:1627)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.LightweightDispatcher.retargetMouseEvent 
(Container.java:3483)
         at java.awt.LightweightDispatcher.processMouseEvent 
(Container.java:3198)
         at java.awt.LightweightDispatcher.dispatchEvent 
(Container.java:3128)
         at java.awt.Container.dispatchEventImpl(Container.java:1613)
         at java.awt.Window.dispatchEventImpl(Window.java:1606)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy 
(EventDispatchThread.java:201)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:151)
         at java.awt.EventDispatchThread.pumpEvents 
(EventDispatchThread.java:145)
         at java.awt.EventDispatchThread.pumpEvents 
(EventDispatchThread.java:137)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java: 
100)
Caused by: java.lang.NullPointerException
         at org.biomoby.client.taverna.plugin.BiomobyScavenger.<init> 
(BiomobyScavenger.java:92)
         ... 52 more
---------------------------------------



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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Mon Sep 19 10:51:38 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 19 Sep 2005 07:51:38 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <87207568-E348-4B3C-AD12-5F6C69AB1E0D@wur.nl>
Message-ID: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>

> Could not retrieve and or process RDF document for BioMoby
> Objects
Can I have your Moby endpoint so that I can test this? I am
not sure why the carriage returns are present.

Eddie



From Pieter.Neerincx at wur.nl  Mon Sep 19 11:06:03 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 19 Sep 2005 17:06:03 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>
References: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>
Message-ID: <3794C121-8E2C-4B0B-BC41-3537752A5085@wur.nl>


On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:

>> Could not retrieve and or process RDF document for BioMoby
>> Objects
>>
> Can I have your Moby endpoint so that I can test this?

Sure!

This is what I use on my development box:

     https://bioinfw05/phenolink/biomoby/central/cgi-bin/MOBY-Central.pl

But it doesn't have a DNS entry, so you might try this:

     https://137.224.52.237/phenolink/biomoby/central/cgi-bin/MOBY- 
Central.pl

My RDF for the objects is at (not sure whether this one will work  
from outside our firewall...):

     https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects

Hope this helps.

Pieter


> I am
> not sure why the carriage returns are present.
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Mon Sep 19 11:20:02 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 19 Sep 2005 08:20:02 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <3794C121-8E2C-4B0B-BC41-3537752A5085@wur.nl>
Message-ID: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>

Hi,

I can't connect to those URLS or endpoints (I timeout).

I will try to find the bug by eyeballing it. If you can
think of another way that I can access your endpoint, please
let me know.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 19, 2005 8:06 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> 
> On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:
> 
> >> Could not retrieve and or process RDF document for
> BioMoby
> >> Objects
> >>
> > Can I have your Moby endpoint so that I can test this?
> 
> Sure!
> 
> This is what I use on my development box:
> 
>      https://bioinfw05/phenolink/biomoby/central/cgi-
> bin/MOBY-Central.pl
> 
> But it doesn't have a DNS entry, so you might try this:
> 
>      https://137.224.52.237/phenolink/biomoby/central/cgi-
> bin/MOBY-
> Central.pl
> 
> My RDF for the objects is at (not sure whether this one
> will work
> from outside our firewall...):
> 
>      https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects
> 
> Hope this helps.
> 
> Pieter
> 
> 
> > I am
> > not sure why the carriage returns are present.
> >
> > Eddie
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From markw at illuminae.com  Mon Sep 19 11:02:51 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 19 Sep 2005 08:02:51 -0700
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure
	of	one year
In-Reply-To: <432E8119.4030502@cnb.uam.es>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
	<432E8119.4030502@cnb.uam.es>
Message-ID: <432ED31B.8000303@illuminae.com>

Thanks David!

Just to clarify, "the Spanish Contingent" was not meant to be insulting 
in any way (nor even forwarded to the mailing list at all) - there are 
just a lot of you using Moby in Spain, between INB and Alfonso's group, 
etc., so I didn't know who/how many would want to join this committee, 
so I just referred to you as a group in a private message to Eddie, 
which he then forwarded to the mailing list :-)

M



David Gonz?lez Pisano wrote:

> I'll be glad to represent the INB (aka "The Spanish Contingent") in 
> the RFC commitee for a year. Thanks for your invitation,
>
> David
>
> Edward Kawas escribi?:
>
>> -----Original Message-----
>> From: mark wilkinson [mailto:markw at illuminae.com] Sent: Thursday, 
>> September 15, 2005 3:06 PM
>> To: Frank Gibbons; Eddie Kawas
>> Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
>> Error-handling in MOBY-S
>>
>> Hey Frank! Cc Eddie
>>
>> Thanks for riding this.  I am on holiday, and not in Net
>> contact except by blackberry, so I'm not "useful" right now.
>>
>> I think we should put out an invitation on the -dev list for
>> the RFC committee with a tenure of one year, but also
>> specifically invite the main developers/vested interests to
>> be part of it:  me, you, martin, eddie, simon, heiko, paul,
>> yan wong, and at least one from the spanish contingent (have
>> I missed anyone?).
>>
>> I don't have all their email addresses on my bberry so
>> unless you or Eddie (cc'd) post this invitation to the dev
>> list yourselves it may take a week before I am back in
>> net-world.  Eddie, could you do this? Tomorrow or this
>> afternoon?  It would be good to get this sorted asap to keep
>> on schedule.
>>
>> M
>>
>>
>> -----Original Message-----
>> From: Frank Gibbons <fgibbons at hms.harvard.edu>
>> Date: Thu, 15 Sep 2005 11:21:53 To:moby-l at biomoby.org
>> Subject: [MOBY-l] Using bugzilla to continue RFC on
>> Error-handling in MOBY-S
>>
>> Hi,
>>
>> I've just added a few "bugs" to the bugzilla, to try to
>> preserve the RFC momentum built up over the past few weeks. I propose 
>> that,
>> although bugzilla is perhaps not ideal for this, it is what it is, it
>> is what we have, and it will do for now.
>>
>> I'd like to propose that we try to continue development of
>> this RFC through bugzilla (see bug #1863), rather than through the 
>> mailing
>> list. Searching through old mail messages (or worse still, through the
>> digest, with all of its repeated messages and long inclusions) is 
>> tedious, and I
>> think contributes to the loss in momentum.
>>
>> So far, in Martin's scheme for RFC-processing, we have
>> (numbers are those used in Martin's original suggestion, now 
>> available in the
>> codebase as Docs/MOBY-S_API/RFC.html)
>>
>> 1. Had a suggestion made by INB to add this features. It was
>> added to bugzilla, No. 1863
>> 2. Suggested to resolve it by today (Sep-15)
>> 3. Martin backed up the RFC
>> 4. I think we have the resources to make this change - it
>> seems an essential part of a robust API, which version 1.0 should be.
>> 5a. List members have exchanged several comments back and
>> forth, resulting in amended versions of the RFC being posted to the 
>> mailing
>> list.
>> 5b. We've also gotten a little side-tracked by the related
>> articleName problem.
>>
>> So it seems to me that it's time to vote on it (step 6 of
>> the Senger seven-step scheme ;-). Martin suggested that Mark would ask
>> a limited number of people to vote on it after the resolution date
>> (today). I guess those people would self-select, or maybe Mark will 
>> select
>> them. They will be requested to make a one-year commitment.
>>
>> After that comes step 7, the "fun part": implementation,
>> documentation.
>>
>> We're pretty close to reaching a conclusion on this. The
>> fact is that even if we do nothing, people want this functionality, 
>> and they
>> WILL implement it. It is in everybody's interest that we have a
>> specification for what the functionality should be. It may change 
>> over time, but I
>> think there has been enough back-and-forth that we have a reasonable 
>> first
>> draft, and should vote on it.
>>
>> -Frank
>> P.S. Of course, this message, along with version 1.7.1 of
>> the RFC is attached to the bug on bugzilla
>>
>> PhD, Computational Biologist,
>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
>> Boston MA 02115, USA.
>> Tel: 617-432-3555       Fax: 617-432-3557       
>> http://llama.med.harvard.edu/~fgibbons
>> _______________________________________________
>> moby-l mailing list
>> moby-l at biomoby.org
>> http://biomoby.org/mailman/listinfo/moby-l
>>
>> -- 
>> Mark Wilkinson
>> ..on the road!
>>
>>
>>
>>  
>>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>



From senger at ebi.ac.uk  Tue Sep 20 04:50:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 20 Sep 2005 09:50:19 +0100 (BST)
Subject: [MOBY-dev] jMoby: new document on Eclipse & jMoby
Message-ID: <Pine.OSF.4.21.0509200948290.851399-100000@ice.ebi.ac.uk>

...is available at
http://biomoby.org/moby-live/Java/docs/EclipseAndJMoby.html. I welcome all
comments and suggestion to improve it, or to correct it.

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)



From senger at ebi.ac.uk  Wed Sep 21 04:55:52 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 21 Sep 2005 09:55:52 +0100 (BST)
Subject: [MOBY-dev] jMoby: a new document about jMoby & Windows
Message-ID: <Pine.OSF.4.21.0509210949260.629792-100000@ice.ebi.ac.uk>

...was added:
   http://biomoby.org/moby-live/Java/docs/WindowsAndJMoby.html

   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)




From francis_gibbons at hms.harvard.edu  Wed Sep 21 16:41:41 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Wed, 21 Sep 2005 16:41:41 -0400
Subject: [MOBY-dev] Purpose of complexResponse?
Message-ID: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>

Hi,

I'm trying to come up with some tests for complexResponse, part of 
MOBY::CommonSubs.pm. The part that's hard is trying to envisage what kind 
of service might return such a response, since it appears that it contains 
both Simple and Collection items. Anyone got any examples of what that 
might look like?

Also, what's the next step with the RFC on error-reporting? Actually, the 
next step *is* to vote, but the question is "when?"

-Frank


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From markw at illuminae.com  Wed Sep 21 17:20:35 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 21 Sep 2005 14:20:35 -0700
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
Message-ID: <4331CEA3.6020205@illuminae.com>

Hello from Montreal!

The RFC committee consists of:

Frank
Martin
Eddie
David
Mark

I don't think we heard from Heiko, Yan, or Paul...  (??)  We also didn't 
get any other volunteers (unless I have missed a message while I was 
away)  In the interim, and just to keep the ball rolling, let's call the 
vote on RFC 1863.   I'll send out a message with the apprpriate subject 
line in a couple of minutes.  If other members join in time, they can 
vote also.

M


>



From edward.kawas at gmail.com  Wed Sep 21 19:58:20 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 21 Sep 2005 16:58:20 -0700
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
Message-ID: <4331f39d.2009e53e.6a06.1d2d@mx.gmail.com>

> I'll send out a message with the
> apprpriate subject
> line in a couple of minutes.

Did you forget to press send ;-)



From markw at illuminae.com  Wed Sep 21 20:18:24 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu, 22 Sep 2005 00:18:24 +0000 GMT
Subject: [MOBY-dev] RFC Committee  Membership last call...
Message-ID: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell01>

I don't think so... I'm pretty surer I sent it...??

M


-----Original Message-----
From: "Edward Kawas" <edward.kawas at gmail.com>
Date: Wed, 21 Sep 2005 16:58:20 
To:"'Core developer announcements'" <moby-dev at portal.open-bio.org>
Subject: RE: [MOBY-dev] RFC Committee  Membership last call...

> I'll send out a message with the
> apprpriate subject
> line in a couple of minutes.

Did you forget to press send ;-)

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

--
Mark Wilkinson
...on the road!


From markw at illuminae.com  Wed Sep 21 17:30:44 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 21 Sep 2005 14:30:44 -0700
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <4331D104.9010308@illuminae.com>

Regarding RFC #1863 Error Handling in MOBY-S

http://bugzilla.open-bio.org/show_bug.cgi?id=1863

The vote has been called.  Voting members may vote by adding their YES 
(accept)  or NO (do not accept) to the comments history  through Bugzilla

Voting ends Sept 26th

M



From Pieter.Neerincx at wur.nl  Thu Sep 22 04:01:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu, 22 Sep 2005 10:01:42 +0200
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <DBF151CE-AA3A-4EF3-97E4-1081641D6AF3@wur.nl>


On  21Sep2005, at 23:20, Mark Wilkinson wrote:

> We also didn't get any other volunteers (unless I have missed a  
> message while I was away)  In the interim, and just to keep the  
> ball rolling, let's call the vote on RFC 1863.   I'll send out a  
> message with the apprpriate subject line in a couple of minutes.   
> If other members join in time, they can vote also.

I'm a big fan of democracy, so where do I join?

I like the proposal :) Found one error in the documentation though.  
In section 3 "Raising exceptions for Simples inside a Collection  
(optional proposal extension)" the text mentions an refarticleName  
attribute that links to the corresponding erroneous Simple inside a  
Collection. If that is correct, the corresponding example in table 6  
is wrong. The example lists refElement tags, but I can not find any  
refarticleName attributes in there...

Pi


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

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1038
Dreijenlaan 3
6703 HA Wageningen
phone: 0317-484 706
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl



From senger at ebi.ac.uk  Thu Sep 22 06:38:14 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 22 Sep 2005 11:38:14 +0100 (BST)
Subject: [MOBY-dev] jMoby: deploymnt added to Moses
Message-ID: <Pine.OSF.4.21.0509221132050.1329336-100000@mozart.ebi.ac.uk>

I have added the last remaining piece to the Moses mosaic: the deployment
of services. The new document describing it is:

http://biomoby.org/moby-live/Java/docs/Moses-deploy.html

Recently, I also fixed some bugs in Moses (and in jMoby Ant generally),
mostly solving incompatibility on Windows platform. As far as I am aware,
things now work on Windows as well.

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)



From ywong at infobiogen.fr  Thu Sep 22 09:36:46 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Thu, 22 Sep 2005 15:36:46 +0200 (CEST)
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <51700.170.252.64.1.1127396206.squirrel@170.252.64.1>

Hello from a street near the Eiffel Tower,

  Just let me some time to read the RFC ...

  I am now working for Accenture Technology Solutions. As I am no longer
commited to any biomoby related project or any bioinformatics project,
it has become increasingly difficult to follow the changes (I use the
remain of my spare time :D)

  Anyway, I'll do my best to solve problems (even if I believe the Python
API to be "stable") and update he API but expect progress to be VERY
SLOW .

  Cheers.

Yan


> Hello from Montreal!
>
> The RFC committee consists of:
>
> Frank
> Martin
> Eddie
> David
> Mark
>
> I don't think we heard from Heiko, Yan, or Paul...  (??)  We also didn't
> get any other volunteers (unless I have missed a message while I was
> away)  In the interim, and just to keep the ball rolling, let's call the
> vote on RFC 1863.   I'll send out a message with the apprpriate subject
> line in a couple of minutes.  If other members join in time, they can
> vote also.
>
> M
>
>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From senger at ebi.ac.uk  Thu Sep 22 10:49:59 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 22 Sep 2005 15:49:59 +0100 (BST)
Subject: [MOBY-dev] is findService(0 case sensitive?
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509221545570.1329336-100000@mozart.ebi.ac.uk>

Mark,
   You told me once that everything in Biomoby is case sensitive (that was
in time when I played with idea to allow case insensitivness but then
stepped back because of Blast's secondary parameters 'e' and 'E').
   Now I see that findService seems to be case insensitive. When I ask for
service getProteinSequence I get two services: getProteinSequence and
GetProteinSequence.
   So what is true? Whatever it is could you tell us and add it to the API
please?

   Cheers,
   Martin

PS. Pending answer about retrieving namespaces... :-)
M.

-- 
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)



From markw at illuminae.com  Thu Sep 22 11:21:07 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu, 22 Sep 2005 15:21:07 +0000 GMT
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
Message-ID: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>


MOBY is intended to be case sensitive.  What you are seeing is likely a consequence of mySQL not being case sensitive, and moby central not double-checking the output of the query.

That's a frustrating bug, since it means I need to post-filter every query :-/

I wonder if there is a flag in mysql that makes the searches case sensitive?

I'll look into it when I get back to Vancouver.  For the moment, code on the assumption that it *is* case sensitive, since that's the intention.

M


-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Thu, 22 Sep 2005 15:49:59 
To:Mark Wilkinson <markw at illuminae.com>
Cc:mobydev <moby-dev at biomoby.org>
Subject: is findService(0 case sensitive?

Mark,
   You told me once that everything in Biomoby is case sensitive (that was
in time when I played with idea to allow case insensitivness but then
stepped back because of Blast's secondary parameters 'e' and 'E').
   Now I see that findService seems to be case insensitive. When I ask for
service getProteinSequence I get two services: getProteinSequence and
GetProteinSequence.
   So what is true? Whatever it is could you tell us and add it to the API
please?

   Cheers,
   Martin

PS. Pending answer about retrieving namespaces... :-)
M.

-- 
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)


--
Mark Wilkinson
...on the road!


From senger at ebi.ac.uk  Thu Sep 22 11:31:34 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 22 Sep 2005 16:31:34 +0100 (BST)
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>
Message-ID: <Pine.OSF.4.21.0509221626160.1329336-100000@mozart.ebi.ac.uk>

Thanks for the fast reply and please don't worry now. I forgot that you
were still away. Sorry for that.

Okay, I will be coding as for case sensitivity. Thanks.
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)



From edward.kawas at gmail.com  Thu Sep 22 11:53:13 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 22 Sep 2005 08:53:13 -0700
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>
Message-ID: <4332d36b.5ae1c862.28fe.fffff8aa@mx.gmail.com>

Hi Mark,

I spent a while looking around, but the following query is
case sensitive (tested on our db)

select * from service_instance where servicename LIKE binary
'getProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'GetProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'getproteinsequence';

returns empty

Eddie
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:21 AM
> To: Martin Senger; Mark Wilkinson
> Cc: mobydev
> Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> 
> 
> MOBY is intended to be case sensitive.  What you are
> seeing is likely a consequence of mySQL not being case
> sensitive, and moby central not double-checking the output
> of the query.
> 
> That's a frustrating bug, since it means I need to post-
> filter every query :-/
> 
> I wonder if there is a flag in mysql that makes the
> searches case sensitive?
> 
> I'll look into it when I get back to Vancouver.  For the
> moment, code on the assumption that it *is* case
sensitive,
> since that's the intention.
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger at ebi.ac.uk>
> Date: Thu, 22 Sep 2005 15:49:59
> To:Mark Wilkinson <markw at illuminae.com>
> Cc:mobydev <moby-dev at biomoby.org>
> Subject: is findService(0 case sensitive?
> 
> Mark,
>    You told me once that everything in Biomoby is case
> sensitive (that was
> in time when I played with idea to allow case
> insensitivness but then
> stepped back because of Blast's secondary parameters 'e'
> and 'E').
>    Now I see that findService seems to be case
insensitive.
> When I ask for
> service getProteinSequence I get two services:
> getProteinSequence and
> GetProteinSequence.
>    So what is true? Whatever it is could you tell us and
> add it to the API
> please?
> 
>    Cheers,
>    Martin
> 
> PS. Pending answer about retrieving namespaces... :-)
> M.
> 
> --
> 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)
> 
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From markw at illuminae.com  Thu Sep 22 11:53:10 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu, 22 Sep 2005 15:53:10 +0000 GMT
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
Message-ID: <327837899-1127404527-cardhu_blackberry.rim.net-13073-@engine12-cell01>

Excellent!  Can you look into the adaptor layer (mysql.pm) and add the "binary" tag to that query?

Thanks!

M

-----Original Message-----
From: "Edward Kawas" <edward.kawas at gmail.com>
Date: Thu, 22 Sep 2005 08:53:13 
To:<markw at illuminae.com>,       "'Core developer announcements'" <moby-dev at portal.open-bio.org>
Subject: RE: [MOBY-dev] Re: is findService(0 case sensitive?

Hi Mark,

I spent a while looking around, but the following query is
case sensitive (tested on our db)

select * from service_instance where servicename LIKE binary
'getProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'GetProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'getproteinsequence';

returns empty

Eddie
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:21 AM
> To: Martin Senger; Mark Wilkinson
> Cc: mobydev
> Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> 
> 
> MOBY is intended to be case sensitive.  What you are
> seeing is likely a consequence of mySQL not being case
> sensitive, and moby central not double-checking the output
> of the query.
> 
> That's a frustrating bug, since it means I need to post-
> filter every query :-/
> 
> I wonder if there is a flag in mysql that makes the
> searches case sensitive?
> 
> I'll look into it when I get back to Vancouver.  For the
> moment, code on the assumption that it *is* case
sensitive,
> since that's the intention.
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger at ebi.ac.uk>
> Date: Thu, 22 Sep 2005 15:49:59
> To:Mark Wilkinson <markw at illuminae.com>
> Cc:mobydev <moby-dev at biomoby.org>
> Subject: is findService(0 case sensitive?
> 
> Mark,
>    You told me once that everything in Biomoby is case
> sensitive (that was
> in time when I played with idea to allow case
> insensitivness but then
> stepped back because of Blast's secondary parameters 'e'
> and 'E').
>    Now I see that findService seems to be case
insensitive.
> When I ask for
> service getProteinSequence I get two services:
> getProteinSequence and
> GetProteinSequence.
>    So what is true? Whatever it is could you tell us and
> add it to the API
> please?
> 
>    Cheers,
>    Martin
> 
> PS. Pending answer about retrieving namespaces... :-)
> M.
> 
> --
> 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)
> 
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

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

--
Mark Wilkinson
...on the road!


From senger at ebi.ac.uk  Thu Sep 22 11:59:21 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 22 Sep 2005 16:59:21 +0100 (BST)
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <4332d36b.5ae1c862.28fe.fffff8aa@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509221657400.1329336-100000@mozart.ebi.ac.uk>

Well, I think that I was asking a wrong question. I am sorry about
that. It turned out that the two services [g|G]etProteinSequence are from
two different authorities.

Mea culpa, mea maxima culpa.

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)



From edward.kawas at gmail.com  Thu Sep 22 11:57:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 22 Sep 2005 08:57:52 -0700
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <327837899-1127404527-cardhu_blackberry.rim.net-13073-@engine12-cell01>
Message-ID: <4332d483.555cc870.2d33.0d85@mx.gmail.com>

Sure, the only query is for getting service instance names
right?

Eddie



> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:53 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Re: is findService(0 case
> sensitive?
> 
> Excellent!  Can you look into the adaptor layer (mysql.pm)
> and add the "binary" tag to that query?
> 
> Thanks!
> 
> M
> 
> -----Original Message-----
> From: "Edward Kawas" <edward.kawas at gmail.com>
> Date: Thu, 22 Sep 2005 08:53:13
> To:<markw at illuminae.com>,       "'Core developer
> announcements'" <moby-dev at portal.open-bio.org>
> Subject: RE: [MOBY-dev] Re: is findService(0 case
> sensitive?
> 
> Hi Mark,
> 
> I spent a while looking around, but the following query is
> case sensitive (tested on our db)
> 
> select * from service_instance where servicename LIKE
> binary
> 'getProteinSequence';
> 
> returns 1 instance
> 
> select * from service_instance where servicename LIKE
> binary
> 'GetProteinSequence';
> 
> returns 1 instance
> 
> select * from service_instance where servicename LIKE
> binary
> 'getproteinsequence';
> 
> returns empty
> 
> Eddie
> > -----Original Message-----
> > From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> > dev-bounces at portal.open-bio.org] On Behalf Of mark
> > wilkinson
> > Sent: Thursday, September 22, 2005 8:21 AM
> > To: Martin Senger; Mark Wilkinson
> > Cc: mobydev
> > Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> >
> >
> > MOBY is intended to be case sensitive.  What you are
> > seeing is likely a consequence of mySQL not being case
> > sensitive, and moby central not double-checking the
> output
> > of the query.
> >
> > That's a frustrating bug, since it means I need to post-
> > filter every query :-/
> >
> > I wonder if there is a flag in mysql that makes the
> > searches case sensitive?
> >
> > I'll look into it when I get back to Vancouver.  For the
> > moment, code on the assumption that it *is* case
> sensitive,
> > since that's the intention.
> >
> > M
> >
> >
> > -----Original Message-----
> > From: Martin Senger <senger at ebi.ac.uk>
> > Date: Thu, 22 Sep 2005 15:49:59
> > To:Mark Wilkinson <markw at illuminae.com>
> > Cc:mobydev <moby-dev at biomoby.org>
> > Subject: is findService(0 case sensitive?
> >
> > Mark,
> >    You told me once that everything in Biomoby is case
> > sensitive (that was
> > in time when I played with idea to allow case
> > insensitivness but then
> > stepped back because of Blast's secondary parameters 'e'
> > and 'E').
> >    Now I see that findService seems to be case
> insensitive.
> > When I ask for
> > service getProteinSequence I get two services:
> > getProteinSequence and
> > GetProteinSequence.
> >    So what is true? Whatever it is could you tell us and
> > add it to the API
> > please?
> >
> >    Cheers,
> >    Martin
> >
> > PS. Pending answer about retrieving namespaces... :-)
> > M.
> >
> > --
> > 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)
> >
> >
> > --
> > Mark Wilkinson
> > ...on the road!
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From senger at ebi.ac.uk  Fri Sep 23 12:32:07 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 23 Sep 2005 17:32:07 +0100 (BST)
Subject: [MOBY-dev] adding Comparable to MobyDataType class
Message-ID: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>

Eddie (and the others),
   I plan to add 'implements Comparable' to MobyDataType (and perhaps also
to MobyService and MobyNamespace) - just to make it easier to sort.
   I noticed that your Registration class inherits from MobyDataType. I do
not think that this new interface would harm it - but better to ask
first. Do you know about any bad consequences if I add there this
interface?

   Thanks,
   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)



From edward.kawas at gmail.com  Fri Sep 23 12:34:31 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 23 Sep 2005 09:34:31 -0700
Subject: [MOBY-dev] RE: adding Comparable to MobyDataType class
In-Reply-To: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
Message-ID: <43342e9a.335a05df.2465.6864@mx.gmail.com>

Hi Martin,

I don't thnk that it will hurt me.

Eddie

> -----Original Message-----
> From: Martin Senger [mailto:senger at ebi.ac.uk]
> Sent: Friday, September 23, 2005 9:32 AM
> To: Edward Kawas
> Cc: Moby Developers
> Subject: adding Comparable to MobyDataType class
> 
> Eddie (and the others),
>    I plan to add 'implements Comparable' to MobyDataType
> (and perhaps also
> to MobyService and MobyNamespace) - just to make it easier
> to sort.
>    I noticed that your Registration class inherits from
> MobyDataType. I do
> not think that this new interface would harm it - but
> better to ask
> first. Do you know about any bad consequences if I add
> there this
> interface?
> 
>    Thanks,
>    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)



From francis_gibbons at hms.harvard.edu  Fri Sep 16 08:47:10 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Fri, 16 Sep 2005 08:47:10 -0400
Subject: [MOBY-dev] RE: invitation for the RFC committee with a tenure of
	one year
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C01@MAILSERVER02.MED.HARVARD.EDU>

Thanks for the invitation, Eddie & Mark. I'm glad to be part of this, excited that we've gotten this far and looking to completing our first formal RFC.
 
-Frank

	-----Original Message----- 
	From: Edward Kawas [mailto:edward.kawas at gmail.com] 
	Sent: Thu 9/15/2005 6:46 PM 
	To: 'Moby Developers' 
	Cc: 'Martin Senger'; 'Eddie Kawas'; 'Twigger Simon'; 'Paul Gordon'; ywong at infobiogen.fr; schoof at mpiz-koeln.mpg.de; Gibbons, Francis ; dgpisano at cnb.uam.es 
	Subject: invitation for the RFC committee with a tenure of one year
	
	



	-----Original Message-----
	From: mark wilkinson [mailto:markw at illuminae.com]
	Sent: Thursday, September 15, 2005 3:06 PM
	To: Frank Gibbons; Eddie Kawas
	Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
	Error-handling in MOBY-S
	
	Hey Frank! Cc Eddie
	
	Thanks for riding this.  I am on holiday, and not in Net
	contact except by blackberry, so I'm not "useful" right now.
	
	I think we should put out an invitation on the -dev list for
	the RFC committee with a tenure of one year, but also
	specifically invite the main developers/vested interests to
	be part of it:  me, you, martin, eddie, simon, heiko, paul,
	yan wong, and at least one from the spanish contingent (have
	I missed anyone?).
	
	I don't have all their email addresses on my bberry so
	unless you or Eddie (cc'd) post this invitation to the dev
	list yourselves it may take a week before I am back in
	net-world.  Eddie, could you do this? Tomorrow or this
	afternoon?  It would be good to get this sorted asap to keep
	on schedule.
	
	M
	
	
	-----Original Message-----
	From: Frank Gibbons <fgibbons at hms.harvard.edu>
	Date: Thu, 15 Sep 2005 11:21:53
	To:moby-l at biomoby.org
	Subject: [MOBY-l] Using bugzilla to continue RFC on
	Error-handling in MOBY-S
	
	Hi,
	
	I've just added a few "bugs" to the bugzilla, to try to
	preserve the RFC
	momentum built up over the past few weeks. I propose that,
	although
	bugzilla is perhaps not ideal for this, it is what it is, it
	is what we
	have, and it will do for now.
	
	I'd like to propose that we try to continue development of
	this RFC through
	bugzilla (see bug #1863), rather than through the mailing
	list. Searching
	through old mail messages (or worse still, through the
	digest, with all of
	its repeated messages and long inclusions) is tedious, and I
	think
	contributes to the loss in momentum.
	
	So far, in Martin's scheme for RFC-processing, we have
	(numbers are those
	used in Martin's original suggestion, now available in the
	codebase as
	Docs/MOBY-S_API/RFC.html)
	
	1. Had a suggestion made by INB to add this features. It was
	added to
	bugzilla, No. 1863
	2. Suggested to resolve it by today (Sep-15)
	3. Martin backed up the RFC
	4. I think we have the resources to make this change - it
	seems an
	essential part of a robust API, which version 1.0 should be.
	5a. List members have exchanged several comments back and
	forth, resulting
	in amended versions of the RFC being posted to the mailing
	list.
	5b. We've also gotten a little side-tracked by the related
	articleName problem.
	
	So it seems to me that it's time to vote on it (step 6 of
	the Senger
	seven-step scheme ;-). Martin suggested that Mark would ask
	a limited
	number of people to vote on it after the resolution date
	(today). I guess
	those people would self-select, or maybe Mark will select
	them. They will
	be requested to make a one-year commitment.
	
	After that comes step 7, the "fun part": implementation,
	documentation.
	
	We're pretty close to reaching a conclusion on this. The
	fact is that even
	if we do nothing, people want this functionality, and they
	WILL implement
	it. It is in everybody's interest that we have a
	specification for what the
	functionality should be. It may change over time, but I
	think there has
	been enough back-and-forth that we have a reasonable first
	draft, and
	should vote on it.
	
	-Frank
	P.S. Of course, this message, along with version 1.7.1 of
	the RFC is
	attached to the bug on bugzilla
	
	PhD, Computational Biologist,
	Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
	Boston MA 02115, USA.
	Tel: 617-432-3555       Fax:
	617-432-3557       http://llama.med.harvard.edu/~fgibbons
	
	_______________________________________________
	moby-l mailing list
	moby-l at biomoby.org
	http://biomoby.org/mailman/listinfo/moby-l
	
	--
	Mark Wilkinson
	..on the road!
	
	




From francis_gibbons at hms.harvard.edu  Fri Sep 16 10:26:56 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Fri, 16 Sep 2005 10:26:56 -0400
Subject: [MOBY-dev] Failing tests in the Perl API.
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>

Pieter,
 
I wrote many of the tests for the  Perl API. When I run them, I see a 99% pass rate, or better. I'm very interested to know which ones are failing for you, and what your local installation looks like (I guess you have a local registry? what's your OS? Perl version? etc.) Clearly, we should have a test suite that passes for most developers most of the time, so that they can be alerted quickly if they break something. So it's really important for me to know which tests are failing and why: the tests may need to be rewritten.
 
Thanks for your feedback.
 
-Frank

	-----Original Message----- 
	From: moby-dev-bounces at portal.open-bio.org on behalf of Edward Kawas 
	Sent: Fri 9/16/2005 9:54 AM 
	To: 'Core developer announcements' 
	Cc: 'Pieter Neerincx' 
	Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come from?
	
	

	>I assume I need to update my BioMOBY API stuff as 
	>well. So I tried an cvs up -d of moby-live. When I try make
	>test for the Perl stuff I see a lot of tests failing....
	>Can I safely ignore them for now?
	
	I am not sure about this question. I know that Mark has a
	new test suite but I am not sure if this is the suite that
	you are running.
	
	One more thing, if the servlets work, you would be able to
	do the following:
	http://yourURL:port/types/Objects
	http://yourURL:port/RESOURCES/MOBY-S/Objects
	http://yourURL:port/authority
	
	These 3 links should show you something meaningful (html, a
	file, more html).
	
	Eddie
	
	_______________________________________________
	MOBY-dev mailing list
	MOBY-dev at biomoby.org
	http://www.biomoby.org/mailman/listinfo/moby-dev
	




From simont at post.its.mcw.edu  Thu Sep 22 10:04:18 2005
From: simont at post.its.mcw.edu (Simon Twigger)
Date: Thu, 22 Sep 2005 09:04:18 -0500 (CDT)
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell0
	1>
References: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell01>
Message-ID: <58021.69.210.117.185.1127397858.squirrel@webmail.mcw.edu>

Hi Mark,

I thought I had sent a reply volunteering for the committee a little while
ago but perhaps it forgot to hit send. If there is still time, I would
like to help out by serving.

Simon.


> I don't think so... I'm pretty surer I sent it...??
>
> M
>
>
> -----Original Message-----
> From: "Edward Kawas" <edward.kawas at gmail.com>
> Date: Wed, 21 Sep 2005 16:58:20
> To:"'Core developer announcements'" <moby-dev at portal.open-bio.org>
> Subject: RE: [MOBY-dev] RFC Committee  Membership last call...
>
>> I'll send out a message with the
>> apprpriate subject
>> line in a couple of minutes.
>
> Did you forget to press send ;-)
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>



From gordonp at ucalgary.ca  Fri Sep 23 15:13:06 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Fri, 23 Sep 2005 13:13:06 -0600
Subject: [MOBY-dev] adding Comparable to MobyDataType class
In-Reply-To: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
Message-ID: <433453C2.9030206@ucalgary.ca>

If you do so, please let me know, as all object classes in the 
org.biomoby.shared data package already implements Comparable, and we 
should have the same ordering rules.

>Eddie (and the others),
>   I plan to add 'implements Comparable' to MobyDataType (and perhaps also
>to MobyService and MobyNamespace) - just to make it easier to sort.
>   I noticed that your Registration class inherits from MobyDataType. I do
>not think that this new interface would harm it - but better to ask
>first. Do you know about any bad consequences if I add there this
>interface?
>
>   Thanks,
>   Martin
>
>  
>



From senger at ebi.ac.uk  Fri Sep 23 23:18:45 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sat, 24 Sep 2005 04:18:45 +0100 (BST)
Subject: [MOBY-dev] adding Comparable to MobyDataType class
In-Reply-To: <433453C2.9030206@ucalgary.ca>
Message-ID: <Pine.OSF.4.21.0509240413570.839150-100000@ice.ebi.ac.uk>

> If you do so, please let me know, as all object classes in the 
> org.biomoby.shared data package already implements Comparable, and we 
> should have the same ordering rules.
>
   Well, of course, but I do not see what you mean. Perhaps I overlooked
something. I see the hierarchy:

   MobyDataObject -> MobyPrimaryDataSimple -> MobyData

where MobyDataObject implements Comparable. I wonder how it can be
influenced by adding Comparable to MobyDataType, MobyService and
MobyNamespace?
   Do you think that I can go ahead and put there Comparable?

   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)



From senger at ebi.ac.uk  Sun Sep 25 02:41:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun, 25 Sep 2005 07:41:57 +0100 (BST)
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>

> The vote has been called.  Voting members may vote by adding their YES 
> (accept)  or NO (do not accept) to the comments history  through Bugzilla
> 
> Voting ends Sept 26th
>
    I propose to extend the vote deadline to October 15th. Reasons are:

   1) The proposal (as available from Bugzilla) is still too complex, full
of explanaition, and it is not clear what is a discussion and what is a
proposal. I recommend that the authors take away most of the reasoning and
just state what is the new API. (The reasoning can come later back to the
documentation, if Frank, as a document-manager, decides so.)

   2) The proposal is in the format which is not readable for everyone
(for example, using OpenOffice mixes the tables on the first page, so I do
not understand what they mean and why they are there). Open source API
should use open documentation tools, as much as it can. The whole Biomoby
API/docs is, so far, written in non-proprietary document format, so I
suggest to continue with it.

   3) The error codes are still not explained enough. I suggest either
remove (some of) them, or document them better. Especially the client-side
errors are still obscure to me.

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.

   5) The proposal should clearly suggest what (if anything) should be
removed from the current Biomoby API. I mean the fact that the current API
(even perhasp not literally, but surely by spirit) expects (allows) an
empty result in case of an error (e.g. an ID cannot be found in a target
database). Will this still be valid, or should serviceNotes be returned
instead?

   I already said that I liked the new proposal and I am going to support
it - but I want to introduce new things into Biomoby API as precisely as
we can. Therefore, I am not ready to vote yet. But just in case, my
suggestion described above, will not be accepted, and the vote deadline
announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
do it on Bugzilla, because (a) I think that this NO is only temporary and
conditionally, and (b) I did not found any "history comments" there so I
would not know how to use Bugzilla for that.)

   Regards,
   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)



From senger at ebi.ac.uk  Sun Sep 25 02:41:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun, 25 Sep 2005 07:41:57 +0100 (BST)
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>

> The vote has been called.  Voting members may vote by adding their YES 
> (accept)  or NO (do not accept) to the comments history  through Bugzilla
> 
> Voting ends Sept 26th
>
    I propose to extend the vote deadline to October 15th. Reasons are:

   1) The proposal (as available from Bugzilla) is still too complex, full
of explanaition, and it is not clear what is a discussion and what is a
proposal. I recommend that the authors take away most of the reasoning and
just state what is the new API. (The reasoning can come later back to the
documentation, if Frank, as a document-manager, decides so.)

   2) The proposal is in the format which is not readable for everyone
(for example, using OpenOffice mixes the tables on the first page, so I do
not understand what they mean and why they are there). Open source API
should use open documentation tools, as much as it can. The whole Biomoby
API/docs is, so far, written in non-proprietary document format, so I
suggest to continue with it.

   3) The error codes are still not explained enough. I suggest either
remove (some of) them, or document them better. Especially the client-side
errors are still obscure to me.

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.

   5) The proposal should clearly suggest what (if anything) should be
removed from the current Biomoby API. I mean the fact that the current API
(even perhasp not literally, but surely by spirit) expects (allows) an
empty result in case of an error (e.g. an ID cannot be found in a target
database). Will this still be valid, or should serviceNotes be returned
instead?

   I already said that I liked the new proposal and I am going to support
it - but I want to introduce new things into Biomoby API as precisely as
we can. Therefore, I am not ready to vote yet. But just in case, my
suggestion described above, will not be accepted, and the vote deadline
announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
do it on Bugzilla, because (a) I think that this NO is only temporary and
conditionally, and (b) I did not found any "history comments" there so I
would not know how to use Bugzilla for that.)

   Regards,
   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)



From Pieter.Neerincx at wur.nl  Mon Sep 26 07:40:20 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 26 Sep 2005 13:40:20 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>
References: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>
Message-ID: <1A427D71-2573-4920-8465-17843E0E3A02@wur.nl>

Hi Eddie,

I've got it up and running. I have now idea what went wrong exactly,  
but I suspect some misconfiguration in Tomcat. I also switched from  
IBM's Java implemntation to Sun's. Had apparently both installed by  
default, but my Tomcat was out of the box using IBM's Java stuff. Now  
with Sun's Java I do have to type 'java -jar install.jar' for the  
servlets installer, just like you documented. Furthermore I have  
Apache configured as frontend for Tomcat now, so I can use port 443  
for https making the whole work again through our firewall. I have  
only one issue left:

When I append my local central to my mygrid.properties file for  
Taverna, I have the old behaviour: hence services from my local  
central, but objects from  the central central. When I remove my  
local central and add it again using right-click -> add biomoby  
scavanger, I get the desired behaviour with both services and objects  
from my local central. It's a bit inconvenient to have to load your  
mobycentral manually all the time :(, but apart from that  
inconvenience it works :). Very nice to see this code in action,  
thanks for the help!

I will document my experience and propose this as an update for the  
page at: http://www.biomoby.org/InstallingMOBYCentral.html if this is  
Ok with you.

Cheers,

Pieter



On 19-Sep-2005, at 5:20 PM, Edward Kawas wrote:

> Hi,
>
> I can't connect to those URLS or endpoints (I timeout).
>
> I will try to find the bug by eyeballing it. If you can
> think of another way that I can access your endpoint, please
> let me know.
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 19, 2005 8:06 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>>
>> On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:
>>
>>
>>>> Could not retrieve and or process RDF document for
>>>>
>> BioMoby
>>
>>>> Objects
>>>>
>>>>
>>> Can I have your Moby endpoint so that I can test this?
>>>
>>
>> Sure!
>>
>> This is what I use on my development box:
>>
>>      https://bioinfw05/phenolink/biomoby/central/cgi-
>> bin/MOBY-Central.pl
>>
>> But it doesn't have a DNS entry, so you might try this:
>>
>>      https://137.224.52.237/phenolink/biomoby/central/cgi-
>> bin/MOBY-
>> Central.pl
>>
>> My RDF for the objects is at (not sure whether this one
>> will work
>> from outside our firewall...):
>>
>>      https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects
>>
>> Hope this helps.
>>
>> Pieter
>>
>>
>>
>>> I am
>>> not sure why the carriage returns are present.
>>>
>>> Eddie
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From dgpisano at cnb.uam.es  Mon Sep 26 09:55:45 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon, 26 Sep 2005 15:55:45 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
Message-ID: <4337FDE1.1080201@cnb.uam.es>

I think we can still vote today, as far as Martin's objections are not 
really about the proposal itself, but about the aesthetics and 
presentation of the proposal. My solutions below

Martin Senger escribi?:

>>The vote has been called.  Voting members may vote by adding their YES 
>>(accept)  or NO (do not accept) to the comments history  through Bugzilla
>>
>>Voting ends Sept 26th
>>
>>    
>>
>    I propose to extend the vote deadline to October 15th. Reasons are:
>
>   1) The proposal (as available from Bugzilla) is still too complex, full
>of explanaition, and it is not clear what is a discussion and what is a
>proposal. I recommend that the authors take away most of the reasoning and
>just state what is the new API. (The reasoning can come later back to the
>documentation, if Frank, as a document-manager, decides so.)
>
>  
>
Explanations would not make the document *more* difficult to understand 
(unless the explanations are wrong)? Probably you are refering to the 
motivation / discussion parts, that we understand we needed to explain 
our reasons to expand MOBY-S specification. I've rewritten the proposal 
so now is just a specification extension proposal (still not an API 
proposal, that's the next implementation step).

>   2) The proposal is in the format which is not readable for everyone
>(for example, using OpenOffice mixes the tables on the first page, so I do
>not understand what they mean and why they are there). Open source API
>should use open documentation tools, as much as it can. The whole Biomoby
>API/docs is, so far, written in non-proprietary document format, so I
>suggest to continue with it.
>  
>
See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
format... We've never talked about this before, and the document can 
easily be exported to whatever format we agree. I am not really 
concerned about using open or closed tools, OMG publishes specifications 
in Word format -between other- and schema documentation using XML Spy 
and nobody objects using commercial tools as far as everybody can 
understand them. Never mind.

Anyway I don't have access to the bugzilla, and I think we still not 
agreed on any format, so please let me what format do you want and I'll 
be happy to send it to Frank to attach it to bugzilla. BTW, how do i 
access to the bugzilla? :-)

>   3) The error codes are still not explained enough. I suggest either
>remove (some of) them, or document them better. Especially the client-side
>errors are still obscure to me.
>  
>
Do you have any specific proposal here? We don't see any major problems, 
but probably we are missing something. Just for clarity, I've removed 
the 800 section (client errors). The proposal (like the LSAE one) is 
open to add new error codes, so this is expandable in the future if we 
agree that we need (or not) specific error codes.

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>  
>
Added a new optional Notes element under serviceNotes to separate human 
readable free text from structured XML mobyException. This way we can 
maintain old functionality into serviceNotes. API changes proposed too.

>   5) The proposal should clearly suggest what (if anything) should be
>removed from the current Biomoby API. I mean the fact that the current API
>(even perhasp not literally, but surely by spirit) expects (allows) an
>empty result in case of an error (e.g. an ID cannot be found in a target
>database). Will this still be valid, or should serviceNotes be returned
>instead?
>  
>
Added a new section with API changes needed. Your question was answered 
in the proposal which is in the bugzilla but in short yes, still an 
empty result has to be sent and (optionally) a serviceNotes with an 
exception be reported with it. This allows the error handling system to 
be compatible with old clients.

>   I already said that I liked the new proposal and I am going to support
>it - but I want to introduce new things into Biomoby API as precisely as
>we can. Therefore, I am not ready to vote yet. But just in case, my
>suggestion described above, will not be accepted, and the vote deadline
>announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
>do it on Bugzilla, because (a) I think that this NO is only temporary and
>conditionally, and (b) I did not found any "history comments" there so I
>would not know how to use Bugzilla for that.)
>
>  
>
Hope that you change your mind. As soon as you tell me which document 
format you want, I'll send the latest version with the changes commented 
above.

>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050926/ab68c498/dgpisano-0004.vcf

From dgpisano at cnb.uam.es  Mon Sep 26 09:55:45 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon, 26 Sep 2005 15:55:45 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
Message-ID: <4337FDE1.1080201@cnb.uam.es>

I think we can still vote today, as far as Martin's objections are not 
really about the proposal itself, but about the aesthetics and 
presentation of the proposal. My solutions below

Martin Senger escribi?:

>>The vote has been called.  Voting members may vote by adding their YES 
>>(accept)  or NO (do not accept) to the comments history  through Bugzilla
>>
>>Voting ends Sept 26th
>>
>>    
>>
>    I propose to extend the vote deadline to October 15th. Reasons are:
>
>   1) The proposal (as available from Bugzilla) is still too complex, full
>of explanaition, and it is not clear what is a discussion and what is a
>proposal. I recommend that the authors take away most of the reasoning and
>just state what is the new API. (The reasoning can come later back to the
>documentation, if Frank, as a document-manager, decides so.)
>
>  
>
Explanations would not make the document *more* difficult to understand 
(unless the explanations are wrong)? Probably you are refering to the 
motivation / discussion parts, that we understand we needed to explain 
our reasons to expand MOBY-S specification. I've rewritten the proposal 
so now is just a specification extension proposal (still not an API 
proposal, that's the next implementation step).

>   2) The proposal is in the format which is not readable for everyone
>(for example, using OpenOffice mixes the tables on the first page, so I do
>not understand what they mean and why they are there). Open source API
>should use open documentation tools, as much as it can. The whole Biomoby
>API/docs is, so far, written in non-proprietary document format, so I
>suggest to continue with it.
>  
>
See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
format... We've never talked about this before, and the document can 
easily be exported to whatever format we agree. I am not really 
concerned about using open or closed tools, OMG publishes specifications 
in Word format -between other- and schema documentation using XML Spy 
and nobody objects using commercial tools as far as everybody can 
understand them. Never mind.

Anyway I don't have access to the bugzilla, and I think we still not 
agreed on any format, so please let me what format do you want and I'll 
be happy to send it to Frank to attach it to bugzilla. BTW, how do i 
access to the bugzilla? :-)

>   3) The error codes are still not explained enough. I suggest either
>remove (some of) them, or document them better. Especially the client-side
>errors are still obscure to me.
>  
>
Do you have any specific proposal here? We don't see any major problems, 
but probably we are missing something. Just for clarity, I've removed 
the 800 section (client errors). The proposal (like the LSAE one) is 
open to add new error codes, so this is expandable in the future if we 
agree that we need (or not) specific error codes.

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>  
>
Added a new optional Notes element under serviceNotes to separate human 
readable free text from structured XML mobyException. This way we can 
maintain old functionality into serviceNotes. API changes proposed too.

>   5) The proposal should clearly suggest what (if anything) should be
>removed from the current Biomoby API. I mean the fact that the current API
>(even perhasp not literally, but surely by spirit) expects (allows) an
>empty result in case of an error (e.g. an ID cannot be found in a target
>database). Will this still be valid, or should serviceNotes be returned
>instead?
>  
>
Added a new section with API changes needed. Your question was answered 
in the proposal which is in the bugzilla but in short yes, still an 
empty result has to be sent and (optionally) a serviceNotes with an 
exception be reported with it. This allows the error handling system to 
be compatible with old clients.

>   I already said that I liked the new proposal and I am going to support
>it - but I want to introduce new things into Biomoby API as precisely as
>we can. Therefore, I am not ready to vote yet. But just in case, my
>suggestion described above, will not be accepted, and the vote deadline
>announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
>do it on Bugzilla, because (a) I think that this NO is only temporary and
>conditionally, and (b) I did not found any "history comments" there so I
>would not know how to use Bugzilla for that.)
>
>  
>
Hope that you change your mind. As soon as you tell me which document 
format you want, I'll send the latest version with the changes commented 
above.

>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050926/ab68c498/dgpisano-0005.vcf

From edward.kawas at gmail.com  Mon Sep 26 10:56:55 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 07:56:55 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <1A427D71-2573-4920-8465-17843E0E3A02@wur.nl>
Message-ID: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>

Hi Pieter,

>When I append my local central to my mygrid.properties file
>for Taverna, I have the old behaviour: hence services from
>my local central, but objects from  the central central.

Where did you get this version of Taverna? Is it the one
from their homepage? If so, have you tried downloading the
one that I put up at
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip?

Also, is it possible to post your Mobycentral endpoint so
that I could see how things work?

Thanks,

Eddie



From senger at ebi.ac.uk  Mon Sep 26 10:59:44 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 26 Sep 2005 15:59:44 +0100 (BST)
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>

> I think we can still vote today, as far as Martin's objections are not 
> really about the proposal itself, but about the aesthetics and 
> presentation of the proposal
>
   No, I disagree. The proposal is correct in the spirit, but incorrect or
unclear in details (which I named in my email). The only aesthetics part
was about the format. That on its own would not give me right to suggest
to postpone the vote.

> Explanations would not make the document *more* difficult to understand 
>
   well the document has about ten pages; but it introduces only few XML
tags, plus a page of error codes; I think that having it more consice
helps to make sure that we are not overlooking some missing or
contradicting point.

> See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
> format...
>
   As I said, this was not my major concern. So do as you wish. I would
probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
API is written now.

> concerned about using open or closed tools, OMG publishes specifications 
> in Word format
>
   Talking about OMG, it is even worse that you think. The submissions
must be in FrameMaker which is completely close format. This is a
long-time living issue on the OMG table... But that's not our cup of tea.

> Anyway I don't have access to the bugzilla
>
   My personal opinion: don't even try - it's easy to be lost there. I did
not find how to vote there anyway.

> Do you have any specific proposal here?
>
   I just wanted to have the codes explained. The last version I saw (the
one from bugzilla) still has the client codes there. And I do not
understand what they mean.

> Added a new optional Notes element under serviceNotes to separate human 
> readable free text from structured XML mobyException. This way we can 
> maintain old functionality into serviceNotes. API changes proposed too.
>
   How can I see the new version?
 
> Added a new section with API changes needed. Your question was answered 
> in the proposal which is in the bugzilla but in short yes, still an 
> empty result has to be sent
>
   But that was under-documented from the beginning. Because the API does
not say what an "empty integer" means. I hoped that we will use this
chnage to clarify this.

> Hope that you change your mind. As soon as you tell me which document 
> format you want, I'll send the latest version with the changes commented 
> above.
> 
   Please send it. I will try to read it as it arrives - (but it's already
close to midnight here so I do not know if I manage it :-)).

   Regards,
   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)



From senger at ebi.ac.uk  Mon Sep 26 10:59:44 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 26 Sep 2005 15:59:44 +0100 (BST)
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>

> I think we can still vote today, as far as Martin's objections are not 
> really about the proposal itself, but about the aesthetics and 
> presentation of the proposal
>
   No, I disagree. The proposal is correct in the spirit, but incorrect or
unclear in details (which I named in my email). The only aesthetics part
was about the format. That on its own would not give me right to suggest
to postpone the vote.

> Explanations would not make the document *more* difficult to understand 
>
   well the document has about ten pages; but it introduces only few XML
tags, plus a page of error codes; I think that having it more consice
helps to make sure that we are not overlooking some missing or
contradicting point.

> See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
> format...
>
   As I said, this was not my major concern. So do as you wish. I would
probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
API is written now.

> concerned about using open or closed tools, OMG publishes specifications 
> in Word format
>
   Talking about OMG, it is even worse that you think. The submissions
must be in FrameMaker which is completely close format. This is a
long-time living issue on the OMG table... But that's not our cup of tea.

> Anyway I don't have access to the bugzilla
>
   My personal opinion: don't even try - it's easy to be lost there. I did
not find how to vote there anyway.

> Do you have any specific proposal here?
>
   I just wanted to have the codes explained. The last version I saw (the
one from bugzilla) still has the client codes there. And I do not
understand what they mean.

> Added a new optional Notes element under serviceNotes to separate human 
> readable free text from structured XML mobyException. This way we can 
> maintain old functionality into serviceNotes. API changes proposed too.
>
   How can I see the new version?
 
> Added a new section with API changes needed. Your question was answered 
> in the proposal which is in the bugzilla but in short yes, still an 
> empty result has to be sent
>
   But that was under-documented from the beginning. Because the API does
not say what an "empty integer" means. I hoped that we will use this
chnage to clarify this.

> Hope that you change your mind. As soon as you tell me which document 
> format you want, I'll send the latest version with the changes commented 
> above.
> 
   Please send it. I will try to read it as it arrives - (but it's already
close to midnight here so I do not know if I manage it :-)).

   Regards,
   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)



From edward.kawas at gmail.com  Mon Sep 26 10:43:07 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 07:43:07 -0700
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <433808ff.43a593e0.0674.1289@mx.gmail.com>

> Anyway I don't have access to the bugzilla
http://bugzilla.open-bio.org/ 
you may need to register first though.
 



From markw at illuminae.com  Mon Sep 26 17:56:56 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 26 Sep 2005 14:56:56 -0700
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>

The RDF committee now consists of:

Frank
Martin
Eddie
David
Mark
Simon
Pieter


I am assuming from Yan's message that he wont have time to participate
(please correct me if I am wrong, Yan :-) ), and I have not yet heard
from Paul Gordon.

In any case, that's a great group!  Thanks all!  Let's close the
committee for now.

So, Martin, how does OMG run its democracy?  Unanimity, or majority
rules?

Mark




From Pieter.Neerincx at wur.nl  Mon Sep 26 19:27:57 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 27 Sep 2005 01:27:57 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>
References: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>
Message-ID: <AE4E0C93-0C74-4404-AD40-D9759336D133@wur.nl>


On  26Sep2005, at 16:56, Edward Kawas wrote:

> Hi Pieter,
>
>
>> When I append my local central to my mygrid.properties file
>> for Taverna, I have the old behaviour: hence services from
>> my local central, but objects from  the central central.
>>
>
> Where did you get this version of Taverna? Is it the one
> from their homepage?

No, I've been testing with the version you put up at the URL  
mentioned below.

> If so, have you tried downloading the
> one that I put up at
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.zip?
> Also, is it possible to post your Mobycentral endpoint so
> that I could see how things work?

Yes, sure. I have now temporarily disabled the SSL requirement, so  
everything should work nicely over our firewall using port 80 :). as  
long as I'm testing I don't need the HTTPS, but some of the people  
that are using my services on a production server do.

My test MOBY Central endpoint is at: http://137.224.52.237/phenolink/ 
biomoby/central/cgi-bin/MOBY-Central.pl
My test RESOURCES script is at: http://137.224.52.237/RESOURCES/MOBY-S/

Hope this helps,

Pieter

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

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1038
Dreijenlaan 3
6703 HA Wageningen
phone: 0317-484 706
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl



From dgpisano at cnb.uam.es  Mon Sep 26 19:11:21 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Tue, 27 Sep 2005 01:11:21 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
Message-ID: <43388019.9040308@cnb.uam.es>

I am attaching a PDF file (faster conversion from Word, the HTML is 
generating is too MS-centric, but we can publish the final approved 
version in HTML). Is as strong rewrite (version 2), but I am still 
maintaining the proposal basics and the specification changes. Basically 
the document is organized in a different way.

Hope this help everybody to take a decision or further improve the  
specification (or both) ;-)

David
(about to dissapear some days for ECCB05)

Martin Senger escribi?:

>>I think we can still vote today, as far as Martin's objections are not 
>>really about the proposal itself, but about the aesthetics and 
>>presentation of the proposal
>>
>>    
>>
>   No, I disagree. The proposal is correct in the spirit, but incorrect or
>unclear in details (which I named in my email). The only aesthetics part
>was about the format. That on its own would not give me right to suggest
>to postpone the vote.
>
>  
>
>>Explanations would not make the document *more* difficult to understand 
>>
>>    
>>
>   well the document has about ten pages; but it introduces only few XML
>tags, plus a page of error codes; I think that having it more consice
>helps to make sure that we are not overlooking some missing or
>contradicting point.
>
>  
>
>>See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
>>format...
>>
>>    
>>
>   As I said, this was not my major concern. So do as you wish. I would
>probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
>API is written now.
>
>  
>
>>concerned about using open or closed tools, OMG publishes specifications 
>>in Word format
>>
>>    
>>
>   Talking about OMG, it is even worse that you think. The submissions
>must be in FrameMaker which is completely close format. This is a
>long-time living issue on the OMG table... But that's not our cup of tea.
>
>  
>
>>Anyway I don't have access to the bugzilla
>>
>>    
>>
>   My personal opinion: don't even try - it's easy to be lost there. I did
>not find how to vote there anyway.
>
>  
>
>>Do you have any specific proposal here?
>>
>>    
>>
>   I just wanted to have the codes explained. The last version I saw (the
>one from bugzilla) still has the client codes there. And I do not
>understand what they mean.
>
>  
>
>>Added a new optional Notes element under serviceNotes to separate human 
>>readable free text from structured XML mobyException. This way we can 
>>maintain old functionality into serviceNotes. API changes proposed too.
>>
>>    
>>
>   How can I see the new version?
> 
>  
>
>>Added a new section with API changes needed. Your question was answered 
>>in the proposal which is in the bugzilla but in short yes, still an 
>>empty result has to be sent
>>
>>    
>>
>   But that was under-documented from the beginning. Because the API does
>not say what an "empty integer" means. I hoped that we will use this
>chnage to clarify this.
>
>  
>
>>Hope that you change your mind. As soon as you tell me which document 
>>format you want, I'll send the latest version with the changes commented 
>>above.
>>
>>    
>>
>   Please send it. I will try to read it as it arrives - (but it's already
>close to midnight here so I do not know if I manage it :-)).
>
>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v2.0.pdf
Type: application/pdf
Size: 106970 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/0501INB-ExceptionReporting-v2.0-0004.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/dgpisano-0004.vcf

From dgpisano at cnb.uam.es  Mon Sep 26 19:11:21 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Tue, 27 Sep 2005 01:11:21 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
Message-ID: <43388019.9040308@cnb.uam.es>

I am attaching a PDF file (faster conversion from Word, the HTML is 
generating is too MS-centric, but we can publish the final approved 
version in HTML). Is as strong rewrite (version 2), but I am still 
maintaining the proposal basics and the specification changes. Basically 
the document is organized in a different way.

Hope this help everybody to take a decision or further improve the  
specification (or both) ;-)

David
(about to dissapear some days for ECCB05)

Martin Senger escribi?:

>>I think we can still vote today, as far as Martin's objections are not 
>>really about the proposal itself, but about the aesthetics and 
>>presentation of the proposal
>>
>>    
>>
>   No, I disagree. The proposal is correct in the spirit, but incorrect or
>unclear in details (which I named in my email). The only aesthetics part
>was about the format. That on its own would not give me right to suggest
>to postpone the vote.
>
>  
>
>>Explanations would not make the document *more* difficult to understand 
>>
>>    
>>
>   well the document has about ten pages; but it introduces only few XML
>tags, plus a page of error codes; I think that having it more consice
>helps to make sure that we are not overlooking some missing or
>contradicting point.
>
>  
>
>>See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
>>format...
>>
>>    
>>
>   As I said, this was not my major concern. So do as you wish. I would
>probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
>API is written now.
>
>  
>
>>concerned about using open or closed tools, OMG publishes specifications 
>>in Word format
>>
>>    
>>
>   Talking about OMG, it is even worse that you think. The submissions
>must be in FrameMaker which is completely close format. This is a
>long-time living issue on the OMG table... But that's not our cup of tea.
>
>  
>
>>Anyway I don't have access to the bugzilla
>>
>>    
>>
>   My personal opinion: don't even try - it's easy to be lost there. I did
>not find how to vote there anyway.
>
>  
>
>>Do you have any specific proposal here?
>>
>>    
>>
>   I just wanted to have the codes explained. The last version I saw (the
>one from bugzilla) still has the client codes there. And I do not
>understand what they mean.
>
>  
>
>>Added a new optional Notes element under serviceNotes to separate human 
>>readable free text from structured XML mobyException. This way we can 
>>maintain old functionality into serviceNotes. API changes proposed too.
>>
>>    
>>
>   How can I see the new version?
> 
>  
>
>>Added a new section with API changes needed. Your question was answered 
>>in the proposal which is in the bugzilla but in short yes, still an 
>>empty result has to be sent
>>
>>    
>>
>   But that was under-documented from the beginning. Because the API does
>not say what an "empty integer" means. I hoped that we will use this
>chnage to clarify this.
>
>  
>
>>Hope that you change your mind. As soon as you tell me which document 
>>format you want, I'll send the latest version with the changes commented 
>>above.
>>
>>    
>>
>   Please send it. I will try to read it as it arrives - (but it's already
>close to midnight here so I do not know if I manage it :-)).
>
>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v2.0.pdf
Type: application/pdf
Size: 106970 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/0501INB-ExceptionReporting-v2.0-0005.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/dgpisano-0005.vcf

From senger at ebi.ac.uk  Mon Sep 26 19:43:40 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 27 Sep 2005 00:43:40 +0100 (BST)
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509270043090.1185944-100000@mozart.ebi.ac.uk>

> So, Martin, how does OMG run its democracy?  Unanimity, or majority
> rules?
>
   Majority.
   M.

-- 
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)



From senger at ebi.ac.uk  Mon Sep 26 21:12:45 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 27 Sep 2005 02:12:45 +0100 (BST)
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient
In-Reply-To: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509270211020.1185944-100000@mozart.ebi.ac.uk>

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
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)



From markw at illuminae.com  Mon Sep 26 21:17:11 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 01:17:11 +0000 GMT
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
Message-ID: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>

You need to thank Eddie and Dennis (my co-op student this summer).  They had already coded this fix, but I had to commit and restart the server :-)

M


-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Tue, 27 Sep 2005 02:12:45 
To:Mark Wilkinson <markw at illuminae.com>
Cc:Moby Developers <moby-dev at biomoby.org>
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
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

--
Mark Wilkinson
...on the road!


From markw at illuminae.com  Mon Sep 26 21:02:45 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 26 Sep 2005 18:02:45 -0700
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient
In-Reply-To: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>
Message-ID: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>

The SINK should no longer be a SOURCE of frustration :-)

M


-- 
"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



From markw at illuminae.com  Mon Sep 26 21:17:11 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 01:17:11 +0000 GMT
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
Message-ID: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>

You need to thank Eddie and Dennis (my co-op student this summer).  They had already coded this fix, but I had to commit and restart the server :-)

M


-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Tue, 27 Sep 2005 02:12:45 
To:Mark Wilkinson <markw at illuminae.com>
Cc:Moby Developers <moby-dev at biomoby.org>
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
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

--
Mark Wilkinson
...on the road!


From edward.kawas at gmail.com  Mon Sep 26 21:31:19 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 18:31:19 -0700
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
In-Reply-To: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>
Message-ID: <4338a0ea.6bd81a7a.1e34.ffffdbb1@mx.gmail.com>

 
> The SINK should no longer be a SOURCE of frustration :-)

You see Mark, that was what I was talking about!



From edward.kawas at gmail.com  Mon Sep 26 21:40:53 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 18:40:53 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <AE4E0C93-0C74-4404-AD40-D9759336D133@wur.nl>
Message-ID: <4338a329.70df3d00.2781.71d9@mx.gmail.com>

Hi Pieter,

I have been toying around with your endpoint. I noticed that
the URL you gave earlier for the Object RDF was inconsistent
with what was retrieved from the API call
getResourceLocation(or something like that ...). 

I think that this occurred when you opened up your endpoint
and perhaps forgot to modify it in your mobycentral.conf
file (does https://bioinfw05:somePort/... resolve on your
machine?). 

The plugin utilizes the API call and hence wouldn't be able
to create a personalized Mobycentral processor (Moby
services and data types) list in Taverna without it.

Once I utilized the URLs that you specified in this message,
everything went as it should. I was able to use your
processors, etc.

I am uploading another version (I tweaked some of the logic)
of the plugin in about 5 minutes. Word on the street is that
Taverna 1.3 is going to be available later on this week
(Friday?) and so that version most likely would be the one
you would want to use. 

In addition, if you notice anything out of the ordinary,
please let me know ASAP so that I can correct it in time for
the much anticipated release.

Thanks,

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 26, 2005 4:28 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> 
> On  26Sep2005, at 16:56, Edward Kawas wrote:
> 
> > Hi Pieter,
> >
> >
> >> When I append my local central to my mygrid.properties
> file
> >> for Taverna, I have the old behaviour: hence services
> from
> >> my local central, but objects from  the central
central.
> >>
> >
> > Where did you get this version of Taverna? Is it the one
> > from their homepage?
> 
> No, I've been testing with the version you put up at the
> URL
> mentioned below.
> 
> > If so, have you tried downloading the
> > one that I put up at
> > http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
> 1.2.zip?
> > Also, is it possible to post your Mobycentral endpoint
> so
> > that I could see how things work?
> 
> Yes, sure. I have now temporarily disabled the SSL
> requirement, so
> everything should work nicely over our firewall using port
> 80 :). as
> long as I'm testing I don't need the HTTPS, but some of
> the people
> that are using my services on a production server do.
> 
> My test MOBY Central endpoint is at:
> http://137.224.52.237/phenolink/
> biomoby/central/cgi-bin/MOBY-Central.pl
> My test RESOURCES script is at:
> http://137.224.52.237/RESOURCES/MOBY-S/
> 
> Hope this helps,
> 
> Pieter
> 
> >
> > Thanks,
> >
> > Eddie
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1038
> Dreijenlaan 3
> 6703 HA Wageningen
> phone: 0317-484 706
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From edward.kawas at gmail.com  Mon Sep 26 22:01:54 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 19:01:54 -0700
Subject: [MOBY-dev] Re: [personal] API for retrieving
	namespacesinsufficient
In-Reply-To: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>
Message-ID: <4338a814.6d9c8408.538c.ffffe8e3@mx.gmail.com>

Mark, I noticed that the retrieve service type fix was not
'uncommented', like the namespace one was. Is this because
you don't want to implement that suggestion?

Lines >= 2615 of Central.pm

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Monday, September 26, 2005 6:17 PM
> To: Core developer announcements; Mark Wilkinson
> Cc: Moby Developers
> Subject: Re: [MOBY-dev] Re: [personal] API for retrieving
> namespacesinsufficient
> 
> You need to thank Eddie and Dennis (my co-op student this
> summer).  They had already coded this fix, but I had to
> commit and restart the server :-)
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger at ebi.ac.uk>
> Date: Tue, 27 Sep 2005 02:12:45
> To:Mark Wilkinson <markw at illuminae.com>
> Cc:Moby Developers <moby-dev at biomoby.org>
> Subject: [MOBY-dev] Re: [personal] API for retrieving
> namespaces insufficient
> 
> > The SINK should no longer be a SOURCE of frustration :-)
> >
>    WONDERFUL!!!! You are my best pal!
>    Thanks 1000x, Martin
> 
> (Just a pity is that I have to leave in few hours, so the
> jMoby
> implementation of this new feature must wait when I am
> back.)
> 
> M.
> 
> 
> --
> 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
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From senger at ebi.ac.uk  Mon Sep 26 22:06:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 27 Sep 2005 03:06:19 +0100 (BST)
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <43388019.9040308@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509270301380.1214670-100000@mozart.ebi.ac.uk>

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   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)



From senger at ebi.ac.uk  Mon Sep 26 22:06:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 27 Sep 2005 03:06:19 +0100 (BST)
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <43388019.9040308@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509270301380.1214670-100000@mozart.ebi.ac.uk>

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   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)



From markw at illuminae.com  Mon Sep 26 22:20:21 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 02:20:21 +0000 GMT
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
Message-ID: <1032375145-1127787656-cardhu_blackberry.rim.net-23779-@engine12-cell01>

It seems that my suggestion to use bugzilla's comment feature was not a winning idea v.v. voting on RFC's...  Would people prefer to just use the mailing list?

M



-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Tue, 27 Sep 2005 03:06:19 
To:David Gonz?lez Pisano <dgpisano at cnb.uam.es>
Cc:Core developer announcements <moby-dev at portal.open-bio.org>,       mobydev <moby-dev at biomoby.org>
Subject: Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   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

--
Mark Wilkinson
...on the road!



From markw at illuminae.com  Mon Sep 26 22:20:21 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 02:20:21 +0000 GMT
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
Message-ID: <1032375145-1127787656-cardhu_blackberry.rim.net-23779-@engine12-cell01>

It seems that my suggestion to use bugzilla's comment feature was not a winning idea v.v. voting on RFC's...  Would people prefer to just use the mailing list?

M



-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Tue, 27 Sep 2005 03:06:19 
To:David Gonz?lez Pisano <dgpisano at cnb.uam.es>
Cc:Core developer announcements <moby-dev at portal.open-bio.org>,       mobydev <moby-dev at biomoby.org>
Subject: Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   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

--
Mark Wilkinson
...on the road!



From Pieter.Neerincx at wur.nl  Tue Sep 27 05:31:05 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 27 Sep 2005 11:31:05 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4338a329.70df3d00.2781.71d9@mx.gmail.com>
References: <4338a329.70df3d00.2781.71d9@mx.gmail.com>
Message-ID: <6EC9FF1D-1762-4CDD-BE3F-D05415A3457E@wur.nl>

Hi Eddie,

On 27-Sep-2005, at 3:40 AM, Edward Kawas wrote:

> Hi Pieter,
>
> I have been toying around with your endpoint. I noticed that
> the URL you gave earlier for the Object RDF was inconsistent
> with what was retrieved from the API call
> getResourceLocation(or something like that ...).
>
> I think that this occurred when you opened up your endpoint
> and perhaps forgot to modify it in your mobycentral.conf
> file (does https://bioinfw05:somePort/... resolve on your
> machine?).

Ooops, you are right I forgot to change the hostname into an IP  
address in that conf file. It does resolve in our LAN because the  
hostname is added to the hosts file on all the machines, but it  
doesn't resolve outside our LAN. I've fixed it now.

>
> The plugin utilizes the API call and hence wouldn't be able
> to create a personalized Mobycentral processor (Moby
> services and data types) list in Taverna without it.
>
> Once I utilized the URLs that you specified in this message,
> everything went as it should. I was able to use your
> processors, etc.

The behaviour I described is still the same for me. It works fine as  
long as I manually add my local central, but simply specifying my  
local central in the taverna/conf/mygrid.properties file doesn't  
work. There must be a difference in the way the BioMOBY scavanger is  
constructed during startup of Taverna and when you manually add a  
BioMOBY scavanger...

>
> I am uploading another version (I tweaked some of the logic)
> of the plugin in about 5 minutes. Word on the street is that
> Taverna 1.3 is going to be available later on this week
> (Friday?) and so that version most likely would be the one
> you would want to use.

Nice! I'll get myself a cup of coffee and try the new version ...

Cheers,

Pieter

> In addition, if you notice anything out of the ordinary,
> please let me know ASAP so that I can correct it in time for
> the much anticipated release.
>
> Thanks,
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 26, 2005 4:28 PM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>>
>> On  26Sep2005, at 16:56, Edward Kawas wrote:
>>
>>
>>> Hi Pieter,
>>>
>>>
>>>
>>>> When I append my local central to my mygrid.properties
>>>>
>> file
>>
>>>> for Taverna, I have the old behaviour: hence services
>>>>
>> from
>>
>>>> my local central, but objects from  the central
>>>>
> central.
>
>>>>
>>>>
>>>
>>> Where did you get this version of Taverna? Is it the one
>>> from their homepage?
>>>
>>
>> No, I've been testing with the version you put up at the
>> URL
>> mentioned below.
>>
>>
>>> If so, have you tried downloading the
>>> one that I put up at
>>> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>>>
>> 1.2.zip?
>>
>>> Also, is it possible to post your Mobycentral endpoint
>>>
>> so
>>
>>> that I could see how things work?
>>>
>>
>> Yes, sure. I have now temporarily disabled the SSL
>> requirement, so
>> everything should work nicely over our firewall using port
>> 80 :). as
>> long as I'm testing I don't need the HTTPS, but some of
>> the people
>> that are using my services on a production server do.
>>
>> My test MOBY Central endpoint is at:
>> http://137.224.52.237/phenolink/
>> biomoby/central/cgi-bin/MOBY-Central.pl
>> My test RESOURCES script is at:
>> http://137.224.52.237/RESOURCES/MOBY-S/
>>
>> Hope this helps,
>>
>> Pieter
>>
>>
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1038
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> phone: 0317-484 706
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From markw at illuminae.com  Mon Sep 26 22:56:56 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 02:56:56 +0000 GMT
Subject: [MOBY-dev] Move to the new website
Message-ID: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>

Hi all,

I am going to try to migrate to the new website this week (biomoby.open-bio.org).  Once we're satisfied with it, I'll get the biomoby.org DNS to resolve to that server.

There's a lot of migration to do, but I think I can manage much of that on my own.  It will be fun!

I'm not sure where people are keeping all of the new documents... Can we make a concerted effort to move them on to that server over the next few days?

Cheers all!  This has been an amazing four months since the last dev meeting!!!

M

--
Mark Wilkinson
...on the road!


From edward.kawas at gmail.com  Tue Sep 27 10:26:45 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 27 Sep 2005 07:26:45 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <6EC9FF1D-1762-4CDD-BE3F-D05415A3457E@wur.nl>
Message-ID: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>

> The behavior I described is still the same for me. It
> works fine as
> long as I manually add my local central, but simply
> specifying my
> local central in the taverna/conf/mygrid.properties file
> doesn't
> work. There must be a difference in the way the BioMOBY
> scavanger is
> constructed during startup of Taverna and when you
> manually add a
> BioMOBY scavenger...

Hi Pieter,

I found out what you were talking about and you were right
on all accounts. I have fixed this *bug* and I created a new
version that I am in the process of uploading.

Actually, I did notice that I am unable to add services
using your endpoint!?! I looked at your service instance rdf
and I noticed that you have the descriptions of services
available, but all find service calls don't seem to be
working. Is this true?

Eddie



From Pieter.Neerincx at wur.nl  Tue Sep 27 10:55:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 27 Sep 2005 16:55:33 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
References: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
Message-ID: <9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>


On 27-Sep-2005, at 4:26 PM, Edward Kawas wrote:

>> The behavior I described is still the same for me. It
>> works fine as
>> long as I manually add my local central, but simply
>> specifying my
>> local central in the taverna/conf/mygrid.properties file
>> doesn't
>> work. There must be a difference in the way the BioMOBY
>> scavanger is
>> constructed during startup of Taverna and when you
>> manually add a
>> BioMOBY scavenger...
>>
>
> Hi Pieter,
>
> I found out what you were talking about and you were right
> on all accounts. I have fixed this *bug* and I created a new
> version that I am in the process of uploading.

Super, will test it at the end of the day.

> Actually, I did notice that I am unable to add services
> using your endpoint!?! I looked at your service instance rdf
> and I noticed that you have the descriptions of services
> available, but all find service calls don't seem to be
> working. Is this true?

I'll look into it. Might be a problem that I switched off https for  
my local central, but not for the services themselves. I've been  
switching between ports, 80, 443, 8080 and 8443 for the past days.  
Maybe some of my config files are not in sync...

Pieter


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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From gss at ncgr.org  Tue Sep 27 13:18:43 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue, 27 Sep 2005 11:18:43 -0600
Subject: [MOBY-dev] Move to the new website
In-Reply-To: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
Message-ID: <43397EF3.50509@ncgr.org>

I hope that it is planned to keep the website content under CVS control.

// Gary

mark wilkinson wrote:
> Hi all,
> 
> I am going to try to migrate to the new website this week (biomoby.open-bio.org).  Once we're satisfied with it, I'll get the biomoby.org DNS to resolve to that server.
> 
> There's a lot of migration to do, but I think I can manage much of that on my own.  It will be fun!
> 
> I'm not sure where people are keeping all of the new documents... Can we make a concerted effort to move them on to that server over the next few days?
> 
> Cheers all!  This has been an amazing four months since the last dev meeting!!!
> 
> M
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> 


From francis_gibbons at hms.harvard.edu  Tue Sep 27 21:27:53 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Tue, 27 Sep 2005 21:27:53 -0400
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.


Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
 
Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
 
-Frank



From francis_gibbons at hms.harvard.edu  Tue Sep 27 21:27:53 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Tue, 27 Sep 2005 21:27:53 -0400
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.


Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
 
Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
 
-Frank



From dgpisano at cnb.uam.es  Wed Sep 28 05:33:05 2005
From: dgpisano at cnb.uam.es (=?UTF-8?B?RGF2aWQgR29uesOhbGV6IFBpc2Fubw==?=)
Date: Wed, 28 Sep 2005 11:33:05 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <433A6351.1080907@cnb.uam.es>

Frank,

Probably the main problem with the PIB is its location, inside the 
Object structure. One of the initial options we considered was to report 
exceptions inside mobyData, but mixing "data" with "what happened while 
computing the data" information didn't look like the best idea. Using 
the PIB also brings up again the problem of what is an empty object: can 
we report back a "not so empty object", ie, an object with no data but 
PIB data? What about an object with no data but CrossReferences? Is not 
really clear to me. Given the examples about the PIB in the 
specification, I always thought it was a good place to fill with static 
data associated to my results (like software version, database release, 
etc..), not really about why the service didn't work.

The last proposal  we uploaded includes a possible solution to avoid 
XML-mixed elements, basically permiting serviceNotes to have two 
elements: mobyException and Notes. This solution allows to extend the 
servicNotes element with other uses/schemas in the future.

David

Gibbons, Francis escribi?:

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>
>
>Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
> 
>Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
> 
>-Frank
>
>_______________________________________________
>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: dgpisano.vcf
Type: text/x-vcard
Size: 349 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050928/31f7573e/dgpisano-0004.vcf

From dgpisano at cnb.uam.es  Wed Sep 28 05:33:05 2005
From: dgpisano at cnb.uam.es (=?UTF-8?B?RGF2aWQgR29uesOhbGV6IFBpc2Fubw==?=)
Date: Wed, 28 Sep 2005 11:33:05 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <433A6351.1080907@cnb.uam.es>

Frank,

Probably the main problem with the PIB is its location, inside the 
Object structure. One of the initial options we considered was to report 
exceptions inside mobyData, but mixing "data" with "what happened while 
computing the data" information didn't look like the best idea. Using 
the PIB also brings up again the problem of what is an empty object: can 
we report back a "not so empty object", ie, an object with no data but 
PIB data? What about an object with no data but CrossReferences? Is not 
really clear to me. Given the examples about the PIB in the 
specification, I always thought it was a good place to fill with static 
data associated to my results (like software version, database release, 
etc..), not really about why the service didn't work.

The last proposal  we uploaded includes a possible solution to avoid 
XML-mixed elements, basically permiting serviceNotes to have two 
elements: mobyException and Notes. This solution allows to extend the 
servicNotes element with other uses/schemas in the future.

David

Gibbons, Francis escribi?:

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>
>
>Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
> 
>Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
> 
>-Frank
>
>_______________________________________________
>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: dgpisano.vcf
Type: text/x-vcard
Size: 349 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050928/31f7573e/dgpisano-0005.vcf

From Pieter.Neerincx at wur.nl  Wed Sep 28 10:01:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 28 Sep 2005 16:01:42 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>
References: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
	<9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>
Message-ID: <8E698684-29C3-43C0-B9A1-58188958D7B5@wur.nl>

Hi Eddie,

On 27-Sep-2005, at 4:55 PM, Pieter Neerincx wrote:
>>
>> Hi Pieter,
>>
>> I found out what you were talking about and you were right
>> on all accounts. I have fixed this *bug* and I created a new
>> version that I am in the process of uploading.
>>
>
> Super, will test it at the end of the day.

Check, it works! Taverna now uses my local central when added to  
taverna/conf/mygrid.porperties.

Ran into a few small other problems though. I'm not sure whether  
these are the result of your custom mod of taverna or whether these  
are generic Taverna bugs...

1. The ~taverna-workbench/runme.sh script to start Taverna was in the  
wrong encoding. It contains windows CR LF line endings. After I  
dos2unix-ed the file it works.

2. I can only add 1 processor to a workflow by "drag and drop".  
Taverna refuses to add any other processor I drag and drop. It  
doesn't matter what kind of processor it is: biomoby service, object,  
local java widget, etc.. I can add more processors to a workflow  
using right-click -> add to workflow.

>
>> Actually, I did notice that I am unable to add services
>> using your endpoint!?! I looked at your service instance rdf
>> and I noticed that you have the descriptions of services
>> available, but all find service calls don't seem to be
>> working. Is this true?
>>
>
> I'll look into it. Might be a problem that I switched off https for  
> my local central, but not for the services themselves. I've been  
> switching between ports, 80, 443, 8080 and 8443 for the past days.  
> Maybe some of my config files are not in sync...

Got that nailed down as well. Wasn't a port problem. I turned on  
debugging in path/to/perl/modules/MOBY/Central.pm this used to simply  
write debug info to /tmp/CentralRegistryLogOut.txt , but with the new  
code base this also generates an "Error 500, internal server error".  
This doesn't happen for all calls to MOBY Central, but it did mess up  
the find services call. The following line:

     $debug && &_LOG("found id $_->{service_instance_id}\n");

occurs several times. Not all of them are fatal, but the ones on line  
1992, 2010, 2028 and 2046 result in the internal server error...  
Don't know how to fix it yet. Turning debugging off must have been  
the easiest work around I applied ever :)

Cheers,

Pieter

>
> Pieter
>
>
>
>>
>> Eddie
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>
>
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From gordonp at ucalgary.ca  Wed Sep 28 10:02:35 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 28 Sep 2005 08:02:35 -0600
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>	<4331CEA3.6020205@illuminae.com>
	<1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
Message-ID: <433AA27B.3050602@ucalgary.ca>

Actually, I did reply "Yes" to Eddie since he e-mailed me directly, but 
I guess it slipped his mind...

>The RDF committee now consists of:
>
>Frank
>Martin
>Eddie
>David
>Mark
>Simon
>Pieter
>
>
>I am assuming from Yan's message that he wont have time to participate
>(please correct me if I am wrong, Yan :-) ), and I have not yet heard
>from Paul Gordon.
>
>In any case, that's a great group!  Thanks all!  Let's close the
>committee for now.
>
>So, Martin, how does OMG run its democracy?  Unanimity, or majority
>rules?
>
>Mark
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>



From markw at illuminae.com  Wed Sep 28 10:03:43 2005
From: markw at illuminae.com (mark wilkinson)
Date: Wed, 28 Sep 2005 14:03:43 +0000 GMT
Subject: [MOBY-dev] RFC Committee  Membership
Message-ID: <489633558-1127916263-cardhu_blackberry.rim.net-9027-@engine09-cell01>

Excellent - thanks!

-----Original Message-----
From: Paul Gordon <gordonp at ucalgary.ca>
Date: Wed, 28 Sep 2005 08:02:35 
To:markw at illuminae.com,       Core developer announcements <moby-dev at portal.open-bio.org>
Subject: Re: [MOBY-dev] RFC Committee  Membership

Actually, I did reply "Yes" to Eddie since he e-mailed me directly, but 
I guess it slipped his mind...

>The RDF committee now consists of:
>
>Frank
>Martin
>Eddie
>David
>Mark
>Simon
>Pieter
>
>
>I am assuming from Yan's message that he wont have time to participate
>(please correct me if I am wrong, Yan :-) ), and I have not yet heard
>from Paul Gordon.
>
>In any case, that's a great group!  Thanks all!  Let's close the
>committee for now.
>
>So, Martin, how does OMG run its democracy?  Unanimity, or majority
>rules?
>
>Mark
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>

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

--
Mark Wilkinson
...on the road!


From Pieter.Neerincx at wur.nl  Wed Sep 28 10:12:54 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 28 Sep 2005 16:12:54 +0200
Subject: [MOBY-dev] Move to the new website
In-Reply-To: <43397EF3.50509@ncgr.org>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
Message-ID: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>

First of all: OMG that new site is so much nicer than the old one!  
That will a big plus for BioMOBY PR.

On 27-Sep-2005, at 7:18 PM, Gary Schiltz wrote:

> I hope that it is planned to keep the website content under CVS  
> control.

That would be cool. Can't find any website stuff in the CVS that  
contains the code though. I already registered at the new site, but  
as far as I get it, that is only to add comments to news posts or  
something. So how do I contribute to this wonderful new site?

>
> // Gary
>
> mark wilkinson wrote:
>
>> Hi all,
>> I am going to try to migrate to the new website this week  
>> (biomoby.open-bio.org).  Once we're satisfied with it, I'll get  
>> the biomoby.org DNS to resolve to that server.
>> There's a lot of migration to do, but I think I can manage much of  
>> that on my own.  It will be fun!
>> I'm not sure where people are keeping all of the new documents...  
>> Can we make a concerted effort to move them on to that server over  
>> the next few days?
>> Cheers all!  This has been an amazing four months since the last  
>> dev meeting!!!

It sure has been. The core dev mailing list is officially described  
as "low volume for announcements only", but after I take I few days  
of I always have to do quite a bit of catching up :)

Cheers,

Pi

>> M
>> --
>> Mark Wilkinson
>> ...on the road!
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Wed Sep 28 11:04:18 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 28 Sep 2005 08:04:18 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <8E698684-29C3-43C0-B9A1-58188958D7B5@wur.nl>
Message-ID: <433ab0f4.7e3a8bd0.47fe.ffffb878@mx.gmail.com>

> 1. The ~taverna-workbench/runme.sh script to start Taverna
> was in the
> wrong encoding. It contains windows CR LF line endings.
> After I
> dos2unix-ed the file it works.
That was my fault. I live in a windows world and created the
archive on windows after I built it with windows.



> 2. I can only add 1 processor to a workflow by "drag and
> drop".
> Taverna refuses to add any other processor I drag and
drop.
> It
> doesn't matter what kind of processor it is: biomoby
> service, object,
> local java widget, etc.. I can add more processors to a
> workflow
> using right-click -> add to workflow.
I wonder if this is because the version you ran was compiled
on my windows machine? I couldn't reproduce this behavior.

Thanks,

Eddie



From markw at illuminae.com  Wed Sep 28 11:11:30 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 08:11:30 -0700
Subject: [moby] Re: [MOBY-dev] Move to the new website
In-Reply-To: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org> <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
Message-ID: <1127920290.13392.7.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 16:12 +0200, Pieter Neerincx wrote:

> It sure has been. The core dev mailing list is officially described  
> as "low volume for announcements only", but after I take I few days  
> of I always have to do quite a bit of catching up :)

Yeah... there are more developers than users ;-)

I guess at this stage in MOBY development, most users eventually become
developers anyway.  Once the 1.0 API is out and coded up, we can start
to "market" MOBY as a tool rather than a toy...  This was one of the
discussions at the last MOBY meeting.

Cheers!

M




From markw at illuminae.com  Wed Sep 28 11:12:45 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 08:12:45 -0700
Subject: [moby] Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S --
	Vote Called
In-Reply-To: <433A6351.1080907@cnb.uam.es>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
	<433A6351.1080907@cnb.uam.es>
Message-ID: <1127920365.13392.10.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 11:33 +0200, David Gonz?lez Pisano wrote:

> Using 
> the PIB also brings up again the problem of what is an empty object: can 
> we report back a "not so empty object", ie, an object with no data but 
> PIB data? What about an object with no data but CrossReferences? Is not 
> really clear to me. Given the examples about the PIB in the 
> specification, I always thought it was a good place to fill with static 
> data associated to my results (like software version, database release, 
> etc..), not really about why the service didn't work.

I agree with this interpretation of the API.  If a service fails, the
mobyData object should have the associated queryID filled in, but
otherwise have NO CONTENT.  This precludes the use of CrossRef's and/or
PIB's for error reporting.


> The last proposal  we uploaded includes a possible solution to avoid 
> XML-mixed elements, basically permiting serviceNotes to have two 
> elements: mobyException and Notes. This solution allows to extend the 
> servicNotes element with other uses/schemas in the future.

I think this is a great idea.  The serviceNotes block was stuck into the
original API just because it seemed so obviously useful, but was
intentionally left "undefined" until someone had time to think of how
best to structure it.  Looks like now someone has found the time!

M




From markw at illuminae.com  Wed Sep 28 12:09:30 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 09:09:30 -0700
Subject: [moby] Re: [MOBY-dev] Move to the new website
In-Reply-To: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org> <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
Message-ID: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 16:12 +0200, Pieter Neerincx wrote:
> First of all: OMG that new site is so much nicer than the old one!  
> That will a big plus for BioMOBY PR.

Yeah, we were all pretty blown away by what Simon did there!  Kudo's to
him!!


> That would be cool. Can't find any website stuff in the CVS that  
> contains the code though. I already registered at the new site, but  
> as far as I get it, that is only to add comments to news posts or  
> something. So how do I contribute to this wonderful new site?

The website is under WordPress control, so anyone who wants an account
can get one and edit the site as they desire.  We have a better
granularity of control with WordPress, such that we can prevent people
from changing e.g. the site templates, or certain "domains", while
allowing them to change other domains to their hearts content.  It isn't
CVS (i,e, there's no back-out of mistakes!) but it's quite nice!

To get a WordPress account ask Simon.  I don't think I have permissions
to create new accounts, so don't ask me :-)

There's a lot of work left to do on it, but I made some headway
yesterday in getting the client information moved over.  It's just a lot
of tedious HTML coding left to do, so I'll likely do the aesthetic stuff
in the pub just to make it tolerable ;-)

I'm planning to do a CVS checkout of the moby-live repository into the
web folder and then link into the new HTML docs that Frank has been
writing for the past few weeks.  Hopefully I'll be able to set up a cron
that updates that folder every day or so to keep the website docs
current.

Cheers all!

M


-- 
"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



From Pieter.Neerincx at wur.nl  Wed Sep 28 14:01:57 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 28 Sep 2005 20:01:57 +0200
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
Message-ID: <C666C785-3B69-4CCA-89A7-0F59865E3D35@wur.nl>

Hi Mark and Eddie,

With Eddie's help I managed to get a local BioMOBY Central (using the  
new code base) up and running and make it work with Taverna :). The  
documentation at:
http://www.biomoby.org/InstallingMOBYCentral.html
is a bit outdated and incomplete. So I upgraded that info with my  
experience. I have a temporary copy online at:
http://137.224.52.237/InstallingLocalMOBYCentral.html
Let me know what you think... and if you like it: either copy it to  
the BioMOBY website or wait for Simon to give me an account for the  
new site.

Pi



From francis_gibbons at hms.harvard.edu  Wed Sep 28 15:01:01 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Wed, 28 Sep 2005 15:01:01 -0400
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <C666C785-3B69-4CCA-89A7-0F59865E3D35@wur.nl>
References: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
Message-ID: <5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>

Pieter,

At 02:01 PM 9/28/2005, you wrote:
>Hi Mark and Eddie,
>
>With Eddie's help I managed to get a local BioMOBY Central (using the
>new code base) up and running and make it work with Taverna :). The
>documentation at:
>http://www.biomoby.org/InstallingMOBYCentral.html
>is a bit outdated and incomplete. So I upgraded that info with my
>experience. I have a temporary copy online at:
>http://137.224.52.237/InstallingLocalMOBYCentral.html
>Let me know what you think... and if you like it: either copy it to
>the BioMOBY website or wait for Simon to give me an account for the
>new site.

I think this belongs in the CVS repository at least, to which I guess you 
already have access. Of course, it needs to go on the website too, but the 
entire content of the website should itself be available from CVS, with the 
website updated automatically from CVS.

-F

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From markw at illuminae.com  Wed Sep 28 18:19:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 15:19:40 -0700
Subject: [MOBY-dev] API docs up on the new site
Message-ID: <1127945980.13392.144.camel@bioinfo.icapture.ubc.ca>

Hi all, 

I've got Frank's new API docs up on the new biomoby site (click on the
"For Developers" link).  It's in a CVS checkout, but I just need to work
out how to put cvs update on a cron...  

Cheers!

M



-- 
"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



From markw at illuminae.com  Wed Sep 28 18:39:23 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 15:39:23 -0700
Subject: [MOBY-dev] RFC #1863 - change request & question
Message-ID: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>

Hi David, 

I have a question:  Have you now lost interest in raising exceptions to
individual simples in a collection?  I notice that your RFC no longer
handles this case (though I came to realize that it was a good idea
after you explained it to me :-) )

Also a request for change:  

Change 1

FROM
In the case of Retrieve calls, failure will be silent and an empty
object of the associated output
type will be returned.

TO
In the case of Retrieve calls, failure will be silent should rise an
exception and an empty object
of the associated output type will be returned.

TO (REVISED)
In the case of an error, failure should raise an exception and an empty
mobyData block with the appropriate queryID will be returned.


Comments:  the wording in the original API are wrong - the object is no
empty, the mobyData block is empty.



-- 
"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



From Pieter.Neerincx at wur.nl  Thu Sep 29 11:11:49 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu, 29 Sep 2005 17:11:49 +0200
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>
References: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>
Message-ID: <C540F3D5-9F4C-4C81-9E6D-BED23048B33A@wur.nl>


On 28-Sep-2005, at 9:01 PM, Frank Gibbons wrote:

> Pieter,
>
> At 02:01 PM 9/28/2005, you wrote:
>
>> Hi Mark and Eddie,
>>
>> With Eddie's help I managed to get a local BioMOBY Central (using the
>> new code base) up and running and make it work with Taverna :). The
>> documentation at:
>> http://www.biomoby.org/InstallingMOBYCentral.html
>> is a bit outdated and incomplete. So I upgraded that info with my
>> experience. I have a temporary copy online at:
>> http://137.224.52.237/InstallingLocalMOBYCentral.html
>> Let me know what you think... and if you like it: either copy it to
>> the BioMOBY website or wait for Simon to give me an account for the
>> new site.
>>
>
> I think this belongs in the CVS repository at least, to which I  
> guess you already have access. Of course, it needs to go on the  
> website too, but the entire content of the website should itself be  
> available from CVS, with the website updated automatically from CVS.

I agree, so I moved it into the CVS. Haven't heard back Mark or Eddie  
if the info is Ok, but they can now easily improve it if they run  
into wrong or missing information :).

For Eddie: the page links to the downloads of your servlets installer  
and custom Taverna version. If this is not Ok with you, please let me  
know.

I didn't find any templates for pages of the new site, so I had a  
look at the source and tried to compile something that is close to  
the new looks...

Pi

> -F
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA  
> 02115, USA.
> Tel: 617-432-3555       Fax: 617-432-3557       http:// 
> llama.med.harvard.edu/~fgibbons
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Thu Sep 29 11:18:18 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 29 Sep 2005 08:18:18 -0700
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <C540F3D5-9F4C-4C81-9E6D-BED23048B33A@wur.nl>
Message-ID: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>

> For Eddie: the page links to the downloads of your
> servlets installer
> and custom Taverna version.

I recently removed the Taverna link because tomorrow (I
think) people can download it from Taverna's homepage.

Eddie





From Pieter.Neerincx at wur.nl  Thu Sep 29 11:43:04 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu, 29 Sep 2005 17:43:04 +0200
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>
References: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>
Message-ID: <4DDBA090-1A2F-4F23-832E-D52DB04CB406@wur.nl>


On 29-Sep-2005, at 5:18 PM, Edward Kawas wrote:

>> For Eddie: the page links to the downloads of your
>> servlets installer
>> and custom Taverna version.
>>
>
> I recently removed the Taverna link because tomorrow (I
> think) people can download it from Taverna's homepage.

Ok, I'll remove that note about getting a custom version of taverna  
then.

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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From dgpisano at cnb.uam.es  Fri Sep 30 05:37:06 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri, 30 Sep 2005 11:37:06 +0200
Subject: [MOBY-dev] RFC #1863 - change request & question
In-Reply-To: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>
References: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>
Message-ID: <433D0742.4050708@cnb.uam.es>

Mark Wilkinson escribi?:

>Hi David, 
>
>I have a question:  Have you now lost interest in raising exceptions to
>individual simples in a collection?  I notice that your RFC no longer
>handles this case (though I came to realize that it was a good idea
>after you explained it to me :-) )
>  
>
Well, we didn't lost interest, but thought about it and decided to 
postpone the opening of the can of worms. After the next proposal 
(asynchrony) we are thinking about a third one for dealing with 
Collections, and Simples inside Collections. The main problematic point 
will be to (re)define namespaces (or parameter labels) and propose 
unique identifiers for Simples inside Collections, so we can refer to 
them. That means that quite a lot of things in the current MOBY 
specification could be discussed and changed, and we think is better not 
to mix the discussion about the errors with the discussion about the 
namespaces/collections. The latests proposals consider referring to the 
exception raising element using elementID tag (instead of the original 
namespaceID), so it can be easily extended to refer to Simples inside 
Collections if in the future we propose a way to identify them

>Also a request for change:  
>
>Change 1
>
>FROM
>In the case of Retrieve calls, failure will be silent and an empty
>object of the associated output
>type will be returned.
>
>TO
>In the case of Retrieve calls, failure will be silent should rise an
>exception and an empty object
>of the associated output type will be returned.
>
>TO (REVISED)
>In the case of an error, failure should raise an exception and an empty
>mobyData block with the appropriate queryID will be returned.
>
>
>Comments:  the wording in the original API are wrong - the object is no
>empty, the mobyData block is empty.
>
>  
>
I think it makes much more sense, will update the document and will send 
it again when is voted. BTW, I obviously vote YES, but don't know about 
the rest of the voters, or even if we postponed the voting date to the 
one suggested by Martin in October.

>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050930/900e212c/dgpisano-0002.vcf

From senger at ebi.ac.uk  Thu Sep  1 00:10:39 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 1 Sep 2005 01:10:39 +0100 (BST)
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY
	v1.5 - INB proposal
In-Reply-To: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509010105240.1462154-100000@mozart.ebi.ac.uk>

> It isn't entirely clear to me that there is a need to throw errors on a
> specific Simple within a Collection.
>
   I quite like how Mark explained it, and it makes sense to me. I am just
not too concerned because this part is just an optional part - so the only
"mandatory" part in the API (regarding this issue) will/would be "...and
ignore other possibly present attributes in the Simples in a Collection".
   But still, I am interested to hear David's argumentation againts Mark's
explanation. David, do you have a real-life use-case where you expect to
create such response?

   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)



From senger at ebi.ac.uk  Thu Sep  1 00:10:39 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 1 Sep 2005 01:10:39 +0100 (BST)
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY
	v1.5 - INB proposal
In-Reply-To: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509010105240.1462154-100000@mozart.ebi.ac.uk>

> It isn't entirely clear to me that there is a need to throw errors on a
> specific Simple within a Collection.
>
   I quite like how Mark explained it, and it makes sense to me. I am just
not too concerned because this part is just an optional part - so the only
"mandatory" part in the API (regarding this issue) will/would be "...and
ignore other possibly present attributes in the Simples in a Collection".
   But still, I am interested to hear David's argumentation againts Mark's
explanation. David, do you have a real-life use-case where you expect to
create such response?

   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)



From senger at ebi.ac.uk  Thu Sep  1 01:19:25 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 1 Sep 2005 02:19:25 +0100 (BST)
Subject: [MOBY-dev] jMoby: problems with Ant under Windows
Message-ID: <Pine.OSF.4.21.0509010210270.1474166-100000@mozart.ebi.ac.uk>

You are a pool of clever and experiences people - would anybody be able to
help me to write (actually to fix) the current Ant's build.zml so it works
fine also under Windows? I am desperately seeking an advise:

1) The command-line arguments when using target <java> cannot remain empty
(under Windows). For example, the command-line:
    java MosesGenerator -e "" -debug
means (under Linux) a command-line with three arguments, but (under
windows) a command-line with just two arguments (-e and -debug). Is there
a solution for this, at all?

2) The target <javadoc>, when used with rich attributes (like bottom,
headre etc.), does not work under windows. First I had to change double
quotes into single quotes (okay, Ant should do it, but does not; but it's
doable). Second I have to remove newlines from some XML elements - like
the 'bottom' one (okay, doable, but annoying, again Any should do it - as
it does for unix). But third: the line for javadoc is too long for
windows. Well, if you have a windows running, try the current build.xml -
try target 'docs' - and you will see what I am talking about, and perhaps
you will kniw how to rectiry.

   Many thanks for your help,
   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)



From edward.kawas at gmail.com  Thu Sep  1 01:24:35 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 31 Aug 2005 18:24:35 -0700
Subject: [MOBY-dev] jMoby: problems with Ant under Windows
In-Reply-To: <Pine.OSF.4.21.0509010210270.1474166-100000@mozart.ebi.ac.uk>
Message-ID: <43165859.64ac00f0.3259.3e66@mx.gmail.com>

Don't yell at me, but all that windows needed was a good
'clean'ing.

Thanks.

Ed

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Wednesday, August 31, 2005 6:19 PM
> To: Moby Developers
> Subject: [MOBY-dev] jMoby: problems with Ant under Windows
> 
> You are a pool of clever and experiences people - would
> anybody be able to
> help me to write (actually to fix) the current Ant's
> build.zml so it works
> fine also under Windows? I am desperately seeking an
> advise:
> 
> 1) The command-line arguments when using target <java>
> cannot remain empty
> (under Windows). For example, the command-line:
>     java MosesGenerator -e "" -debug
> means (under Linux) a command-line with three arguments,
> but (under
> windows) a command-line with just two arguments (-e and -
> debug). Is there
> a solution for this, at all?
> 
> 2) The target <javadoc>, when used with rich attributes
> (like bottom,
> headre etc.), does not work under windows. First I had to
> change double
> quotes into single quotes (okay, Ant should do it, but
> does not; but it's
> doable). Second I have to remove newlines from some XML
> elements - like
> the 'bottom' one (okay, doable, but annoying, again Any
> should do it - as
> it does for unix). But third: the line for javadoc is too
> long for
> windows. Well, if you have a windows running, try the
> current build.xml -
> try target 'docs' - and you will see what I am talking
> about, and perhaps
> you will kniw how to rectiry.
> 
>    Many thanks for your help,
>    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



From senger at ebi.ac.uk  Thu Sep  1 05:54:05 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 1 Sep 2005 06:54:05 +0100 (BST)
Subject: [MOBY-dev] jMoby: problems with Ant under Windows
In-Reply-To: <43165859.64ac00f0.3259.3e66@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509010653180.1474166-100000@mozart.ebi.ac.uk>

> Don't yell at me, but all that windows needed was a good
> 'clean'ing.
>
   Eddie, what are you talking about? About Ant problems I asked about?
   M.
 
> Thanks.
> 
> Ed
> 
> > -----Original Message-----
> > From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> > dev-bounces at portal.open-bio.org] On Behalf Of Martin
> > Senger
> > Sent: Wednesday, August 31, 2005 6:19 PM
> > To: Moby Developers
> > Subject: [MOBY-dev] jMoby: problems with Ant under Windows
> > 
> > You are a pool of clever and experiences people - would
> > anybody be able to
> > help me to write (actually to fix) the current Ant's
> > build.zml so it works
> > fine also under Windows? I am desperately seeking an
> > advise:
> > 
> > 1) The command-line arguments when using target <java>
> > cannot remain empty
> > (under Windows). For example, the command-line:
> >     java MosesGenerator -e "" -debug
> > means (under Linux) a command-line with three arguments,
> > but (under
> > windows) a command-line with just two arguments (-e and -
> > debug). Is there
> > a solution for this, at all?
> > 
> > 2) The target <javadoc>, when used with rich attributes
> > (like bottom,
> > headre etc.), does not work under windows. First I had to
> > change double
> > quotes into single quotes (okay, Ant should do it, but
> > does not; but it's
> > doable). Second I have to remove newlines from some XML
> > elements - like
> > the 'bottom' one (okay, doable, but annoying, again Any
> > should do it - as
> > it does for unix). But third: the line for javadoc is too
> > long for
> > windows. Well, if you have a windows running, try the
> > current build.xml -
> > try target 'docs' - and you will see what I am talking
> > about, and perhaps
> > you will kniw how to rectiry.
> > 
> >    Many thanks for your help,
> >    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
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 

-- 
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)



From fgibbons at hms.harvard.edu  Thu Sep  1 13:59:14 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Thu, 01 Sep 2005 09:59:14 -0400
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <200508310321.j7V3L7AG014458@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>

Martin,

Thanks for your comments on the API documentation. As I think I pointed out 
earlier, at this point all I've done is to take what was in the wiki, clean 
up the HTML a bit, and check it into CVS. I added a few little bits of 
text, put in some links, and did a little semantic markup, but that's it.

>    The first few comments about the registry API:
>
>    * I think that the first page (with a list of methods) should also have
>(even start with) a list of links to objects used by these methods, such
>as a query object.

If this API is to language-independent, then I'm not so sure we can talk 
about objects, unless the Java and Perl implementations agree on it. My 
personal feeling is that what's needed most is high-level, abstract 
description of the overall scheme. A year ago, newbies had to try and put 
together that picture from the Perl code. While I think the Javadoc is 
really good (especially MOSES), the Perldoc still needs work. And even when 
both are as good as we'd like them to be, it's still useful to specify the 
API in language-independent terms. In Perl, there is not "query object" 
only registry/service objects.

>    * I disagree with labelling the deregisteService as depracated. As far
>as I understood, it will be still around for quick resgiter/unregister
>cycle where I am not conceedrn about security (that somebody can
>deregister my service). So from the API point of view it is a normal
>method, not a deprecated one. Mark?

Well, this is marked as 'deprecated' in the wiki, hence it is so marked 
here too. At some point (perhaps v 0.9?) it would be great to have a code 
freeze, in which we could make sure that the docs and implementation agree, 
so that we could have a product that is internally consistent, even as 
development continues. There's even nothing wrong with writing the API as 
we *wish* it to be (some would say that's how it should be done), and then 
trying to code to that. We can release a version in which the documentation 
makes clear what is implemented, and what is 'to-do'.

>    * service protocol "moby" is actually a service category, not a 
> protocol I think

>    * some details have also categories cgi.soap, some not... I suggest to
>remove all cgi and sopa for now (we will have in in the CVS if we need it
>to re-introsduce it later; surely the 'soap' category bring nothing than a
>confusion (isn't it current moby based on soap? - I know how it is, but
>newbies perhaps not)

Yeah, I tend to agree that this is confusing, since only "moby" exists (not 
"cgi" and "soap"). I agree that they should be culled, but since this is 
what was in the wiki, and I didn't know what the development plans were for 
it, I left it in.

>    * I would move definition of a "A MOBY compliant service" to the
>section about services API (here may be just a link to it).  As I said I
>am really concern that these two APIs are (or were before you enter the
>scene) confusing, so make them as separate as possible.

I agree, I'll try to get greater separation between the registry and 
services APIs.

>    * retrieveResourceURLs has a wrong description (something about providers)

I think is still under development - Mark?

>    And the last (but not an unimportant) general comment: the XML-based
>API should be expressed as DTD (which is more preferable in this context,
>XSD is not so human readable).

I think we'll need a volunteer to help us out on that - I've used DTD/XSDs, 
but never written one. Anyone?

>    Also the details about individual tags and attributes are quitel 
> imited now.

Yeah, we really need to beef up the details.

Thanks for your useful comments, Martin. I look forward to more.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From senger at ebi.ac.uk  Thu Sep  1 14:31:05 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 1 Sep 2005 15:31:05 +0100 (BST)
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <Pine.OSF.4.21.0509011524240.895262-100000@ice.ebi.ac.uk>

> If this API is to language-independent, then I'm not so sure we can talk 
> about objects
>
   Oh no, no, that's a misunderstanding. Sorry for the confusion. I would
be the first who would shout "Long Live Language Independence!". I said
"query object" because this term is used in the current API. But I meant
the XML, of course.

> Well, this is marked as 'deprecated' in the wiki, hence it is so marked 
> here too.
>
   I understand. It was more to Mark. Just to record my concern and fear
that Mark can one day remove it and say "what are you complaining about,
it was deprecated already for years?". I am quite often scare what Mark
can do suddenly... (well, I wanted to add :-) but I found that it was not
a joke, after all).

> >    * retrieveResourceURLs has a wrong description (something about providers)
> 
> I think is still under development - Mark?
>
   Not as far I know. I have it already implemented in jMoby and it worked
(about a month ago). The only thing stull under discussion was the content
type of this resources (if to provide more or not). And also a clear
definition what is expected from the service providers when they suddenly
become the LSID metadata resolvers.
 
   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)



From edward.kawas at gmail.com  Thu Sep  1 12:44:22 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 1 Sep 2005 05:44:22 -0700
Subject: [MOBY-dev] jMoby: problems with Ant under Windows
In-Reply-To: <Pine.OSF.4.21.0509010653180.1474166-100000@mozart.ebi.ac.uk>
Message-ID: <4316f7ad.17975dab.1578.1c6c@mx.gmail.com>

I just meant that the clean compile command worked.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Wednesday, August 31, 2005 10:54 PM
> To: Core developer announcements
> Subject: RE: [MOBY-dev] jMoby: problems with Ant under
> Windows
> 
> > Don't yell at me, but all that windows needed was a good
> > 'clean'ing.
> >
>    Eddie, what are you talking about? About Ant problems I
> asked about?
>    M.
> 
> > Thanks.
> >
> > Ed
> >
> > > -----Original Message-----
> > > From: moby-dev-bounces at portal.open-bio.org
> [mailto:moby-
> > > dev-bounces at portal.open-bio.org] On Behalf Of Martin
> > > Senger
> > > Sent: Wednesday, August 31, 2005 6:19 PM
> > > To: Moby Developers
> > > Subject: [MOBY-dev] jMoby: problems with Ant under
> Windows
> > >
> > > You are a pool of clever and experiences people -
> would
> > > anybody be able to
> > > help me to write (actually to fix) the current Ant's
> > > build.zml so it works
> > > fine also under Windows? I am desperately seeking an
> > > advise:
> > >
> > > 1) The command-line arguments when using target <java>
> > > cannot remain empty
> > > (under Windows). For example, the command-line:
> > >     java MosesGenerator -e "" -debug
> > > means (under Linux) a command-line with three
> arguments,
> > > but (under
> > > windows) a command-line with just two arguments (-e
> and -
> > > debug). Is there
> > > a solution for this, at all?
> > >
> > > 2) The target <javadoc>, when used with rich
> attributes
> > > (like bottom,
> > > headre etc.), does not work under windows. First I had
> to
> > > change double
> > > quotes into single quotes (okay, Ant should do it, but
> > > does not; but it's
> > > doable). Second I have to remove newlines from some
> XML
> > > elements - like
> > > the 'bottom' one (okay, doable, but annoying, again
> Any
> > > should do it - as
> > > it does for unix). But third: the line for javadoc is
> too
> > > long for
> > > windows. Well, if you have a windows running, try the
> > > current build.xml -
> > > try target 'docs' - and you will see what I am talking
> > > about, and perhaps
> > > you will kniw how to rectiry.
> > >
> > >    Many thanks for your help,
> > >    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
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> --
> 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



From markw at illuminae.com  Thu Sep  1 16:23:04 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Thu, 01 Sep 2005 09:23:04 -0700
Subject: [moby] [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <1125591784.28085.50.camel@bioinfo.icapture.ubc.ca>

On Thu, 2005-09-01 at 09:59 -0400, Frank Gibbons wrote:

> >    * I disagree with labelling the deregisteService as depracated. As far
> >as I understood, it will be still around for quick resgiter/unregister
> >cycle where I am not conceedrn about security (that somebody can
> >deregister my service). So from the API point of view it is a normal
> >method, not a deprecated one. Mark?

It was the initial intention to remove it permanently from the API
because of the security problem, and have the agent do the
deregistration when the service provider removes their RDF signature;
however that decision is now in flux because of the need for rapid
register/deregister cycles.  As such, I haven't changed the 'deprecated'
status until this is resolved.

The behaviour right now is that a service can be deregistered using this
call if it was initially registered without a signatureURL.  I think
this is a reasonable way to go forward, but since we haven't turned the
agent on yet, it isn't entirely clear if this behaviour is sufficient to
accommodate the majority of cases.  It should be, so I'm be inclined to
de-deprecate that call and simply update the API to reflect its current
behaviour.


> There's even nothing wrong with writing the API as 
> we *wish* it to be (some would say that's how it should be done),

That's more or less how things have been going since the last MOBY
meeting - the API was being updated ahead of the code. I'm trying (more
successfully now than a couple of months ago) to keep them in sync, but
this is an extremely rapid development phase we are going through as we
approach the 1.0 release at the end of this month, so...  yeah... it's a
bit chaotic right now, and will be for the next few weeks.




> >    * some details have also categories cgi.soap, some not... I suggest to
> >remove all cgi and sopa for now (we will have in in the CVS if we need it
> >to re-introsduce it later; surely the 'soap' category bring nothing than a
> >confusion (isn't it current moby based on soap? - I know how it is, but
> >newbies perhaps not)

Yes, let's remove all references to anything other than "moby" category
from the API.  The code did support CGI GET service registrations after
the Singapore hackathon (and it probably still does, but it isn't being
tested regularly); however until we spend some time fully defining this
behaviour we should take it out.  I will update the code to prevent
anything other than "moby" registrations.



> >    * retrieveResourceURLs has a wrong description (something about providers)
> 
> I think is still under development - Mark?

I think it is working as advertised...??

M


-- 
"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



From tmo at ebi.ac.uk  Thu Sep  1 15:47:33 2005
From: tmo at ebi.ac.uk (Tom Oinn)
Date: Thu, 01 Sep 2005 16:47:33 +0100
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <43172295.8090207@ebi.ac.uk>


>>    And the last (but not an unimportant) general comment: the XML-based
>> API should be expressed as DTD (which is more preferable in this context,
>> XSD is not so human readable).
> 
> 
> I think we'll need a volunteer to help us out on that - I've used 
> DTD/XSDs, but never written one. Anyone?

We've used XMLSpy in the past to produce graphical representations of 
XSD and DTD, this is generally easier to read than the textual ones. 
With some restrictions this can also be used to convert XSD to DTD 
although personally I prefer reading XSD.

Tom


From dgpisano at cnb.uam.es  Fri Sep  2 09:31:49 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri, 02 Sep 2005 11:31:49 +0200
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBYv1.5
	- INB proposal
In-Reply-To: <Pine.OSF.4.21.0509010105240.1462154-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509010105240.1462154-100000@mozart.ebi.ac.uk>
Message-ID: <43181C05.7090508@cnb.uam.es>

Martin Senger escribi?:

>>It isn't entirely clear to me that there is a need to throw errors on a
>>specific Simple within a Collection.
>>    
>>
>   I quite like how Mark explained it, and it makes sense to me. I am just
>not too concerned because this part is just an optional part - so the only
>"mandatory" part in the API (regarding this issue) will/would be "...and
>ignore other possibly present attributes in the Simples in a Collection".
>   But still, I am interested to hear David's argumentation againts Mark's
>explanation. David, do you have a real-life use-case where you expect to
>create such response?
>
>  
>
No, I don't have a real life example with an input collection. But I do 
have one with an output collection that could serve as example. We could 
imagine this kind of problems in input collections. Jose Maria sent it 
to the list months ago, but I can post it again. Is a real service which 
is being used in the PlaNet project (getInteractions).

A given service retrieves information about protein interactions from 
different data sources (a couple of SQL databases and one XML data 
base). Each database is stored in a different server, including the 
corresponding DBMS. The input to the service is a Simple representing a 
protein, while the output is a Collection with all possible interactions 
where that protein is participating.

In some cases, the service is not able to contact with a particular 
DBMS. Under this situation, rather than stopping the whole service 
execution and raise an exception for the whole Collection, the service 
could go ahead to the next server and report an exception with 
severity='warning' (assuming that at least one DBMS responded with 
useful information) for one or more Simples inside the Collection.

Even with only partial results, the service is still interesting enough 
for a client to wish it to continue. These types of situations are 
expected to arise -for example- when working with collections.




>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050902/26e5c58f/attachment.vcf>

From senger at ebi.ac.uk  Fri Sep  2 11:06:28 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 2 Sep 2005 12:06:28 +0100 (BST)
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBYv1.5
	- INB proposal
In-Reply-To: <43181C05.7090508@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>

> corresponding DBMS. The input to the service is a Simple representing a 
> protein, while the output is a Collection with all possible interactions 
> where that protein is participating.
>
   This is a good example because it nicely illustrates what Mark said,
and not a need for naming Simples in a Collection (IMHO) :-) :

   1) First, you cannot have a service that can return *all* protein
interactions. Such service is a sci-fi. So you go for "all possible"
protein interactions. Well, but when a DBMS source is not available, its
interactions are "not possible".
   2) Also, you do not know what interactions *would* be found in the
non-responding DBMS, so you cannot create any Simple representing such
non-returned interactions.
   3) And last, you can still inform the users about not covering all my
resources (this time) in a general warning in mobyException - but there is
really no sense to put this warniong in a collection itself.

   I must admit that I have not paid much attention to this topic when it
was explained in Malage. Because now, I really do not see why we need it.
(I hate to agree to much with Mark, it's dangerous because it is addictive
:-)).

   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)



From senger at ebi.ac.uk  Fri Sep  2 11:16:52 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 2 Sep 2005 12:16:52 +0100 (BST)
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <43182A24.1030800@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>

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

-- 
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)



From dgpisano at cnb.uam.es  Fri Sep  2 11:46:18 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri, 02 Sep 2005 13:46:18 +0200
Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in
	bioMOBYv1.5- INB proposal
In-Reply-To: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
Message-ID: <43183B8A.2010607@cnb.uam.es>

Ok, I admit it was not a good example ;-)

Martin Senger escribi?:

>>corresponding DBMS. The input to the service is a Simple representing a 
>>protein, while the output is a Collection with all possible interactions 
>>where that protein is participating.
>>
>  This is a good example because it nicely illustrates what Mark said,
>and not a need for naming Simples in a Collection (IMHO) :-) :
>
>   1) First, you cannot have a service that can return *all* protein
>interactions. Such service is a sci-fi. So you go for "all possible"
>protein interactions. Well, but when a DBMS source is not available, its
>interactions are "not possible".
>  
>
Obviously. Maybe Jose Mar?a could explain it better, but we are not 
talking about the biology here, and probably the example should say *all 
possible protein interactions stored in my databases", ok. But the topic 
is why should I want to report an error for a Simple in a Collection, 
not if is possible to obtain all interactions for a given protein or not ;-)

The example (like all examples) should help us to extrapolate and 
imagine real use cases. In this case, I can imagine another service 
where I want to annotate an input probe list collection (those present 
in my microarray), for example against several databases with different 
information. Some of them are not available at execution time, or cannot 
find the required information because the query does not accept a given 
input character, so I want to inform the user that I have a warning for 
this specific probe, because I was not able to retrieve the information 
from the db due to whatever problem had happened.

>   2) Also, you do not know what interactions *would* be found in the
>non-responding DBMS, so you cannot create any Simple representing such
>non-returned interactions.
>  
>
Again, let's suppose my Simple needs the name *and* the type and 
description of the interaction, and that pieces of information are 
stored in different DB's. What if I can retrieve the name (ie, not an 
empty simple) but cannot retrieve its type, description, etc... (ie, my 
object is not empty but cannot be completed...)?

>   3) And last, you can still inform the users about not covering all my
>resources (this time) in a general warning in mobyException - but there is
>really no sense to put this warniong in a collection itself.
>  
>
I still think that the general case (a whole resource needed for the 
service or the collection is not available) is different than the 
particular case (a single error, warning or information could be 
generated for a particular Simple inside an input Collection, while the 
other Simples are all right).

>   I must admit that I have not paid much attention to this topic when it
>was explained in Malage. Because now, I really do not see why we need it.
>
Whatever. Is an optional part in the proposal, and depends on a BioMOBY 
specification change to be possible to implement, so there is no problem 
in removing it from the proposal if the community thinks is not 
necessary to specify it. We will save the file for future use if needed ;-)

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050902/8f080999/attachment.vcf>

From jmfernandez at cnb.uam.es  Fri Sep  2 12:53:54 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Fri, 02 Sep 2005 14:53:54 +0200
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
References: <5.2.1.1.2.20050901094729.011eba00@email.med.harvard.edu>
Message-ID: <43184B62.5020606@cnb.uam.es>

> 
>>    And the last (but not an unimportant) general comment: the XML-based
>> API should be expressed as DTD (which is more preferable in this context,
>> XSD is not so human readable).
> 
> 
> I think we'll need a volunteer to help us out on that - I've used 
> DTD/XSDs, but never written one. Anyone?
> 

Well, I have developed many XML based formats, and I have used maaaany 
different tools since I began. I agree with Tom about XSD, . A useful 
open source tool is Pollo (pollo.sourceforge.net). Other ones are 
XMLmind XML Editor (http://www.xmlmind.com/xmleditor/) and oXygen 
(http://www.oxygenxml.com/), which I used to generate the documentation 
for a XML Schema I developed using Pollo (see 
http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).

I'm quite busy now, but if you give me one week I can do that.

	Best Regards,
		Jos? Mar?a

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)


From edward.kawas at gmail.com  Fri Sep  2 12:53:47 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 2 Sep 2005 05:53:47 -0700
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
Message-ID: <43184b5f.14a53cea.215f.410d@mx.gmail.com>

Martin,

Can you explain this a little more because I don?t
understand what you are trying to say.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Friday, September 02, 2005 4:17 AM
> To: David Gonz?lez Pisano
> Cc: Mark Wilkinson; Moby Developers
> Subject: [MOBY-dev] problem with article names?
> 
> 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
> 
> --
> 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




From senger at ebi.ac.uk  Fri Sep  2 13:13:18 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 2 Sep 2005 14:13:18 +0100 (BST)
Subject: [MOBY-dev] problem with article names?
In-Reply-To: <43184b5f.14a53cea.215f.410d@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509021406450.695974-100000@ice.ebi.ac.uk>

> Can you explain this a little more because I don?t
> understand what you are trying to say.
>
   So perhaps I am on a wrong track. But here it is:

   A service has to have article names for its inputs and outputs
(according the new API).
   An example: MyService produces GenericSequence with an article name
"Sequence". YourService is registered as consumig also GenericSequence but
with an article name "QuerySequence".
   I put in Taverna a workflow: MyService --> YourService.
   MyService produces a GenericSequence with a name "Sequence" - because
that's how it was registered. YourSequence gets data from MySequence. It
expect an article name "QuerySequence" but wht it gets is a sequence with
an article name "Sequence". YourService starts to wonder what the hell
should I do with it?
   Because if YourService is able to accept any name, then why we bother
to have them at all?
   Thsi is a situation, most common situation, where a service has only
one input and one output.

   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)




From senger at ebi.ac.uk  Fri Sep  2 13:17:13 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 2 Sep 2005 14:17:13 +0100 (BST)
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <43184B62.5020606@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>

> for a XML Schema I developed using Pollo (see 
> http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).
>
   That's exactly I was hoping in... Good examples.
   Just tell me where the pieces of documentation come from? I guess they
must come from the XSD file itself - is there a "documentation" tag for
it, or what?

   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)



From markw at illuminae.com  Fri Sep  2 15:28:04 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 02 Sep 2005 08:28:04 -0700
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021206390.695974-100000@ice.ebi.ac.uk>
Message-ID: <1125674884.29942.26.camel@bioinfo.icapture.ubc.ca>


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



From markw at illuminae.com  Fri Sep  2 15:41:15 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 02 Sep 2005 08:41:15 -0700
Subject: [moby] Re: [personal] Re: [MOBY-dev] [RFC] Exception Reporting
	in bioMOBYv1.5- INB proposal
In-Reply-To: <43183B8A.2010607@cnb.uam.es>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
	<43183B8A.2010607@cnb.uam.es>
Message-ID: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>

On Fri, 2005-09-02 at 13:46 +0200, David Gonz?lez Pisano wrote:

> Again, let's suppose my Simple needs the name *and* the type and 
> description of the interaction, and that pieces of information are 
> stored in different DB's. What if I can retrieve the name (ie, not an 
> empty simple) but cannot retrieve its type, description, etc... (ie, my 
> object is not empty but cannot be completed...)?

That's a great example, and does make the case quite convincingly...

...but *please* don't use articleName to achieve this!  :-)

M



-- 
"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



From markw at illuminae.com  Fri Sep  2 15:41:15 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Fri, 02 Sep 2005 08:41:15 -0700
Subject: [moby] Re: [personal] Re: [MOBY-dev] [RFC] Exception Reporting
	in bioMOBYv1.5- INB proposal
In-Reply-To: <43183B8A.2010607@cnb.uam.es>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>
	<43183B8A.2010607@cnb.uam.es>
Message-ID: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>

On Fri, 2005-09-02 at 13:46 +0200, David Gonz?lez Pisano wrote:

> Again, let's suppose my Simple needs the name *and* the type and 
> description of the interaction, and that pieces of information are 
> stored in different DB's. What if I can retrieve the name (ie, not an 
> empty simple) but cannot retrieve its type, description, etc... (ie, my 
> object is not empty but cannot be completed...)?

That's a great example, and does make the case quite convincingly...

...but *please* don't use articleName to achieve this!  :-)

M



-- 
"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



From dgpisano at cnb.uam.es  Fri Sep  2 10:32:04 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri, 02 Sep 2005 12:32:04 +0200
Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.7 - INBproposal
In-Reply-To: <Pine.OSF.4.21.0508310222530.1148966-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0508310222530.1148966-100000@mozart.ebi.ac.uk>
Message-ID: <43182A24.1030800@cnb.uam.es>

Martin Senger escribi?:

>Thanks for the updated document. Before I express my comments to it
>here is a few bits regarding RFC procedure for this proposal (assuming
>that we agreed on an RFC procedure as, or close to, suggested in
>previous emails:
>
>1) I second the proposal (so it can become an RFC) 
>
Thanks. Let's move this quickly and go over the asynchony one ;-)

>2) I suggest to resolve it (accept or refuse) before September 15 (so
>this is an RFC calendar). Concretely, I propose that Mark will ask
>selected voters after this date to vote on it. (BTW, I like and
>support his idea to have a year-long tenure on the voting list (that's
>actually very close why OMG has its Architecture Board also with
>rotating, and *dedicated*, people).
>
>Now back to the proposal, here are my comments (I suggest that those
>comments that are acceptable by the INB authors, and that are not in
>contradiction with the email discussion, will be incorporate and a new
>draft will be circulated - perhaps already without reasoning).  
>
Here you have the new draft (version 1.7, version 1.6 was internal review)

>Generally, I like the proposal, my comments are only about details.
>
>1) The attribute names 'Value' and 'Description' are not
>intuitive. They should express more what they are about. What about
>"errorCode" (or only "code") and "errorMessage" (or only "message")? 
>
Changed to "exceptionCode" and "exceptionMessage" so we refer to all 
exceptions (errors, warnings and other information messages). 
"errorCode" sounds to me like "only for errors"...

>2) I know that the article name in Simples in Collection is an
>optional part of the proposal - but I agree with Mark that using there
>again the term "articleName" is bad (too overloaded). What about to
>use there a completely different tag, like "elementId"?
>
>>From this change (if accepted) follows at once that the attribute name
>in mobyException should not be "refArticleName" (because sometimes it
>refers to a non-article name) - so why not to call it just a "ref", or
>"refElement"?
>  
>
Let's name it refElement and keep on mentioning the optional part if 
Mark agrees that naming Simples inside Collections could be possible. 
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"?

>3) I would like to have (in the exception API handling) a remark that
>the clients are obliged to be aware that a service can also raise an
>exception that will be delivered in the SOAP envelope (that is a
>standard way). As I said, good clients have to do it anyway (because
>your service does not have always full control what to return back) -
>so I would keep this option there.
>  
>
Is mentioned in the last part of the document, but there is nothing we 
propose about the structure and content of the SOAP Fail payload... 
Should that be discussed, or better we focus on the MOBY part and just 
mention that the clients should be aware that some exceptions could be 
in the SOAP layers (ie, write your SOAP exception handling code in your 
client for better exception catching in all the layers of the 
communication)?

>4) Just to keep in synch with other software projects, I would add one
>more severity level - a simple "message" (so we would have, errors,
>warnings, messages).
>  
>
That would be, for example:

a. Exception severity (*severity* attribute in *mobyException* tag)
Values: *error*  | *warning *|* information*

>5) The list of codes is not always clear:
>   - should the sub-phrases in 201 be distinguish by a separate code?
>   - 621 (service not available) means actually that the resources the
>service wishes to use are not available (because if it was a service
>itself, it would not have any chance to report it, that would be a
>soap exception mentioned above),
>   - 622 (malformed Moby response) - what is a response here? - and
>anyway, this may be difficult to catch (I know in SOAP::Lite you do
>not get control only when the whole XML is parsed)
>   - why do you call some codes "client-side detected errors"?
>
>   - generally, I would put less codes and rather to define how
>service providers can expressed their own service-specific codes (by
>saying in which range they should put such specific codes)
>  
>
Rewritten the errors part. The main objetive, in our opinion, is to list 
the common errors that could occur in the execution of a web service 
(list taken from LSAE) _and_ the errors common to all bioMOBY services 
(as extension to LSAE). Only the errors that are particular to specific 
services are should not be included. We are using the recommendations in 
LSAE to extend the error codes range.

Note that there are a number of errors (service not available, for 
example) that only the client can report. We can call them client-side 
detected errors and give some codes, or just skip them, reduce to scope 
of this proposal only to the bioMOBY errors reportable by the services, 
and give the clients the freedom to report client-side detected errors 
as they want.

>6) Some typos:
>   - articlename attribute should be articleName
>   - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is
>something else in Biomoby API)
>  
>
Changed that

>7) Attributes in mobyException (refArticleName, or whatever name we
>will agree on, and reqQuery) should be made optional - so an exception
>can refer to the whole response (or to a whole query if only reqQuery
>is present).
>  
>
I agree, that allows us to report an exception for the whole mobyContent 
(it was in the motivations but no clearly stated in the specification 
proposal). Already added.

>   With regards,
>   Martin
>  
>
Thanks for the comments and corrections,

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v1.7.doc
Type: application/msword
Size: 187392 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050902/938c216c/attachment.doc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050902/938c216c/attachment.vcf>

From carrere at toulouse.inra.fr  Fri Sep  2 18:28:57 2005
From: carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Fri, 02 Sep 2005 20:28:57 +0200
Subject: [MOBY-dev] Server maintenance: services unreachable
	bioinfo.genopole-toulouse.prd.fr
In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0509021156520.695974-100000@ice.ebi.ac.uk>	<43183B8A.2010607@cnb.uam.es>
	<1125675675.29942.36.camel@bioinfo.icapture.ubc.ca>
Message-ID: <431899E9.3060403@toulouse.inra.fr>

Due to maintenance on our server (inverter change), services provided by 
*bioinfo.genopole-toulouse.prd*.fr will be unreachable next *Tuesday 
(September 6th)* during  5 hours (10 a.m. to 3 p.m. GMT+1).

Sebastien Carrere

-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.18/87 - Release Date: 01/09/2005

From senger at ebi.ac.uk  Sat Sep  3 03:03:03 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sat, 3 Sep 2005 04:03:03 +0100 (BST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <1125674884.29942.26.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>

> 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)



From senger at ebi.ac.uk  Sun Sep  4 14:45:31 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun, 4 Sep 2005 15:45:31 +0100 (BST)
Subject: [MOBY-dev] jMoby: third-parties libraries update
Message-ID: <Pine.OSF.4.21.0509041542170.1093336-100000@mozart.ebi.ac.uk>

I have update Axis libraries to its latest version. Also alltools2 were
rebuilt considerably (and alltools.jar removed). Therefore, please start
your next session with jMoby by:
   ./build.sh
which should update your lib directory. After that do:
   ./build-dev.sh clean compile

I tried to test it as much as I was able... If you still find a problem
please report it and I will fix it asap.

   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)



From jmfernandez at cnb.uam.es  Mon Sep  5 15:26:09 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 05 Sep 2005 17:26:09 +0200
Subject: [MOBY-dev] Martin's comments on the MOBY API docs
In-Reply-To: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509021415350.695974-100000@ice.ebi.ac.uk>
Message-ID: <431C6391.5080708@cnb.uam.es>



Martin Senger wrote:
>>for a XML Schema I developed using Pollo (see 
>>http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML-ORIEL.html).
>>
> 
>    That's exactly I was hoping in... Good examples.
>    Just tell me where the pieces of documentation come from? I guess they
> must come from the XSD file itself - is there a "documentation" tag for
> it, or what?

Yes, it is. XML Schema allows you to create a xsd:annotation inside 
almost any XML Schema tag (attribute and element declarations, keys, 
etc...), and inside xsd:annotation you can add one or more 
xsd:documentation tags. If you look inside 
http://www.pdg.cnb.uam.es/ORIEL/iHOP-XML.xsd, you will see the 
xsd:documentation tag.

David uses XMLSpy and he has told me that XMLSpy documentation is 
translated to xsd:documentation tags when a XML Schema is generated.

	Best Regards,
		Jos? Mar?a

> 
>    Martin
> 

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)


From jmfernandez at cnb.uam.es  Mon Sep  5 20:28:17 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 05 Sep 2005 22:28:17 +0200
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509030341220.871956-100000@ice.ebi.ac.uk>
Message-ID: <431CAA61.8030009@cnb.uam.es>

Hi everybody,
	there is a fourth option, where it is not mandatory to have an article 
name for primary inputs: primary inputs must be submitted in the same 
order as they were declared at service registration, and they are 
expected to arrive so to the service. Even it could happen that no 
primary input had an article name!

	But there is a drawback: service coding should be more coupled to 
service declaration in order to take into account the input parameters 
order, so this option is more error-prone.

	Best Regards,
		Jos? Mar?a

Martin Senger wrote:
>>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
> 

-- 
Jos? Mar?a Fern?ndez Gonz?lez		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Dise?o de Proteinas		Protein Design Group
Centro Nacional de Biotecnolog?a	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)


From rroyo at lsi.upc.edu  Tue Sep  6 06:43:10 2005
From: rroyo at lsi.upc.edu (rroyo at lsi.upc.edu)
Date: Tue, 6 Sep 2005 08:43:10 +0200 (MET DST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
Message-ID: <9177548284rroyo@lsi.upc.es>

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
-----------------------------------------------------







From rroyo at lsi.upc.edu  Tue Sep  6 06:43:10 2005
From: rroyo at lsi.upc.edu (rroyo at lsi.upc.edu)
Date: Tue, 6 Sep 2005 08:43:10 +0200 (MET DST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
Message-ID: <9177548284rroyo@lsi.upc.es>

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
-----------------------------------------------------







From senger at ebi.ac.uk  Tue Sep  6 07:24:47 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 6 Sep 2005 08:24:47 +0100 (BST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <9177548284rroyo@lsi.upc.es>
Message-ID: <Pine.OSF.4.21.0509060822110.1434283-100000@mozart.ebi.ac.uk>

> 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?
>
   I said that the option 3 applies only for services with single input
and single output. In your example, the article names are mandatory, and
workflow engine *has* to add them if the services should be connected.
   But because the case with one-one services is the most often, I
considered worth to allow to skip article names.

   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)



From senger at ebi.ac.uk  Tue Sep  6 07:24:47 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 6 Sep 2005 08:24:47 +0100 (BST)
Subject: [MOBY-dev] Re: [personal] problem with article names?
In-Reply-To: <9177548284rroyo@lsi.upc.es>
Message-ID: <Pine.OSF.4.21.0509060822110.1434283-100000@mozart.ebi.ac.uk>

> 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?
>
   I said that the option 3 applies only for services with single input
and single output. In your example, the article names are mandatory, and
workflow engine *has* to add them if the services should be connected.
   But because the case with one-one services is the most often, I
considered worth to allow to skip article names.

   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)



From Pieter.Neerincx at wur.nl  Tue Sep  6 16:30:46 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 6 Sep 2005 18:30:46 +0200
Subject: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <4315524C.6040307@toulouse.inra.fr>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
Message-ID: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>

Hi,

I have some services that query databases. The result can be nothing,  
a single object, or it can be several thousand objects.... I was also  
running into trouble with big XML documents. I'm using the Perl API,  
which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the  
job done for small xml structures, but for big ones it's a mess.  
Firstly, SOAP::Lite loads the entire message in memory as one big  
piece (hence no chunks or streams etc.). Secondly, if you use  
Data::Dumper to have a look at the perl data structures that are  
built, you will see that the same info is copied two, three or more  
times. There's quite a bit of redundancy in there. As a result the  
expansion factor for parsing xml by SOAP::lite is between 10 and 13  
(according to people on the SOAP::Lite mailing list). That means a 10  
MB xml document will become 100-130 MB in memory. Several clients  
accessing several of these services at the same time will simply  
bring our servers on their knees :(. If there are people on the  
mailinglist with experience in handling laaaaaarge inputs and/or  
outputs I'd really appreciate it if you drop a few lines...

So far I have looked at working with attachments. Not really an  
option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy  
combo. xsltproc sounds good. I currently changed my services to send  
only a pointer (URL) as result which the client has to fetch. For a  
quick and dirty workaround it works beautifully, but from a design  
point of view it bad bad bad :( ...

Cheers,

Pi


On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:

> The MOBY message that I wanted to parse was a 12 Megabyte one.
> The web-service concerned is:
>
> name: ImgaGetTigrXMLEntriesFromKeyword
> uri: bioinfo.genopole-toulouse.prd.fr
> input: String
> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of / 
> IMGA_Accession, as IMGA_Accession
>
> I think this is a little bit extreme, but it works fine now.
>
> Sebastien
>
> Chunyan Wang wrote:
>
>
>> Hi,
>> I changed TimeOut from default to 50000 in the Apache config to  
>> fix timeout problem.
>> How big was your XML file when you had problem?
>> Cheers,
>>
>> Joyce
>>
>> Sebastien Carrere wrote:
>>
>>
>>> Hi all,
>>>
>>> I got the same problem when I wanted to parse huge XML files.
>>> That's why I have written a clone of CommonSub.pm using  
>>> "xsltproc" to parse MOBY message.
>>> Then the parsing time problem was removed.
>>>
>>> However, how do you fixed timeout problem ?
>>>
>>> Sebastien
>>>
>>> Chunyan Wang wrote:
>>>
>>>
>>>>
>>>>
>>>> Martin Senger wrote:
>>>>
>>>>
>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   What language are you using, what XML library in that language?
>>>>>
>>>>>
>>>> I am using Perl and XML::DOM. I am using  
>>>> "genericServiceInputParser($data)" to parse the input sequence  
>>>> in my service.
>>>> By the way, I want to let you know I fixed timeout problem.  
>>>> Thanks for your suggestion.
>>>>
>>>> Joyce
>>>>
>>>>
>>>>>   Martin
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>
> -- 
> __________________________________________________________
>
> Sebastien CARRERE                        LIPM (INRA-CNRS)
>                      B.P.52627 -- 31326 CASTANET TOLOSAN
> tel:(33) 5-61-28-53-29
> fax:(33) 5-61-28-50-61
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From markw at illuminae.com  Tue Sep  6 18:05:19 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Tue, 06 Sep 2005 11:05:19 -0700
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca> <4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
Message-ID: <1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>

This is indeed still an issue, and you are right about the pain of using
SOAP::Lite + MIME::Tools in Perl (though I know that is soon going to be
better, since we are now using an apparently stable combination of
these, plus SOAP attachemnts, for our own LSID resolver!  However these
are not available on CPAN yet AFAIK).

I recall that Lincoln S. wrote to Paul K. several years ago asking if it
would ever be possible to swap-out the DOM parser in SOAP::Lite for a
SAX parser in order to overcome this limitation (and also with an eye to
streaming responses...), but I don't think this even made it on to the
SOAP::Lite radar so I doubt that the solution is going to come from that
community anytime soon.

So... I can't advise anything, but perhaps others in the MOBY community
can!

M


On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
> Hi,
> 
> I have some services that query databases. The result can be nothing,  
> a single object, or it can be several thousand objects.... I was also  
> running into trouble with big XML documents. I'm using the Perl API,  
> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the  
> job done for small xml structures, but for big ones it's a mess.  
> Firstly, SOAP::Lite loads the entire message in memory as one big  
> piece (hence no chunks or streams etc.). Secondly, if you use  
> Data::Dumper to have a look at the perl data structures that are  
> built, you will see that the same info is copied two, three or more  
> times. There's quite a bit of redundancy in there. As a result the  
> expansion factor for parsing xml by SOAP::lite is between 10 and 13  
> (according to people on the SOAP::Lite mailing list). That means a 10  
> MB xml document will become 100-130 MB in memory. Several clients  
> accessing several of these services at the same time will simply  
> bring our servers on their knees :(. If there are people on the  
> mailinglist with experience in handling laaaaaarge inputs and/or  
> outputs I'd really appreciate it if you drop a few lines...
> 
> So far I have looked at working with attachments. Not really an  
> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy  
> combo. xsltproc sounds good. I currently changed my services to send  
> only a pointer (URL) as result which the client has to fetch. For a  
> quick and dirty workaround it works beautifully, but from a design  
> point of view it bad bad bad :( ...
> 
> Cheers,
> 
> Pi
> 
> 
> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
> 
> > The MOBY message that I wanted to parse was a 12 Megabyte one.
> > The web-service concerned is:
> >
> > name: ImgaGetTigrXMLEntriesFromKeyword
> > uri: bioinfo.genopole-toulouse.prd.fr
> > input: String
> > Output(s): /Collection of /text-xml, as TIGRXML and /Collection of / 
> > IMGA_Accession, as IMGA_Accession
> >
> > I think this is a little bit extreme, but it works fine now.
> >
> > Sebastien
> >
> > Chunyan Wang wrote:
> >
> >
> >> Hi,
> >> I changed TimeOut from default to 50000 in the Apache config to  
> >> fix timeout problem.
> >> How big was your XML file when you had problem?
> >> Cheers,
> >>
> >> Joyce
> >>
> >> Sebastien Carrere wrote:
> >>
> >>
> >>> Hi all,
> >>>
> >>> I got the same problem when I wanted to parse huge XML files.
> >>> That's why I have written a clone of CommonSub.pm using  
> >>> "xsltproc" to parse MOBY message.
> >>> Then the parsing time problem was removed.
> >>>
> >>> However, how do you fixed timeout problem ?
> >>>
> >>> Sebastien
> >>>
> >>> Chunyan Wang wrote:
> >>>
> >>>
> >>>>
> >>>>
> >>>> Martin Senger wrote:
> >>>>
> >>>>
> >>>>>> Could anybody explain this "problem" to me? Thanks.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>   What language are you using, what XML library in that language?
> >>>>>
> >>>>>
> >>>> I am using Perl and XML::DOM. I am using  
> >>>> "genericServiceInputParser($data)" to parse the input sequence  
> >>>> in my service.
> >>>> By the way, I want to let you know I fixed timeout problem.  
> >>>> Thanks for your suggestion.
> >>>>
> >>>> Joyce
> >>>>
> >>>>
> >>>>>   Martin
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev at biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >>
> >>
> >
> > -- 
> > __________________________________________________________
> >
> > Sebastien CARRERE                        LIPM (INRA-CNRS)
> >                      B.P.52627 -- 31326 CASTANET TOLOSAN
> > tel:(33) 5-61-28-53-29
> > fax:(33) 5-61-28-50-61
> >
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
"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



From senger at ebi.ac.uk  Tue Sep  6 23:40:59 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 7 Sep 2005 00:40:59 +0100 (BST)
Subject: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
Message-ID: <Pine.OSF.4.21.0509070038370.1284933-100000@mozart.ebi.ac.uk>

Although I am a Perl programmer I am not a Perl-service provider so my
SOAP::Lite vs. XML parses experiences are limited, but I recall that some
parsing problems (not all) may be overcome by sending data as byte arrays,
not strings (and Biomoby API dictates that both clients and servers
must be ready to accept both such formats). Have you tried that?

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)



From Pieter.Neerincx at wur.nl  Wed Sep  7 11:12:56 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 7 Sep 2005 13:12:56 +0200
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
Message-ID: <84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>


On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:

> This is indeed still an issue, and you are right about the pain of  
> using
> SOAP::Lite + MIME::Tools in Perl (though I know that is soon going  
> to be
> better, since we are now using an apparently stable combination of
> these, plus SOAP attachemnts, for our own LSID resolver!  However  
> these
> are not available on CPAN yet AFAIK).

Ok, so there is a combination that really works :). Could you please  
tell me which version of SOAP::Lite and MIME::Tools you are mixing to  
make SOAP with attachments work?


>
> I recall that Lincoln S. wrote to Paul K. several years ago asking  
> if it
> would ever be possible to swap-out the DOM parser in SOAP::Lite for a
> SAX parser in order to overcome this limitation (and also with an  
> eye to
> streaming responses...), but I don't think this even made it on to the
> SOAP::Lite radar so I doubt that the solution is going to come from  
> that
> community anytime soon.

I doubt that as well. If I find some solution to streaming the SOAP  
XML I'll post it to the list...

Thanks,

Pieter

>
> So... I can't advise anything, but perhaps others in the MOBY  
> community
> can!
>
> M
>
>
> On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
>
>> Hi,
>>
>> I have some services that query databases. The result can be nothing,
>> a single object, or it can be several thousand objects.... I was also
>> running into trouble with big XML documents. I'm using the Perl API,
>> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
>> job done for small xml structures, but for big ones it's a mess.
>> Firstly, SOAP::Lite loads the entire message in memory as one big
>> piece (hence no chunks or streams etc.). Secondly, if you use
>> Data::Dumper to have a look at the perl data structures that are
>> built, you will see that the same info is copied two, three or more
>> times. There's quite a bit of redundancy in there. As a result the
>> expansion factor for parsing xml by SOAP::lite is between 10 and 13
>> (according to people on the SOAP::Lite mailing list). That means a 10
>> MB xml document will become 100-130 MB in memory. Several clients
>> accessing several of these services at the same time will simply
>> bring our servers on their knees :(. If there are people on the
>> mailinglist with experience in handling laaaaaarge inputs and/or
>> outputs I'd really appreciate it if you drop a few lines...
>>
>> So far I have looked at working with attachments. Not really an
>> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
>> combo. xsltproc sounds good. I currently changed my services to send
>> only a pointer (URL) as result which the client has to fetch. For a
>> quick and dirty workaround it works beautifully, but from a design
>> point of view it bad bad bad :( ...
>>
>> Cheers,
>>
>> Pi
>>
>>
>> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
>>
>>
>>> The MOBY message that I wanted to parse was a 12 Megabyte one.
>>> The web-service concerned is:
>>>
>>> name: ImgaGetTigrXMLEntriesFromKeyword
>>> uri: bioinfo.genopole-toulouse.prd.fr
>>> input: String
>>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /
>>> IMGA_Accession, as IMGA_Accession
>>>
>>> I think this is a little bit extreme, but it works fine now.
>>>
>>> Sebastien
>>>
>>> Chunyan Wang wrote:
>>>
>>>
>>>
>>>> Hi,
>>>> I changed TimeOut from default to 50000 in the Apache config to
>>>> fix timeout problem.
>>>> How big was your XML file when you had problem?
>>>> Cheers,
>>>>
>>>> Joyce
>>>>
>>>> Sebastien Carrere wrote:
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I got the same problem when I wanted to parse huge XML files.
>>>>> That's why I have written a clone of CommonSub.pm using
>>>>> "xsltproc" to parse MOBY message.
>>>>> Then the parsing time problem was removed.
>>>>>
>>>>> However, how do you fixed timeout problem ?
>>>>>
>>>>> Sebastien
>>>>>
>>>>> Chunyan Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Martin Senger wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   What language are you using, what XML library in that  
>>>>>>> language?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I am using Perl and XML::DOM. I am using
>>>>>> "genericServiceInputParser($data)" to parse the input sequence
>>>>>> in my service.
>>>>>> By the way, I want to let you know I fixed timeout problem.
>>>>>> Thanks for your suggestion.
>>>>>>
>>>>>> Joyce
>>>>>>
>>>>>>
>>>>>>
>>>>>>>   Martin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> __________________________________________________________
>>>
>>> Sebastien CARRERE                        LIPM (INRA-CNRS)
>>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
>>> tel:(33) 5-61-28-53-29
>>> fax:(33) 5-61-28-50-61
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> -- 
> "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
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From markw at illuminae.com  Wed Sep  7 16:39:59 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 07 Sep 2005 09:39:59 -0700
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca> <4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
	<84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
Message-ID: <1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>

SOAP::Lite
$Id: Lite.pm,v 1.11 2003/08/11 05:54:51 paulclinger Exp $

MIME::Tools
$VERSION = "5.417";


M


On Wed, 2005-09-07 at 13:12 +0200, Pieter Neerincx wrote:
> On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:
> 
> > This is indeed still an issue, and you are right about the pain of  
> > using
> > SOAP::Lite + MIME::Tools in Perl (though I know that is soon going  
> > to be
> > better, since we are now using an apparently stable combination of
> > these, plus SOAP attachemnts, for our own LSID resolver!  However  
> > these
> > are not available on CPAN yet AFAIK).
> 
> Ok, so there is a combination that really works :). Could you please  
> tell me which version of SOAP::Lite and MIME::Tools you are mixing to  
> make SOAP with attachments work?
> 
> 
> >
> > I recall that Lincoln S. wrote to Paul K. several years ago asking  
> > if it
> > would ever be possible to swap-out the DOM parser in SOAP::Lite for a
> > SAX parser in order to overcome this limitation (and also with an  
> > eye to
> > streaming responses...), but I don't think this even made it on to the
> > SOAP::Lite radar so I doubt that the solution is going to come from  
> > that
> > community anytime soon.
> 
> I doubt that as well. If I find some solution to streaming the SOAP  
> XML I'll post it to the list...
> 
> Thanks,
> 
> Pieter
> 
> >
> > So... I can't advise anything, but perhaps others in the MOBY  
> > community
> > can!
> >
> > M
> >
> >
> > On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
> >
> >> Hi,
> >>
> >> I have some services that query databases. The result can be nothing,
> >> a single object, or it can be several thousand objects.... I was also
> >> running into trouble with big XML documents. I'm using the Perl API,
> >> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
> >> job done for small xml structures, but for big ones it's a mess.
> >> Firstly, SOAP::Lite loads the entire message in memory as one big
> >> piece (hence no chunks or streams etc.). Secondly, if you use
> >> Data::Dumper to have a look at the perl data structures that are
> >> built, you will see that the same info is copied two, three or more
> >> times. There's quite a bit of redundancy in there. As a result the
> >> expansion factor for parsing xml by SOAP::lite is between 10 and 13
> >> (according to people on the SOAP::Lite mailing list). That means a 10
> >> MB xml document will become 100-130 MB in memory. Several clients
> >> accessing several of these services at the same time will simply
> >> bring our servers on their knees :(. If there are people on the
> >> mailinglist with experience in handling laaaaaarge inputs and/or
> >> outputs I'd really appreciate it if you drop a few lines...
> >>
> >> So far I have looked at working with attachments. Not really an
> >> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
> >> combo. xsltproc sounds good. I currently changed my services to send
> >> only a pointer (URL) as result which the client has to fetch. For a
> >> quick and dirty workaround it works beautifully, but from a design
> >> point of view it bad bad bad :( ...
> >>
> >> Cheers,
> >>
> >> Pi
> >>
> >>
> >> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
> >>
> >>
> >>> The MOBY message that I wanted to parse was a 12 Megabyte one.
> >>> The web-service concerned is:
> >>>
> >>> name: ImgaGetTigrXMLEntriesFromKeyword
> >>> uri: bioinfo.genopole-toulouse.prd.fr
> >>> input: String
> >>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /
> >>> IMGA_Accession, as IMGA_Accession
> >>>
> >>> I think this is a little bit extreme, but it works fine now.
> >>>
> >>> Sebastien
> >>>
> >>> Chunyan Wang wrote:
> >>>
> >>>
> >>>
> >>>> Hi,
> >>>> I changed TimeOut from default to 50000 in the Apache config to
> >>>> fix timeout problem.
> >>>> How big was your XML file when you had problem?
> >>>> Cheers,
> >>>>
> >>>> Joyce
> >>>>
> >>>> Sebastien Carrere wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I got the same problem when I wanted to parse huge XML files.
> >>>>> That's why I have written a clone of CommonSub.pm using
> >>>>> "xsltproc" to parse MOBY message.
> >>>>> Then the parsing time problem was removed.
> >>>>>
> >>>>> However, how do you fixed timeout problem ?
> >>>>>
> >>>>> Sebastien
> >>>>>
> >>>>> Chunyan Wang wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Martin Senger wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> Could anybody explain this "problem" to me? Thanks.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>   What language are you using, what XML library in that  
> >>>>>>> language?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> I am using Perl and XML::DOM. I am using
> >>>>>> "genericServiceInputParser($data)" to parse the input sequence
> >>>>>> in my service.
> >>>>>> By the way, I want to let you know I fixed timeout problem.
> >>>>>> Thanks for your suggestion.
> >>>>>>
> >>>>>> Joyce
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>   Martin
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MOBY-dev mailing list
> >>>>>> MOBY-dev at biomoby.org
> >>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev at biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> -- 
> >>> __________________________________________________________
> >>>
> >>> Sebastien CARRERE                        LIPM (INRA-CNRS)
> >>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
> >>> tel:(33) 5-61-28-53-29
> >>> fax:(33) 5-61-28-50-61
> >>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev at biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx at wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> > -- 
> > "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
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
"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



From carrere at toulouse.inra.fr  Thu Sep  8 14:49:16 2005
From: carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Thu, 08 Sep 2005 16:49:16 +0200
Subject: [moby] Re: [MOBY-dev] Question on parser
In-Reply-To: <1125414060.19194.26.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>	<431365E1.7080800@cpsc.ucalgary.ca>
	<4313FE70.80308@toulouse.inra.fr>
	<1125414060.19194.26.camel@bioinfo.icapture.ubc.ca>
Message-ID: <43204F6C.1040409@toulouse.inra.fr>

I added the Perl Module (i) we develloped in Toulouse and the mandatory 
XSLT style-sheet (ii) in the CVS repository.

i.  moby-live/Perl/MOBY/MOBYXSLT.pm
ii. moby-live/Perl/MOBY/xsl/parseMobyMessage.xsl

If you want more information (services examples using this module), do 
not hesitate.

Sebastien




Mark Wilkinson wrote:

>On Tue, 2005-08-30 at 08:36 +0200, Sebastien Carrere wrote:
>
>  
>
>>That's why I have written a clone of CommonSub.pm using "xsltproc" to 
>>parse MOBY message.
>>    
>>
>
>Would you be willing to add this to the CVS?
>
>
>  
>
>>However, how do you fixed timeout problem ?
>>    
>>
>
>In the 1.0 release we should have a spec for asynchronous services, so
>this problem will hopefully not be as severe...
>
>M
>
>
>  
>

-- 
__________________________________________________________

Sebastien CARRERE                        LIPM (INRA-CNRS)
                      B.P.52627 -- 31326 CASTANET TOLOSAN
tel:(33) 5-61-28-53-29
fax:(33) 5-61-28-50-61
				



From Pieter.Neerincx at wur.nl  Mon Sep 12 14:56:13 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 12 Sep 2005 16:56:13 +0200
Subject: [moby] Re: [MOBY-dev] Question on parser -> Big XML documents
In-Reply-To: <1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>
References: <Pine.OSF.4.21.0508291849220.999093-100000@ice.ebi.ac.uk>
	<431365E1.7080800@cpsc.ucalgary.ca>	<4313FE70.80308@toulouse.inra.fr>
	<431486B4.6060700@cpsc.ucalgary.ca>
	<4315524C.6040307@toulouse.inra.fr>
	<1F0B9A14-BF8F-4C4A-A244-780D6BEF2FA7@wur.nl>
	<1126029919.30821.25.camel@bioinfo.icapture.ubc.ca>
	<84C46D21-1382-4DCC-97D5-75BA114C38C3@wur.nl>
	<1126111199.32349.43.camel@bioinfo.icapture.ubc.ca>
Message-ID: <A66B84DF-2937-4334-B42C-6158A9832B11@wur.nl>

On 7-Sep-2005, at 6:39 PM, Mark Wilkinson wrote:

> SOAP::Lite
> $Id: Lite.pm,v 1.11 2003/08/11 05:54:51 paulclinger Exp $
>
> MIME::Tools
> $VERSION = "5.417";

Did you apply any custom patches? Or are those simply the defaults?

Pi

>
> M
>
>
> On Wed, 2005-09-07 at 13:12 +0200, Pieter Neerincx wrote:
>
>> On 6-Sep-2005, at 8:05 PM, Mark Wilkinson wrote:
>>
>>
>>> This is indeed still an issue, and you are right about the pain of
>>> using
>>> SOAP::Lite + MIME::Tools in Perl (though I know that is soon going
>>> to be
>>> better, since we are now using an apparently stable combination of
>>> these, plus SOAP attachemnts, for our own LSID resolver!  However
>>> these
>>> are not available on CPAN yet AFAIK).
>>>
>>
>> Ok, so there is a combination that really works :). Could you please
>> tell me which version of SOAP::Lite and MIME::Tools you are mixing to
>> make SOAP with attachments work?
>>
>>
>>
>>>
>>> I recall that Lincoln S. wrote to Paul K. several years ago asking
>>> if it
>>> would ever be possible to swap-out the DOM parser in SOAP::Lite  
>>> for a
>>> SAX parser in order to overcome this limitation (and also with an
>>> eye to
>>> streaming responses...), but I don't think this even made it on  
>>> to the
>>> SOAP::Lite radar so I doubt that the solution is going to come from
>>> that
>>> community anytime soon.
>>>
>>
>> I doubt that as well. If I find some solution to streaming the SOAP
>> XML I'll post it to the list...
>>
>> Thanks,
>>
>> Pieter
>>
>>
>>>
>>> So... I can't advise anything, but perhaps others in the MOBY
>>> community
>>> can!
>>>
>>> M
>>>
>>>
>>> On Tue, 2005-09-06 at 18:30 +0200, Pieter Neerincx wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I have some services that query databases. The result can be  
>>>> nothing,
>>>> a single object, or it can be several thousand objects.... I was  
>>>> also
>>>> running into trouble with big XML documents. I'm using the Perl  
>>>> API,
>>>> which uses SOAP::Lite, which uses XML::LibXML. SOAP::Lite gets the
>>>> job done for small xml structures, but for big ones it's a mess.
>>>> Firstly, SOAP::Lite loads the entire message in memory as one big
>>>> piece (hence no chunks or streams etc.). Secondly, if you use
>>>> Data::Dumper to have a look at the perl data structures that are
>>>> built, you will see that the same info is copied two, three or more
>>>> times. There's quite a bit of redundancy in there. As a result the
>>>> expansion factor for parsing xml by SOAP::lite is between 10 and 13
>>>> (according to people on the SOAP::Lite mailing list). That means  
>>>> a 10
>>>> MB xml document will become 100-130 MB in memory. Several clients
>>>> accessing several of these services at the same time will simply
>>>> bring our servers on their knees :(. If there are people on the
>>>> mailinglist with experience in handling laaaaaarge inputs and/or
>>>> outputs I'd really appreciate it if you drop a few lines...
>>>>
>>>> So far I have looked at working with attachments. Not really an
>>>> option with Perl. Combining SOAP::Lite with MIME::Tools is a buggy
>>>> combo. xsltproc sounds good. I currently changed my services to  
>>>> send
>>>> only a pointer (URL) as result which the client has to fetch. For a
>>>> quick and dirty workaround it works beautifully, but from a design
>>>> point of view it bad bad bad :( ...
>>>>
>>>> Cheers,
>>>>
>>>> Pi
>>>>
>>>>
>>>> On 31-Aug-2005, at 8:46 AM, Sebastien Carrere wrote:
>>>>
>>>>
>>>>
>>>>> The MOBY message that I wanted to parse was a 12 Megabyte one.
>>>>> The web-service concerned is:
>>>>>
>>>>> name: ImgaGetTigrXMLEntriesFromKeyword
>>>>> uri: bioinfo.genopole-toulouse.prd.fr
>>>>> input: String
>>>>> Output(s): /Collection of /text-xml, as TIGRXML and /Collection  
>>>>> of /
>>>>> IMGA_Accession, as IMGA_Accession
>>>>>
>>>>> I think this is a little bit extreme, but it works fine now.
>>>>>
>>>>> Sebastien
>>>>>
>>>>> Chunyan Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>> I changed TimeOut from default to 50000 in the Apache config to
>>>>>> fix timeout problem.
>>>>>> How big was your XML file when you had problem?
>>>>>> Cheers,
>>>>>>
>>>>>> Joyce
>>>>>>
>>>>>> Sebastien Carrere wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I got the same problem when I wanted to parse huge XML files.
>>>>>>> That's why I have written a clone of CommonSub.pm using
>>>>>>> "xsltproc" to parse MOBY message.
>>>>>>> Then the parsing time problem was removed.
>>>>>>>
>>>>>>> However, how do you fixed timeout problem ?
>>>>>>>
>>>>>>> Sebastien
>>>>>>>
>>>>>>> Chunyan Wang wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Martin Senger wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Could anybody explain this "problem" to me? Thanks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   What language are you using, what XML library in that
>>>>>>>>> language?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I am using Perl and XML::DOM. I am using
>>>>>>>> "genericServiceInputParser($data)" to parse the input sequence
>>>>>>>> in my service.
>>>>>>>> By the way, I want to let you know I fixed timeout problem.
>>>>>>>> Thanks for your suggestion.
>>>>>>>>
>>>>>>>> Joyce
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>   Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MOBY-dev mailing list
>>>>>>>> MOBY-dev at biomoby.org
>>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> __________________________________________________________
>>>>>
>>>>> Sebastien CARRERE                        LIPM (INRA-CNRS)
>>>>>                      B.P.52627 -- 31326 CASTANET TOLOSAN
>>>>> tel:(33) 5-61-28-53-29
>>>>> fax:(33) 5-61-28-50-61
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>> -- 
>>> "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
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> -- 
> "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
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From Pieter.Neerincx at wur.nl  Mon Sep 12 15:05:51 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 12 Sep 2005 17:05:51 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
Message-ID: <B35BC13D-D39B-4A67-B009-C91D31B53BDA@wur.nl>

Hi all,

I'm having some trouble to make BioMOBY work with Taverna. I have a  
local development Moby central. When I register both new services and  
new objects I notice that only my custom services are listed in  
Taverna. The list of moby objects is not in sync with what is  
registered in my central. So where does Taverna get those objects  
from and how do I get my own objects in there? Does anyone have a clue?

Cheers,

Pieter

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Mon Sep 12 15:10:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 12 Sep 2005 08:10:52 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <B35BC13D-D39B-4A67-B009-C91D31B53BDA@wur.nl>
Message-ID: <43259a80.30867065.1135.ffff8504@mx.gmail.com>

Hi,

The answer basically is that you also need to set up some
servlets (RESOURCES script, types, etc), if you have a
custom registry.

So Taverna is basically reading in your services, and cannot
find the objects, so it probably defaults to the Mobycentral
registry.

Eddie 

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 12, 2005 8:06 AM
> To: Core developer announcements
> Subject: [MOBY-dev] Moby objects in Taverna. Where do they
> come from?
> 
> Hi all,
> 
> I'm having some trouble to make BioMOBY work with Taverna.
> I have a
> local development Moby central. When I register both new
> services and
> new objects I notice that only my custom services are
> listed in
> Taverna. The list of moby objects is not in sync with what
> is
> registered in my central. So where does Taverna get those
> objects
> from and how do I get my own objects in there? Does anyone
> have a clue?
> 
> Cheers,
> 
> Pieter
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From senger at ebi.ac.uk  Tue Sep 13 01:30:38 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 02:30:38 +0100 (BST)
Subject: [MOBY-dev] jMOBY DOES NOT COMPILE (again!)
Message-ID: <Pine.OSF.4.21.0509130225110.887285-100000@ice.ebi.ac.uk>

Eddie,
   I am sorry for the upper-case letters but it is really important to
realize that if someone (I suspect you in this case) commits changes
without checking that the whole jMoby is compilable that it may have a bad
impact of the other users. At the moment, I am in the middle of the
Biomoby course (in Japan) and jMoby does not compile. Plenty of errors
from the RDF agent 'test' package.
   I apologize if the problem was caused by someone else - and I am
calling Eddie - but in the past it was usually Eddie :-) (Unless it was
me, of course, that would be a real embarassment.)

   So please fix the problem asap. I will have to remove the offending
classes from the repository if it continues to break the compilation.

   Thanks and with regards,
   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)



From senger at ebi.ac.uk  Tue Sep 13 03:48:07 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 04:48:07 +0100 (BST)
Subject: [MOBY-dev] RE: jMOBY DOES NOT COMPILE (again!)
In-Reply-To: <432649ea.64d22026.0f99.5d5f@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509130446380.887285-100000@ice.ebi.ac.uk>

> When I made my changes, I did a ./build.bat clean compile
> and everything was fine.
>
   So perhaps you have some other, not-included, librraies on your
classpath.

> What messages are you getting?
>

    [javac] Found 55 semantic errors compiling
"/net/nfs7/vol4/industry/senger/moby-live/Java/src/main/org/biomoby/registry/rdfagent/test/RDFAgentTestSuite.java":

    [javac]    328.     public void performTest1() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type
"org.biomoby.registry.rdfagent.test.TestException" was not found.


    [javac]    357.     public void performTest2() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    375.     public void performTest3() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    393.     public void performTest4() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.


    [javac]    411.     public void performTest5() throws TestException {
    [javac]                                               ^-----------^
    [javac] *** Semantic Error: Type "TestException" was not found.

   ... etc.

   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)



From edward.kawas at gmail.com  Tue Sep 13 03:39:17 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 12 Sep 2005 20:39:17 -0700
Subject: [MOBY-dev] RE: jMOBY DOES NOT COMPILE (again!)
In-Reply-To: <Pine.OSF.4.21.0509130225110.887285-100000@ice.ebi.ac.uk>
Message-ID: <432649ea.64d22026.0f99.5d5f@mx.gmail.com>

When I made my changes, I did a ./build.bat clean compile
and everything was fine. What messages are you getting?


Eddie

> -----Original Message-----
> From: Martin Senger [mailto:senger at ebi.ac.uk]
> Sent: Monday, September 12, 2005 6:31 PM
> To: Edward Kawas
> Cc: Moby Developers
> Subject: jMOBY DOES NOT COMPILE (again!)
> 
> Eddie,
>    I am sorry for the upper-case letters but it is really
> important to
> realize that if someone (I suspect you in this case)
> commits changes
> without checking that the whole jMoby is compilable that
> it may have a bad
> impact of the other users. At the moment, I am in the
> middle of the
> Biomoby course (in Japan) and jMoby does not compile.
> Plenty of errors
> from the RDF agent 'test' package.
>    I apologize if the problem was caused by someone else -
> and I am
> calling Eddie - but in the past it was usually Eddie :-)
> (Unless it was
> me, of course, that would be a real embarassment.)
> 
>    So please fix the problem asap. I will have to remove
> the offending
> classes from the repository if it continues to break the
> compilation.
> 
>    Thanks and with regards,
>    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)



From senger at ebi.ac.uk  Tue Sep 13 07:56:14 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 08:56:14 +0100 (BST)
Subject: [MOBY-dev] jMoby small update & a windows question
Message-ID: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>

I have updated library alltools2.jar - so please when you use jMoby next
time start with: ./build.sh (or ./build.bat).

I wonder if people familiar with windows can answer my question about
windows scripts:

The script is build/run/run-cmdline-client.bat (but the same applies to
all other .bat scripts there). It does not work if your PROJECT_HOME is a
directory with whitespaces, like
   C:\Document and Settings\martin\Desktop\jMoby

I have already added there a lot of double quotes - so it "almost" works
now, but not yet. The problem is the line:

for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i

where I do not know how to put quotes arround the first %PROJECT_HOME%. If
I quote is, the '*.jar' part does not seem to expand as expected.

I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
then I can remove the %PROJECT_HOME% from all other places. But I still
wonder how I should write it without this workaround. Does anybody know
how to do it?

Thanks,
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)



From Pieter.Neerincx at wur.nl  Tue Sep 13 08:34:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 13 Sep 2005 10:34:42 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <43259a80.30867065.1135.ffff8504@mx.gmail.com>
References: <43259a80.30867065.1135.ffff8504@mx.gmail.com>
Message-ID: <A7015A51-2FAA-417D-95C7-E2AF2630F540@wur.nl>

Hi Eddie,

On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:

> Hi,
>
> The answer basically is that you also need to set up some
> servlets (RESOURCES script, types, etc), if you have a
> custom registry.

Thanks for the quick feedback. I was already afraid it would be  
something like that :(.

> So Taverna is basically reading in your services, and cannot
> find the objects, so it probably defaults to the Mobycentral
> registry.

Would it help if I register my objects at THE central mobycentral  
instead of in my local central? Or are the objects hardcoded in some  
jar file (like lib/jmoby.jar perhaps)?

Pieter

>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 12, 2005 8:06 AM
>> To: Core developer announcements
>> Subject: [MOBY-dev] Moby objects in Taverna. Where do they
>> come from?
>>
>> Hi all,
>>
>> I'm having some trouble to make BioMOBY work with Taverna.
>> I have a
>> local development Moby central. When I register both new
>> services and
>> new objects I notice that only my custom services are
>> listed in
>> Taverna. The list of moby objects is not in sync with what
>> is
>> registered in my central. So where does Taverna get those
>> objects
>> from and how do I get my own objects in there? Does anyone
>> have a clue?
>>
>> Cheers,
>>
>> Pieter
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From ots at ac.uma.es  Tue Sep 13 08:31:01 2005
From: ots at ac.uma.es (Oswaldo Trelles)
Date: Tue, 13 Sep 2005 10:31:01 +0200
Subject: [MOBY-dev] jMoby small update & a windows question
References: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>
Message-ID: <007201c5b83d$797e8de0$346dd696@ac.uma.es>

perhaps it is due to the old MS-DOS format under which the BAT files are
executed
you could try with    C:\Docume~1\martin\Desktop\jMoby

oswaldo

----- Original Message ----- 
From: "Martin Senger" <senger at ebi.ac.uk>
To: "Moby Developers" <moby-dev at biomoby.org>
Sent: Tuesday, September 13, 2005 9:56 AM
Subject: [MOBY-dev] jMoby small update & a windows question


> I have updated library alltools2.jar - so please when you use jMoby next
> time start with: ./build.sh (or ./build.bat).
>
> I wonder if people familiar with windows can answer my question about
> windows scripts:
>
> The script is build/run/run-cmdline-client.bat (but the same applies to
> all other .bat scripts there). It does not work if your PROJECT_HOME is a
> directory with whitespaces, like
>    C:\Document and Settings\martin\Desktop\jMoby
>
> I have already added there a lot of double quotes - so it "almost" works
> now, but not yet. The problem is the line:
>
> for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i
>
> where I do not know how to put quotes arround the first %PROJECT_HOME%. If
> I quote is, the '*.jar' part does not seem to expand as expected.
>
> I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
> then I can remove the %PROJECT_HOME% from all other places. But I still
> wonder how I should write it without this workaround. Does anybody know
> how to do it?
>
> Thanks,
> 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



From ots at ac.uma.es  Tue Sep 13 08:31:01 2005
From: ots at ac.uma.es (Oswaldo Trelles)
Date: Tue, 13 Sep 2005 10:31:01 +0200
Subject: [MOBY-dev] jMoby small update & a windows question
References: <Pine.OSF.4.21.0509130848120.960900-100000@ice.ebi.ac.uk>
Message-ID: <007201c5b83d$797e8de0$346dd696@ac.uma.es>

perhaps it is due to the old MS-DOS format under which the BAT files are
executed
you could try with    C:\Docume~1\martin\Desktop\jMoby

oswaldo

----- Original Message ----- 
From: "Martin Senger" <senger at ebi.ac.uk>
To: "Moby Developers" <moby-dev at biomoby.org>
Sent: Tuesday, September 13, 2005 9:56 AM
Subject: [MOBY-dev] jMoby small update & a windows question


> I have updated library alltools2.jar - so please when you use jMoby next
> time start with: ./build.sh (or ./build.bat).
>
> I wonder if people familiar with windows can answer my question about
> windows scripts:
>
> The script is build/run/run-cmdline-client.bat (but the same applies to
> all other .bat scripts there). It does not work if your PROJECT_HOME is a
> directory with whitespaces, like
>    C:\Document and Settings\martin\Desktop\jMoby
>
> I have already added there a lot of double quotes - so it "almost" works
> now, but not yet. The problem is the line:
>
> for %%i in (%PROJECT_HOME%\lib\*.jar) do call "%PROJECT_HOME%\cp.bat" %%i
>
> where I do not know how to put quotes arround the first %PROJECT_HOME%. If
> I quote is, the '*.jar' part does not seem to expand as expected.
>
> I solved it for now with a workaround: First I do cd "%PROJECT_HOME%", and
> then I can remove the %PROJECT_HOME% from all other places. But I still
> wonder how I should write it without this workaround. Does anybody know
> how to do it?
>
> Thanks,
> 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



From senger at ebi.ac.uk  Tue Sep 13 08:48:16 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 09:48:16 +0100 (BST)
Subject: [MOBY-dev] jMoby small update & a windows question
In-Reply-To: <007201c5b83d$797e8de0$346dd696@ac.uma.es>
Message-ID: <Pine.OSF.4.21.0509130944050.960900-100000@ice.ebi.ac.uk>

Thanks for the help.

> perhaps it is due to the old MS-DOS format under which the BAT files
> are executed
>
   No, they are executed under cmd running in windows XP. But perhaps I
even do not know how to execute them better. An advice is welcome.

> you could try with    C:\Docume~1\martin\Desktop\jMoby
>
   Actually, this seems to me to be the old 8.3 format. And this works
fine because it does not have spaces. But I do not know how to change
programatically the "C:\Document and Settings\martin\Desktop\jMoby" to
"C:\Docume~1\martin\Desktop\jMoby". This is done by Ant, when replacing a
token @PROJECT_HOME@ by a dir name (using a filterset). I cannot do it
manually.

   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)



From senger at ebi.ac.uk  Tue Sep 13 08:48:16 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 13 Sep 2005 09:48:16 +0100 (BST)
Subject: [MOBY-dev] jMoby small update & a windows question
In-Reply-To: <007201c5b83d$797e8de0$346dd696@ac.uma.es>
Message-ID: <Pine.OSF.4.21.0509130944050.960900-100000@ice.ebi.ac.uk>

Thanks for the help.

> perhaps it is due to the old MS-DOS format under which the BAT files
> are executed
>
   No, they are executed under cmd running in windows XP. But perhaps I
even do not know how to execute them better. An advice is welcome.

> you could try with    C:\Docume~1\martin\Desktop\jMoby
>
   Actually, this seems to me to be the old 8.3 format. And this works
fine because it does not have spaces. But I do not know how to change
programatically the "C:\Document and Settings\martin\Desktop\jMoby" to
"C:\Docume~1\martin\Desktop\jMoby". This is done by Ant, when replacing a
token @PROJECT_HOME@ by a dir name (using a filterset). I cannot do it
manually.

   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)



From edward.kawas at gmail.com  Tue Sep 13 13:08:20 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 13 Sep 2005 06:08:20 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <A7015A51-2FAA-417D-95C7-E2AF2630F540@wur.nl>
Message-ID: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>

Hi,

Objects aren't hard coded. They just have to be registered
in Mobycentral.

I am not sure if you are up for it, but you could always
install the servlets (I could help you).

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 1:35 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi Eddie,
> 
> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > The answer basically is that you also need to set up
> some
> > servlets (RESOURCES script, types, etc), if you have a
> > custom registry.
> 
> Thanks for the quick feedback. I was already afraid it
> would be
> something like that :(.
> 
> > So Taverna is basically reading in your services, and
> cannot
> > find the objects, so it probably defaults to the
> Mobycentral
> > registry.
> 
> Would it help if I register my objects at THE central
> mobycentral
> instead of in my local central? Or are the objects
> hardcoded in some
> jar file (like lib/jmoby.jar perhaps)?
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces at portal.open-bio.org
> [mailto:moby-
> >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Monday, September 12, 2005 8:06 AM
> >> To: Core developer announcements
> >> Subject: [MOBY-dev] Moby objects in Taverna. Where do
> they
> >> come from?
> >>
> >> Hi all,
> >>
> >> I'm having some trouble to make BioMOBY work with
> Taverna.
> >> I have a
> >> local development Moby central. When I register both
> new
> >> services and
> >> new objects I notice that only my custom services are
> >> listed in
> >> Taverna. The list of moby objects is not in sync with
> what
> >> is
> >> registered in my central. So where does Taverna get
> those
> >> objects
> >> from and how do I get my own objects in there? Does
> anyone
> >> have a clue?
> >>
> >> Cheers,
> >>
> >> Pieter
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx at wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From Pieter.Neerincx at wur.nl  Tue Sep 13 14:17:46 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 13 Sep 2005 16:17:46 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>
References: <4326cf49.5a8d5b45.2852.ffffa755@mx.gmail.com>
Message-ID: <DB4FF9B0-3BDE-42DA-AB89-8CBDEF8705C5@wur.nl>

Hi Eddie,

On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:

> Hi,
>
> Objects aren't hard coded. They just have to be registered
> in Mobycentral.

Today I fetched the source code for Taverna and 'grep'ed over the  
files. There are several instances where the path to the central  
biomoby central and an RDF file are hardcoded outside the files in  
conf/. Sometime ago I started to work with Taverna and the user  
manual only mentions the path to a biomoby central in the conf/ 
mygrid.properties file. So I appended my local biomoby central to  
this conf file and expected this would allow me to use both services  
and objects registered in my local central. I think that the current  
situation where service info is fetched from a URL in the conf/ 
mygrid.properties file and object info is fetched from a RDF file at  
a different location is very confusing and needlessly complex.  
Especially since I cannot supply an URL to a custom RDF file for my  
objects in the conf/mygrid.properties file. I did see though that I  
can right-click in Taverna to add a scavenger and than I can supply  
both an URL to my local central and an URL to this RDF file for the  
objects.

I also browsed the mailinglist and wiki. Did I understand correctly  
that the current situation is a temporary solution and that  
eventually all info (hence services and objects) will be described  
using RDF? Please correct me if I'm wrong...

> I am not sure if you are up for it, but you could always
> install the servlets

Are those servlets generating this RDF file from the info in a central?
Is this documented somewhere? I couldn't find any reference to  
servlets at http://www.biomoby.org/InstallingMOBYCentral.html ...

> (I could help you).

Your help is much appreciated! Thanks,

Pieter

>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 1:35 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi Eddie,
>>
>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> The answer basically is that you also need to set up
>>>
>> some
>>
>>> servlets (RESOURCES script, types, etc), if you have a
>>> custom registry.
>>>
>>
>> Thanks for the quick feedback. I was already afraid it
>> would be
>> something like that :(.
>>
>>
>>> So Taverna is basically reading in your services, and
>>>
>> cannot
>>
>>> find the objects, so it probably defaults to the
>>>
>> Mobycentral
>>
>>> registry.
>>>
>>
>> Would it help if I register my objects at THE central
>> mobycentral
>> instead of in my local central? Or are the objects
>> hardcoded in some
>> jar file (like lib/jmoby.jar perhaps)?
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>> To: Core developer announcements
>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
>>>>
>> they
>>
>>>> come from?
>>>>
>>>> Hi all,
>>>>
>>>> I'm having some trouble to make BioMOBY work with
>>>>
>> Taverna.
>>
>>>> I have a
>>>> local development Moby central. When I register both
>>>>
>> new
>>
>>>> services and
>>>> new objects I notice that only my custom services are
>>>> listed in
>>>> Taverna. The list of moby objects is not in sync with
>>>>
>> what
>>
>>>> is
>>>> registered in my central. So where does Taverna get
>>>>
>> those
>>
>>>> objects
>>>> from and how do I get my own objects in there? Does
>>>>
>> anyone
>>
>>>> have a clue?
>>>>
>>>> Cheers,
>>>>
>>>> Pieter
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Tue Sep 13 14:43:32 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 13 Sep 2005 07:43:32 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <DB4FF9B0-3BDE-42DA-AB89-8CBDEF8705C5@wur.nl>
Message-ID: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>

Hi,

For the Taverna workbench, download it temporarily from
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip
This version contains my changes (the ones that are in the
Taverna CVS).

The Moby api actually now has a method in it called
getResources (or something similar to that) that returns the
locations of these documents for a registry. So in the newly
updated version of the plugin, I have removed the textbox
that asks for this url and replaced it with an api call.
(a description on the Moby plugin can be found at
http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.ht
ml but is being changed to reflect the api calling).

You are correct in saying that we are moving towards having
Services and datatypes described by RDF.

Finally, as for the servlet installation, if you are
interested, I can guide you through this relatively painless
procedure. I would just need to update certain files that
you need to download and you would have to install tomcat.

Eddie



> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 7:18 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi Eddie,
> 
> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > Objects aren't hard coded. They just have to be
> registered
> > in Mobycentral.
> 
> Today I fetched the source code for Taverna and 'grep'ed
> over the
> files. There are several instances where the path to the
> central
> biomoby central and an RDF file are hardcoded outside the
> files in
> conf/. Sometime ago I started to work with Taverna and the
> user
> manual only mentions the path to a biomoby central in the
> conf/
> mygrid.properties file. So I appended my local biomoby
> central to
> this conf file and expected this would allow me to use
> both services
> and objects registered in my local central. I think that
> the current
> situation where service info is fetched from a URL in the
> conf/
> mygrid.properties file and object info is fetched from a
> RDF file at
> a different location is very confusing and needlessly
> complex.
> Especially since I cannot supply an URL to a custom RDF
> file for my
> objects in the conf/mygrid.properties file. I did see
> though that I
> can right-click in Taverna to add a scavenger and than I
> can supply
> both an URL to my local central and an URL to this RDF
> file for the
> objects.
> 
> I also browsed the mailinglist and wiki. Did I understand
> correctly
> that the current situation is a temporary solution and
> that
> eventually all info (hence services and objects) will be
> described
> using RDF? Please correct me if I'm wrong...
> 
> > I am not sure if you are up for it, but you could always
> > install the servlets
> 
> Are those servlets generating this RDF file from the info
> in a central?
> Is this documented somewhere? I couldn't find any
> reference to
> servlets at
> http://www.biomoby.org/InstallingMOBYCentral.html ...
> 
> > (I could help you).
> 
> Your help is much appreciated! Thanks,
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces at portal.open-bio.org
> [mailto:moby-
> >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Tuesday, September 13, 2005 1:35 AM
> >> To: Core developer announcements
> >> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
> do
> >> they come from?
> >>
> >> Hi Eddie,
> >>
> >> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> The answer basically is that you also need to set up
> >>>
> >> some
> >>
> >>> servlets (RESOURCES script, types, etc), if you have a
> >>> custom registry.
> >>>
> >>
> >> Thanks for the quick feedback. I was already afraid it
> >> would be
> >> something like that :(.
> >>
> >>
> >>> So Taverna is basically reading in your services, and
> >>>
> >> cannot
> >>
> >>> find the objects, so it probably defaults to the
> >>>
> >> Mobycentral
> >>
> >>> registry.
> >>>
> >>
> >> Would it help if I register my objects at THE central
> >> mobycentral
> >> instead of in my local central? Or are the objects
> >> hardcoded in some
> >> jar file (like lib/jmoby.jar perhaps)?
> >>
> >> Pieter
> >>
> >>
> >>>
> >>> Eddie
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: moby-dev-bounces at portal.open-bio.org
> >>>>
> >> [mailto:moby-
> >>
> >>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >>>> Neerincx
> >>>> Sent: Monday, September 12, 2005 8:06 AM
> >>>> To: Core developer announcements
> >>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
> >>>>
> >> they
> >>
> >>>> come from?
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I'm having some trouble to make BioMOBY work with
> >>>>
> >> Taverna.
> >>
> >>>> I have a
> >>>> local development Moby central. When I register both
> >>>>
> >> new
> >>
> >>>> services and
> >>>> new objects I notice that only my custom services are
> >>>> listed in
> >>>> Taverna. The list of moby objects is not in sync with
> >>>>
> >> what
> >>
> >>>> is
> >>>> registered in my central. So where does Taverna get
> >>>>
> >> those
> >>
> >>>> objects
> >>>> from and how do I get my own objects in there? Does
> >>>>
> >> anyone
> >>
> >>>> have a clue?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Pieter
> >>>>
> >>>> Wageningen University and Research centre (WUR)
> >>>> Laboratory of Bioinformatics
> >>>> Transitorium (building 312) room 1034
> >>>> Dreijenlaan 3
> >>>> 6703 HA Wageningen
> >>>> The Netherlands
> >>>> phone: 0317-483 060
> >>>> fax: 0317-483 584
> >>>> mobile: 06-143 66 783
> >>>> pieter.neerincx at wur.nl
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev at biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev at biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx at wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From Pieter.Neerincx at wur.nl  Tue Sep 13 15:48:47 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 13 Sep 2005 17:48:47 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>
References: <4326e596.7263410f.2fc4.3c32@mx.gmail.com>
Message-ID: <E56B487A-CAED-4EFE-B0AD-97C3B4F21E6C@wur.nl>

Hi,

On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:

> Hi,
>
> For the Taverna workbench, download it temporarily from
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
> zip

I will...

> This version contains my changes (the ones that are in the
> Taverna CVS).
>
> The Moby api actually now has a method in it called
> getResources (or something similar to that) that returns the
> locations of these documents for a registry.

Ok, that sounds like a much more elegant solution :).

> So in the newly
> updated version of the plugin, I have removed the textbox
> that asks for this url and replaced it with an api call.
> (a description on the Moby plugin can be found at
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.ht
> ml but is being changed to reflect the api calling).
>
> You are correct in saying that we are moving towards having
> Services and datatypes described by RDF.
>
> Finally, as for the servlet installation, if you are
> interested, I can guide you through this relatively painless
> procedure. I would just need to update certain files that
> you need to download and you would have to install tomcat.

Ok, I will start with tomcat tomorrow... and will request further  
advice one I have that one up and running...

Pieter

>
> Eddie
>
>
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 7:18 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi Eddie,
>>
>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> Objects aren't hard coded. They just have to be
>>>
>> registered
>>
>>> in Mobycentral.
>>>
>>
>> Today I fetched the source code for Taverna and 'grep'ed
>> over the
>> files. There are several instances where the path to the
>> central
>> biomoby central and an RDF file are hardcoded outside the
>> files in
>> conf/. Sometime ago I started to work with Taverna and the
>> user
>> manual only mentions the path to a biomoby central in the
>> conf/
>> mygrid.properties file. So I appended my local biomoby
>> central to
>> this conf file and expected this would allow me to use
>> both services
>> and objects registered in my local central. I think that
>> the current
>> situation where service info is fetched from a URL in the
>> conf/
>> mygrid.properties file and object info is fetched from a
>> RDF file at
>> a different location is very confusing and needlessly
>> complex.
>> Especially since I cannot supply an URL to a custom RDF
>> file for my
>> objects in the conf/mygrid.properties file. I did see
>> though that I
>> can right-click in Taverna to add a scavenger and than I
>> can supply
>> both an URL to my local central and an URL to this RDF
>> file for the
>> objects.
>>
>> I also browsed the mailinglist and wiki. Did I understand
>> correctly
>> that the current situation is a temporary solution and
>> that
>> eventually all info (hence services and objects) will be
>> described
>> using RDF? Please correct me if I'm wrong...
>>
>>
>>> I am not sure if you are up for it, but you could always
>>> install the servlets
>>>
>>
>> Are those servlets generating this RDF file from the info
>> in a central?
>> Is this documented somewhere? I couldn't find any
>> reference to
>> servlets at
>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>
>>
>>> (I could help you).
>>>
>>
>> Your help is much appreciated! Thanks,
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>>>
>> do
>>
>>>> they come from?
>>>>
>>>> Hi Eddie,
>>>>
>>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> The answer basically is that you also need to set up
>>>>>
>>>>>
>>>> some
>>>>
>>>>
>>>>> servlets (RESOURCES script, types, etc), if you have a
>>>>> custom registry.
>>>>>
>>>>>
>>>>
>>>> Thanks for the quick feedback. I was already afraid it
>>>> would be
>>>> something like that :(.
>>>>
>>>>
>>>>
>>>>> So Taverna is basically reading in your services, and
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>> find the objects, so it probably defaults to the
>>>>>
>>>>>
>>>> Mobycentral
>>>>
>>>>
>>>>> registry.
>>>>>
>>>>>
>>>>
>>>> Would it help if I register my objects at THE central
>>>> mobycentral
>>>> instead of in my local central? Or are the objects
>>>> hardcoded in some
>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>>>
>>>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>>>> Neerincx
>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>> To: Core developer announcements
>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where do
>>>>>>
>>>>>>
>>>> they
>>>>
>>>>
>>>>>> come from?
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm having some trouble to make BioMOBY work with
>>>>>>
>>>>>>
>>>> Taverna.
>>>>
>>>>
>>>>>> I have a
>>>>>> local development Moby central. When I register both
>>>>>>
>>>>>>
>>>> new
>>>>
>>>>
>>>>>> services and
>>>>>> new objects I notice that only my custom services are
>>>>>> listed in
>>>>>> Taverna. The list of moby objects is not in sync with
>>>>>>
>>>>>>
>>>> what
>>>>
>>>>
>>>>>> is
>>>>>> registered in my central. So where does Taverna get
>>>>>>
>>>>>>
>>>> those
>>>>
>>>>
>>>>>> objects
>>>>>> from and how do I get my own objects in there? Does
>>>>>>
>>>>>>
>>>> anyone
>>>>
>>>>
>>>>>> have a clue?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Pieter
>>>>>>
>>>>>> Wageningen University and Research centre (WUR)
>>>>>> Laboratory of Bioinformatics
>>>>>> Transitorium (building 312) room 1034
>>>>>> Dreijenlaan 3
>>>>>> 6703 HA Wageningen
>>>>>> The Netherlands
>>>>>> phone: 0317-483 060
>>>>>> fax: 0317-483 584
>>>>>> mobile: 06-143 66 783
>>>>>> pieter.neerincx at wur.nl
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Tue Sep 13 15:58:51 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 13 Sep 2005 08:58:51 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <E56B487A-CAED-4EFE-B0AD-97C3B4F21E6C@wur.nl>
Message-ID: <4326f75b.52b7817a.2384.5590@mx.gmail.com>

Great. I will be waiting ;-)

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Tuesday, September 13, 2005 8:49 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> Hi,
> 
> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
> 
> > Hi,
> >
> > For the Taverna workbench, download it temporarily from
> > http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
> 1.2.
> > zip
> 
> I will...
> 
> > This version contains my changes (the ones that are in
> the
> > Taverna CVS).
> >
> > The Moby api actually now has a method in it called
> > getResources (or something similar to that) that returns
> the
> > locations of these documents for a registry.
> 
> Ok, that sounds like a much more elegant solution :).
> 
> > So in the newly
> > updated version of the plugin, I have removed the
> textbox
> > that asks for this url and replaced it with an api call.
> > (a description on the Moby plugin can be found at
> >
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
> ht
> > ml but is being changed to reflect the api calling).
> >
> > You are correct in saying that we are moving towards
> having
> > Services and datatypes described by RDF.
> >
> > Finally, as for the servlet installation, if you are
> > interested, I can guide you through this relatively
> painless
> > procedure. I would just need to update certain files
> that
> > you need to download and you would have to install
> tomcat.
> 
> Ok, I will start with tomcat tomorrow... and will request
> further
> advice one I have that one up and running...
> 
> Pieter
> 
> >
> > Eddie
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: moby-dev-bounces at portal.open-bio.org
> [mailto:moby-
> >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >> Neerincx
> >> Sent: Tuesday, September 13, 2005 7:18 AM
> >> To: Core developer announcements
> >> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
> do
> >> they come from?
> >>
> >> Hi Eddie,
> >>
> >> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> Objects aren't hard coded. They just have to be
> >>>
> >> registered
> >>
> >>> in Mobycentral.
> >>>
> >>
> >> Today I fetched the source code for Taverna and
> 'grep'ed
> >> over the
> >> files. There are several instances where the path to
> the
> >> central
> >> biomoby central and an RDF file are hardcoded outside
> the
> >> files in
> >> conf/. Sometime ago I started to work with Taverna and
> the
> >> user
> >> manual only mentions the path to a biomoby central in
> the
> >> conf/
> >> mygrid.properties file. So I appended my local biomoby
> >> central to
> >> this conf file and expected this would allow me to use
> >> both services
> >> and objects registered in my local central. I think
> that
> >> the current
> >> situation where service info is fetched from a URL in
> the
> >> conf/
> >> mygrid.properties file and object info is fetched from
> a
> >> RDF file at
> >> a different location is very confusing and needlessly
> >> complex.
> >> Especially since I cannot supply an URL to a custom RDF
> >> file for my
> >> objects in the conf/mygrid.properties file. I did see
> >> though that I
> >> can right-click in Taverna to add a scavenger and than
> I
> >> can supply
> >> both an URL to my local central and an URL to this RDF
> >> file for the
> >> objects.
> >>
> >> I also browsed the mailinglist and wiki. Did I
> understand
> >> correctly
> >> that the current situation is a temporary solution and
> >> that
> >> eventually all info (hence services and objects) will
> be
> >> described
> >> using RDF? Please correct me if I'm wrong...
> >>
> >>
> >>> I am not sure if you are up for it, but you could
> always
> >>> install the servlets
> >>>
> >>
> >> Are those servlets generating this RDF file from the
> info
> >> in a central?
> >> Is this documented somewhere? I couldn't find any
> >> reference to
> >> servlets at
> >> http://www.biomoby.org/InstallingMOBYCentral.html ...
> >>
> >>
> >>> (I could help you).
> >>>
> >>
> >> Your help is much appreciated! Thanks,
> >>
> >> Pieter
> >>
> >>
> >>>
> >>> Eddie
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: moby-dev-bounces at portal.open-bio.org
> >>>>
> >> [mailto:moby-
> >>
> >>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> >>>> Neerincx
> >>>> Sent: Tuesday, September 13, 2005 1:35 AM
> >>>> To: Core developer announcements
> >>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
> Where
> >>>>
> >> do
> >>
> >>>> they come from?
> >>>>
> >>>> Hi Eddie,
> >>>>
> >>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> The answer basically is that you also need to set up
> >>>>>
> >>>>>
> >>>> some
> >>>>
> >>>>
> >>>>> servlets (RESOURCES script, types, etc), if you have
> a
> >>>>> custom registry.
> >>>>>
> >>>>>
> >>>>
> >>>> Thanks for the quick feedback. I was already afraid
> it
> >>>> would be
> >>>> something like that :(.
> >>>>
> >>>>
> >>>>
> >>>>> So Taverna is basically reading in your services,
> and
> >>>>>
> >>>>>
> >>>> cannot
> >>>>
> >>>>
> >>>>> find the objects, so it probably defaults to the
> >>>>>
> >>>>>
> >>>> Mobycentral
> >>>>
> >>>>
> >>>>> registry.
> >>>>>
> >>>>>
> >>>>
> >>>> Would it help if I register my objects at THE central
> >>>> mobycentral
> >>>> instead of in my local central? Or are the objects
> >>>> hardcoded in some
> >>>> jar file (like lib/jmoby.jar perhaps)?
> >>>>
> >>>> Pieter
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Eddie
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: moby-dev-bounces at portal.open-bio.org
> >>>>>>
> >>>>>>
> >>>> [mailto:moby-
> >>>>
> >>>>
> >>>>>> dev-bounces at portal.open-bio.org] On Behalf Of
> Pieter
> >>>>>> Neerincx
> >>>>>> Sent: Monday, September 12, 2005 8:06 AM
> >>>>>> To: Core developer announcements
> >>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
> do
> >>>>>>
> >>>>>>
> >>>> they
> >>>>
> >>>>
> >>>>>> come from?
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I'm having some trouble to make BioMOBY work with
> >>>>>>
> >>>>>>
> >>>> Taverna.
> >>>>
> >>>>
> >>>>>> I have a
> >>>>>> local development Moby central. When I register
> both
> >>>>>>
> >>>>>>
> >>>> new
> >>>>
> >>>>
> >>>>>> services and
> >>>>>> new objects I notice that only my custom services
> are
> >>>>>> listed in
> >>>>>> Taverna. The list of moby objects is not in sync
> with
> >>>>>>
> >>>>>>
> >>>> what
> >>>>
> >>>>
> >>>>>> is
> >>>>>> registered in my central. So where does Taverna get
> >>>>>>
> >>>>>>
> >>>> those
> >>>>
> >>>>
> >>>>>> objects
> >>>>>> from and how do I get my own objects in there? Does
> >>>>>>
> >>>>>>
> >>>> anyone
> >>>>
> >>>>
> >>>>>> have a clue?
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Pieter
> >>>>>>
> >>>>>> Wageningen University and Research centre (WUR)
> >>>>>> Laboratory of Bioinformatics
> >>>>>> Transitorium (building 312) room 1034
> >>>>>> Dreijenlaan 3
> >>>>>> 6703 HA Wageningen
> >>>>>> The Netherlands
> >>>>>> phone: 0317-483 060
> >>>>>> fax: 0317-483 584
> >>>>>> mobile: 06-143 66 783
> >>>>>> pieter.neerincx at wur.nl
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MOBY-dev mailing list
> >>>>>> MOBY-dev at biomoby.org
> >>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> MOBY-dev mailing list
> >>>>> MOBY-dev at biomoby.org
> >>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> Wageningen University and Research centre (WUR)
> >>>> Laboratory of Bioinformatics
> >>>> Transitorium (building 312) room 1034
> >>>> Dreijenlaan 3
> >>>> 6703 HA Wageningen
> >>>> The Netherlands
> >>>> phone: 0317-483 060
> >>>> fax: 0317-483 584
> >>>> mobile: 06-143 66 783
> >>>> pieter.neerincx at wur.nl
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MOBY-dev mailing list
> >>>> MOBY-dev at biomoby.org
> >>>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> MOBY-dev mailing list
> >>> MOBY-dev at biomoby.org
> >>> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>>
> >>>
> >>
> >>
> >> Wageningen University and Research centre (WUR)
> >> Laboratory of Bioinformatics
> >> Transitorium (building 312) room 1034
> >> Dreijenlaan 3
> >> 6703 HA Wageningen
> >> The Netherlands
> >> phone: 0317-483 060
> >> fax: 0317-483 584
> >> mobile: 06-143 66 783
> >> pieter.neerincx at wur.nl
> >>
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From Pieter.Neerincx at wur.nl  Wed Sep 14 11:04:53 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 14 Sep 2005 13:04:53 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4326f75b.52b7817a.2384.5590@mx.gmail.com>
References: <4326f75b.52b7817a.2384.5590@mx.gmail.com>
Message-ID: <1ACC63DC-D971-4137-97FA-1D90AD0EE571@wur.nl>

Ok, got Tomcat installed... Please tell me what to download from  
where and where to install it...

Thanks,

Pieter

On 13-Sep-2005, at 5:58 PM, Edward Kawas wrote:

> Great. I will be waiting ;-)
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Tuesday, September 13, 2005 8:49 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>> Hi,
>>
>> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
>>
>>
>>> Hi,
>>>
>>> For the Taverna workbench, download it temporarily from
>>> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>>>
>> 1.2.
>>
>>> zip
>>>
>>
>> I will...
>>
>>
>>> This version contains my changes (the ones that are in
>>>
>> the
>>
>>> Taverna CVS).
>>>
>>> The Moby api actually now has a method in it called
>>> getResources (or something similar to that) that returns
>>>
>> the
>>
>>> locations of these documents for a registry.
>>>
>>
>> Ok, that sounds like a much more elegant solution :).
>>
>>
>>> So in the newly
>>> updated version of the plugin, I have removed the
>>>
>> textbox
>>
>>> that asks for this url and replaced it with an api call.
>>> (a description on the Moby plugin can be found at
>>>
>>>
>> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
>> ht
>>
>>> ml but is being changed to reflect the api calling).
>>>
>>> You are correct in saying that we are moving towards
>>>
>> having
>>
>>> Services and datatypes described by RDF.
>>>
>>> Finally, as for the servlet installation, if you are
>>> interested, I can guide you through this relatively
>>>
>> painless
>>
>>> procedure. I would just need to update certain files
>>>
>> that
>>
>>> you need to download and you would have to install
>>>
>> tomcat.
>>
>> Ok, I will start with tomcat tomorrow... and will request
>> further
>> advice one I have that one up and running...
>>
>> Pieter
>>
>>
>>>
>>> Eddie
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>
>> [mailto:moby-
>>
>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>> Neerincx
>>>> Sent: Tuesday, September 13, 2005 7:18 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>>>
>> do
>>
>>>> they come from?
>>>>
>>>> Hi Eddie,
>>>>
>>>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> Objects aren't hard coded. They just have to be
>>>>>
>>>>>
>>>> registered
>>>>
>>>>
>>>>> in Mobycentral.
>>>>>
>>>>>
>>>>
>>>> Today I fetched the source code for Taverna and
>>>>
>> 'grep'ed
>>
>>>> over the
>>>> files. There are several instances where the path to
>>>>
>> the
>>
>>>> central
>>>> biomoby central and an RDF file are hardcoded outside
>>>>
>> the
>>
>>>> files in
>>>> conf/. Sometime ago I started to work with Taverna and
>>>>
>> the
>>
>>>> user
>>>> manual only mentions the path to a biomoby central in
>>>>
>> the
>>
>>>> conf/
>>>> mygrid.properties file. So I appended my local biomoby
>>>> central to
>>>> this conf file and expected this would allow me to use
>>>> both services
>>>> and objects registered in my local central. I think
>>>>
>> that
>>
>>>> the current
>>>> situation where service info is fetched from a URL in
>>>>
>> the
>>
>>>> conf/
>>>> mygrid.properties file and object info is fetched from
>>>>
>> a
>>
>>>> RDF file at
>>>> a different location is very confusing and needlessly
>>>> complex.
>>>> Especially since I cannot supply an URL to a custom RDF
>>>> file for my
>>>> objects in the conf/mygrid.properties file. I did see
>>>> though that I
>>>> can right-click in Taverna to add a scavenger and than
>>>>
>> I
>>
>>>> can supply
>>>> both an URL to my local central and an URL to this RDF
>>>> file for the
>>>> objects.
>>>>
>>>> I also browsed the mailinglist and wiki. Did I
>>>>
>> understand
>>
>>>> correctly
>>>> that the current situation is a temporary solution and
>>>> that
>>>> eventually all info (hence services and objects) will
>>>>
>> be
>>
>>>> described
>>>> using RDF? Please correct me if I'm wrong...
>>>>
>>>>
>>>>
>>>>> I am not sure if you are up for it, but you could
>>>>>
>> always
>>
>>>>> install the servlets
>>>>>
>>>>>
>>>>
>>>> Are those servlets generating this RDF file from the
>>>>
>> info
>>
>>>> in a central?
>>>> Is this documented somewhere? I couldn't find any
>>>> reference to
>>>> servlets at
>>>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>>>
>>>>
>>>>
>>>>> (I could help you).
>>>>>
>>>>>
>>>>
>>>> Your help is much appreciated! Thanks,
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>>>
>>>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>>>> Neerincx
>>>>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>>>> To: Core developer announcements
>>>>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
>>>>>>
>> Where
>>
>>>>>>
>>>>>>
>>>> do
>>>>
>>>>
>>>>>> they come from?
>>>>>>
>>>>>> Hi Eddie,
>>>>>>
>>>>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The answer basically is that you also need to set up
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> some
>>>>>>
>>>>>>
>>>>>>
>>>>>>> servlets (RESOURCES script, types, etc), if you have
>>>>>>>
>> a
>>
>>>>>>> custom registry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks for the quick feedback. I was already afraid
>>>>>>
>> it
>>
>>>>>> would be
>>>>>> something like that :(.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> So Taverna is basically reading in your services,
>>>>>>>
>> and
>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> cannot
>>>>>>
>>>>>>
>>>>>>
>>>>>>> find the objects, so it probably defaults to the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Mobycentral
>>>>>>
>>>>>>
>>>>>>
>>>>>>> registry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Would it help if I register my objects at THE central
>>>>>> mobycentral
>>>>>> instead of in my local central? Or are the objects
>>>>>> hardcoded in some
>>>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>>>
>>>>>> Pieter
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Eddie
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> [mailto:moby-
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> dev-bounces at portal.open-bio.org] On Behalf Of
>>>>>>>>
>> Pieter
>>
>>>>>>>> Neerincx
>>>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>>>> To: Core developer announcements
>>>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
>>>>>>>>
>> do
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> they
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> come from?
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'm having some trouble to make BioMOBY work with
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> Taverna.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> I have a
>>>>>>>> local development Moby central. When I register
>>>>>>>>
>> both
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> new
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> services and
>>>>>>>> new objects I notice that only my custom services
>>>>>>>>
>> are
>>
>>>>>>>> listed in
>>>>>>>> Taverna. The list of moby objects is not in sync
>>>>>>>>
>> with
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> what
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> is
>>>>>>>> registered in my central. So where does Taverna get
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> those
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> objects
>>>>>>>> from and how do I get my own objects in there? Does
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> anyone
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> have a clue?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Pieter
>>>>>>>>
>>>>>>>> Wageningen University and Research centre (WUR)
>>>>>>>> Laboratory of Bioinformatics
>>>>>>>> Transitorium (building 312) room 1034
>>>>>>>> Dreijenlaan 3
>>>>>>>> 6703 HA Wageningen
>>>>>>>> The Netherlands
>>>>>>>> phone: 0317-483 060
>>>>>>>> fax: 0317-483 584
>>>>>>>> mobile: 06-143 66 783
>>>>>>>> pieter.neerincx at wur.nl
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MOBY-dev mailing list
>>>>>>>> MOBY-dev at biomoby.org
>>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> MOBY-dev mailing list
>>>>>>> MOBY-dev at biomoby.org
>>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Wageningen University and Research centre (WUR)
>>>>>> Laboratory of Bioinformatics
>>>>>> Transitorium (building 312) room 1034
>>>>>> Dreijenlaan 3
>>>>>> 6703 HA Wageningen
>>>>>> The Netherlands
>>>>>> phone: 0317-483 060
>>>>>> fax: 0317-483 584
>>>>>> mobile: 06-143 66 783
>>>>>> pieter.neerincx at wur.nl
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at biomoby.org
>>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at biomoby.org
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>> Laboratory of Bioinformatics
>>>> Transitorium (building 312) room 1034
>>>> Dreijenlaan 3
>>>> 6703 HA Wageningen
>>>> The Netherlands
>>>> phone: 0317-483 060
>>>> fax: 0317-483 584
>>>> mobile: 06-143 66 783
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Thu Sep 15 22:46:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 15 Sep 2005 15:46:52 -0700
Subject: [MOBY-dev] invitation for the RFC committee with a tenure of one
	year
Message-ID: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>



-----Original Message-----
From: mark wilkinson [mailto:markw at illuminae.com] 
Sent: Thursday, September 15, 2005 3:06 PM
To: Frank Gibbons; Eddie Kawas
Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
Error-handling in MOBY-S

Hey Frank! Cc Eddie

Thanks for riding this.  I am on holiday, and not in Net
contact except by blackberry, so I'm not "useful" right now.

I think we should put out an invitation on the -dev list for
the RFC committee with a tenure of one year, but also
specifically invite the main developers/vested interests to
be part of it:  me, you, martin, eddie, simon, heiko, paul,
yan wong, and at least one from the spanish contingent (have
I missed anyone?).

I don't have all their email addresses on my bberry so
unless you or Eddie (cc'd) post this invitation to the dev
list yourselves it may take a week before I am back in
net-world.  Eddie, could you do this? Tomorrow or this
afternoon?  It would be good to get this sorted asap to keep
on schedule.

M


-----Original Message-----
From: Frank Gibbons <fgibbons at hms.harvard.edu>
Date: Thu, 15 Sep 2005 11:21:53 
To:moby-l at biomoby.org
Subject: [MOBY-l] Using bugzilla to continue RFC on
Error-handling in MOBY-S

Hi,

I've just added a few "bugs" to the bugzilla, to try to
preserve the RFC 
momentum built up over the past few weeks. I propose that,
although 
bugzilla is perhaps not ideal for this, it is what it is, it
is what we 
have, and it will do for now.

I'd like to propose that we try to continue development of
this RFC through 
bugzilla (see bug #1863), rather than through the mailing
list. Searching 
through old mail messages (or worse still, through the
digest, with all of 
its repeated messages and long inclusions) is tedious, and I
think 
contributes to the loss in momentum.

So far, in Martin's scheme for RFC-processing, we have
(numbers are those 
used in Martin's original suggestion, now available in the
codebase as 
Docs/MOBY-S_API/RFC.html)

1. Had a suggestion made by INB to add this features. It was
added to 
bugzilla, No. 1863
2. Suggested to resolve it by today (Sep-15)
3. Martin backed up the RFC
4. I think we have the resources to make this change - it
seems an 
essential part of a robust API, which version 1.0 should be.
5a. List members have exchanged several comments back and
forth, resulting 
in amended versions of the RFC being posted to the mailing
list.
5b. We've also gotten a little side-tracked by the related
articleName problem.

So it seems to me that it's time to vote on it (step 6 of
the Senger 
seven-step scheme ;-). Martin suggested that Mark would ask
a limited 
number of people to vote on it after the resolution date
(today). I guess 
those people would self-select, or maybe Mark will select
them. They will 
be requested to make a one-year commitment.

After that comes step 7, the "fun part": implementation,
documentation.

We're pretty close to reaching a conclusion on this. The
fact is that even 
if we do nothing, people want this functionality, and they
WILL implement 
it. It is in everybody's interest that we have a
specification for what the 
functionality should be. It may change over time, but I
think there has 
been enough back-and-forth that we have a reasonable first
draft, and 
should vote on it.

-Frank
P.S. Of course, this message, along with version 1.7.1 of
the RFC is 
attached to the bug on bugzilla

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

_______________________________________________
moby-l mailing list
moby-l at biomoby.org
http://biomoby.org/mailman/listinfo/moby-l

--
Mark Wilkinson
..on the road!



From ed.kawas at gmail.com  Fri Sep 16 00:04:26 2005
From: ed.kawas at gmail.com (Eddie Kawas)
Date: Thu, 15 Sep 2005 17:04:26 -0700
Subject: [MOBY-dev] taverna update
Message-ID: <432a0c0e.0f0001ad.6fb1.4f25@mx.gmail.com>

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie




From markw at illuminae.com  Fri Sep 16 04:20:50 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri, 16 Sep 2005 04:20:50 +0000 GMT
Subject: [MOBY-dev] taverna update
Message-ID: <2044406868-1126844547-cardhu_blackberry.rim.net-21354-@engine13-cell01>

This is the kick-ass addition to Taverna that only MOBY can accomplish!  I'm really excited about this!  Lead the biologist by the hand through workflow creation... It isn't quite a "wizard" but getting there!

Thanks Eddie!  Your plugin is bare(bear)able!

M
.
 
-----Original Message-----
From: "Eddie Kawas" <ed.kawas at gmail.com>
Date: Thu, 15 Sep 2005 17:04:26 
To:<moby-l at biomoby.org>, "'Moby Developers'" <moby-dev at biomoby.org>
Subject: [MOBY-dev] taverna update

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie


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

--
Mark Wilkinson
...on the road!


From markw at illuminae.com  Fri Sep 16 04:20:50 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri, 16 Sep 2005 04:20:50 +0000 GMT
Subject: [MOBY-dev] taverna update
Message-ID: <2044406868-1126844547-cardhu_blackberry.rim.net-21354-@engine13-cell01>

This is the kick-ass addition to Taverna that only MOBY can accomplish!  I'm really excited about this!  Lead the biologist by the hand through workflow creation... It isn't quite a "wizard" but getting there!

Thanks Eddie!  Your plugin is bare(bear)able!

M
.
 
-----Original Message-----
From: "Eddie Kawas" <ed.kawas at gmail.com>
Date: Thu, 15 Sep 2005 17:04:26 
To:<moby-l at biomoby.org>, "'Moby Developers'" <moby-dev at biomoby.org>
Subject: [MOBY-dev] taverna update

Hi,

I have modified the Moby plugin and I was wondering if
Moby'ers would like to try it and let me know what you
think?

I basically added the ability to add Moby objects, and the
objects that are contained within the object in the form of
has(a), to the workflow.

I also added some new things to the popup window that arises
when you context (right) click the Moby object/service
processor in the 'advance model explorer'. When the window
pops up, there is a context menu for certain nodes in the
tree that allows you to add services/datatypes to the
workflow, after 'discovering' them.

I think that it's better just to try it out. The one
downside is that you can only use the Vancouver based
Mobycentral registry (since I am taking advantage of recent
api additions).

The link to this 'new' taverna is:
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip

I would first suggest that you ensure that your old
workflows work and then try creating workflows using the
'enhancements'. If you have any problems/suggestions, let me
know.

Thanks,

Eddie


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

--
Mark Wilkinson
...on the road!


From senger at ebi.ac.uk  Fri Sep 16 08:16:49 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 09:16:49 +0100 (BST)
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509160914540.1437894-100000@mozart.ebi.ac.uk>

Thank you for your invitation. It will be my pleasure and honour to take
this tenure. I will do my best in the interests of the Biomoby community.

Regards,
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)



From Pieter.Neerincx at wur.nl  Fri Sep 16 13:37:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri, 16 Sep 2005 15:37:33 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4329bac6.25d8a4f3.6fb1.ffffb832@mx.gmail.com>
References: <4329bac6.25d8a4f3.6fb1.ffffb832@mx.gmail.com>
Message-ID: <D2F9CBDD-C6D9-4644-9267-EF3113A418FB@wur.nl>

Hi Eddie,

Thanks for the tools! Here's my feedback:

On 15-Sep-2005, at 8:17 PM, Edward Kawas wrote:

> Hi Pieter,
>
>
>
> I am sending you a link to a java based installer (GUI) that should  
> make installation very easy. If this is not useful for you, I will  
> create 3 war files and send you the links to them.
>
> http://bioinfo.icapture.ubc.ca/ekawas/servlets/install.jar
>
>
>
> Some people can run the jar file by double clicking it. If that  
> doesn?t work, then type at the command prompt
>
> java ?jar install.jar
This gave me:

     The java class is not found: -jar

Works fine though without the -jar :) So 'java install.jar' was enough.
>
>
> If that doesn?t work, then email me back and I will send you 3 war  
> files and let you know what to do with them.
>
>
>
> Assuming that all goes well, there are a few things for you to do,  
> configuration wise.
>
>
>
> You will have to edit the biomoby.properties file in 3 different  
> locations:
>
>
>
> /tomcat/webapps/RESOURCES/WEB-INF/classes/org/BioMoby/registry/ 
> properties
>
> /tomcat/webapps/types/WEB-INF/classes/org/BioMoby/registry/properties
>
> /tomcat/webapps/authority/WEB-INF/classes/org/BioMoby/registry/ 
> properties
Close, but the installer created ..../biomoby/.... instead of ..../ 
BioMoby/.... .
>
> Open this file in any one of the locations and modify the properties:
>
> ?config?  - this property points to mobycentral.conf(ig)
>
> ?lsid_port?  -  this is the port that tomcat is running on
Ok, that is a bit confusing though. Shouldn't it be labelled  
'tomcat_port' port then?
> ?lsid_domain? ? the domain that you would like your lsids to have
> ?resources_script_domain? ? the domain that the RESOURCES script (a  
> servlet you have installed) uses.
>
>  Save this file in the 3 above stated locations.
Ok, done. Editing one file and copying it 2 times was fast enough. So  
it's not a big deal, but I do wonder you why you would want to have  
this redundancy. Are people ever going to use different settings in  
these 3 locations? If not, then why not have just one file to rule 'm  
all?
>  Restart tomcat and let me know what happens! My fingers are  
> crossed ;-)
Well, nothing yet. At least Tomcat doesn't complain. Seems to be Ok.  
But in Taverna I see my custom services from my local central as  
before and my custom objects are missing as before. You didn't  
mention it, but I assume I need to update my BioMOBY API stuff as  
well. So I tried an cvs up -d of moby-live. When I try make test for  
the Perl stuff I see a lot of tests failing.... Can I safely ignore  
them for now?

Pieter


> Eddie
>
>
>
> From: Pieter Neerincx [mailto:Pieter.Neerincx at wur.nl]
> Sent: Thursday, September 15, 2005 10:19 AM
> To: Edward Kawas
> Subject: Fwd: [MOBY-dev] Moby objects in Taverna. Where do they  
> come from?
>
>
>
> Hi Eddie,
>
>
>
> I suspect some problems with the mailinglist. I send the mail below  
> to the mailinglist yesterday, but so I haven't received it back  
> yet. Haven't received any other mails from the list anymore and one  
> of your mails of on 13-Sep-2005 was the last one showing up in the  
> online archive....
>
>
>
> Anyway, Tomcat is up and running so I'm awaiting further  
> instructions :).
>
>
>
> Cheers,
>
>
>
> Pieter
>
>
>
> Begin forwarded message:
>
>
>
>
> From: Pieter Neerincx <Pieter.Neerincx at wur.nl>
>
> Date: 14-September-2005 1:04:53 PM GMT+02:00
>
> To: Core developer announcements <moby-dev at portal.open-bio.org>
>
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do they come  
> from?
>
>
>
>
>
> Ok, got Tomcat installed... Please tell me what to download from  
> where and where to install it...
>
>
>
> Thanks,
>
>
>
> Pieter
>
>
>
> On 13-Sep-2005, at 5:58 PM, Edward Kawas wrote:
>
>
>
>
>
>
> Great. I will be waiting ;-)
>
>
>
> Eddie
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>
> Neerincx
>
> Sent: Tuesday, September 13, 2005 8:49 AM
>
> To: Core developer announcements
>
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>
> they come from?
>
>
>
> Hi,
>
>
>
> On 13-Sep-2005, at 4:43 PM, Edward Kawas wrote:
>
>
>
>
>
>
>
>
> Hi,
>
>
>
> For the Taverna workbench, download it temporarily from
>
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>
>
>
>
>
> 1.2.
>
>
>
>
>
>
> zip
>
>
>
>
>
>
>
> I will...
>
>
>
>
>
>
>
>
> This version contains my changes (the ones that are in
>
>
>
>
>
> the
>
>
>
>
>
>
> Taverna CVS).
>
>
>
> The Moby api actually now has a method in it called
>
> getResources (or something similar to that) that returns
>
>
>
>
>
> the
>
>
>
>
>
>
> locations of these documents for a registry.
>
>
>
>
>
>
>
> Ok, that sounds like a much more elegant solution :).
>
>
>
>
>
>
>
>
> So in the newly
>
> updated version of the plugin, I have removed the
>
>
>
>
>
> textbox
>
>
>
>
>
>
> that asks for this url and replaced it with an api call.
>
> (a description on the Moby plugin can be found at
>
>
>
>
>
>
>
> http://bioinfo.icapture.ubc.ca/ekawas/guide/biomobyworker.
>
> ht
>
>
>
>
>
>
> ml but is being changed to reflect the api calling).
>
>
>
> You are correct in saying that we are moving towards
>
>
>
>
>
> having
>
>
>
>
>
>
> Services and datatypes described by RDF.
>
>
>
> Finally, as for the servlet installation, if you are
>
> interested, I can guide you through this relatively
>
>
>
>
>
> painless
>
>
>
>
>
>
> procedure. I would just need to update certain files
>
>
>
>
>
> that
>
>
>
>
>
>
> you need to download and you would have to install
>
>
>
>
>
> tomcat.
>
>
>
> Ok, I will start with tomcat tomorrow... and will request
>
> further
>
> advice one I have that one up and running...
>
>
>
> Pieter
>
>
>
>
>
>
>
>
>
>
> Eddie
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: moby-dev-bounces at portal.open-bio.org
>
>
>
>
>
> [mailto:moby-
>
>
>
>
>
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>
>> Neerincx
>>
>> Sent: Tuesday, September 13, 2005 7:18 AM
>>
>> To: Core developer announcements
>>
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where
>>
>>
>>
>>
> do
>
>
>
>
>
>> they come from?
>>
>>
>>
>> Hi Eddie,
>>
>>
>>
>> On 13-Sep-2005, at 3:08 PM, Edward Kawas wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>>
>>
>> Objects aren't hard coded. They just have to be
>>
>>
>>
>>
>>
>>
>>
>> registered
>>
>>
>>
>>
>>
>>
>>
>>
>> in Mobycentral.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Today I fetched the source code for Taverna and
>>
>>
>>
>>
> 'grep'ed
>
>
>
>
>
>> over the
>>
>> files. There are several instances where the path to
>>
>>
>>
>>
> the
>
>
>
>
>
>> central
>>
>> biomoby central and an RDF file are hardcoded outside
>>
>>
>>
>>
> the
>
>
>
>
>
>> files in
>>
>> conf/. Sometime ago I started to work with Taverna and
>>
>>
>>
>>
> the
>
>
>
>
>
>> user
>>
>> manual only mentions the path to a biomoby central in
>>
>>
>>
>>
> the
>
>
>
>
>
>> conf/
>>
>> mygrid.properties file. So I appended my local biomoby
>>
>> central to
>>
>> this conf file and expected this would allow me to use
>>
>> both services
>>
>> and objects registered in my local central. I think
>>
>>
>>
>>
> that
>
>
>
>
>
>> the current
>>
>> situation where service info is fetched from a URL in
>>
>>
>>
>>
> the
>
>
>
>
>
>> conf/
>>
>> mygrid.properties file and object info is fetched from
>>
>>
>>
>>
> a
>
>
>
>
>
>> RDF file at
>>
>> a different location is very confusing and needlessly
>>
>> complex.
>>
>> Especially since I cannot supply an URL to a custom RDF
>>
>> file for my
>>
>> objects in the conf/mygrid.properties file. I did see
>>
>> though that I
>>
>> can right-click in Taverna to add a scavenger and than
>>
>>
>>
>>
> I
>
>
>
>
>
>> can supply
>>
>> both an URL to my local central and an URL to this RDF
>>
>> file for the
>>
>> objects.
>>
>>
>>
>> I also browsed the mailinglist and wiki. Did I
>>
>>
>>
>>
> understand
>
>
>
>
>
>> correctly
>>
>> that the current situation is a temporary solution and
>>
>> that
>>
>> eventually all info (hence services and objects) will
>>
>>
>>
>>
> be
>
>
>
>
>
>> described
>>
>> using RDF? Please correct me if I'm wrong...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I am not sure if you are up for it, but you could
>>
>>
>>
>>
> always
>
>
>
>
>
>>> install the servlets
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> Are those servlets generating this RDF file from the
>>
>>
>>
>>
> info
>
>
>
>
>
>> in a central?
>>
>> Is this documented somewhere? I couldn't find any
>>
>> reference to
>>
>> servlets at
>>
>> http://www.biomoby.org/InstallingMOBYCentral.html ...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> (I could help you).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Your help is much appreciated! Thanks,
>>
>>
>>
>> Pieter
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Eddie
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>>
>> From: moby-dev-bounces at portal.open-bio.org
>>
>>
>>
>>
>>
>>
>>
>> [mailto:moby-
>>
>>
>>
>>
>>
>>
>>
>>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>>>
>>> Neerincx
>>>
>>> Sent: Tuesday, September 13, 2005 1:35 AM
>>>
>>> To: Core developer announcements
>>>
>>> Subject: Re: [MOBY-dev] Moby objects in Taverna.
>>>
>>>
>>>
>>>
> Where
>
>
>
>
>
>>>>
>>>>
>>>>
>>>>
>>>>
>> do
>>
>>
>>
>>
>>
>>
>>
>>> they come from?
>>>
>>>
>>>
>>> Hi Eddie,
>>>
>>>
>>>
>>> On 12-Sep-2005, at 5:10 PM, Edward Kawas wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> The answer basically is that you also need to set up
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> some
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> servlets (RESOURCES script, types, etc), if you have
>>>
>>>
>>>
>>>
> a
>
>
>
>
>
>>>>> custom registry.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Thanks for the quick feedback. I was already afraid
>>>>
>>>>
>>>>
>>>>
> it
>
>
>
>
>
>>>> would be
>>>>
>>>> something like that :(.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So Taverna is basically reading in your services,
>>>>
>>>>
>>>>
>>>>
> and
>
>
>
>
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> find the objects, so it probably defaults to the
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Mobycentral
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> registry.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Would it help if I register my objects at THE central
>>>>
>>>> mobycentral
>>>>
>>>> instead of in my local central? Or are the objects
>>>>
>>>> hardcoded in some
>>>>
>>>> jar file (like lib/jmoby.jar perhaps)?
>>>>
>>>>
>>>>
>>>> Pieter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Eddie
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>> From: moby-dev-bounces at portal.open-bio.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [mailto:moby-
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> dev-bounces at portal.open-bio.org] On Behalf Of
>>>>>
>>>>>
>>>>>
>>>>>
> Pieter
>
>
>
>
>
>>>>>> Neerincx
>>>>>>
>>>>>> Sent: Monday, September 12, 2005 8:06 AM
>>>>>>
>>>>>> To: Core developer announcements
>>>>>>
>>>>>> Subject: [MOBY-dev] Moby objects in Taverna. Where
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> do
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> they
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> come from?
>>>>>
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> I'm having some trouble to make BioMOBY work with
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Taverna.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I have a
>>>>>
>>>>> local development Moby central. When I register
>>>>>
>>>>>
>>>>>
>>>>>
> both
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> new
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> services and
>>>>>
>>>>> new objects I notice that only my custom services
>>>>>
>>>>>
>>>>>
>>>>>
> are
>
>
>
>
>
>>>>>> listed in
>>>>>>
>>>>>> Taverna. The list of moby objects is not in sync
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> with
>
>
>
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> what
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> is
>>>>>
>>>>> registered in my central. So where does Taverna get
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> those
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> objects
>>>>>
>>>>> from and how do I get my own objects in there? Does
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> anyone
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> have a clue?
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> Pieter
>>>>>
>>>>>
>>>>>
>>>>> Wageningen University and Research centre (WUR)
>>>>>
>>>>> Laboratory of Bioinformatics
>>>>>
>>>>> Transitorium (building 312) room 1034
>>>>>
>>>>> Dreijenlaan 3
>>>>>
>>>>> 6703 HA Wageningen
>>>>>
>>>>> The Netherlands
>>>>>
>>>>> phone: 0317-483 060
>>>>>
>>>>> fax: 0317-483 584
>>>>>
>>>>> mobile: 06-143 66 783
>>>>>
>>>>> pieter.neerincx at wur.nl
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> MOBY-dev mailing list
>>>>>
>>>>> MOBY-dev at biomoby.org
>>>>>
>>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> MOBY-dev mailing list
>>>>
>>>> MOBY-dev at biomoby.org
>>>>
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Wageningen University and Research centre (WUR)
>>>>
>>>> Laboratory of Bioinformatics
>>>>
>>>> Transitorium (building 312) room 1034
>>>>
>>>> Dreijenlaan 3
>>>>
>>>> 6703 HA Wageningen
>>>>
>>>> The Netherlands
>>>>
>>>> phone: 0317-483 060
>>>>
>>>> fax: 0317-483 584
>>>>
>>>> mobile: 06-143 66 783
>>>>
>>>> pieter.neerincx at wur.nl
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> MOBY-dev mailing list
>>>>
>>>> MOBY-dev at biomoby.org
>>>>
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> MOBY-dev mailing list
>>>
>>> MOBY-dev at biomoby.org
>>>
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> Wageningen University and Research centre (WUR)
>>
>> Laboratory of Bioinformatics
>>
>> Transitorium (building 312) room 1034
>>
>> Dreijenlaan 3
>>
>> 6703 HA Wageningen
>>
>> The Netherlands
>>
>> phone: 0317-483 060
>>
>> fax: 0317-483 584
>>
>> mobile: 06-143 66 783
>>
>> pieter.neerincx at wur.nl
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> MOBY-dev mailing list
>>
>> MOBY-dev at biomoby.org
>>
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev at biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx at wur.nl
>
>
>
>
>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev at biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
> _______________________________________________
>
> MOBY-dev mailing list
>
> MOBY-dev at biomoby.org
>
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx at wur.nl
>
>
>
>
>
>
>
>
>
>
>
>
>
> Wageningen University and Research centre (WUR)
>
> Laboratory of Bioinformatics
>
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
>
> 6703 HA Wageningen
>
> The Netherlands
>
> phone: 0317-483 060
>
> fax: 0317-483 584
>
> mobile: 06-143 66 783
>
> pieter.neerincx at wur.nl
>
>
>
>
>
>
>
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl






From edward.kawas at gmail.com  Fri Sep 16 13:54:24 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 06:54:24 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <D2F9CBDD-C6D9-4644-9267-EF3113A418FB@wur.nl>
Message-ID: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>

>I assume I need to update my BioMOBY API stuff as  
>well. So I tried an cvs up -d of moby-live. When I try make
>test for the Perl stuff I see a lot of tests failing....
>Can I safely ignore them for now?

I am not sure about this question. I know that Mark has a
new test suite but I am not sure if this is the suite that
you are running.

One more thing, if the servlets work, you would be able to
do the following:
http://yourURL:port/types/Objects
http://yourURL:port/RESOURCES/MOBY-S/Objects
http://yourURL:port/authority

These 3 links should show you something meaningful (html, a
file, more html).

Eddie



From Pieter.Neerincx at wur.nl  Fri Sep 16 14:04:24 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri, 16 Sep 2005 16:04:24 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
References: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
Message-ID: <2474E6AB-0592-4028-B15A-08062062350B@wur.nl>


On 16-Sep-2005, at 3:54 PM, Edward Kawas wrote:

>> I assume I need to update my BioMOBY API stuff as
>> well. So I tried an cvs up -d of moby-live. When I try make
>> test for the Perl stuff I see a lot of tests failing....
>> Can I safely ignore them for now?
>>
>
> I am not sure about this question. I know that Mark has a
> new test suite but I am not sure if this is the suite that
> you are running.

Ok, maybe Mark can shed some light on which version of the API is  
running on the current mobycentral server...

>
> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
> These 3 links should show you something meaningful (html, a
> file, more html).

Yes, works perfectly. I get xml/rdf returned and the first two links  
contain amongst others my custom objects :).


Pieter

>
> Eddie
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From senger at ebi.ac.uk  Fri Sep 16 14:10:38 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 15:10:38 +0100 (BST)
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ace96.441fb1bf.5d93.614d@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>

> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
   Well, my understanding (Eddie/Mark, correct me if I am mistaken please)
is that you should *not* used these URLs directly (and Eddie should not
advice it :-)). You should use a new API method 'retrieveResourceURLs'
which gives you those URLs.
   This new method is implemented, for example, in jMoby (Java libraries
for biomoby) - in Central.java interface. It is also described in the
biomoby API.
 
   Regards,
   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)



From edward.kawas at gmail.com  Fri Sep 16 14:16:12 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:16:12 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad3af.701b5241.51a9.ffffed46@mx.gmail.com>



>    Well, my understanding (Eddie/Mark, correct me if I am
> mistaken please)
> is that you should *not* used these URLs directly (and
> Eddie should not
> advice it :-)). You should use a new API method
> 'retrieveResourceURLs'
> which gives you those URLs.
>    This new method is implemented, for example, in jMoby
> (Java libraries
> for biomoby) - in Central.java interface. It is also
> described in the
> biomoby API.


Relax Martin ;-) Just wanted to ensure that the installation
worked!

Eddie





From senger at ebi.ac.uk  Fri Sep 16 14:22:27 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 15:22:27 +0100 (BST)
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad3af.701b5241.51a9.ffffed46@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161521130.1458011-100000@mozart.ebi.ac.uk>

> Relax Martin ;-) Just wanted to ensure that the installation
> worked!
>
   That's exactly my point: How he can be sure that an installation worked
if he does not test all methods that should be supported...

   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)



From edward.kawas at gmail.com  Fri Sep 16 14:25:04 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:25:04 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161521130.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad5c3.1aa4d48b.6fb1.ffffe6f6@mx.gmail.com>

>    That's exactly my point: How he can be sure that an
> installation worked
> if he does not test all methods that should be
supported...

Testing the servlet installation. 

The updated Moby code in Taverna utilizes the new api calls!



From senger at ebi.ac.uk  Fri Sep 16 14:30:46 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 15:30:46 +0100 (BST)
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad5c3.1aa4d48b.6fb1.ffffe6f6@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509161529570.1458011-100000@mozart.ebi.ac.uk>

> The updated Moby code in Taverna utilizes the new api calls!
>
   That's good.
   Which reminds me: have you reached (with Mark) a conclusion about the
content-type of these resources?

   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)



From Pieter.Neerincx at wur.nl  Fri Sep 16 14:35:13 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri, 16 Sep 2005 16:35:13 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509161506120.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <106CCC00-6072-41B9-82B5-C031F0E0F380@wur.nl>


On 16-Sep-2005, at 4:10 PM, Martin Senger wrote:

>> One more thing, if the servlets work, you would be able to
>> do the following:
>> http://yourURL:port/types/Objects
>> http://yourURL:port/RESOURCES/MOBY-S/Objects
>> http://yourURL:port/authority
>>
>>
>    Well, my understanding (Eddie/Mark, correct me if I am mistaken  
> please)
> is that you should *not* used these URLs directly (and Eddie should  
> not
> advice it :-)).

That does make sense, but having a quick look at what those URLs  
produce just to get an quick idea whether those servlets are working  
in Tomcat at all can't hurt :)

> You should use a new API method 'retrieveResourceURLs'
> which gives you those URLs.
>    This new method is implemented, for example, in jMoby (Java  
> libraries
> for biomoby) - in Central.java interface. It is also described in the
> biomoby API.

Ok, so I definitely should upgrade my biomoby API as well...

Thanks,

Pieter

>
>    Regards,
>    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)
>
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Fri Sep 16 14:41:22 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:41:22 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <106CCC00-6072-41B9-82B5-C031F0E0F380@wur.nl>
Message-ID: <432ad996.18f52057.633b.2430@mx.gmail.com>

> Ok, so I definitely should upgrade my biomoby API as
> well...
Yes. Perhaps others who have done this upgrade could give
you a few pointers. Anyone?!

Thanks,

Ed



From edward.kawas at gmail.com  Fri Sep 16 14:42:35 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:42:35 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <Pine.OSF.4.21.0509161529570.1458011-100000@mozart.ebi.ac.uk>
Message-ID: <432ad9de.370ca386.0467.ffffc707@mx.gmail.com>


>    That's good.
>    Which reminds me: have you reached (with Mark) a
> conclusion about the
> content-type of these resources?


If only you could hear me whistling aloud as I look the
other way.

We haven't discussed this yet. Sorry Martin.

Eddie



From Pieter.Neerincx at wur.nl  Fri Sep 16 15:01:12 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Fri, 16 Sep 2005 17:01:12 +0200
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <6C0F151C-AB25-470F-A8E9-89996DCC051F@wur.nl>

Hi Frank,

On 16-Sep-2005, at 4:26 PM, Gibbons, Francis wrote:

> Pieter,
>
> I wrote many of the tests for the  Perl API. When I run them, I see  
> a 99% pass rate, or better. I'm very interested to know which ones  
> are failing for you, and what your local installation looks like (I  
> guess you have a local registry? what's your OS? Perl version? etc.)

I'm running SuSE Linux Enterprise Server 9 (SLES9) with all the  
latest and greatest updates / patches. My Perl version is 5.8.3  
(default that comes with SLES9) I do have a local biomobycentral, but  
that shouldn't make any difference for the tests. I haven't set  
MOBY_xxx ENV vars, so for the tests  everything should default to the  
central mobycentral.

I see 3/361 subtests failed, 99.17% okay and 8 subtests UNEXPECTEDLY  
SUCCEEDED. The 99.17% might seem not too shabby, but for a user like  
me it's pretty difficult to figure out how essential the failing  
stuff is :(.... I'll just give it try anyway. If it doesn't work I'll  
downgrade again. Keeping my fingers crossed...

Below is what I got from the tests.

Cheers,

Pieter

pieter at bioinfw05:~/moby-live/Perl> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Central...................................ok
t/Client-Central............................NOK 3#     Failed test (t/ 
Client-Central.t at line 73)
#     MOBY::Client::Central->can('retrieveObjectSchema') failed
# Registry failed to supply mandatory methods
t/Client-Central............................ok 134/0# Looks like you  
failed 1 tests of 134.
t/Client-Central............................dubious
         Test returned status 1 (wstat 256, 0x100)
Scalar found where operator expected at (eval 153) line 1, near  
"'int'  $__val"
         (Missing operator before   $__val?)
DIED. FAILED test 3
         Failed 1/134 tests, 99.25% okay
t/Client-CollectionArticle..................ok
t/Client-OntologyServer.....................NOK 2#     Failed test (t/ 
Client-OntologyServer.t at line 36)
#     MOBY::Client::OntologyServer->can('relationshipExists') failed
# OntologyServer doesn't implement full API
t/Client-OntologyServer.....................ok 24/0Use of  
uninitialized value in pattern match (m//) at /mnt/geninf01/home/ 
geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/OntologyServer.pm  
line 98.
Use of uninitialized value in pattern match (m//) at /mnt/geninf01/ 
home/geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/ 
OntologyServer.pm line 98.
t/Client-OntologyServer.....................ok 25/0No such method:  
MOBY::Client::OntologyServer::relationshipExists at t/Client- 
OntologyServer.t line 76
# Looks like you failed 1 tests of 25.
# Looks like your test died just after 25.
t/Client-OntologyServer.....................dubious
         Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED test 2
         Failed 1/25 tests, 96.00% okay
t/Client-Registration.......................ok
t/Client-SecondaryArticle...................ok
t/Client-Service............................NOK 3#     Failed test (t/ 
Client-Service.t at line 36)
#     MOBY::Client::Service->can('serviceName') failed
# MOBY::Client::Service doesn't implement full API.
t/Client-Service............................ok 6/0# Looks like you  
failed 1 tests of 6.
t/Client-Service............................dubious
         Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 3
         Failed 1/6 tests, 83.33% okay
t/Client-ServiceInstance....................ok
t/Client-SimpleArticle......................ok
t/CommonSubs................................ok 18/0MOBY::CommonSubs  
WARNING ** the namespace 'bogus NS' does not exist in the MOBY  
ontology, and does not have a valid LSID
t/CommonSubs................................ok
t/Config....................................skipped
         all skipped: Required only for local MOBY Central
t/CrossReference............................ok
t/dbConnect.................................ok
t/lsid-authority-ClassResolver..............ok
t/lsid-authority-dbConnect..................ok
t/lsid-authority-Error......................ok
t/lsid-authority-NamespaceResolver..........ok
t/lsid-authority-PredicateResolver..........ok
t/lsid-authority-RDFConfigure...............ok
t/lsid-authority-RelationshipResolver.......ok
t/lsid-authority-ServiceInstanceResolver....skipped
         all skipped: Skip until apparent namespace pollution fixed  
in ServiceInstanceResolver
t/lsid-authority-ServiceResolver............ok
t/Template..................................skipped
         all skipped: This is just a template
Failed Test               Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------ 
-------
t/Client-Central.t           1   256   134    1   0.75%  3
t/Client-OntologyServer.t  255 65280    25    1   4.00%  2
t/Client-Service.t           1   256     6    1  16.67%  3
  (8 subtests UNEXPECTEDLY SUCCEEDED), 3 tests skipped.
Failed 3/23 test scripts, 86.96% okay. 3/361 subtests failed, 99.17%  
okay.
make: *** [test_dynamic] Error 255


> Clearly, we should have a test suite that passes for most  
> developers most of the time, so that they can be alerted quickly if  
> they break something. So it's really important for me to know which  
> tests are failing and why: the tests may need to be rewritten.
>
> Thanks for your feedback.
>
> -Frank
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org on behalf of Edward Kawas
> Sent: Fri 9/16/2005 9:54 AM
> To: 'Core developer announcements'
> Cc: 'Pieter Neerincx'
> Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come  
> from?
>
> >I assume I need to update my BioMOBY API stuff as
> >well. So I tried an cvs up -d of moby-live. When I try make
> >test for the Perl stuff I see a lot of tests failing....
> >Can I safely ignore them for now?
>
> I am not sure about this question. I know that Mark has a
> new test suite but I am not sure if this is the suite that
> you are running.
>
> One more thing, if the servlets work, you would be able to
> do the following:
> http://yourURL:port/types/Objects
> http://yourURL:port/RESOURCES/MOBY-S/Objects
> http://yourURL:port/authority
>
> These 3 links should show you something meaningful (html, a
> file, more html).
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Fri Sep 16 14:14:50 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 16 Sep 2005 07:14:50 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <2474E6AB-0592-4028-B15A-08062062350B@wur.nl>
Message-ID: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>

> Yes, works perfectly. I get xml/rdf returned and the first
> two links
> contain amongst others my custom objects :).

Great! That is good news.

Eddie



From fgibbons at hms.harvard.edu  Fri Sep 16 16:27:30 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri, 16 Sep 2005 12:27:30 -0400
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <6C0F151C-AB25-470F-A8E9-89996DCC051F@wur.nl>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <5.2.1.1.2.20050916121257.0123eca0@email.med.harvard.edu>

Pieter,

Thanks for the quick feedback. In fact, your output is pretty much the same 
as mine, specifically in the tests that failed. There are also some which 
"unexpectedly succeed" for me too, I just haven't had a chance to check 
what they are.

The failing stuff is for the most part, apparently not that important. It 
represents aspects of the stated API (in particularly when it says "failed 
to implement complete API" or similar): methods which the API describes, 
but which are not yet implemented. I just got involved recently as a 
developer, and writing tests has been my way to understand the API, from 
the inside out. I'll modify the tests so that these go on the TO-DO list, 
and no longer generate error messages (it's not clear when they will 
actually be implemented).

There is one failure that concerns me, this one:

t/Client-Central............................dubious
         Test returned status 1 (wstat 256, 0x100)
Scalar found where operator expected at (eval 153) line 1, near
"'int'  $__val"
         (Missing operator before   $__val?)
DIED. FAILED test 3
         Failed 1/134 tests, 99.25% okay

I don't understand what '$__val' is referring to. More importantly, it 
looks like it's causing the entire test to abort ("DIED"), yet it reports 
only 1/134 failed. There are no explicit eval's in the test script, perhaps 
the message is coming from a module that is imported with 'use'.  I've 
searched the MOBY codebase, and there is no variable with that name, so it 
may be coming in from an external module.  If you have any ideas, I'm 
interested in hearing them, since this single script represents about half 
of the current tests, so if it aborts, especially if it aborts reporting 
success, that's a problem.

So thanks again for the feedback. I'll fix most of those problems I 
mentioned, which should make the remaining one (above) stand out more.

-Frank

At 11:01 AM 9/16/2005, you wrote:
>Hi Frank,
>
>On 16-Sep-2005, at 4:26 PM, Gibbons, Francis wrote:
>
>>Pieter,
>>
>>I wrote many of the tests for the  Perl API. When I run them, I see
>>a 99% pass rate, or better. I'm very interested to know which ones
>>are failing for you, and what your local installation looks like (I
>>guess you have a local registry? what's your OS? Perl version? etc.)
>
>I'm running SuSE Linux Enterprise Server 9 (SLES9) with all the
>latest and greatest updates / patches. My Perl version is 5.8.3
>(default that comes with SLES9) I do have a local biomobycentral, but
>that shouldn't make any difference for the tests. I haven't set
>MOBY_xxx ENV vars, so for the tests  everything should default to the
>central mobycentral.
>
>I see 3/361 subtests failed, 99.17% okay and 8 subtests UNEXPECTEDLY
>SUCCEEDED. The 99.17% might seem not too shabby, but for a user like
>me it's pretty difficult to figure out how essential the failing
>stuff is :(.... I'll just give it try anyway. If it doesn't work I'll
>downgrade again. Keeping my fingers crossed...
>
>Below is what I got from the tests.
>
>Cheers,
>
>Pieter
>
>pieter at bioinfw05:~/moby-live/Perl> make test
>PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
>"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
>t/Central...................................ok
>t/Client-Central............................NOK 3#     Failed test (t/ 
>Client-Central.t at line 73)
>#     MOBY::Client::Central->can('retrieveObjectSchema') failed
># Registry failed to supply mandatory methods
>t/Client-Central............................ok 134/0# Looks like you
>failed 1 tests of 134.
>t/Client-Central............................dubious
>         Test returned status 1 (wstat 256, 0x100)
>Scalar found where operator expected at (eval 153) line 1, near
>"'int'  $__val"
>         (Missing operator before   $__val?)
>DIED. FAILED test 3
>         Failed 1/134 tests, 99.25% okay
>t/Client-CollectionArticle..................ok
>t/Client-OntologyServer.....................NOK 2#     Failed test (t/ 
>Client-OntologyServer.t at line 36)
>#     MOBY::Client::OntologyServer->can('relationshipExists') failed
># OntologyServer doesn't implement full API
>t/Client-OntologyServer.....................ok 24/0Use of
>uninitialized value in pattern match (m//) at /mnt/geninf01/home/ 
>geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/OntologyServer.pm
>line 98.
>Use of uninitialized value in pattern match (m//) at /mnt/geninf01/ 
>home/geninf/pieter/moby-live/Perl/blib/lib/MOBY/Client/ OntologyServer.pm 
>line 98.
>t/Client-OntologyServer.....................ok 25/0No such method:
>MOBY::Client::OntologyServer::relationshipExists at t/Client- 
>OntologyServer.t line 76
># Looks like you failed 1 tests of 25.
># Looks like your test died just after 25.
>t/Client-OntologyServer.....................dubious
>         Test returned status 255 (wstat 65280, 0xff00)
>DIED. FAILED test 2
>         Failed 1/25 tests, 96.00% okay
>t/Client-Registration.......................ok
>t/Client-SecondaryArticle...................ok
>t/Client-Service............................NOK 3#     Failed test (t/ 
>Client-Service.t at line 36)
>#     MOBY::Client::Service->can('serviceName') failed
># MOBY::Client::Service doesn't implement full API.
>t/Client-Service............................ok 6/0# Looks like you
>failed 1 tests of 6.
>t/Client-Service............................dubious
>         Test returned status 1 (wstat 256, 0x100)
>DIED. FAILED test 3
>         Failed 1/6 tests, 83.33% okay
>t/Client-ServiceInstance....................ok
>t/Client-SimpleArticle......................ok
>t/CommonSubs................................ok 18/0MOBY::CommonSubs
>WARNING ** the namespace 'bogus NS' does not exist in the MOBY
>ontology, and does not have a valid LSID
>t/CommonSubs................................ok
>t/Config....................................skipped
>         all skipped: Required only for local MOBY Central
>t/CrossReference............................ok
>t/dbConnect.................................ok
>t/lsid-authority-ClassResolver..............ok
>t/lsid-authority-dbConnect..................ok
>t/lsid-authority-Error......................ok
>t/lsid-authority-NamespaceResolver..........ok
>t/lsid-authority-PredicateResolver..........ok
>t/lsid-authority-RDFConfigure...............ok
>t/lsid-authority-RelationshipResolver.......ok
>t/lsid-authority-ServiceInstanceResolver....skipped
>         all skipped: Skip until apparent namespace pollution fixed
>in ServiceInstanceResolver
>t/lsid-authority-ServiceResolver............ok
>t/Template..................................skipped
>         all skipped: This is just a template
>Failed Test               Stat Wstat Total Fail  Failed  List of Failed
>------------------------------------------------------------------------ 
>-------
>t/Client-Central.t           1   256   134    1   0.75%  3
>t/Client-OntologyServer.t  255 65280    25    1   4.00%  2
>t/Client-Service.t           1   256     6    1  16.67%  3
>  (8 subtests UNEXPECTEDLY SUCCEEDED), 3 tests skipped.
>Failed 3/23 test scripts, 86.96% okay. 3/361 subtests failed, 99.17%
>okay.
>make: *** [test_dynamic] Error 255
>
>
>>Clearly, we should have a test suite that passes for most
>>developers most of the time, so that they can be alerted quickly if
>>they break something. So it's really important for me to know which
>>tests are failing and why: the tests may need to be rewritten.
>>
>>Thanks for your feedback.
>>
>>-Frank
>>-----Original Message-----
>>From: moby-dev-bounces at portal.open-bio.org on behalf of Edward Kawas
>>Sent: Fri 9/16/2005 9:54 AM
>>To: 'Core developer announcements'
>>Cc: 'Pieter Neerincx'
>>Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come
>>from?
>>
>> >I assume I need to update my BioMOBY API stuff as
>> >well. So I tried an cvs up -d of moby-live. When I try make
>> >test for the Perl stuff I see a lot of tests failing....
>> >Can I safely ignore them for now?
>>
>>I am not sure about this question. I know that Mark has a
>>new test suite but I am not sure if this is the suite that
>>you are running.
>>
>>One more thing, if the servlets work, you would be able to
>>do the following:
>>http://yourURL:port/types/Objects
>>http://yourURL:port/RESOURCES/MOBY-S/Objects
>>http://yourURL:port/authority
>>
>>These 3 links should show you something meaningful (html, a
>>file, more html).
>>
>>Eddie
>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>Wageningen University and Research centre (WUR)
>Laboratory of Bioinformatics
>Transitorium (building 312) room 1034
>Dreijenlaan 3
>6703 HA Wageningen
>The Netherlands
>phone: 0317-483 060
>fax: 0317-483 584
>mobile: 06-143 66 783
>pieter.neerincx at wur.nl
>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From fgibbons at hms.harvard.edu  Fri Sep 16 17:59:10 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri, 16 Sep 2005 13:59:10 -0400
Subject: [MOBY-dev] I have a subscription,
 but I keep getting messages saying I'm not subscribed....
Message-ID: <5.2.1.1.2.20050916135616.027b2030@email.med.harvard.edu>

Can anyone help me with this: I am signed up for MOBY-dev, but every time I 
post, I get a message telling me that I'm not, and that my posting is 
awaiting approval by the moderators. I recently (yesterday) changed from 
digest mode to getting each message as it's posted on MOBY-l, and this 
behavior seemed to coincide with that. Does anyone know what I should do? 
Would unsubscribing and resubscribing be the way to go?

Thanks,

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From fgibbons at hms.harvard.edu  Fri Sep 16 18:02:24 2005
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri, 16 Sep 2005 14:02:24 -0400
Subject: [MOBY-dev] Schedule? You mean there's a schedule?
In-Reply-To: <200509152247.j8FMlBnq032114@portal.open-bio.org>
Message-ID: <5.2.1.1.2.20050916140030.01161200@email.med.harvard.edu>

Mark,

At 06:47 PM 9/15/2005, moby-dev-request at portal.open-bio.org wrote:
>Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep on schedule.
                                                                                             ^^^^^^^^^^^^

Mark,

So what is thing you call a "schedule"? Where might an interested party 
find it, if so inclined.... :-)

(I know you're on vacay, no rush, just curious/kidding.)

-F


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From senger at ebi.ac.uk  Fri Sep 16 18:37:50 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 16 Sep 2005 19:37:50 +0100 (BST)
Subject: [MOBY-dev] I have a subscription, but I keep getting messages
	saying I'm not subscribed....
In-Reply-To: <5.2.1.1.2.20050916135616.027b2030@email.med.harvard.edu>
Message-ID: <Pine.OSF.4.21.0509161936370.1458011-100000@mozart.ebi.ac.uk>

> behavior seemed to coincide with that. Does anyone know what I should do? 
> Would unsubscribing and resubscribing be the way to go?
>
   Because Mark is on holiday, you may try and ask directly the admin of
the open-bio: Chris Dagdigian <dag at sonsorol.org>.
 
   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)



From simont at mcw.edu  Fri Sep 16 17:50:12 2005
From: simont at mcw.edu (Twigger Simon)
Date: Fri, 16 Sep 2005 12:50:12 -0500
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <A8FC74D9-A5A5-47DB-BC93-8FB52365226B@mcw.edu>

Hi Mark, Eddie,

Thanks for the invite, I am certainly happy to help out on the RFC  
committee. I promise to vote early and often.

Simon,


On Sep 15, 2005, at 5:46 PM, Edward Kawas wrote:

>
>
> -----Original Message-----
> From: mark wilkinson [mailto:markw at illuminae.com]
> Sent: Thursday, September 15, 2005 3:06 PM
> To: Frank Gibbons; Eddie Kawas
> Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
> Error-handling in MOBY-S
>
> Hey Frank! Cc Eddie
>
> Thanks for riding this.  I am on holiday, and not in Net
> contact except by blackberry, so I'm not "useful" right now.
>
> I think we should put out an invitation on the -dev list for
> the RFC committee with a tenure of one year, but also
> specifically invite the main developers/vested interests to
> be part of it:  me, you, martin, eddie, simon, heiko, paul,
> yan wong, and at least one from the spanish contingent (have
> I missed anyone?).
>
> I don't have all their email addresses on my bberry so
> unless you or Eddie (cc'd) post this invitation to the dev
> list yourselves it may take a week before I am back in
> net-world.  Eddie, could you do this? Tomorrow or this
> afternoon?  It would be good to get this sorted asap to keep
> on schedule.
>
> M
>
>
> -----Original Message-----
> From: Frank Gibbons <fgibbons at hms.harvard.edu>
> Date: Thu, 15 Sep 2005 11:21:53
> To:moby-l at biomoby.org
> Subject: [MOBY-l] Using bugzilla to continue RFC on
> Error-handling in MOBY-S
>
> Hi,
>
> I've just added a few "bugs" to the bugzilla, to try to
> preserve the RFC
> momentum built up over the past few weeks. I propose that,
> although
> bugzilla is perhaps not ideal for this, it is what it is, it
> is what we
> have, and it will do for now.
>
> I'd like to propose that we try to continue development of
> this RFC through
> bugzilla (see bug #1863), rather than through the mailing
> list. Searching
> through old mail messages (or worse still, through the
> digest, with all of
> its repeated messages and long inclusions) is tedious, and I
> think
> contributes to the loss in momentum.
>
> So far, in Martin's scheme for RFC-processing, we have
> (numbers are those
> used in Martin's original suggestion, now available in the
> codebase as
> Docs/MOBY-S_API/RFC.html)
>
> 1. Had a suggestion made by INB to add this features. It was
> added to
> bugzilla, No. 1863
> 2. Suggested to resolve it by today (Sep-15)
> 3. Martin backed up the RFC
> 4. I think we have the resources to make this change - it
> seems an
> essential part of a robust API, which version 1.0 should be.
> 5a. List members have exchanged several comments back and
> forth, resulting
> in amended versions of the RFC being posted to the mailing
> list.
> 5b. We've also gotten a little side-tracked by the related
> articleName problem.
>
> So it seems to me that it's time to vote on it (step 6 of
> the Senger
> seven-step scheme ;-). Martin suggested that Mark would ask
> a limited
> number of people to vote on it after the resolution date
> (today). I guess
> those people would self-select, or maybe Mark will select
> them. They will
> be requested to make a one-year commitment.
>
> After that comes step 7, the "fun part": implementation,
> documentation.
>
> We're pretty close to reaching a conclusion on this. The
> fact is that even
> if we do nothing, people want this functionality, and they
> WILL implement
> it. It is in everybody's interest that we have a
> specification for what the
> functionality should be. It may change over time, but I
> think there has
> been enough back-and-forth that we have a reasonable first
> draft, and
> should vote on it.
>
> -Frank
> P.S. Of course, this message, along with version 1.7.1 of
> the RFC is
> attached to the bug on bugzilla
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
> Boston MA 02115, USA.
> Tel: 617-432-3555       Fax:
> 617-432-3557       http://llama.med.harvard.edu/~fgibbons
>
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>
> --
> Mark Wilkinson
> ..on the road!
>
>

--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw



From markw at illuminae.com  Fri Sep 16 23:05:49 2005
From: markw at illuminae.com (mark wilkinson)
Date: Fri, 16 Sep 2005 23:05:49 +0000 GMT
Subject: [MOBY-dev] Schedule? You mean there's a schedule?
Message-ID: <1955319201-1126912049-cardhu_blackberry.rim.net-17094-@engine09-cell01>

I just meant that we had decided to have the vote on the 15th, but the committee has not been assembed yet, so we are a bit behind schedule for that vote :-)

M


-----Original Message-----
From: Frank Gibbons <fgibbons at hms.harvard.edu>
Date: Fri, 16 Sep 2005 14:02:24 
To:moby-dev at biomoby.org
Subject: [MOBY-dev] Schedule? You mean there's a schedule?

Mark,

At 06:47 PM 9/15/2005, moby-dev-request at portal.open-bio.org wrote:
>Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep on schedule.
                                                                                             ^^^^^^^^^^^^

Mark,

So what is thing you call a "schedule"? Where might an interested party 
find it, if so inclined.... :-)

(I know you're on vacay, no rush, just curious/kidding.)

-F


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

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

--
Mark Wilkinson
...on the road!


From senger at ebi.ac.uk  Mon Sep 19 07:30:09 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 19 Sep 2005 08:30:09 +0100 (BST)
Subject: [MOBY-dev] jMoby:  caching in CentralImpl
In-Reply-To: <42CEC551.4090108@ucalgary.ca>
Message-ID: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>

Paul (and others),
   I have mentioned in Vancouver that I would like to remove caching from
CentralImpl because we have now probably more powerfull caching in
CentralDigestCachedImpl (which I am improving now), and we will have even
better caching when we implement it based on RDF Resources. You said that
I can go ahead. But I would like to confirm it because removing it from
CentralImpl may break some of your code (or of the others).
   Do I have your green lights?

   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)



From senger at ebi.ac.uk  Mon Sep 19 07:41:33 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 19 Sep 2005 08:41:33 +0100 (BST)
Subject: [MOBY-dev] API for retrieving namespaces insufficient
Message-ID: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>

Mark,
   I know that the registry API can be replaced by its RDF representation,
but it is still an API and we are using it a lot (because for simple
requests it will be always faster than retrieving the whole RDF
document). That's why I would like to make it better. One missing thing
(actually a 'sink' :-)) is that you register some attributes for a
namespace but there is no way to get it back (that's why I said '
sink'). For example, authority. I suggest that you could add it to the
object returned from retrieveNamespaces. Do it for me please...

   Add there something like please:
           <contactEmail>your_name at contact.address.com</contactEmail>
           <authURI>Your.URI.here</authURI>

   Does anybody object?
   If not, could Eddie make it soon please (well, I mean now :-)?

   The same applies, of course, for service types. These two (and, afaik,
only these two) sinks exist in the current API).

   Many thanks,
   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)



From dgpisano at cnb.uam.es  Mon Sep 19 09:12:57 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon, 19 Sep 2005 11:12:57 +0200
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure of
	one year
In-Reply-To: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
Message-ID: <432E8119.4030502@cnb.uam.es>

I'll be glad to represent the INB (aka "The Spanish Contingent") in the 
RFC commitee for a year. Thanks for your invitation,

David

Edward Kawas escribi?:

>-----Original Message-----
>From: mark wilkinson [mailto:markw at illuminae.com] 
>Sent: Thursday, September 15, 2005 3:06 PM
>To: Frank Gibbons; Eddie Kawas
>Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
>Error-handling in MOBY-S
>
>Hey Frank! Cc Eddie
>
>Thanks for riding this.  I am on holiday, and not in Net
>contact except by blackberry, so I'm not "useful" right now.
>
>I think we should put out an invitation on the -dev list for
>the RFC committee with a tenure of one year, but also
>specifically invite the main developers/vested interests to
>be part of it:  me, you, martin, eddie, simon, heiko, paul,
>yan wong, and at least one from the spanish contingent (have
>I missed anyone?).
>
>I don't have all their email addresses on my bberry so
>unless you or Eddie (cc'd) post this invitation to the dev
>list yourselves it may take a week before I am back in
>net-world.  Eddie, could you do this? Tomorrow or this
>afternoon?  It would be good to get this sorted asap to keep
>on schedule.
>
>M
>
>
>-----Original Message-----
>From: Frank Gibbons <fgibbons at hms.harvard.edu>
>Date: Thu, 15 Sep 2005 11:21:53 
>To:moby-l at biomoby.org
>Subject: [MOBY-l] Using bugzilla to continue RFC on
>Error-handling in MOBY-S
>
>Hi,
>
>I've just added a few "bugs" to the bugzilla, to try to
>preserve the RFC 
>momentum built up over the past few weeks. I propose that,
>although 
>bugzilla is perhaps not ideal for this, it is what it is, it
>is what we 
>have, and it will do for now.
>
>I'd like to propose that we try to continue development of
>this RFC through 
>bugzilla (see bug #1863), rather than through the mailing
>list. Searching 
>through old mail messages (or worse still, through the
>digest, with all of 
>its repeated messages and long inclusions) is tedious, and I
>think 
>contributes to the loss in momentum.
>
>So far, in Martin's scheme for RFC-processing, we have
>(numbers are those 
>used in Martin's original suggestion, now available in the
>codebase as 
>Docs/MOBY-S_API/RFC.html)
>
>1. Had a suggestion made by INB to add this features. It was
>added to 
>bugzilla, No. 1863
>2. Suggested to resolve it by today (Sep-15)
>3. Martin backed up the RFC
>4. I think we have the resources to make this change - it
>seems an 
>essential part of a robust API, which version 1.0 should be.
>5a. List members have exchanged several comments back and
>forth, resulting 
>in amended versions of the RFC being posted to the mailing
>list.
>5b. We've also gotten a little side-tracked by the related
>articleName problem.
>
>So it seems to me that it's time to vote on it (step 6 of
>the Senger 
>seven-step scheme ;-). Martin suggested that Mark would ask
>a limited 
>number of people to vote on it after the resolution date
>(today). I guess 
>those people would self-select, or maybe Mark will select
>them. They will 
>be requested to make a one-year commitment.
>
>After that comes step 7, the "fun part": implementation,
>documentation.
>
>We're pretty close to reaching a conclusion on this. The
>fact is that even 
>if we do nothing, people want this functionality, and they
>WILL implement 
>it. It is in everybody's interest that we have a
>specification for what the 
>functionality should be. It may change over time, but I
>think there has 
>been enough back-and-forth that we have a reasonable first
>draft, and 
>should vote on it.
>
>-Frank
>P.S. Of course, this message, along with version 1.7.1 of
>the RFC is 
>attached to the bug on bugzilla
>
>PhD, Computational Biologist,
>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
>Boston MA 02115, USA.
>Tel: 617-432-3555       Fax: 
>617-432-3557       http://llama.med.harvard.edu/~fgibbons 
>
>_______________________________________________
>moby-l mailing list
>moby-l at biomoby.org
>http://biomoby.org/mailman/listinfo/moby-l
>
>--
>Mark Wilkinson
>..on the road!
>
>
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050919/8552b4c0/attachment.vcf>

From pieter.neerincx at wur.nl  Mon Sep 19 09:41:45 2005
From: pieter.neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 19 Sep 2005 11:41:45 +0200
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
References: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
Message-ID: <36612E59-02E5-41BB-842A-EF368649EB2B@wur.nl>

Hi Frank,

On 16-Sep-2005, at 8:04 PM, Frank Gibbons wrote:

> Hi Pieter,
>
> I've updated the tests and some of the Perl code, so that *nothing*  
> should fail now.

Thanks. It's a good thing you already created tests for parts of the  
API that have not been implemented yet. But it's even better that  
those tests don't confuse users anymore :).

> You might see messages about _skip_ped tests, but nothing about  
> "unexpectedly succeed"ing tests, etc. In particular, if Client- 
> Central.t still fails, I'm interested in finding out why.

Client-Central.t is fine now. I also don't know where the '$__val'  
came from. But the tests are not complaining about it anymore :) In  
addition to some messages about skipped tests I do get a warning  
about a non-existing 'bogus NS' in CommonSubs.t. See below for the  
output of the tests. I assume it's safe to ignore that one.

>
> -Frank
>

Cheers,

Pieter


pieter at bioinfw05:~/moby-live/Perl> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Central...................................ok
t/Client-Central............................ok
t/Client-CollectionArticle..................ok
t/Client-OntologyServer.....................ok
         5/39 skipped: relationshipExists not implemented
t/Client-Registration.......................ok
t/Client-SecondaryArticle...................ok
t/Client-Service............................ok
t/Client-ServiceInstance....................ok
t/Client-SimpleArticle......................ok
t/CommonSubs................................ok 18/0MOBY::CommonSubs  
WARNING ** the namespace 'bogus NS' does not exist in the MOBY  
ontology, and does not have a valid LSID
t/CommonSubs................................ok
t/Config....................................skipped
         all skipped: Required only for local MOBY Central
t/CrossReference............................ok
t/dbConnect.................................ok
t/lsid-authority-ClassResolver..............ok
t/lsid-authority-dbConnect..................ok
t/lsid-authority-Error......................ok
t/lsid-authority-NamespaceResolver..........ok
t/lsid-authority-PredicateResolver..........ok
t/lsid-authority-RDFConfigure...............ok
t/lsid-authority-RelationshipResolver.......ok
t/lsid-authority-ServiceInstanceResolver....skipped
         all skipped: Skip until apparent namespace pollution fixed  
in ServiceInstanceResolver
t/lsid-authority-ServiceResolver............ok
t/Template..................................skipped
         all skipped: This is just a template
All tests successful, 3 tests and 5 subtests skipped.
Files=23, Tests=376, 61 wallclock secs ( 4.61 cusr +  0.59 csys =   
5.20 CPU)


From Pieter.Neerincx at wur.nl  Mon Sep 19 13:04:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 19 Sep 2005 15:04:33 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>
References: <432ad35d.41928bb4.633b.1a3f@mx.gmail.com>
Message-ID: <7FA8D0EE-81DE-4DF1-95BE-146E5EB55DC6@wur.nl>

Hi Eddie,

I think I'm almost there. When I use the 'old / official' Taverna 1.2  
and manually add a biomoby scavanger for my local central (supplying  
both an URL to my biomoby central registry and my biomoby object RDF  
document) it works. I get both my custom services and custom objects  
listed in Taverna. So the servlets and Tomcat are doing there job.  
But when I use you modified version of Taverna from: http:// 
bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.zip it doesn't  
work. The custom objects are still missing. I updated my biomoby API  
stuff once more today from CVS, but that didn't help.... I was  
wondering if it is necessary to put some additional lines in my  
mobycentral.config file. After browsing the code it seems to me that  
MOBY::Central->retrieveResourceURLs tries to fetch resourceURL and  
allResources lines from that file...

Cheers,

Pieter




On 16-Sep-2005, at 4:14 PM, Edward Kawas wrote:

>> Yes, works perfectly. I get xml/rdf returned and the first
>> two links
>> contain amongst others my custom objects :).
>>
>
> Great! That is good news.
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Mon Sep 19 13:11:25 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 19 Sep 2005 06:11:25 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <7FA8D0EE-81DE-4DF1-95BE-146E5EB55DC6@wur.nl>
Message-ID: <432eb8ff.589d431d.4335.2914@mx.gmail.com>

Hi,

> I
> was
> wondering if it is necessary to put some additional lines
> in my
> mobycentral.config file. After browsing the code it seems
> to me that
> MOBY::Central->retrieveResourceURLs tries to fetch
> resourceURL and
> allResources lines from that file...

[mobycentral]
dbname = mobycentral
rdfagent = /usr/local/apache2/MOBY/rdfagent
lsid_authority = biomoby.org
lsid_namespace = serviceinstance
resourceURL =
http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
allResources = http://biomoby.org/RESOURCES/MOBY-S/FULL
 
[mobyobject]
dbname = mobyobject
lsid_authority = biomoby.org
lsid_namespace = objectclass
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Objects

[mobynamespace]
dbname = mobynamespace
lsid_authority = biomoby.org
lsid_namespace = namespacetype
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Namespaces

[mobyservice]
dbname = mobyservice
lsid_authority = biomoby.org
lsid_namespace = servicetype
resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Services

[mobyrelationship]
dbname = mobyrelationship
lsid_authority = biomoby.org
#lsid_namespace = relationshiptype

Those are the new lines (as far as I know) that should be
added to the config file.

Eddie



From gordonp at ucalgary.ca  Mon Sep 19 13:02:53 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Mon, 19 Sep 2005 07:02:53 -0600
Subject: [MOBY-dev] jMoby:  caching in CentralImpl
In-Reply-To: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509190826090.1018187-100000@ice.ebi.ac.uk>
Message-ID: <432EB6FD.7070508@ucalgary.ca>

Go ahead.  As long as someone tells me they're going to break my code, 
rather than just doing it, I'm fine :-)

Martin Senger wrote:

>Paul (and others),
>   I have mentioned in Vancouver that I would like to remove caching from
>CentralImpl because we have now probably more powerfull caching in
>CentralDigestCachedImpl (which I am improving now), and we will have even
>better caching when we implement it based on RDF Resources. You said that
>I can go ahead. But I would like to confirm it because removing it from
>CentralImpl may break some of your code (or of the others).
>   Do I have your green lights?
>
>   Cheers,
>   Martin
>
>  
>



From francis_gibbons at hms.harvard.edu  Mon Sep 19 14:44:54 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Mon, 19 Sep 2005 10:44:54 -0400
Subject: [MOBY-dev] Re: Failing tests in the Perl API.
In-Reply-To: <36612E59-02E5-41BB-842A-EF368649EB2B@wur.nl>
References: <5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>
	<5.2.1.1.2.20050916140304.011587d0@email.med.harvard.edu>
Message-ID: <5.2.1.1.2.20050919104414.010eb940@email.med.harvard.edu>

Hi Pieter,

At 05:41 AM 9/19/2005, you wrote:
>Client-Central.t is fine now. I also don't know where the '$__val'
>came from. But the tests are not complaining about it anymore :) In
>addition to some messages about skipped tests I do get a warning
>about a non-existing 'bogus NS' in CommonSubs.t. See below for the
>output of the tests. I assume it's safe to ignore that one.

Yes, it's safe to ignore that one. I'm re-working CommonSubs.pm right now, 
and expect to make that warning message disappear shortly.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From Pieter.Neerincx at wur.nl  Mon Sep 19 14:46:19 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 19 Sep 2005 16:46:19 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432eb8ff.589d431d.4335.2914@mx.gmail.com>
References: <432eb8ff.589d431d.4335.2914@mx.gmail.com>
Message-ID: <87207568-E348-4B3C-AD12-5F6C69AB1E0D@wur.nl>

Hi Eddie,

On 19-Sep-2005, at 3:11 PM, Edward Kawas wrote:

> Hi,
>
> [mobycentral]
> dbname = mobycentral
> rdfagent = /usr/local/apache2/MOBY/rdfagent
> lsid_authority = biomoby.org
> lsid_namespace = serviceinstance
> resourceURL =
> http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances
> allResources = http://biomoby.org/RESOURCES/MOBY-S/FULL
>
> [mobyobject]
> dbname = mobyobject
> lsid_authority = biomoby.org
> lsid_namespace = objectclass
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Objects
>
> [mobynamespace]
> dbname = mobynamespace
> lsid_authority = biomoby.org
> lsid_namespace = namespacetype
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Namespaces
>
> [mobyservice]
> dbname = mobyservice
> lsid_authority = biomoby.org
> lsid_namespace = servicetype
> resourceURL = http://biomoby.org/RESOURCES/MOBY-S/Services
>
> [mobyrelationship]
> dbname = mobyrelationship
> lsid_authority = biomoby.org
> #lsid_namespace = relationshiptype
>
> Those are the new lines (as far as I know) that should be
> added to the config file.

Thanks, I already guessed some of the URLs, but not all of them :). I  
created a small Perl script to test MOBY::Client::Central- 
 >retrieveResourceURLs. This works now, but unfortunately still no  
fun with Taverna. When I start Taverna with my local central appended  
in the mygrid.properties file, nothing happens: no custom objects  
form my local central and also no error messages. When I add my local  
central manually using right-click->add new biomoby scavanger, I got  
the error below. Taverna complains it can't process the RDF document  
for the biomoby objects :(. So I pointed my browser to the URL for  
the biomoby objects RDF file and had a look: The RDF looks pretty  
normal, but I did notice <cr> elements and the xml parser fails on  
those. (Do you happen to develop on a windows machine?) So I stripped  
the carriage returns from RDF objects file, saved it and changed the  
URL for the objects RDF to this static file: tada.... That finally  
got the show on the road :).

Cheers,

Pieter

Taverna command line error messages:
---------------------------------------
Creating biomoby scavenger : 'https://bioinfw05/phenolink/biomoby/ 
central/cgi-bin/MOBY-Central.pl'
ERROR                                      2005-09-19 16:01:16,854  
(com.hp.hpl.jena.rdf.model.impl.RDFDefaultErrorHandler:44) - http:// 
www.w3.org/TR/html4/loose.dtd[31:3]: {E301} The declaration for the  
entity "HTML.Version" must end with '>'.
Failed: rethrew: com.hp.hpl.jena.rdf.arp.ParseException: {E301} The  
declaration for the entity "HTML.Version" must end with '>'.
[Ljava.lang.StackTraceElement;@c9f71b
org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException:  
Could not retrieve and or process RDF document for BioMoby Objects
         at org.biomoby.client.taverna.plugin.BiomobyScavenger.<init> 
(BiomobyScavenger.java:95)
         at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper 
$2.actionPerformed(BiomobyScavengerHelper.java:83)
         at javax.swing.AbstractButton.fireActionPerformed 
(AbstractButton.java:1786)
         at javax.swing.AbstractButton 
$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
         at javax.swing.DefaultButtonModel.fireActionPerformed 
(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed 
(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased 
(BasicButtonListener.java:245)
         at java.awt.Component.processMouseEvent(Component.java:5100)
         at java.awt.Component.processEvent(Component.java:4897)
         at java.awt.Container.processEvent(Container.java:1569)
         at java.awt.Component.dispatchEventImpl(Component.java:3615)
         at java.awt.Container.dispatchEventImpl(Container.java:1627)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.LightweightDispatcher.retargetMouseEvent 
(Container.java:3483)
         at java.awt.LightweightDispatcher.processMouseEvent 
(Container.java:3198)
         at java.awt.LightweightDispatcher.dispatchEvent 
(Container.java:3128)
         at java.awt.Container.dispatchEventImpl(Container.java:1613)
         at java.awt.Window.dispatchEventImpl(Window.java:1606)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy 
(EventDispatchThread.java:201)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:151)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:141)
         at java.awt.Dialog$1.run(Dialog.java:540)
         at java.awt.Dialog.show(Dialog.java:561)
         at java.awt.Component.show(Component.java:1133)
         at java.awt.Component.setVisible(Component.java:1088)
         at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper 
$1.actionPerformed(BiomobyScavengerHelper.java:119)
         at javax.swing.AbstractButton.fireActionPerformed 
(AbstractButton.java:1786)
         at javax.swing.AbstractButton 
$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
         at javax.swing.DefaultButtonModel.fireActionPerformed 
(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed 
(DefaultButtonModel.java:258)
         at javax.swing.AbstractButton.doClick(AbstractButton.java:289)
         at javax.swing.plaf.basic.BasicMenuItemUI.doClick 
(BasicMenuItemUI.java:1113)
         at javax.swing.plaf.basic.BasicMenuItemUI 
$MouseInputHandler.mouseReleased(BasicMenuItemUI.java:943)
         at java.awt.Component.processMouseEvent(Component.java:5100)
         at java.awt.Component.processEvent(Component.java:4897)
         at java.awt.Container.processEvent(Container.java:1569)
         at java.awt.Component.dispatchEventImpl(Component.java:3615)
         at java.awt.Container.dispatchEventImpl(Container.java:1627)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.LightweightDispatcher.retargetMouseEvent 
(Container.java:3483)
         at java.awt.LightweightDispatcher.processMouseEvent 
(Container.java:3198)
         at java.awt.LightweightDispatcher.dispatchEvent 
(Container.java:3128)
         at java.awt.Container.dispatchEventImpl(Container.java:1613)
         at java.awt.Window.dispatchEventImpl(Window.java:1606)
         at java.awt.Component.dispatchEvent(Component.java:3477)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy 
(EventDispatchThread.java:201)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy 
(EventDispatchThread.java:151)
         at java.awt.EventDispatchThread.pumpEvents 
(EventDispatchThread.java:145)
         at java.awt.EventDispatchThread.pumpEvents 
(EventDispatchThread.java:137)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java: 
100)
Caused by: java.lang.NullPointerException
         at org.biomoby.client.taverna.plugin.BiomobyScavenger.<init> 
(BiomobyScavenger.java:92)
         ... 52 more
---------------------------------------



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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Mon Sep 19 14:51:38 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 19 Sep 2005 07:51:38 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <87207568-E348-4B3C-AD12-5F6C69AB1E0D@wur.nl>
Message-ID: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>

> Could not retrieve and or process RDF document for BioMoby
> Objects
Can I have your Moby endpoint so that I can test this? I am
not sure why the carriage returns are present.

Eddie



From Pieter.Neerincx at wur.nl  Mon Sep 19 15:06:03 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 19 Sep 2005 17:06:03 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>
References: <432ed07f.478d76ea.6fb1.ffffd924@mx.gmail.com>
Message-ID: <3794C121-8E2C-4B0B-BC41-3537752A5085@wur.nl>


On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:

>> Could not retrieve and or process RDF document for BioMoby
>> Objects
>>
> Can I have your Moby endpoint so that I can test this?

Sure!

This is what I use on my development box:

     https://bioinfw05/phenolink/biomoby/central/cgi-bin/MOBY-Central.pl

But it doesn't have a DNS entry, so you might try this:

     https://137.224.52.237/phenolink/biomoby/central/cgi-bin/MOBY- 
Central.pl

My RDF for the objects is at (not sure whether this one will work  
from outside our firewall...):

     https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects

Hope this helps.

Pieter


> I am
> not sure why the carriage returns are present.
>
> Eddie
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Mon Sep 19 15:20:02 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 19 Sep 2005 08:20:02 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <3794C121-8E2C-4B0B-BC41-3537752A5085@wur.nl>
Message-ID: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>

Hi,

I can't connect to those URLS or endpoints (I timeout).

I will try to find the bug by eyeballing it. If you can
think of another way that I can access your endpoint, please
let me know.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 19, 2005 8:06 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> 
> On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:
> 
> >> Could not retrieve and or process RDF document for
> BioMoby
> >> Objects
> >>
> > Can I have your Moby endpoint so that I can test this?
> 
> Sure!
> 
> This is what I use on my development box:
> 
>      https://bioinfw05/phenolink/biomoby/central/cgi-
> bin/MOBY-Central.pl
> 
> But it doesn't have a DNS entry, so you might try this:
> 
>      https://137.224.52.237/phenolink/biomoby/central/cgi-
> bin/MOBY-
> Central.pl
> 
> My RDF for the objects is at (not sure whether this one
> will work
> from outside our firewall...):
> 
>      https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects
> 
> Hope this helps.
> 
> Pieter
> 
> 
> > I am
> > not sure why the carriage returns are present.
> >
> > Eddie
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From markw at illuminae.com  Mon Sep 19 15:02:51 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 19 Sep 2005 08:02:51 -0700
Subject: [MOBY-dev] Re: invitation for the RFC committee with a tenure
	of	one year
In-Reply-To: <432E8119.4030502@cnb.uam.es>
References: <4329f9e0.788fe627.5d93.ffffc9e4@mx.gmail.com>
	<432E8119.4030502@cnb.uam.es>
Message-ID: <432ED31B.8000303@illuminae.com>

Thanks David!

Just to clarify, "the Spanish Contingent" was not meant to be insulting 
in any way (nor even forwarded to the mailing list at all) - there are 
just a lot of you using Moby in Spain, between INB and Alfonso's group, 
etc., so I didn't know who/how many would want to join this committee, 
so I just referred to you as a group in a private message to Eddie, 
which he then forwarded to the mailing list :-)

M



David Gonz?lez Pisano wrote:

> I'll be glad to represent the INB (aka "The Spanish Contingent") in 
> the RFC commitee for a year. Thanks for your invitation,
>
> David
>
> Edward Kawas escribi?:
>
>> -----Original Message-----
>> From: mark wilkinson [mailto:markw at illuminae.com] Sent: Thursday, 
>> September 15, 2005 3:06 PM
>> To: Frank Gibbons; Eddie Kawas
>> Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
>> Error-handling in MOBY-S
>>
>> Hey Frank! Cc Eddie
>>
>> Thanks for riding this.  I am on holiday, and not in Net
>> contact except by blackberry, so I'm not "useful" right now.
>>
>> I think we should put out an invitation on the -dev list for
>> the RFC committee with a tenure of one year, but also
>> specifically invite the main developers/vested interests to
>> be part of it:  me, you, martin, eddie, simon, heiko, paul,
>> yan wong, and at least one from the spanish contingent (have
>> I missed anyone?).
>>
>> I don't have all their email addresses on my bberry so
>> unless you or Eddie (cc'd) post this invitation to the dev
>> list yourselves it may take a week before I am back in
>> net-world.  Eddie, could you do this? Tomorrow or this
>> afternoon?  It would be good to get this sorted asap to keep
>> on schedule.
>>
>> M
>>
>>
>> -----Original Message-----
>> From: Frank Gibbons <fgibbons at hms.harvard.edu>
>> Date: Thu, 15 Sep 2005 11:21:53 To:moby-l at biomoby.org
>> Subject: [MOBY-l] Using bugzilla to continue RFC on
>> Error-handling in MOBY-S
>>
>> Hi,
>>
>> I've just added a few "bugs" to the bugzilla, to try to
>> preserve the RFC momentum built up over the past few weeks. I propose 
>> that,
>> although bugzilla is perhaps not ideal for this, it is what it is, it
>> is what we have, and it will do for now.
>>
>> I'd like to propose that we try to continue development of
>> this RFC through bugzilla (see bug #1863), rather than through the 
>> mailing
>> list. Searching through old mail messages (or worse still, through the
>> digest, with all of its repeated messages and long inclusions) is 
>> tedious, and I
>> think contributes to the loss in momentum.
>>
>> So far, in Martin's scheme for RFC-processing, we have
>> (numbers are those used in Martin's original suggestion, now 
>> available in the
>> codebase as Docs/MOBY-S_API/RFC.html)
>>
>> 1. Had a suggestion made by INB to add this features. It was
>> added to bugzilla, No. 1863
>> 2. Suggested to resolve it by today (Sep-15)
>> 3. Martin backed up the RFC
>> 4. I think we have the resources to make this change - it
>> seems an essential part of a robust API, which version 1.0 should be.
>> 5a. List members have exchanged several comments back and
>> forth, resulting in amended versions of the RFC being posted to the 
>> mailing
>> list.
>> 5b. We've also gotten a little side-tracked by the related
>> articleName problem.
>>
>> So it seems to me that it's time to vote on it (step 6 of
>> the Senger seven-step scheme ;-). Martin suggested that Mark would ask
>> a limited number of people to vote on it after the resolution date
>> (today). I guess those people would self-select, or maybe Mark will 
>> select
>> them. They will be requested to make a one-year commitment.
>>
>> After that comes step 7, the "fun part": implementation,
>> documentation.
>>
>> We're pretty close to reaching a conclusion on this. The
>> fact is that even if we do nothing, people want this functionality, 
>> and they
>> WILL implement it. It is in everybody's interest that we have a
>> specification for what the functionality should be. It may change 
>> over time, but I
>> think there has been enough back-and-forth that we have a reasonable 
>> first
>> draft, and should vote on it.
>>
>> -Frank
>> P.S. Of course, this message, along with version 1.7.1 of
>> the RFC is attached to the bug on bugzilla
>>
>> PhD, Computational Biologist,
>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
>> Boston MA 02115, USA.
>> Tel: 617-432-3555       Fax: 617-432-3557       
>> http://llama.med.harvard.edu/~fgibbons
>> _______________________________________________
>> moby-l mailing list
>> moby-l at biomoby.org
>> http://biomoby.org/mailman/listinfo/moby-l
>>
>> -- 
>> Mark Wilkinson
>> ..on the road!
>>
>>
>>
>>  
>>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>



From senger at ebi.ac.uk  Tue Sep 20 08:50:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 20 Sep 2005 09:50:19 +0100 (BST)
Subject: [MOBY-dev] jMoby: new document on Eclipse & jMoby
Message-ID: <Pine.OSF.4.21.0509200948290.851399-100000@ice.ebi.ac.uk>

...is available at
http://biomoby.org/moby-live/Java/docs/EclipseAndJMoby.html. I welcome all
comments and suggestion to improve it, or to correct it.

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)



From senger at ebi.ac.uk  Wed Sep 21 08:55:52 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 21 Sep 2005 09:55:52 +0100 (BST)
Subject: [MOBY-dev] jMoby: a new document about jMoby & Windows
Message-ID: <Pine.OSF.4.21.0509210949260.629792-100000@ice.ebi.ac.uk>

...was added:
   http://biomoby.org/moby-live/Java/docs/WindowsAndJMoby.html

   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)




From francis_gibbons at hms.harvard.edu  Wed Sep 21 20:41:41 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Wed, 21 Sep 2005 16:41:41 -0400
Subject: [MOBY-dev] Purpose of complexResponse?
Message-ID: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>

Hi,

I'm trying to come up with some tests for complexResponse, part of 
MOBY::CommonSubs.pm. The part that's hard is trying to envisage what kind 
of service might return such a response, since it appears that it contains 
both Simple and Collection items. Anyone got any examples of what that 
might look like?

Also, what's the next step with the RFC on error-reporting? Actually, the 
next step *is* to vote, but the question is "when?"

-Frank


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From markw at illuminae.com  Wed Sep 21 21:20:35 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 21 Sep 2005 14:20:35 -0700
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
Message-ID: <4331CEA3.6020205@illuminae.com>

Hello from Montreal!

The RFC committee consists of:

Frank
Martin
Eddie
David
Mark

I don't think we heard from Heiko, Yan, or Paul...  (??)  We also didn't 
get any other volunteers (unless I have missed a message while I was 
away)  In the interim, and just to keep the ball rolling, let's call the 
vote on RFC 1863.   I'll send out a message with the apprpriate subject 
line in a couple of minutes.  If other members join in time, they can 
vote also.

M


>



From edward.kawas at gmail.com  Wed Sep 21 23:58:20 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 21 Sep 2005 16:58:20 -0700
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
Message-ID: <4331f39d.2009e53e.6a06.1d2d@mx.gmail.com>

> I'll send out a message with the
> apprpriate subject
> line in a couple of minutes.

Did you forget to press send ;-)



From markw at illuminae.com  Thu Sep 22 00:18:24 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu, 22 Sep 2005 00:18:24 +0000 GMT
Subject: [MOBY-dev] RFC Committee  Membership last call...
Message-ID: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell01>

I don't think so... I'm pretty surer I sent it...??

M


-----Original Message-----
From: "Edward Kawas" <edward.kawas at gmail.com>
Date: Wed, 21 Sep 2005 16:58:20 
To:"'Core developer announcements'" <moby-dev at portal.open-bio.org>
Subject: RE: [MOBY-dev] RFC Committee  Membership last call...

> I'll send out a message with the
> apprpriate subject
> line in a couple of minutes.

Did you forget to press send ;-)

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

--
Mark Wilkinson
...on the road!


From markw at illuminae.com  Wed Sep 21 21:30:44 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 21 Sep 2005 14:30:44 -0700
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <4331D104.9010308@illuminae.com>

Regarding RFC #1863 Error Handling in MOBY-S

http://bugzilla.open-bio.org/show_bug.cgi?id=1863

The vote has been called.  Voting members may vote by adding their YES 
(accept)  or NO (do not accept) to the comments history  through Bugzilla

Voting ends Sept 26th

M



From Pieter.Neerincx at wur.nl  Thu Sep 22 08:01:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu, 22 Sep 2005 10:01:42 +0200
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <DBF151CE-AA3A-4EF3-97E4-1081641D6AF3@wur.nl>


On  21Sep2005, at 23:20, Mark Wilkinson wrote:

> We also didn't get any other volunteers (unless I have missed a  
> message while I was away)  In the interim, and just to keep the  
> ball rolling, let's call the vote on RFC 1863.   I'll send out a  
> message with the apprpriate subject line in a couple of minutes.   
> If other members join in time, they can vote also.

I'm a big fan of democracy, so where do I join?

I like the proposal :) Found one error in the documentation though.  
In section 3 "Raising exceptions for Simples inside a Collection  
(optional proposal extension)" the text mentions an refarticleName  
attribute that links to the corresponding erroneous Simple inside a  
Collection. If that is correct, the corresponding example in table 6  
is wrong. The example lists refElement tags, but I can not find any  
refarticleName attributes in there...

Pi


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

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1038
Dreijenlaan 3
6703 HA Wageningen
phone: 0317-484 706
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl



From senger at ebi.ac.uk  Thu Sep 22 10:38:14 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 22 Sep 2005 11:38:14 +0100 (BST)
Subject: [MOBY-dev] jMoby: deploymnt added to Moses
Message-ID: <Pine.OSF.4.21.0509221132050.1329336-100000@mozart.ebi.ac.uk>

I have added the last remaining piece to the Moses mosaic: the deployment
of services. The new document describing it is:

http://biomoby.org/moby-live/Java/docs/Moses-deploy.html

Recently, I also fixed some bugs in Moses (and in jMoby Ant generally),
mostly solving incompatibility on Windows platform. As far as I am aware,
things now work on Windows as well.

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)



From ywong at infobiogen.fr  Thu Sep 22 13:36:46 2005
From: ywong at infobiogen.fr (ywong at infobiogen.fr)
Date: Thu, 22 Sep 2005 15:36:46 +0200 (CEST)
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <51700.170.252.64.1.1127396206.squirrel@170.252.64.1>

Hello from a street near the Eiffel Tower,

  Just let me some time to read the RFC ...

  I am now working for Accenture Technology Solutions. As I am no longer
commited to any biomoby related project or any bioinformatics project,
it has become increasingly difficult to follow the changes (I use the
remain of my spare time :D)

  Anyway, I'll do my best to solve problems (even if I believe the Python
API to be "stable") and update he API but expect progress to be VERY
SLOW .

  Cheers.

Yan


> Hello from Montreal!
>
> The RFC committee consists of:
>
> Frank
> Martin
> Eddie
> David
> Mark
>
> I don't think we heard from Heiko, Yan, or Paul...  (??)  We also didn't
> get any other volunteers (unless I have missed a message while I was
> away)  In the interim, and just to keep the ball rolling, let's call the
> vote on RFC 1863.   I'll send out a message with the apprpriate subject
> line in a couple of minutes.  If other members join in time, they can
> vote also.
>
> M
>
>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From senger at ebi.ac.uk  Thu Sep 22 14:49:59 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 22 Sep 2005 15:49:59 +0100 (BST)
Subject: [MOBY-dev] is findService(0 case sensitive?
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509221545570.1329336-100000@mozart.ebi.ac.uk>

Mark,
   You told me once that everything in Biomoby is case sensitive (that was
in time when I played with idea to allow case insensitivness but then
stepped back because of Blast's secondary parameters 'e' and 'E').
   Now I see that findService seems to be case insensitive. When I ask for
service getProteinSequence I get two services: getProteinSequence and
GetProteinSequence.
   So what is true? Whatever it is could you tell us and add it to the API
please?

   Cheers,
   Martin

PS. Pending answer about retrieving namespaces... :-)
M.

-- 
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)



From markw at illuminae.com  Thu Sep 22 15:21:07 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu, 22 Sep 2005 15:21:07 +0000 GMT
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
Message-ID: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>


MOBY is intended to be case sensitive.  What you are seeing is likely a consequence of mySQL not being case sensitive, and moby central not double-checking the output of the query.

That's a frustrating bug, since it means I need to post-filter every query :-/

I wonder if there is a flag in mysql that makes the searches case sensitive?

I'll look into it when I get back to Vancouver.  For the moment, code on the assumption that it *is* case sensitive, since that's the intention.

M


-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Thu, 22 Sep 2005 15:49:59 
To:Mark Wilkinson <markw at illuminae.com>
Cc:mobydev <moby-dev at biomoby.org>
Subject: is findService(0 case sensitive?

Mark,
   You told me once that everything in Biomoby is case sensitive (that was
in time when I played with idea to allow case insensitivness but then
stepped back because of Blast's secondary parameters 'e' and 'E').
   Now I see that findService seems to be case insensitive. When I ask for
service getProteinSequence I get two services: getProteinSequence and
GetProteinSequence.
   So what is true? Whatever it is could you tell us and add it to the API
please?

   Cheers,
   Martin

PS. Pending answer about retrieving namespaces... :-)
M.

-- 
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)


--
Mark Wilkinson
...on the road!


From senger at ebi.ac.uk  Thu Sep 22 15:31:34 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 22 Sep 2005 16:31:34 +0100 (BST)
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>
Message-ID: <Pine.OSF.4.21.0509221626160.1329336-100000@mozart.ebi.ac.uk>

Thanks for the fast reply and please don't worry now. I forgot that you
were still away. Sorry for that.

Okay, I will be coding as for case sensitivity. Thanks.
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)



From edward.kawas at gmail.com  Thu Sep 22 15:53:13 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 22 Sep 2005 08:53:13 -0700
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <28742527-1127402605-cardhu_blackberry.rim.net-24632-@engine09-cell01>
Message-ID: <4332d36b.5ae1c862.28fe.fffff8aa@mx.gmail.com>

Hi Mark,

I spent a while looking around, but the following query is
case sensitive (tested on our db)

select * from service_instance where servicename LIKE binary
'getProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'GetProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'getproteinsequence';

returns empty

Eddie
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:21 AM
> To: Martin Senger; Mark Wilkinson
> Cc: mobydev
> Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> 
> 
> MOBY is intended to be case sensitive.  What you are
> seeing is likely a consequence of mySQL not being case
> sensitive, and moby central not double-checking the output
> of the query.
> 
> That's a frustrating bug, since it means I need to post-
> filter every query :-/
> 
> I wonder if there is a flag in mysql that makes the
> searches case sensitive?
> 
> I'll look into it when I get back to Vancouver.  For the
> moment, code on the assumption that it *is* case
sensitive,
> since that's the intention.
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger at ebi.ac.uk>
> Date: Thu, 22 Sep 2005 15:49:59
> To:Mark Wilkinson <markw at illuminae.com>
> Cc:mobydev <moby-dev at biomoby.org>
> Subject: is findService(0 case sensitive?
> 
> Mark,
>    You told me once that everything in Biomoby is case
> sensitive (that was
> in time when I played with idea to allow case
> insensitivness but then
> stepped back because of Blast's secondary parameters 'e'
> and 'E').
>    Now I see that findService seems to be case
insensitive.
> When I ask for
> service getProteinSequence I get two services:
> getProteinSequence and
> GetProteinSequence.
>    So what is true? Whatever it is could you tell us and
> add it to the API
> please?
> 
>    Cheers,
>    Martin
> 
> PS. Pending answer about retrieving namespaces... :-)
> M.
> 
> --
> 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)
> 
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From markw at illuminae.com  Thu Sep 22 15:53:10 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu, 22 Sep 2005 15:53:10 +0000 GMT
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
Message-ID: <327837899-1127404527-cardhu_blackberry.rim.net-13073-@engine12-cell01>

Excellent!  Can you look into the adaptor layer (mysql.pm) and add the "binary" tag to that query?

Thanks!

M

-----Original Message-----
From: "Edward Kawas" <edward.kawas at gmail.com>
Date: Thu, 22 Sep 2005 08:53:13 
To:<markw at illuminae.com>,       "'Core developer announcements'" <moby-dev at portal.open-bio.org>
Subject: RE: [MOBY-dev] Re: is findService(0 case sensitive?

Hi Mark,

I spent a while looking around, but the following query is
case sensitive (tested on our db)

select * from service_instance where servicename LIKE binary
'getProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'GetProteinSequence';

returns 1 instance

select * from service_instance where servicename LIKE binary
'getproteinsequence';

returns empty

Eddie
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:21 AM
> To: Martin Senger; Mark Wilkinson
> Cc: mobydev
> Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> 
> 
> MOBY is intended to be case sensitive.  What you are
> seeing is likely a consequence of mySQL not being case
> sensitive, and moby central not double-checking the output
> of the query.
> 
> That's a frustrating bug, since it means I need to post-
> filter every query :-/
> 
> I wonder if there is a flag in mysql that makes the
> searches case sensitive?
> 
> I'll look into it when I get back to Vancouver.  For the
> moment, code on the assumption that it *is* case
sensitive,
> since that's the intention.
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger at ebi.ac.uk>
> Date: Thu, 22 Sep 2005 15:49:59
> To:Mark Wilkinson <markw at illuminae.com>
> Cc:mobydev <moby-dev at biomoby.org>
> Subject: is findService(0 case sensitive?
> 
> Mark,
>    You told me once that everything in Biomoby is case
> sensitive (that was
> in time when I played with idea to allow case
> insensitivness but then
> stepped back because of Blast's secondary parameters 'e'
> and 'E').
>    Now I see that findService seems to be case
insensitive.
> When I ask for
> service getProteinSequence I get two services:
> getProteinSequence and
> GetProteinSequence.
>    So what is true? Whatever it is could you tell us and
> add it to the API
> please?
> 
>    Cheers,
>    Martin
> 
> PS. Pending answer about retrieving namespaces... :-)
> M.
> 
> --
> 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)
> 
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

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

--
Mark Wilkinson
...on the road!


From senger at ebi.ac.uk  Thu Sep 22 15:59:21 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 22 Sep 2005 16:59:21 +0100 (BST)
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <4332d36b.5ae1c862.28fe.fffff8aa@mx.gmail.com>
Message-ID: <Pine.OSF.4.21.0509221657400.1329336-100000@mozart.ebi.ac.uk>

Well, I think that I was asking a wrong question. I am sorry about
that. It turned out that the two services [g|G]etProteinSequence are from
two different authorities.

Mea culpa, mea maxima culpa.

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)



From edward.kawas at gmail.com  Thu Sep 22 15:57:52 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 22 Sep 2005 08:57:52 -0700
Subject: [MOBY-dev] Re: is findService(0 case sensitive?
In-Reply-To: <327837899-1127404527-cardhu_blackberry.rim.net-13073-@engine12-cell01>
Message-ID: <4332d483.555cc870.2d33.0d85@mx.gmail.com>

Sure, the only query is for getting service instance names
right?

Eddie



> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Thursday, September 22, 2005 8:53 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Re: is findService(0 case
> sensitive?
> 
> Excellent!  Can you look into the adaptor layer (mysql.pm)
> and add the "binary" tag to that query?
> 
> Thanks!
> 
> M
> 
> -----Original Message-----
> From: "Edward Kawas" <edward.kawas at gmail.com>
> Date: Thu, 22 Sep 2005 08:53:13
> To:<markw at illuminae.com>,       "'Core developer
> announcements'" <moby-dev at portal.open-bio.org>
> Subject: RE: [MOBY-dev] Re: is findService(0 case
> sensitive?
> 
> Hi Mark,
> 
> I spent a while looking around, but the following query is
> case sensitive (tested on our db)
> 
> select * from service_instance where servicename LIKE
> binary
> 'getProteinSequence';
> 
> returns 1 instance
> 
> select * from service_instance where servicename LIKE
> binary
> 'GetProteinSequence';
> 
> returns 1 instance
> 
> select * from service_instance where servicename LIKE
> binary
> 'getproteinsequence';
> 
> returns empty
> 
> Eddie
> > -----Original Message-----
> > From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> > dev-bounces at portal.open-bio.org] On Behalf Of mark
> > wilkinson
> > Sent: Thursday, September 22, 2005 8:21 AM
> > To: Martin Senger; Mark Wilkinson
> > Cc: mobydev
> > Subject: [MOBY-dev] Re: is findService(0 case sensitive?
> >
> >
> > MOBY is intended to be case sensitive.  What you are
> > seeing is likely a consequence of mySQL not being case
> > sensitive, and moby central not double-checking the
> output
> > of the query.
> >
> > That's a frustrating bug, since it means I need to post-
> > filter every query :-/
> >
> > I wonder if there is a flag in mysql that makes the
> > searches case sensitive?
> >
> > I'll look into it when I get back to Vancouver.  For the
> > moment, code on the assumption that it *is* case
> sensitive,
> > since that's the intention.
> >
> > M
> >
> >
> > -----Original Message-----
> > From: Martin Senger <senger at ebi.ac.uk>
> > Date: Thu, 22 Sep 2005 15:49:59
> > To:Mark Wilkinson <markw at illuminae.com>
> > Cc:mobydev <moby-dev at biomoby.org>
> > Subject: is findService(0 case sensitive?
> >
> > Mark,
> >    You told me once that everything in Biomoby is case
> > sensitive (that was
> > in time when I played with idea to allow case
> > insensitivness but then
> > stepped back because of Blast's secondary parameters 'e'
> > and 'E').
> >    Now I see that findService seems to be case
> insensitive.
> > When I ask for
> > service getProteinSequence I get two services:
> > getProteinSequence and
> > GetProteinSequence.
> >    So what is true? Whatever it is could you tell us and
> > add it to the API
> > please?
> >
> >    Cheers,
> >    Martin
> >
> > PS. Pending answer about retrieving namespaces... :-)
> > M.
> >
> > --
> > 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)
> >
> >
> > --
> > Mark Wilkinson
> > ...on the road!
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From senger at ebi.ac.uk  Fri Sep 23 16:32:07 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Fri, 23 Sep 2005 17:32:07 +0100 (BST)
Subject: [MOBY-dev] adding Comparable to MobyDataType class
Message-ID: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>

Eddie (and the others),
   I plan to add 'implements Comparable' to MobyDataType (and perhaps also
to MobyService and MobyNamespace) - just to make it easier to sort.
   I noticed that your Registration class inherits from MobyDataType. I do
not think that this new interface would harm it - but better to ask
first. Do you know about any bad consequences if I add there this
interface?

   Thanks,
   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)



From edward.kawas at gmail.com  Fri Sep 23 16:34:31 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 23 Sep 2005 09:34:31 -0700
Subject: [MOBY-dev] RE: adding Comparable to MobyDataType class
In-Reply-To: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
Message-ID: <43342e9a.335a05df.2465.6864@mx.gmail.com>

Hi Martin,

I don't thnk that it will hurt me.

Eddie

> -----Original Message-----
> From: Martin Senger [mailto:senger at ebi.ac.uk]
> Sent: Friday, September 23, 2005 9:32 AM
> To: Edward Kawas
> Cc: Moby Developers
> Subject: adding Comparable to MobyDataType class
> 
> Eddie (and the others),
>    I plan to add 'implements Comparable' to MobyDataType
> (and perhaps also
> to MobyService and MobyNamespace) - just to make it easier
> to sort.
>    I noticed that your Registration class inherits from
> MobyDataType. I do
> not think that this new interface would harm it - but
> better to ask
> first. Do you know about any bad consequences if I add
> there this
> interface?
> 
>    Thanks,
>    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)



From francis_gibbons at hms.harvard.edu  Fri Sep 16 12:47:10 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Fri, 16 Sep 2005 08:47:10 -0400
Subject: [MOBY-dev] RE: invitation for the RFC committee with a tenure of
	one year
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C01@MAILSERVER02.MED.HARVARD.EDU>

Thanks for the invitation, Eddie & Mark. I'm glad to be part of this, excited that we've gotten this far and looking to completing our first formal RFC.
 
-Frank

	-----Original Message----- 
	From: Edward Kawas [mailto:edward.kawas at gmail.com] 
	Sent: Thu 9/15/2005 6:46 PM 
	To: 'Moby Developers' 
	Cc: 'Martin Senger'; 'Eddie Kawas'; 'Twigger Simon'; 'Paul Gordon'; ywong at infobiogen.fr; schoof at mpiz-koeln.mpg.de; Gibbons, Francis ; dgpisano at cnb.uam.es 
	Subject: invitation for the RFC committee with a tenure of one year
	
	



	-----Original Message-----
	From: mark wilkinson [mailto:markw at illuminae.com]
	Sent: Thursday, September 15, 2005 3:06 PM
	To: Frank Gibbons; Eddie Kawas
	Subject: Re: [MOBY-l] Using bugzilla to continue RFC on
	Error-handling in MOBY-S
	
	Hey Frank! Cc Eddie
	
	Thanks for riding this.  I am on holiday, and not in Net
	contact except by blackberry, so I'm not "useful" right now.
	
	I think we should put out an invitation on the -dev list for
	the RFC committee with a tenure of one year, but also
	specifically invite the main developers/vested interests to
	be part of it:  me, you, martin, eddie, simon, heiko, paul,
	yan wong, and at least one from the spanish contingent (have
	I missed anyone?).
	
	I don't have all their email addresses on my bberry so
	unless you or Eddie (cc'd) post this invitation to the dev
	list yourselves it may take a week before I am back in
	net-world.  Eddie, could you do this? Tomorrow or this
	afternoon?  It would be good to get this sorted asap to keep
	on schedule.
	
	M
	
	
	-----Original Message-----
	From: Frank Gibbons <fgibbons at hms.harvard.edu>
	Date: Thu, 15 Sep 2005 11:21:53
	To:moby-l at biomoby.org
	Subject: [MOBY-l] Using bugzilla to continue RFC on
	Error-handling in MOBY-S
	
	Hi,
	
	I've just added a few "bugs" to the bugzilla, to try to
	preserve the RFC
	momentum built up over the past few weeks. I propose that,
	although
	bugzilla is perhaps not ideal for this, it is what it is, it
	is what we
	have, and it will do for now.
	
	I'd like to propose that we try to continue development of
	this RFC through
	bugzilla (see bug #1863), rather than through the mailing
	list. Searching
	through old mail messages (or worse still, through the
	digest, with all of
	its repeated messages and long inclusions) is tedious, and I
	think
	contributes to the loss in momentum.
	
	So far, in Martin's scheme for RFC-processing, we have
	(numbers are those
	used in Martin's original suggestion, now available in the
	codebase as
	Docs/MOBY-S_API/RFC.html)
	
	1. Had a suggestion made by INB to add this features. It was
	added to
	bugzilla, No. 1863
	2. Suggested to resolve it by today (Sep-15)
	3. Martin backed up the RFC
	4. I think we have the resources to make this change - it
	seems an
	essential part of a robust API, which version 1.0 should be.
	5a. List members have exchanged several comments back and
	forth, resulting
	in amended versions of the RFC being posted to the mailing
	list.
	5b. We've also gotten a little side-tracked by the related
	articleName problem.
	
	So it seems to me that it's time to vote on it (step 6 of
	the Senger
	seven-step scheme ;-). Martin suggested that Mark would ask
	a limited
	number of people to vote on it after the resolution date
	(today). I guess
	those people would self-select, or maybe Mark will select
	them. They will
	be requested to make a one-year commitment.
	
	After that comes step 7, the "fun part": implementation,
	documentation.
	
	We're pretty close to reaching a conclusion on this. The
	fact is that even
	if we do nothing, people want this functionality, and they
	WILL implement
	it. It is in everybody's interest that we have a
	specification for what the
	functionality should be. It may change over time, but I
	think there has
	been enough back-and-forth that we have a reasonable first
	draft, and
	should vote on it.
	
	-Frank
	P.S. Of course, this message, along with version 1.7.1 of
	the RFC is
	attached to the bug on bugzilla
	
	PhD, Computational Biologist,
	Harvard Medical School BCMP/SGM-322, 250 Longwood Ave,
	Boston MA 02115, USA.
	Tel: 617-432-3555       Fax:
	617-432-3557       http://llama.med.harvard.edu/~fgibbons
	
	_______________________________________________
	moby-l mailing list
	moby-l at biomoby.org
	http://biomoby.org/mailman/listinfo/moby-l
	
	--
	Mark Wilkinson
	..on the road!
	
	




From francis_gibbons at hms.harvard.edu  Fri Sep 16 14:26:56 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Fri, 16 Sep 2005 10:26:56 -0400
Subject: [MOBY-dev] Failing tests in the Perl API.
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C02@MAILSERVER02.MED.HARVARD.EDU>

Pieter,
 
I wrote many of the tests for the  Perl API. When I run them, I see a 99% pass rate, or better. I'm very interested to know which ones are failing for you, and what your local installation looks like (I guess you have a local registry? what's your OS? Perl version? etc.) Clearly, we should have a test suite that passes for most developers most of the time, so that they can be alerted quickly if they break something. So it's really important for me to know which tests are failing and why: the tests may need to be rewritten.
 
Thanks for your feedback.
 
-Frank

	-----Original Message----- 
	From: moby-dev-bounces at portal.open-bio.org on behalf of Edward Kawas 
	Sent: Fri 9/16/2005 9:54 AM 
	To: 'Core developer announcements' 
	Cc: 'Pieter Neerincx' 
	Subject: RE: [MOBY-dev] Moby objects in Taverna. Where do they come from?
	
	

	>I assume I need to update my BioMOBY API stuff as 
	>well. So I tried an cvs up -d of moby-live. When I try make
	>test for the Perl stuff I see a lot of tests failing....
	>Can I safely ignore them for now?
	
	I am not sure about this question. I know that Mark has a
	new test suite but I am not sure if this is the suite that
	you are running.
	
	One more thing, if the servlets work, you would be able to
	do the following:
	http://yourURL:port/types/Objects
	http://yourURL:port/RESOURCES/MOBY-S/Objects
	http://yourURL:port/authority
	
	These 3 links should show you something meaningful (html, a
	file, more html).
	
	Eddie
	
	_______________________________________________
	MOBY-dev mailing list
	MOBY-dev at biomoby.org
	http://www.biomoby.org/mailman/listinfo/moby-dev
	




From simont at post.its.mcw.edu  Thu Sep 22 14:04:18 2005
From: simont at post.its.mcw.edu (Simon Twigger)
Date: Thu, 22 Sep 2005 09:04:18 -0500 (CDT)
Subject: [MOBY-dev] RFC Committee  Membership last call...
In-Reply-To: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell0
	1>
References: <1991925382-1127348441-cardhu_blackberry.rim.net-26351-@engine20-cell01>
Message-ID: <58021.69.210.117.185.1127397858.squirrel@webmail.mcw.edu>

Hi Mark,

I thought I had sent a reply volunteering for the committee a little while
ago but perhaps it forgot to hit send. If there is still time, I would
like to help out by serving.

Simon.


> I don't think so... I'm pretty surer I sent it...??
>
> M
>
>
> -----Original Message-----
> From: "Edward Kawas" <edward.kawas at gmail.com>
> Date: Wed, 21 Sep 2005 16:58:20
> To:"'Core developer announcements'" <moby-dev at portal.open-bio.org>
> Subject: RE: [MOBY-dev] RFC Committee  Membership last call...
>
>> I'll send out a message with the
>> apprpriate subject
>> line in a couple of minutes.
>
> Did you forget to press send ;-)
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>



From gordonp at ucalgary.ca  Fri Sep 23 19:13:06 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Fri, 23 Sep 2005 13:13:06 -0600
Subject: [MOBY-dev] adding Comparable to MobyDataType class
In-Reply-To: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509231728390.839150-100000@ice.ebi.ac.uk>
Message-ID: <433453C2.9030206@ucalgary.ca>

If you do so, please let me know, as all object classes in the 
org.biomoby.shared data package already implements Comparable, and we 
should have the same ordering rules.

>Eddie (and the others),
>   I plan to add 'implements Comparable' to MobyDataType (and perhaps also
>to MobyService and MobyNamespace) - just to make it easier to sort.
>   I noticed that your Registration class inherits from MobyDataType. I do
>not think that this new interface would harm it - but better to ask
>first. Do you know about any bad consequences if I add there this
>interface?
>
>   Thanks,
>   Martin
>
>  
>



From senger at ebi.ac.uk  Sat Sep 24 03:18:45 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sat, 24 Sep 2005 04:18:45 +0100 (BST)
Subject: [MOBY-dev] adding Comparable to MobyDataType class
In-Reply-To: <433453C2.9030206@ucalgary.ca>
Message-ID: <Pine.OSF.4.21.0509240413570.839150-100000@ice.ebi.ac.uk>

> If you do so, please let me know, as all object classes in the 
> org.biomoby.shared data package already implements Comparable, and we 
> should have the same ordering rules.
>
   Well, of course, but I do not see what you mean. Perhaps I overlooked
something. I see the hierarchy:

   MobyDataObject -> MobyPrimaryDataSimple -> MobyData

where MobyDataObject implements Comparable. I wonder how it can be
influenced by adding Comparable to MobyDataType, MobyService and
MobyNamespace?
   Do you think that I can go ahead and put there Comparable?

   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)



From senger at ebi.ac.uk  Sun Sep 25 06:41:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun, 25 Sep 2005 07:41:57 +0100 (BST)
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>

> The vote has been called.  Voting members may vote by adding their YES 
> (accept)  or NO (do not accept) to the comments history  through Bugzilla
> 
> Voting ends Sept 26th
>
    I propose to extend the vote deadline to October 15th. Reasons are:

   1) The proposal (as available from Bugzilla) is still too complex, full
of explanaition, and it is not clear what is a discussion and what is a
proposal. I recommend that the authors take away most of the reasoning and
just state what is the new API. (The reasoning can come later back to the
documentation, if Frank, as a document-manager, decides so.)

   2) The proposal is in the format which is not readable for everyone
(for example, using OpenOffice mixes the tables on the first page, so I do
not understand what they mean and why they are there). Open source API
should use open documentation tools, as much as it can. The whole Biomoby
API/docs is, so far, written in non-proprietary document format, so I
suggest to continue with it.

   3) The error codes are still not explained enough. I suggest either
remove (some of) them, or document them better. Especially the client-side
errors are still obscure to me.

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.

   5) The proposal should clearly suggest what (if anything) should be
removed from the current Biomoby API. I mean the fact that the current API
(even perhasp not literally, but surely by spirit) expects (allows) an
empty result in case of an error (e.g. an ID cannot be found in a target
database). Will this still be valid, or should serviceNotes be returned
instead?

   I already said that I liked the new proposal and I am going to support
it - but I want to introduce new things into Biomoby API as precisely as
we can. Therefore, I am not ready to vote yet. But just in case, my
suggestion described above, will not be accepted, and the vote deadline
announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
do it on Bugzilla, because (a) I think that this NO is only temporary and
conditionally, and (b) I did not found any "history comments" there so I
would not know how to use Bugzilla for that.)

   Regards,
   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)



From senger at ebi.ac.uk  Sun Sep 25 06:41:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Sun, 25 Sep 2005 07:41:57 +0100 (BST)
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
In-Reply-To: <4331D104.9010308@illuminae.com>
Message-ID: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>

> The vote has been called.  Voting members may vote by adding their YES 
> (accept)  or NO (do not accept) to the comments history  through Bugzilla
> 
> Voting ends Sept 26th
>
    I propose to extend the vote deadline to October 15th. Reasons are:

   1) The proposal (as available from Bugzilla) is still too complex, full
of explanaition, and it is not clear what is a discussion and what is a
proposal. I recommend that the authors take away most of the reasoning and
just state what is the new API. (The reasoning can come later back to the
documentation, if Frank, as a document-manager, decides so.)

   2) The proposal is in the format which is not readable for everyone
(for example, using OpenOffice mixes the tables on the first page, so I do
not understand what they mean and why they are there). Open source API
should use open documentation tools, as much as it can. The whole Biomoby
API/docs is, so far, written in non-proprietary document format, so I
suggest to continue with it.

   3) The error codes are still not explained enough. I suggest either
remove (some of) them, or document them better. Especially the client-side
errors are still obscure to me.

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.

   5) The proposal should clearly suggest what (if anything) should be
removed from the current Biomoby API. I mean the fact that the current API
(even perhasp not literally, but surely by spirit) expects (allows) an
empty result in case of an error (e.g. an ID cannot be found in a target
database). Will this still be valid, or should serviceNotes be returned
instead?

   I already said that I liked the new proposal and I am going to support
it - but I want to introduce new things into Biomoby API as precisely as
we can. Therefore, I am not ready to vote yet. But just in case, my
suggestion described above, will not be accepted, and the vote deadline
announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
do it on Bugzilla, because (a) I think that this NO is only temporary and
conditionally, and (b) I did not found any "history comments" there so I
would not know how to use Bugzilla for that.)

   Regards,
   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)



From Pieter.Neerincx at wur.nl  Mon Sep 26 11:40:20 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Mon, 26 Sep 2005 13:40:20 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>
References: <432ed724.5f8badb4.78a4.0443@mx.gmail.com>
Message-ID: <1A427D71-2573-4920-8465-17843E0E3A02@wur.nl>

Hi Eddie,

I've got it up and running. I have now idea what went wrong exactly,  
but I suspect some misconfiguration in Tomcat. I also switched from  
IBM's Java implemntation to Sun's. Had apparently both installed by  
default, but my Tomcat was out of the box using IBM's Java stuff. Now  
with Sun's Java I do have to type 'java -jar install.jar' for the  
servlets installer, just like you documented. Furthermore I have  
Apache configured as frontend for Tomcat now, so I can use port 443  
for https making the whole work again through our firewall. I have  
only one issue left:

When I append my local central to my mygrid.properties file for  
Taverna, I have the old behaviour: hence services from my local  
central, but objects from  the central central. When I remove my  
local central and add it again using right-click -> add biomoby  
scavanger, I get the desired behaviour with both services and objects  
from my local central. It's a bit inconvenient to have to load your  
mobycentral manually all the time :(, but apart from that  
inconvenience it works :). Very nice to see this code in action,  
thanks for the help!

I will document my experience and propose this as an update for the  
page at: http://www.biomoby.org/InstallingMOBYCentral.html if this is  
Ok with you.

Cheers,

Pieter



On 19-Sep-2005, at 5:20 PM, Edward Kawas wrote:

> Hi,
>
> I can't connect to those URLS or endpoints (I timeout).
>
> I will try to find the bug by eyeballing it. If you can
> think of another way that I can access your endpoint, please
> let me know.
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 19, 2005 8:06 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>>
>> On 19-Sep-2005, at 4:51 PM, Edward Kawas wrote:
>>
>>
>>>> Could not retrieve and or process RDF document for
>>>>
>> BioMoby
>>
>>>> Objects
>>>>
>>>>
>>> Can I have your Moby endpoint so that I can test this?
>>>
>>
>> Sure!
>>
>> This is what I use on my development box:
>>
>>      https://bioinfw05/phenolink/biomoby/central/cgi-
>> bin/MOBY-Central.pl
>>
>> But it doesn't have a DNS entry, so you might try this:
>>
>>      https://137.224.52.237/phenolink/biomoby/central/cgi-
>> bin/MOBY-
>> Central.pl
>>
>> My RDF for the objects is at (not sure whether this one
>> will work
>> from outside our firewall...):
>>
>>      https://137.224.52.237:8443/RESOURCES/MOBY-S/Objects
>>
>> Hope this helps.
>>
>> Pieter
>>
>>
>>
>>> I am
>>> not sure why the carriage returns are present.
>>>
>>> Eddie
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>> phone: 0317-483 060
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From dgpisano at cnb.uam.es  Mon Sep 26 13:55:45 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon, 26 Sep 2005 15:55:45 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
Message-ID: <4337FDE1.1080201@cnb.uam.es>

I think we can still vote today, as far as Martin's objections are not 
really about the proposal itself, but about the aesthetics and 
presentation of the proposal. My solutions below

Martin Senger escribi?:

>>The vote has been called.  Voting members may vote by adding their YES 
>>(accept)  or NO (do not accept) to the comments history  through Bugzilla
>>
>>Voting ends Sept 26th
>>
>>    
>>
>    I propose to extend the vote deadline to October 15th. Reasons are:
>
>   1) The proposal (as available from Bugzilla) is still too complex, full
>of explanaition, and it is not clear what is a discussion and what is a
>proposal. I recommend that the authors take away most of the reasoning and
>just state what is the new API. (The reasoning can come later back to the
>documentation, if Frank, as a document-manager, decides so.)
>
>  
>
Explanations would not make the document *more* difficult to understand 
(unless the explanations are wrong)? Probably you are refering to the 
motivation / discussion parts, that we understand we needed to explain 
our reasons to expand MOBY-S specification. I've rewritten the proposal 
so now is just a specification extension proposal (still not an API 
proposal, that's the next implementation step).

>   2) The proposal is in the format which is not readable for everyone
>(for example, using OpenOffice mixes the tables on the first page, so I do
>not understand what they mean and why they are there). Open source API
>should use open documentation tools, as much as it can. The whole Biomoby
>API/docs is, so far, written in non-proprietary document format, so I
>suggest to continue with it.
>  
>
See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
format... We've never talked about this before, and the document can 
easily be exported to whatever format we agree. I am not really 
concerned about using open or closed tools, OMG publishes specifications 
in Word format -between other- and schema documentation using XML Spy 
and nobody objects using commercial tools as far as everybody can 
understand them. Never mind.

Anyway I don't have access to the bugzilla, and I think we still not 
agreed on any format, so please let me what format do you want and I'll 
be happy to send it to Frank to attach it to bugzilla. BTW, how do i 
access to the bugzilla? :-)

>   3) The error codes are still not explained enough. I suggest either
>remove (some of) them, or document them better. Especially the client-side
>errors are still obscure to me.
>  
>
Do you have any specific proposal here? We don't see any major problems, 
but probably we are missing something. Just for clarity, I've removed 
the 800 section (client errors). The proposal (like the LSAE one) is 
open to add new error codes, so this is expandable in the future if we 
agree that we need (or not) specific error codes.

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>  
>
Added a new optional Notes element under serviceNotes to separate human 
readable free text from structured XML mobyException. This way we can 
maintain old functionality into serviceNotes. API changes proposed too.

>   5) The proposal should clearly suggest what (if anything) should be
>removed from the current Biomoby API. I mean the fact that the current API
>(even perhasp not literally, but surely by spirit) expects (allows) an
>empty result in case of an error (e.g. an ID cannot be found in a target
>database). Will this still be valid, or should serviceNotes be returned
>instead?
>  
>
Added a new section with API changes needed. Your question was answered 
in the proposal which is in the bugzilla but in short yes, still an 
empty result has to be sent and (optionally) a serviceNotes with an 
exception be reported with it. This allows the error handling system to 
be compatible with old clients.

>   I already said that I liked the new proposal and I am going to support
>it - but I want to introduce new things into Biomoby API as precisely as
>we can. Therefore, I am not ready to vote yet. But just in case, my
>suggestion described above, will not be accepted, and the vote deadline
>announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
>do it on Bugzilla, because (a) I think that this NO is only temporary and
>conditionally, and (b) I did not found any "history comments" there so I
>would not know how to use Bugzilla for that.)
>
>  
>
Hope that you change your mind. As soon as you tell me which document 
format you want, I'll send the latest version with the changes commented 
above.

>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050926/ab68c498/attachment.vcf>

From dgpisano at cnb.uam.es  Mon Sep 26 13:55:45 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Mon, 26 Sep 2005 15:55:45 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509250725080.1098371-100000@mozart.ebi.ac.uk>
Message-ID: <4337FDE1.1080201@cnb.uam.es>

I think we can still vote today, as far as Martin's objections are not 
really about the proposal itself, but about the aesthetics and 
presentation of the proposal. My solutions below

Martin Senger escribi?:

>>The vote has been called.  Voting members may vote by adding their YES 
>>(accept)  or NO (do not accept) to the comments history  through Bugzilla
>>
>>Voting ends Sept 26th
>>
>>    
>>
>    I propose to extend the vote deadline to October 15th. Reasons are:
>
>   1) The proposal (as available from Bugzilla) is still too complex, full
>of explanaition, and it is not clear what is a discussion and what is a
>proposal. I recommend that the authors take away most of the reasoning and
>just state what is the new API. (The reasoning can come later back to the
>documentation, if Frank, as a document-manager, decides so.)
>
>  
>
Explanations would not make the document *more* difficult to understand 
(unless the explanations are wrong)? Probably you are refering to the 
motivation / discussion parts, that we understand we needed to explain 
our reasons to expand MOBY-S specification. I've rewritten the proposal 
so now is just a specification extension proposal (still not an API 
proposal, that's the next implementation step).

>   2) The proposal is in the format which is not readable for everyone
>(for example, using OpenOffice mixes the tables on the first page, so I do
>not understand what they mean and why they are there). Open source API
>should use open documentation tools, as much as it can. The whole Biomoby
>API/docs is, so far, written in non-proprietary document format, so I
>suggest to continue with it.
>  
>
See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
format... We've never talked about this before, and the document can 
easily be exported to whatever format we agree. I am not really 
concerned about using open or closed tools, OMG publishes specifications 
in Word format -between other- and schema documentation using XML Spy 
and nobody objects using commercial tools as far as everybody can 
understand them. Never mind.

Anyway I don't have access to the bugzilla, and I think we still not 
agreed on any format, so please let me what format do you want and I'll 
be happy to send it to Frank to attach it to bugzilla. BTW, how do i 
access to the bugzilla? :-)

>   3) The error codes are still not explained enough. I suggest either
>remove (some of) them, or document them better. Especially the client-side
>errors are still obscure to me.
>  
>
Do you have any specific proposal here? We don't see any major problems, 
but probably we are missing something. Just for clarity, I've removed 
the 800 section (client errors). The proposal (like the LSAE one) is 
open to add new error codes, so this is expandable in the future if we 
agree that we need (or not) specific error codes.

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>  
>
Added a new optional Notes element under serviceNotes to separate human 
readable free text from structured XML mobyException. This way we can 
maintain old functionality into serviceNotes. API changes proposed too.

>   5) The proposal should clearly suggest what (if anything) should be
>removed from the current Biomoby API. I mean the fact that the current API
>(even perhasp not literally, but surely by spirit) expects (allows) an
>empty result in case of an error (e.g. an ID cannot be found in a target
>database). Will this still be valid, or should serviceNotes be returned
>instead?
>  
>
Added a new section with API changes needed. Your question was answered 
in the proposal which is in the bugzilla but in short yes, still an 
empty result has to be sent and (optionally) a serviceNotes with an 
exception be reported with it. This allows the error handling system to 
be compatible with old clients.

>   I already said that I liked the new proposal and I am going to support
>it - but I want to introduce new things into Biomoby API as precisely as
>we can. Therefore, I am not ready to vote yet. But just in case, my
>suggestion described above, will not be accepted, and the vote deadline
>announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
>do it on Bugzilla, because (a) I think that this NO is only temporary and
>conditionally, and (b) I did not found any "history comments" there so I
>would not know how to use Bugzilla for that.)
>
>  
>
Hope that you change your mind. As soon as you tell me which document 
format you want, I'll send the latest version with the changes commented 
above.

>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050926/ab68c498/attachment-0001.vcf>

From edward.kawas at gmail.com  Mon Sep 26 14:56:55 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 07:56:55 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <1A427D71-2573-4920-8465-17843E0E3A02@wur.nl>
Message-ID: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>

Hi Pieter,

>When I append my local central to my mygrid.properties file
>for Taverna, I have the old behaviour: hence services from
>my local central, but objects from  the central central.

Where did you get this version of Taverna? Is it the one
from their homepage? If so, have you tried downloading the
one that I put up at
http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.
zip?

Also, is it possible to post your Mobycentral endpoint so
that I could see how things work?

Thanks,

Eddie



From senger at ebi.ac.uk  Mon Sep 26 14:59:44 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 26 Sep 2005 15:59:44 +0100 (BST)
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>

> I think we can still vote today, as far as Martin's objections are not 
> really about the proposal itself, but about the aesthetics and 
> presentation of the proposal
>
   No, I disagree. The proposal is correct in the spirit, but incorrect or
unclear in details (which I named in my email). The only aesthetics part
was about the format. That on its own would not give me right to suggest
to postpone the vote.

> Explanations would not make the document *more* difficult to understand 
>
   well the document has about ten pages; but it introduces only few XML
tags, plus a page of error codes; I think that having it more consice
helps to make sure that we are not overlooking some missing or
contradicting point.

> See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
> format...
>
   As I said, this was not my major concern. So do as you wish. I would
probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
API is written now.

> concerned about using open or closed tools, OMG publishes specifications 
> in Word format
>
   Talking about OMG, it is even worse that you think. The submissions
must be in FrameMaker which is completely close format. This is a
long-time living issue on the OMG table... But that's not our cup of tea.

> Anyway I don't have access to the bugzilla
>
   My personal opinion: don't even try - it's easy to be lost there. I did
not find how to vote there anyway.

> Do you have any specific proposal here?
>
   I just wanted to have the codes explained. The last version I saw (the
one from bugzilla) still has the client codes there. And I do not
understand what they mean.

> Added a new optional Notes element under serviceNotes to separate human 
> readable free text from structured XML mobyException. This way we can 
> maintain old functionality into serviceNotes. API changes proposed too.
>
   How can I see the new version?
 
> Added a new section with API changes needed. Your question was answered 
> in the proposal which is in the bugzilla but in short yes, still an 
> empty result has to be sent
>
   But that was under-documented from the beginning. Because the API does
not say what an "empty integer" means. I hoped that we will use this
chnage to clarify this.

> Hope that you change your mind. As soon as you tell me which document 
> format you want, I'll send the latest version with the changes commented 
> above.
> 
   Please send it. I will try to read it as it arrives - (but it's already
close to midnight here so I do not know if I manage it :-)).

   Regards,
   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)



From senger at ebi.ac.uk  Mon Sep 26 14:59:44 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 26 Sep 2005 15:59:44 +0100 (BST)
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>

> I think we can still vote today, as far as Martin's objections are not 
> really about the proposal itself, but about the aesthetics and 
> presentation of the proposal
>
   No, I disagree. The proposal is correct in the spirit, but incorrect or
unclear in details (which I named in my email). The only aesthetics part
was about the format. That on its own would not give me right to suggest
to postpone the vote.

> Explanations would not make the document *more* difficult to understand 
>
   well the document has about ten pages; but it introduces only few XML
tags, plus a page of error codes; I think that having it more consice
helps to make sure that we are not overlooking some missing or
contradicting point.

> See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
> format...
>
   As I said, this was not my major concern. So do as you wish. I would
probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
API is written now.

> concerned about using open or closed tools, OMG publishes specifications 
> in Word format
>
   Talking about OMG, it is even worse that you think. The submissions
must be in FrameMaker which is completely close format. This is a
long-time living issue on the OMG table... But that's not our cup of tea.

> Anyway I don't have access to the bugzilla
>
   My personal opinion: don't even try - it's easy to be lost there. I did
not find how to vote there anyway.

> Do you have any specific proposal here?
>
   I just wanted to have the codes explained. The last version I saw (the
one from bugzilla) still has the client codes there. And I do not
understand what they mean.

> Added a new optional Notes element under serviceNotes to separate human 
> readable free text from structured XML mobyException. This way we can 
> maintain old functionality into serviceNotes. API changes proposed too.
>
   How can I see the new version?
 
> Added a new section with API changes needed. Your question was answered 
> in the proposal which is in the bugzilla but in short yes, still an 
> empty result has to be sent
>
   But that was under-documented from the beginning. Because the API does
not say what an "empty integer" means. I hoped that we will use this
chnage to clarify this.

> Hope that you change your mind. As soon as you tell me which document 
> format you want, I'll send the latest version with the changes commented 
> above.
> 
   Please send it. I will try to read it as it arrives - (but it's already
close to midnight here so I do not know if I manage it :-)).

   Regards,
   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)



From edward.kawas at gmail.com  Mon Sep 26 14:43:07 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 07:43:07 -0700
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <4337FDE1.1080201@cnb.uam.es>
Message-ID: <433808ff.43a593e0.0674.1289@mx.gmail.com>

> Anyway I don't have access to the bugzilla
http://bugzilla.open-bio.org/ 
you may need to register first though.
 



From markw at illuminae.com  Mon Sep 26 21:56:56 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 26 Sep 2005 14:56:56 -0700
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <4331CEA3.6020205@illuminae.com>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>
	<4331CEA3.6020205@illuminae.com>
Message-ID: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>

The RDF committee now consists of:

Frank
Martin
Eddie
David
Mark
Simon
Pieter


I am assuming from Yan's message that he wont have time to participate
(please correct me if I am wrong, Yan :-) ), and I have not yet heard
from Paul Gordon.

In any case, that's a great group!  Thanks all!  Let's close the
committee for now.

So, Martin, how does OMG run its democracy?  Unanimity, or majority
rules?

Mark




From Pieter.Neerincx at wur.nl  Mon Sep 26 23:27:57 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 27 Sep 2005 01:27:57 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>
References: <43380c3b.37e82463.0d7a.15c3@mx.gmail.com>
Message-ID: <AE4E0C93-0C74-4404-AD40-D9759336D133@wur.nl>


On  26Sep2005, at 16:56, Edward Kawas wrote:

> Hi Pieter,
>
>
>> When I append my local central to my mygrid.properties file
>> for Taverna, I have the old behaviour: hence services from
>> my local central, but objects from  the central central.
>>
>
> Where did you get this version of Taverna? Is it the one
> from their homepage?

No, I've been testing with the version you put up at the URL  
mentioned below.

> If so, have you tried downloading the
> one that I put up at
> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-1.2.zip?
> Also, is it possible to post your Mobycentral endpoint so
> that I could see how things work?

Yes, sure. I have now temporarily disabled the SSL requirement, so  
everything should work nicely over our firewall using port 80 :). as  
long as I'm testing I don't need the HTTPS, but some of the people  
that are using my services on a production server do.

My test MOBY Central endpoint is at: http://137.224.52.237/phenolink/ 
biomoby/central/cgi-bin/MOBY-Central.pl
My test RESOURCES script is at: http://137.224.52.237/RESOURCES/MOBY-S/

Hope this helps,

Pieter

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

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1038
Dreijenlaan 3
6703 HA Wageningen
phone: 0317-484 706
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl



From dgpisano at cnb.uam.es  Mon Sep 26 23:11:21 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Tue, 27 Sep 2005 01:11:21 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
Message-ID: <43388019.9040308@cnb.uam.es>

I am attaching a PDF file (faster conversion from Word, the HTML is 
generating is too MS-centric, but we can publish the final approved 
version in HTML). Is as strong rewrite (version 2), but I am still 
maintaining the proposal basics and the specification changes. Basically 
the document is organized in a different way.

Hope this help everybody to take a decision or further improve the  
specification (or both) ;-)

David
(about to dissapear some days for ECCB05)

Martin Senger escribi?:

>>I think we can still vote today, as far as Martin's objections are not 
>>really about the proposal itself, but about the aesthetics and 
>>presentation of the proposal
>>
>>    
>>
>   No, I disagree. The proposal is correct in the spirit, but incorrect or
>unclear in details (which I named in my email). The only aesthetics part
>was about the format. That on its own would not give me right to suggest
>to postpone the vote.
>
>  
>
>>Explanations would not make the document *more* difficult to understand 
>>
>>    
>>
>   well the document has about ten pages; but it introduces only few XML
>tags, plus a page of error codes; I think that having it more consice
>helps to make sure that we are not overlooking some missing or
>contradicting point.
>
>  
>
>>See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
>>format...
>>
>>    
>>
>   As I said, this was not my major concern. So do as you wish. I would
>probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
>API is written now.
>
>  
>
>>concerned about using open or closed tools, OMG publishes specifications 
>>in Word format
>>
>>    
>>
>   Talking about OMG, it is even worse that you think. The submissions
>must be in FrameMaker which is completely close format. This is a
>long-time living issue on the OMG table... But that's not our cup of tea.
>
>  
>
>>Anyway I don't have access to the bugzilla
>>
>>    
>>
>   My personal opinion: don't even try - it's easy to be lost there. I did
>not find how to vote there anyway.
>
>  
>
>>Do you have any specific proposal here?
>>
>>    
>>
>   I just wanted to have the codes explained. The last version I saw (the
>one from bugzilla) still has the client codes there. And I do not
>understand what they mean.
>
>  
>
>>Added a new optional Notes element under serviceNotes to separate human 
>>readable free text from structured XML mobyException. This way we can 
>>maintain old functionality into serviceNotes. API changes proposed too.
>>
>>    
>>
>   How can I see the new version?
> 
>  
>
>>Added a new section with API changes needed. Your question was answered 
>>in the proposal which is in the bugzilla but in short yes, still an 
>>empty result has to be sent
>>
>>    
>>
>   But that was under-documented from the beginning. Because the API does
>not say what an "empty integer" means. I hoped that we will use this
>chnage to clarify this.
>
>  
>
>>Hope that you change your mind. As soon as you tell me which document 
>>format you want, I'll send the latest version with the changes commented 
>>above.
>>
>>    
>>
>   Please send it. I will try to read it as it arrives - (but it's already
>close to midnight here so I do not know if I manage it :-)).
>
>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v2.0.pdf
Type: application/pdf
Size: 106970 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/attachment.vcf>

From dgpisano at cnb.uam.es  Mon Sep 26 23:11:21 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Tue, 27 Sep 2005 01:11:21 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0509261542540.1530111-100000@mozart.ebi.ac.uk>
Message-ID: <43388019.9040308@cnb.uam.es>

I am attaching a PDF file (faster conversion from Word, the HTML is 
generating is too MS-centric, but we can publish the final approved 
version in HTML). Is as strong rewrite (version 2), but I am still 
maintaining the proposal basics and the specification changes. Basically 
the document is organized in a different way.

Hope this help everybody to take a decision or further improve the  
specification (or both) ;-)

David
(about to dissapear some days for ECCB05)

Martin Senger escribi?:

>>I think we can still vote today, as far as Martin's objections are not 
>>really about the proposal itself, but about the aesthetics and 
>>presentation of the proposal
>>
>>    
>>
>   No, I disagree. The proposal is correct in the spirit, but incorrect or
>unclear in details (which I named in my email). The only aesthetics part
>was about the format. That on its own would not give me right to suggest
>to postpone the vote.
>
>  
>
>>Explanations would not make the document *more* difficult to understand 
>>
>>    
>>
>   well the document has about ten pages; but it introduces only few XML
>tags, plus a page of error codes; I think that having it more consice
>helps to make sure that we are not overlooking some missing or
>contradicting point.
>
>  
>
>>See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
>>format...
>>
>>    
>>
>   As I said, this was not my major concern. So do as you wish. I would
>probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
>API is written now.
>
>  
>
>>concerned about using open or closed tools, OMG publishes specifications 
>>in Word format
>>
>>    
>>
>   Talking about OMG, it is even worse that you think. The submissions
>must be in FrameMaker which is completely close format. This is a
>long-time living issue on the OMG table... But that's not our cup of tea.
>
>  
>
>>Anyway I don't have access to the bugzilla
>>
>>    
>>
>   My personal opinion: don't even try - it's easy to be lost there. I did
>not find how to vote there anyway.
>
>  
>
>>Do you have any specific proposal here?
>>
>>    
>>
>   I just wanted to have the codes explained. The last version I saw (the
>one from bugzilla) still has the client codes there. And I do not
>understand what they mean.
>
>  
>
>>Added a new optional Notes element under serviceNotes to separate human 
>>readable free text from structured XML mobyException. This way we can 
>>maintain old functionality into serviceNotes. API changes proposed too.
>>
>>    
>>
>   How can I see the new version?
> 
>  
>
>>Added a new section with API changes needed. Your question was answered 
>>in the proposal which is in the bugzilla but in short yes, still an 
>>empty result has to be sent
>>
>>    
>>
>   But that was under-documented from the beginning. Because the API does
>not say what an "empty integer" means. I hoped that we will use this
>chnage to clarify this.
>
>  
>
>>Hope that you change your mind. As soon as you tell me which document 
>>format you want, I'll send the latest version with the changes commented 
>>above.
>>
>>    
>>
>   Please send it. I will try to read it as it arrives - (but it's already
>close to midnight here so I do not know if I manage it :-)).
>
>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v2.0.pdf
Type: application/pdf
Size: 106970 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/attachment-0001.vcf>

From senger at ebi.ac.uk  Mon Sep 26 23:43:40 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 27 Sep 2005 00:43:40 +0100 (BST)
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509270043090.1185944-100000@mozart.ebi.ac.uk>

> So, Martin, how does OMG run its democracy?  Unanimity, or majority
> rules?
>
   Majority.
   M.

-- 
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)



From senger at ebi.ac.uk  Tue Sep 27 01:12:45 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 27 Sep 2005 02:12:45 +0100 (BST)
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient
In-Reply-To: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>
Message-ID: <Pine.OSF.4.21.0509270211020.1185944-100000@mozart.ebi.ac.uk>

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
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)



From markw at illuminae.com  Tue Sep 27 01:17:11 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 01:17:11 +0000 GMT
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
Message-ID: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>

You need to thank Eddie and Dennis (my co-op student this summer).  They had already coded this fix, but I had to commit and restart the server :-)

M


-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Tue, 27 Sep 2005 02:12:45 
To:Mark Wilkinson <markw at illuminae.com>
Cc:Moby Developers <moby-dev at biomoby.org>
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
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

--
Mark Wilkinson
...on the road!


From markw at illuminae.com  Tue Sep 27 01:02:45 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 26 Sep 2005 18:02:45 -0700
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient
In-Reply-To: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>
References: <Pine.OSF.4.21.0509190833590.1018187-100000@ice.ebi.ac.uk>
Message-ID: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>

The SINK should no longer be a SOURCE of frustration :-)

M


-- 
"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



From markw at illuminae.com  Tue Sep 27 01:17:11 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 01:17:11 +0000 GMT
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
Message-ID: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>

You need to thank Eddie and Dennis (my co-op student this summer).  They had already coded this fix, but I had to commit and restart the server :-)

M


-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Tue, 27 Sep 2005 02:12:45 
To:Mark Wilkinson <markw at illuminae.com>
Cc:Moby Developers <moby-dev at biomoby.org>
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces insufficient

> The SINK should no longer be a SOURCE of frustration :-)
>
   WONDERFUL!!!! You are my best pal!
   Thanks 1000x, Martin

(Just a pity is that I have to leave in few hours, so the jMoby
implementation of this new feature must wait when I am back.)

M.


-- 
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

--
Mark Wilkinson
...on the road!


From edward.kawas at gmail.com  Tue Sep 27 01:31:19 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 18:31:19 -0700
Subject: [MOBY-dev] Re: [personal] API for retrieving namespaces
	insufficient
In-Reply-To: <1127782965.5587.347.camel@bioinfo.icapture.ubc.ca>
Message-ID: <4338a0ea.6bd81a7a.1e34.ffffdbb1@mx.gmail.com>

 
> The SINK should no longer be a SOURCE of frustration :-)

You see Mark, that was what I was talking about!



From edward.kawas at gmail.com  Tue Sep 27 01:40:53 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 18:40:53 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <AE4E0C93-0C74-4404-AD40-D9759336D133@wur.nl>
Message-ID: <4338a329.70df3d00.2781.71d9@mx.gmail.com>

Hi Pieter,

I have been toying around with your endpoint. I noticed that
the URL you gave earlier for the Object RDF was inconsistent
with what was retrieved from the API call
getResourceLocation(or something like that ...). 

I think that this occurred when you opened up your endpoint
and perhaps forgot to modify it in your mobycentral.conf
file (does https://bioinfw05:somePort/... resolve on your
machine?). 

The plugin utilizes the API call and hence wouldn't be able
to create a personalized Mobycentral processor (Moby
services and data types) list in Taverna without it.

Once I utilized the URLs that you specified in this message,
everything went as it should. I was able to use your
processors, etc.

I am uploading another version (I tweaked some of the logic)
of the plugin in about 5 minutes. Word on the street is that
Taverna 1.3 is going to be available later on this week
(Friday?) and so that version most likely would be the one
you would want to use. 

In addition, if you notice anything out of the ordinary,
please let me know ASAP so that I can correct it in time for
the much anticipated release.

Thanks,

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
> Neerincx
> Sent: Monday, September 26, 2005 4:28 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
> they come from?
> 
> 
> On  26Sep2005, at 16:56, Edward Kawas wrote:
> 
> > Hi Pieter,
> >
> >
> >> When I append my local central to my mygrid.properties
> file
> >> for Taverna, I have the old behaviour: hence services
> from
> >> my local central, but objects from  the central
central.
> >>
> >
> > Where did you get this version of Taverna? Is it the one
> > from their homepage?
> 
> No, I've been testing with the version you put up at the
> URL
> mentioned below.
> 
> > If so, have you tried downloading the
> > one that I put up at
> > http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
> 1.2.zip?
> > Also, is it possible to post your Mobycentral endpoint
> so
> > that I could see how things work?
> 
> Yes, sure. I have now temporarily disabled the SSL
> requirement, so
> everything should work nicely over our firewall using port
> 80 :). as
> long as I'm testing I don't need the HTTPS, but some of
> the people
> that are using my services on a production server do.
> 
> My test MOBY Central endpoint is at:
> http://137.224.52.237/phenolink/
> biomoby/central/cgi-bin/MOBY-Central.pl
> My test RESOURCES script is at:
> http://137.224.52.237/RESOURCES/MOBY-S/
> 
> Hope this helps,
> 
> Pieter
> 
> >
> > Thanks,
> >
> > Eddie
> >
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> 
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1038
> Dreijenlaan 3
> 6703 HA Wageningen
> phone: 0317-484 706
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From edward.kawas at gmail.com  Tue Sep 27 02:01:54 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 26 Sep 2005 19:01:54 -0700
Subject: [MOBY-dev] Re: [personal] API for retrieving
	namespacesinsufficient
In-Reply-To: <80709412-1127783868-cardhu_blackberry.rim.net-6802-@engine09-cell01>
Message-ID: <4338a814.6d9c8408.538c.ffffe8e3@mx.gmail.com>

Mark, I noticed that the retrieve service type fix was not
'uncommented', like the namespace one was. Is this because
you don't want to implement that suggestion?

Lines >= 2615 of Central.pm

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of mark
> wilkinson
> Sent: Monday, September 26, 2005 6:17 PM
> To: Core developer announcements; Mark Wilkinson
> Cc: Moby Developers
> Subject: Re: [MOBY-dev] Re: [personal] API for retrieving
> namespacesinsufficient
> 
> You need to thank Eddie and Dennis (my co-op student this
> summer).  They had already coded this fix, but I had to
> commit and restart the server :-)
> 
> M
> 
> 
> -----Original Message-----
> From: Martin Senger <senger at ebi.ac.uk>
> Date: Tue, 27 Sep 2005 02:12:45
> To:Mark Wilkinson <markw at illuminae.com>
> Cc:Moby Developers <moby-dev at biomoby.org>
> Subject: [MOBY-dev] Re: [personal] API for retrieving
> namespaces insufficient
> 
> > The SINK should no longer be a SOURCE of frustration :-)
> >
>    WONDERFUL!!!! You are my best pal!
>    Thanks 1000x, Martin
> 
> (Just a pity is that I have to leave in few hours, so the
> jMoby
> implementation of this new feature must wait when I am
> back.)
> 
> M.
> 
> 
> --
> 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
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From senger at ebi.ac.uk  Tue Sep 27 02:06:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 27 Sep 2005 03:06:19 +0100 (BST)
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <43388019.9040308@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509270301380.1214670-100000@mozart.ebi.ac.uk>

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   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)



From senger at ebi.ac.uk  Tue Sep 27 02:06:19 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 27 Sep 2005 03:06:19 +0100 (BST)
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <43388019.9040308@cnb.uam.es>
Message-ID: <Pine.OSF.4.21.0509270301380.1214670-100000@mozart.ebi.ac.uk>

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   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)



From markw at illuminae.com  Tue Sep 27 02:20:21 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 02:20:21 +0000 GMT
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
Message-ID: <1032375145-1127787656-cardhu_blackberry.rim.net-23779-@engine12-cell01>

It seems that my suggestion to use bugzilla's comment feature was not a winning idea v.v. voting on RFC's...  Would people prefer to just use the mailing list?

M



-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Tue, 27 Sep 2005 03:06:19 
To:David Gonz?lez Pisano <dgpisano at cnb.uam.es>
Cc:Core developer announcements <moby-dev at portal.open-bio.org>,       mobydev <moby-dev at biomoby.org>
Subject: Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   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

--
Mark Wilkinson
...on the road!



From markw at illuminae.com  Tue Sep 27 02:20:21 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 02:20:21 +0000 GMT
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
Message-ID: <1032375145-1127787656-cardhu_blackberry.rim.net-23779-@engine12-cell01>

It seems that my suggestion to use bugzilla's comment feature was not a winning idea v.v. voting on RFC's...  Would people prefer to just use the mailing list?

M



-----Original Message-----
From: Martin Senger <senger at ebi.ac.uk>
Date: Tue, 27 Sep 2005 03:06:19 
To:David Gonz?lez Pisano <dgpisano at cnb.uam.es>
Cc:Core developer announcements <moby-dev at portal.open-bio.org>,       mobydev <moby-dev at biomoby.org>
Subject: Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called

David,
   Many thanks for the new document.
   The only detail is the "Notes" in serviceNotes. If we have this, the
old implementation need to be changed (because they expect the
human-readable text directly in serviceNotes now). I do not mind
(actually, I prefer that it is not a mixed-mode XML), but we need to be
aware of it.

   Please register my vote as YES.

   If the vote goes through, I will implement this chance at once in
jMoby.

   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

--
Mark Wilkinson
...on the road!



From Pieter.Neerincx at wur.nl  Tue Sep 27 09:31:05 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 27 Sep 2005 11:31:05 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <4338a329.70df3d00.2781.71d9@mx.gmail.com>
References: <4338a329.70df3d00.2781.71d9@mx.gmail.com>
Message-ID: <6EC9FF1D-1762-4CDD-BE3F-D05415A3457E@wur.nl>

Hi Eddie,

On 27-Sep-2005, at 3:40 AM, Edward Kawas wrote:

> Hi Pieter,
>
> I have been toying around with your endpoint. I noticed that
> the URL you gave earlier for the Object RDF was inconsistent
> with what was retrieved from the API call
> getResourceLocation(or something like that ...).
>
> I think that this occurred when you opened up your endpoint
> and perhaps forgot to modify it in your mobycentral.conf
> file (does https://bioinfw05:somePort/... resolve on your
> machine?).

Ooops, you are right I forgot to change the hostname into an IP  
address in that conf file. It does resolve in our LAN because the  
hostname is added to the hosts file on all the machines, but it  
doesn't resolve outside our LAN. I've fixed it now.

>
> The plugin utilizes the API call and hence wouldn't be able
> to create a personalized Mobycentral processor (Moby
> services and data types) list in Taverna without it.
>
> Once I utilized the URLs that you specified in this message,
> everything went as it should. I was able to use your
> processors, etc.

The behaviour I described is still the same for me. It works fine as  
long as I manually add my local central, but simply specifying my  
local central in the taverna/conf/mygrid.properties file doesn't  
work. There must be a difference in the way the BioMOBY scavanger is  
constructed during startup of Taverna and when you manually add a  
BioMOBY scavanger...

>
> I am uploading another version (I tweaked some of the logic)
> of the plugin in about 5 minutes. Word on the street is that
> Taverna 1.3 is going to be available later on this week
> (Friday?) and so that version most likely would be the one
> you would want to use.

Nice! I'll get myself a cup of coffee and try the new version ...

Cheers,

Pieter

> In addition, if you notice anything out of the ordinary,
> please let me know ASAP so that I can correct it in time for
> the much anticipated release.
>
> Thanks,
>
> Eddie
>
>
>> -----Original Message-----
>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>> dev-bounces at portal.open-bio.org] On Behalf Of Pieter
>> Neerincx
>> Sent: Monday, September 26, 2005 4:28 PM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] Moby objects in Taverna. Where do
>> they come from?
>>
>>
>> On  26Sep2005, at 16:56, Edward Kawas wrote:
>>
>>
>>> Hi Pieter,
>>>
>>>
>>>
>>>> When I append my local central to my mygrid.properties
>>>>
>> file
>>
>>>> for Taverna, I have the old behaviour: hence services
>>>>
>> from
>>
>>>> my local central, but objects from  the central
>>>>
> central.
>
>>>>
>>>>
>>>
>>> Where did you get this version of Taverna? Is it the one
>>> from their homepage?
>>>
>>
>> No, I've been testing with the version you put up at the
>> URL
>> mentioned below.
>>
>>
>>> If so, have you tried downloading the
>>> one that I put up at
>>> http://bioinfo.icapture.ubc.ca/ekawas/taverna-workbench-
>>>
>> 1.2.zip?
>>
>>> Also, is it possible to post your Mobycentral endpoint
>>>
>> so
>>
>>> that I could see how things work?
>>>
>>
>> Yes, sure. I have now temporarily disabled the SSL
>> requirement, so
>> everything should work nicely over our firewall using port
>> 80 :). as
>> long as I'm testing I don't need the HTTPS, but some of
>> the people
>> that are using my services on a production server do.
>>
>> My test MOBY Central endpoint is at:
>> http://137.224.52.237/phenolink/
>> biomoby/central/cgi-bin/MOBY-Central.pl
>> My test RESOURCES script is at:
>> http://137.224.52.237/RESOURCES/MOBY-S/
>>
>> Hope this helps,
>>
>> Pieter
>>
>>
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1038
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> phone: 0317-484 706
>> fax: 0317-483 584
>> mobile: 06-143 66 783
>> pieter.neerincx at wur.nl
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From markw at illuminae.com  Tue Sep 27 02:56:56 2005
From: markw at illuminae.com (mark wilkinson)
Date: Tue, 27 Sep 2005 02:56:56 +0000 GMT
Subject: [MOBY-dev] Move to the new website
Message-ID: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>

Hi all,

I am going to try to migrate to the new website this week (biomoby.open-bio.org).  Once we're satisfied with it, I'll get the biomoby.org DNS to resolve to that server.

There's a lot of migration to do, but I think I can manage much of that on my own.  It will be fun!

I'm not sure where people are keeping all of the new documents... Can we make a concerted effort to move them on to that server over the next few days?

Cheers all!  This has been an amazing four months since the last dev meeting!!!

M

--
Mark Wilkinson
...on the road!


From edward.kawas at gmail.com  Tue Sep 27 14:26:45 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 27 Sep 2005 07:26:45 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <6EC9FF1D-1762-4CDD-BE3F-D05415A3457E@wur.nl>
Message-ID: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>

> The behavior I described is still the same for me. It
> works fine as
> long as I manually add my local central, but simply
> specifying my
> local central in the taverna/conf/mygrid.properties file
> doesn't
> work. There must be a difference in the way the BioMOBY
> scavanger is
> constructed during startup of Taverna and when you
> manually add a
> BioMOBY scavenger...

Hi Pieter,

I found out what you were talking about and you were right
on all accounts. I have fixed this *bug* and I created a new
version that I am in the process of uploading.

Actually, I did notice that I am unable to add services
using your endpoint!?! I looked at your service instance rdf
and I noticed that you have the descriptions of services
available, but all find service calls don't seem to be
working. Is this true?

Eddie



From Pieter.Neerincx at wur.nl  Tue Sep 27 14:55:33 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Tue, 27 Sep 2005 16:55:33 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
References: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
Message-ID: <9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>


On 27-Sep-2005, at 4:26 PM, Edward Kawas wrote:

>> The behavior I described is still the same for me. It
>> works fine as
>> long as I manually add my local central, but simply
>> specifying my
>> local central in the taverna/conf/mygrid.properties file
>> doesn't
>> work. There must be a difference in the way the BioMOBY
>> scavanger is
>> constructed during startup of Taverna and when you
>> manually add a
>> BioMOBY scavenger...
>>
>
> Hi Pieter,
>
> I found out what you were talking about and you were right
> on all accounts. I have fixed this *bug* and I created a new
> version that I am in the process of uploading.

Super, will test it at the end of the day.

> Actually, I did notice that I am unable to add services
> using your endpoint!?! I looked at your service instance rdf
> and I noticed that you have the descriptions of services
> available, but all find service calls don't seem to be
> working. Is this true?

I'll look into it. Might be a problem that I switched off https for  
my local central, but not for the services themselves. I've been  
switching between ports, 80, 443, 8080 and 8443 for the past days.  
Maybe some of my config files are not in sync...

Pieter


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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From gss at ncgr.org  Tue Sep 27 17:18:43 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue, 27 Sep 2005 11:18:43 -0600
Subject: [MOBY-dev] Move to the new website
In-Reply-To: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
Message-ID: <43397EF3.50509@ncgr.org>

I hope that it is planned to keep the website content under CVS control.

// Gary

mark wilkinson wrote:
> Hi all,
> 
> I am going to try to migrate to the new website this week (biomoby.open-bio.org).  Once we're satisfied with it, I'll get the biomoby.org DNS to resolve to that server.
> 
> There's a lot of migration to do, but I think I can manage much of that on my own.  It will be fun!
> 
> I'm not sure where people are keeping all of the new documents... Can we make a concerted effort to move them on to that server over the next few days?
> 
> Cheers all!  This has been an amazing four months since the last dev meeting!!!
> 
> M
> 
> --
> Mark Wilkinson
> ...on the road!
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> 


From francis_gibbons at hms.harvard.edu  Wed Sep 28 01:27:53 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Tue, 27 Sep 2005 21:27:53 -0400
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.


Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
 
Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
 
-Frank



From francis_gibbons at hms.harvard.edu  Wed Sep 28 01:27:53 2005
From: francis_gibbons at hms.harvard.edu (Gibbons, Francis )
Date: Tue, 27 Sep 2005 21:27:53 -0400
Subject: [MOBY-dev] RFC #1863  Error Handling in MOBY-S   --  Vote Called
Message-ID: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.


Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
 
Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
 
-Frank



From dgpisano at cnb.uam.es  Wed Sep 28 09:33:05 2005
From: dgpisano at cnb.uam.es (=?UTF-8?B?RGF2aWQgR29uesOhbGV6IFBpc2Fubw==?=)
Date: Wed, 28 Sep 2005 11:33:05 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <433A6351.1080907@cnb.uam.es>

Frank,

Probably the main problem with the PIB is its location, inside the 
Object structure. One of the initial options we considered was to report 
exceptions inside mobyData, but mixing "data" with "what happened while 
computing the data" information didn't look like the best idea. Using 
the PIB also brings up again the problem of what is an empty object: can 
we report back a "not so empty object", ie, an object with no data but 
PIB data? What about an object with no data but CrossReferences? Is not 
really clear to me. Given the examples about the PIB in the 
specification, I always thought it was a good place to fill with static 
data associated to my results (like software version, database release, 
etc..), not really about why the service didn't work.

The last proposal  we uploaded includes a possible solution to avoid 
XML-mixed elements, basically permiting serviceNotes to have two 
elements: mobyException and Notes. This solution allows to extend the 
servicNotes element with other uses/schemas in the future.

David

Gibbons, Francis escribi?:

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>
>
>Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
> 
>Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
> 
>-Frank
>
>_______________________________________________
>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: dgpisano.vcf
Type: text/x-vcard
Size: 349 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050928/31f7573e/attachment.vcf>

From dgpisano at cnb.uam.es  Wed Sep 28 09:33:05 2005
From: dgpisano at cnb.uam.es (=?UTF-8?B?RGF2aWQgR29uesOhbGV6IFBpc2Fubw==?=)
Date: Wed, 28 Sep 2005 11:33:05 +0200
Subject: [MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called
In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
Message-ID: <433A6351.1080907@cnb.uam.es>

Frank,

Probably the main problem with the PIB is its location, inside the 
Object structure. One of the initial options we considered was to report 
exceptions inside mobyData, but mixing "data" with "what happened while 
computing the data" information didn't look like the best idea. Using 
the PIB also brings up again the problem of what is an empty object: can 
we report back a "not so empty object", ie, an object with no data but 
PIB data? What about an object with no data but CrossReferences? Is not 
really clear to me. Given the examples about the PIB in the 
specification, I always thought it was a good place to fill with static 
data associated to my results (like software version, database release, 
etc..), not really about why the service didn't work.

The last proposal  we uploaded includes a possible solution to avoid 
XML-mixed elements, basically permiting serviceNotes to have two 
elements: mobyException and Notes. This solution allows to extend the 
servicNotes element with other uses/schemas in the future.

David

Gibbons, Francis escribi?:

>   4) The proposal is not clear how to integrate new XML tags in
>serviceNotes with the current usage of serviceNotes. The current usage is
>a free text: should this free text be expected before, or after the
>exception code? Should it be there either exception tags or classic notes
>text? This would be the only place in Biomoby API with XML-mixed element,
>so it needs to be clarified, an example showing all possibilities would be
>beneficial.
>
>
>Martin, I wonder if the Provision Information Block (PIB) would make a more appropriate home for this XML content. As I understand if (from very brief conversation with Mark) it is not used right now (at least in the Perl API, though perhaps it's used in the Java version).  The current API has this to say about PIB: http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI#Provision
> 
>Specifially PIB was intended to provide XML-encoded metadata about the service, and maybe there's a good reason to restrict it to that. I do agree that mixing free text with XML (or having the content be ambiguous) would be tricky, and should be avoided if possible. Perhaps this is a way around that particular issue.
> 
>-Frank
>
>_______________________________________________
>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: dgpisano.vcf
Type: text/x-vcard
Size: 349 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050928/31f7573e/attachment-0001.vcf>

From Pieter.Neerincx at wur.nl  Wed Sep 28 14:01:42 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 28 Sep 2005 16:01:42 +0200
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>
References: <433956a8.18dec003.2d4a.6da9@mx.gmail.com>
	<9A90858B-EDA7-4FC6-9A64-26BECAE3662B@wur.nl>
Message-ID: <8E698684-29C3-43C0-B9A1-58188958D7B5@wur.nl>

Hi Eddie,

On 27-Sep-2005, at 4:55 PM, Pieter Neerincx wrote:
>>
>> Hi Pieter,
>>
>> I found out what you were talking about and you were right
>> on all accounts. I have fixed this *bug* and I created a new
>> version that I am in the process of uploading.
>>
>
> Super, will test it at the end of the day.

Check, it works! Taverna now uses my local central when added to  
taverna/conf/mygrid.porperties.

Ran into a few small other problems though. I'm not sure whether  
these are the result of your custom mod of taverna or whether these  
are generic Taverna bugs...

1. The ~taverna-workbench/runme.sh script to start Taverna was in the  
wrong encoding. It contains windows CR LF line endings. After I  
dos2unix-ed the file it works.

2. I can only add 1 processor to a workflow by "drag and drop".  
Taverna refuses to add any other processor I drag and drop. It  
doesn't matter what kind of processor it is: biomoby service, object,  
local java widget, etc.. I can add more processors to a workflow  
using right-click -> add to workflow.

>
>> Actually, I did notice that I am unable to add services
>> using your endpoint!?! I looked at your service instance rdf
>> and I noticed that you have the descriptions of services
>> available, but all find service calls don't seem to be
>> working. Is this true?
>>
>
> I'll look into it. Might be a problem that I switched off https for  
> my local central, but not for the services themselves. I've been  
> switching between ports, 80, 443, 8080 and 8443 for the past days.  
> Maybe some of my config files are not in sync...

Got that nailed down as well. Wasn't a port problem. I turned on  
debugging in path/to/perl/modules/MOBY/Central.pm this used to simply  
write debug info to /tmp/CentralRegistryLogOut.txt , but with the new  
code base this also generates an "Error 500, internal server error".  
This doesn't happen for all calls to MOBY Central, but it did mess up  
the find services call. The following line:

     $debug && &_LOG("found id $_->{service_instance_id}\n");

occurs several times. Not all of them are fatal, but the ones on line  
1992, 2010, 2028 and 2046 result in the internal server error...  
Don't know how to fix it yet. Turning debugging off must have been  
the easiest work around I applied ever :)

Cheers,

Pieter

>
> Pieter
>
>
>
>>
>> Eddie
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>
>
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
> phone: 0317-483 060
> fax: 0317-483 584
> mobile: 06-143 66 783
> pieter.neerincx at wur.nl
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From gordonp at ucalgary.ca  Wed Sep 28 14:02:35 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 28 Sep 2005 08:02:35 -0600
Subject: [MOBY-dev] RFC Committee  Membership
In-Reply-To: <1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
References: <5.2.1.1.2.20050921163919.011fab90@email.med.harvard.edu>	<4331CEA3.6020205@illuminae.com>
	<1127771816.5587.266.camel@bioinfo.icapture.ubc.ca>
Message-ID: <433AA27B.3050602@ucalgary.ca>

Actually, I did reply "Yes" to Eddie since he e-mailed me directly, but 
I guess it slipped his mind...

>The RDF committee now consists of:
>
>Frank
>Martin
>Eddie
>David
>Mark
>Simon
>Pieter
>
>
>I am assuming from Yan's message that he wont have time to participate
>(please correct me if I am wrong, Yan :-) ), and I have not yet heard
>from Paul Gordon.
>
>In any case, that's a great group!  Thanks all!  Let's close the
>committee for now.
>
>So, Martin, how does OMG run its democracy?  Unanimity, or majority
>rules?
>
>Mark
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>



From markw at illuminae.com  Wed Sep 28 14:03:43 2005
From: markw at illuminae.com (mark wilkinson)
Date: Wed, 28 Sep 2005 14:03:43 +0000 GMT
Subject: [MOBY-dev] RFC Committee  Membership
Message-ID: <489633558-1127916263-cardhu_blackberry.rim.net-9027-@engine09-cell01>

Excellent - thanks!

-----Original Message-----
From: Paul Gordon <gordonp at ucalgary.ca>
Date: Wed, 28 Sep 2005 08:02:35 
To:markw at illuminae.com,       Core developer announcements <moby-dev at portal.open-bio.org>
Subject: Re: [MOBY-dev] RFC Committee  Membership

Actually, I did reply "Yes" to Eddie since he e-mailed me directly, but 
I guess it slipped his mind...

>The RDF committee now consists of:
>
>Frank
>Martin
>Eddie
>David
>Mark
>Simon
>Pieter
>
>
>I am assuming from Yan's message that he wont have time to participate
>(please correct me if I am wrong, Yan :-) ), and I have not yet heard
>from Paul Gordon.
>
>In any case, that's a great group!  Thanks all!  Let's close the
>committee for now.
>
>So, Martin, how does OMG run its democracy?  Unanimity, or majority
>rules?
>
>Mark
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>  
>

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

--
Mark Wilkinson
...on the road!


From Pieter.Neerincx at wur.nl  Wed Sep 28 14:12:54 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 28 Sep 2005 16:12:54 +0200
Subject: [MOBY-dev] Move to the new website
In-Reply-To: <43397EF3.50509@ncgr.org>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
Message-ID: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>

First of all: OMG that new site is so much nicer than the old one!  
That will a big plus for BioMOBY PR.

On 27-Sep-2005, at 7:18 PM, Gary Schiltz wrote:

> I hope that it is planned to keep the website content under CVS  
> control.

That would be cool. Can't find any website stuff in the CVS that  
contains the code though. I already registered at the new site, but  
as far as I get it, that is only to add comments to news posts or  
something. So how do I contribute to this wonderful new site?

>
> // Gary
>
> mark wilkinson wrote:
>
>> Hi all,
>> I am going to try to migrate to the new website this week  
>> (biomoby.open-bio.org).  Once we're satisfied with it, I'll get  
>> the biomoby.org DNS to resolve to that server.
>> There's a lot of migration to do, but I think I can manage much of  
>> that on my own.  It will be fun!
>> I'm not sure where people are keeping all of the new documents...  
>> Can we make a concerted effort to move them on to that server over  
>> the next few days?
>> Cheers all!  This has been an amazing four months since the last  
>> dev meeting!!!

It sure has been. The core dev mailing list is officially described  
as "low volume for announcements only", but after I take I few days  
of I always have to do quite a bit of catching up :)

Cheers,

Pi

>> M
>> --
>> Mark Wilkinson
>> ...on the road!
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Wed Sep 28 15:04:18 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 28 Sep 2005 08:04:18 -0700
Subject: [MOBY-dev] Moby objects in Taverna. Where do they come from?
In-Reply-To: <8E698684-29C3-43C0-B9A1-58188958D7B5@wur.nl>
Message-ID: <433ab0f4.7e3a8bd0.47fe.ffffb878@mx.gmail.com>

> 1. The ~taverna-workbench/runme.sh script to start Taverna
> was in the
> wrong encoding. It contains windows CR LF line endings.
> After I
> dos2unix-ed the file it works.
That was my fault. I live in a windows world and created the
archive on windows after I built it with windows.



> 2. I can only add 1 processor to a workflow by "drag and
> drop".
> Taverna refuses to add any other processor I drag and
drop.
> It
> doesn't matter what kind of processor it is: biomoby
> service, object,
> local java widget, etc.. I can add more processors to a
> workflow
> using right-click -> add to workflow.
I wonder if this is because the version you ran was compiled
on my windows machine? I couldn't reproduce this behavior.

Thanks,

Eddie



From markw at illuminae.com  Wed Sep 28 15:11:30 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 08:11:30 -0700
Subject: [moby] Re: [MOBY-dev] Move to the new website
In-Reply-To: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org> <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
Message-ID: <1127920290.13392.7.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 16:12 +0200, Pieter Neerincx wrote:

> It sure has been. The core dev mailing list is officially described  
> as "low volume for announcements only", but after I take I few days  
> of I always have to do quite a bit of catching up :)

Yeah... there are more developers than users ;-)

I guess at this stage in MOBY development, most users eventually become
developers anyway.  Once the 1.0 API is out and coded up, we can start
to "market" MOBY as a tool rather than a toy...  This was one of the
discussions at the last MOBY meeting.

Cheers!

M




From markw at illuminae.com  Wed Sep 28 15:12:45 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 08:12:45 -0700
Subject: [moby] Re: [MOBY-dev] RFC #1863 Error Handling in MOBY-S --
	Vote Called
In-Reply-To: <433A6351.1080907@cnb.uam.es>
References: <16C1B7E52D13C54D9297F8102407AC800D4C05@MAILSERVER02.MED.HARVARD.EDU>
	<433A6351.1080907@cnb.uam.es>
Message-ID: <1127920365.13392.10.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 11:33 +0200, David Gonz?lez Pisano wrote:

> Using 
> the PIB also brings up again the problem of what is an empty object: can 
> we report back a "not so empty object", ie, an object with no data but 
> PIB data? What about an object with no data but CrossReferences? Is not 
> really clear to me. Given the examples about the PIB in the 
> specification, I always thought it was a good place to fill with static 
> data associated to my results (like software version, database release, 
> etc..), not really about why the service didn't work.

I agree with this interpretation of the API.  If a service fails, the
mobyData object should have the associated queryID filled in, but
otherwise have NO CONTENT.  This precludes the use of CrossRef's and/or
PIB's for error reporting.


> The last proposal  we uploaded includes a possible solution to avoid 
> XML-mixed elements, basically permiting serviceNotes to have two 
> elements: mobyException and Notes. This solution allows to extend the 
> servicNotes element with other uses/schemas in the future.

I think this is a great idea.  The serviceNotes block was stuck into the
original API just because it seemed so obviously useful, but was
intentionally left "undefined" until someone had time to think of how
best to structure it.  Looks like now someone has found the time!

M




From markw at illuminae.com  Wed Sep 28 16:09:30 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 09:09:30 -0700
Subject: [moby] Re: [MOBY-dev] Move to the new website
In-Reply-To: <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org> <8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
Message-ID: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>

On Wed, 2005-09-28 at 16:12 +0200, Pieter Neerincx wrote:
> First of all: OMG that new site is so much nicer than the old one!  
> That will a big plus for BioMOBY PR.

Yeah, we were all pretty blown away by what Simon did there!  Kudo's to
him!!


> That would be cool. Can't find any website stuff in the CVS that  
> contains the code though. I already registered at the new site, but  
> as far as I get it, that is only to add comments to news posts or  
> something. So how do I contribute to this wonderful new site?

The website is under WordPress control, so anyone who wants an account
can get one and edit the site as they desire.  We have a better
granularity of control with WordPress, such that we can prevent people
from changing e.g. the site templates, or certain "domains", while
allowing them to change other domains to their hearts content.  It isn't
CVS (i,e, there's no back-out of mistakes!) but it's quite nice!

To get a WordPress account ask Simon.  I don't think I have permissions
to create new accounts, so don't ask me :-)

There's a lot of work left to do on it, but I made some headway
yesterday in getting the client information moved over.  It's just a lot
of tedious HTML coding left to do, so I'll likely do the aesthetic stuff
in the pub just to make it tolerable ;-)

I'm planning to do a CVS checkout of the moby-live repository into the
web folder and then link into the new HTML docs that Frank has been
writing for the past few weeks.  Hopefully I'll be able to set up a cron
that updates that folder every day or so to keep the website docs
current.

Cheers all!

M


-- 
"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



From Pieter.Neerincx at wur.nl  Wed Sep 28 18:01:57 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Wed, 28 Sep 2005 20:01:57 +0200
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
References: <246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
Message-ID: <C666C785-3B69-4CCA-89A7-0F59865E3D35@wur.nl>

Hi Mark and Eddie,

With Eddie's help I managed to get a local BioMOBY Central (using the  
new code base) up and running and make it work with Taverna :). The  
documentation at:
http://www.biomoby.org/InstallingMOBYCentral.html
is a bit outdated and incomplete. So I upgraded that info with my  
experience. I have a temporary copy online at:
http://137.224.52.237/InstallingLocalMOBYCentral.html
Let me know what you think... and if you like it: either copy it to  
the BioMOBY website or wait for Simon to give me an account for the  
new site.

Pi



From francis_gibbons at hms.harvard.edu  Wed Sep 28 19:01:01 2005
From: francis_gibbons at hms.harvard.edu (Frank Gibbons)
Date: Wed, 28 Sep 2005 15:01:01 -0400
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <C666C785-3B69-4CCA-89A7-0F59865E3D35@wur.nl>
References: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
Message-ID: <5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>

Pieter,

At 02:01 PM 9/28/2005, you wrote:
>Hi Mark and Eddie,
>
>With Eddie's help I managed to get a local BioMOBY Central (using the
>new code base) up and running and make it work with Taverna :). The
>documentation at:
>http://www.biomoby.org/InstallingMOBYCentral.html
>is a bit outdated and incomplete. So I upgraded that info with my
>experience. I have a temporary copy online at:
>http://137.224.52.237/InstallingLocalMOBYCentral.html
>Let me know what you think... and if you like it: either copy it to
>the BioMOBY website or wait for Simon to give me an account for the
>new site.

I think this belongs in the CVS repository at least, to which I guess you 
already have access. Of course, it needs to go on the website too, but the 
entire content of the website should itself be available from CVS, with the 
website updated automatically from CVS.

-F

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 



From markw at illuminae.com  Wed Sep 28 22:19:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 15:19:40 -0700
Subject: [MOBY-dev] API docs up on the new site
Message-ID: <1127945980.13392.144.camel@bioinfo.icapture.ubc.ca>

Hi all, 

I've got Frank's new API docs up on the new biomoby site (click on the
"For Developers" link).  It's in a CVS checkout, but I just need to work
out how to put cvs update on a cron...  

Cheers!

M



-- 
"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



From markw at illuminae.com  Wed Sep 28 22:39:23 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 28 Sep 2005 15:39:23 -0700
Subject: [MOBY-dev] RFC #1863 - change request & question
Message-ID: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>

Hi David, 

I have a question:  Have you now lost interest in raising exceptions to
individual simples in a collection?  I notice that your RFC no longer
handles this case (though I came to realize that it was a good idea
after you explained it to me :-) )

Also a request for change:  

Change 1

FROM
In the case of Retrieve calls, failure will be silent and an empty
object of the associated output
type will be returned.

TO
In the case of Retrieve calls, failure will be silent should rise an
exception and an empty object
of the associated output type will be returned.

TO (REVISED)
In the case of an error, failure should raise an exception and an empty
mobyData block with the appropriate queryID will be returned.


Comments:  the wording in the original API are wrong - the object is no
empty, the mobyData block is empty.



-- 
"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



From Pieter.Neerincx at wur.nl  Thu Sep 29 15:11:49 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu, 29 Sep 2005 17:11:49 +0200
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>
References: <1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<246207166-1127829659-cardhu_blackberry.rim.net-18648-@engine08-cell01>
	<43397EF3.50509@ncgr.org>
	<8728FBD9-A1EA-4CC2-A51D-53C299C69868@wur.nl>
	<1127923770.13392.56.camel@bioinfo.icapture.ubc.ca>
	<5.2.1.1.2.20050928145902.01136fd0@email.med.harvard.edu>
Message-ID: <C540F3D5-9F4C-4C81-9E6D-BED23048B33A@wur.nl>


On 28-Sep-2005, at 9:01 PM, Frank Gibbons wrote:

> Pieter,
>
> At 02:01 PM 9/28/2005, you wrote:
>
>> Hi Mark and Eddie,
>>
>> With Eddie's help I managed to get a local BioMOBY Central (using the
>> new code base) up and running and make it work with Taverna :). The
>> documentation at:
>> http://www.biomoby.org/InstallingMOBYCentral.html
>> is a bit outdated and incomplete. So I upgraded that info with my
>> experience. I have a temporary copy online at:
>> http://137.224.52.237/InstallingLocalMOBYCentral.html
>> Let me know what you think... and if you like it: either copy it to
>> the BioMOBY website or wait for Simon to give me an account for the
>> new site.
>>
>
> I think this belongs in the CVS repository at least, to which I  
> guess you already have access. Of course, it needs to go on the  
> website too, but the entire content of the website should itself be  
> available from CVS, with the website updated automatically from CVS.

I agree, so I moved it into the CVS. Haven't heard back Mark or Eddie  
if the info is Ok, but they can now easily improve it if they run  
into wrong or missing information :).

For Eddie: the page links to the downloads of your servlets installer  
and custom Taverna version. If this is not Ok with you, please let me  
know.

I didn't find any templates for pages of the new site, so I had a  
look at the source and tried to compile something that is close to  
the new looks...

Pi

> -F
>
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA  
> 02115, USA.
> Tel: 617-432-3555       Fax: 617-432-3557       http:// 
> llama.med.harvard.edu/~fgibbons
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From edward.kawas at gmail.com  Thu Sep 29 15:18:18 2005
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 29 Sep 2005 08:18:18 -0700
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <C540F3D5-9F4C-4C81-9E6D-BED23048B33A@wur.nl>
Message-ID: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>

> For Eddie: the page links to the downloads of your
> servlets installer
> and custom Taverna version.

I recently removed the Taverna link because tomorrow (I
think) people can download it from Taverna's homepage.

Eddie





From Pieter.Neerincx at wur.nl  Thu Sep 29 15:43:04 2005
From: Pieter.Neerincx at wur.nl (Pieter Neerincx)
Date: Thu, 29 Sep 2005 17:43:04 +0200
Subject: [MOBY-dev] Installing a local BioMOBY Central documentation
In-Reply-To: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>
References: <433c05bd.55ed718d.47fe.ffff898d@mx.gmail.com>
Message-ID: <4DDBA090-1A2F-4F23-832E-D52DB04CB406@wur.nl>


On 29-Sep-2005, at 5:18 PM, Edward Kawas wrote:

>> For Eddie: the page links to the downloads of your
>> servlets installer
>> and custom Taverna version.
>>
>
> I recently removed the Taverna link because tomorrow (I
> think) people can download it from Taverna's homepage.

Ok, I'll remove that note about getting a custom version of taverna  
then.

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


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl





From dgpisano at cnb.uam.es  Fri Sep 30 09:37:06 2005
From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=)
Date: Fri, 30 Sep 2005 11:37:06 +0200
Subject: [MOBY-dev] RFC #1863 - change request & question
In-Reply-To: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>
References: <1127947163.13392.156.camel@bioinfo.icapture.ubc.ca>
Message-ID: <433D0742.4050708@cnb.uam.es>

Mark Wilkinson escribi?:

>Hi David, 
>
>I have a question:  Have you now lost interest in raising exceptions to
>individual simples in a collection?  I notice that your RFC no longer
>handles this case (though I came to realize that it was a good idea
>after you explained it to me :-) )
>  
>
Well, we didn't lost interest, but thought about it and decided to 
postpone the opening of the can of worms. After the next proposal 
(asynchrony) we are thinking about a third one for dealing with 
Collections, and Simples inside Collections. The main problematic point 
will be to (re)define namespaces (or parameter labels) and propose 
unique identifiers for Simples inside Collections, so we can refer to 
them. That means that quite a lot of things in the current MOBY 
specification could be discussed and changed, and we think is better not 
to mix the discussion about the errors with the discussion about the 
namespaces/collections. The latests proposals consider referring to the 
exception raising element using elementID tag (instead of the original 
namespaceID), so it can be easily extended to refer to Simples inside 
Collections if in the future we propose a way to identify them

>Also a request for change:  
>
>Change 1
>
>FROM
>In the case of Retrieve calls, failure will be silent and an empty
>object of the associated output
>type will be returned.
>
>TO
>In the case of Retrieve calls, failure will be silent should rise an
>exception and an empty object
>of the associated output type will be returned.
>
>TO (REVISED)
>In the case of an error, failure should raise an exception and an empty
>mobyData block with the appropriate queryID will be returned.
>
>
>Comments:  the wording in the original API are wrong - the object is no
>empty, the mobyData block is empty.
>
>  
>
I think it makes much more sense, will update the document and will send 
it again when is voted. BTW, I obviously vote YES, but don't know about 
the rest of the voters, or even if we postponed the voting date to the 
one suggested by Martin in October.

>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050930/900e212c/attachment.vcf>