From phillip.lord at newcastle.ac.uk Mon May 1 08:12:41 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Mon, 01 May 2006 13:12:41 +0100 Subject: [MOBY-dev] Shims In-Reply-To: <4453E7F5.3000609@cs.man.ac.uk> (Carole Goble's message of "Sat, 29 Apr 2006 23:25:57 +0100") References: <4452848B.2080500@ucalgary.ca> <09EDCBE0-BDD0-4ED1-8B10-F496F989AE7B@cs.man.ac.uk> <4453E7F5.3000609@cs.man.ac.uk> Message-ID: >>>>> "Carole" == Carole Goble writes: Carole> as the person who coined the term shim it is there precisely Carole> because there are a whole range of words that have been Carole> used. mediator, adaptor, conversion etc. not all shims are Carole> conversions. Carole> the new term gives a fresh start. By the way, the first shim Carole> paper not by manchester is now published Carole> Adapters, shims, and glue--service interoperability for in Carole> silico experiments Carole> U. Radetzki, U. Leser, S. C. Schulze-Rauschenbach, Carole> J. Zimmermann, J. Carole> Lussem, T. Bode, and A. B. Cremers Bioinformatics 2006 Carole> 22: 1137-1143. Carole> http://bioinformatics.oxfordjournals.org/cgi/content/abstract/22/9/1137?etoc What we need is an ontology of "words commonly used in computer sciences, which all mean approximately the same thing". Or, perhaps, a structured, controlled vocabulary would be better. I think that the closest word is adaptor, but shim services are slightly different -- adaptors are generally stateless (although they can connect stateful objects), while many shim services require data to operate on. Shim's a nice word: it's kind of old worldy, a bit like widget, or thingumybob, but unlike either of these it has a quite precise technical meaning, at least in engineering... Phil From ssoiland at cs.man.ac.uk Tue May 2 04:32:55 2006 From: ssoiland at cs.man.ac.uk (Stian Soiland) Date: Tue, 02 May 2006 09:32:55 +0100 Subject: [MOBY-dev] RFC: jMoby will start using Java 1.5. from June 30, 2006 In-Reply-To: References: Message-ID: <44571937.70809@cs.man.ac.uk> Martin Senger wrote: > Eddie, how is going your Taverna 1.5.enquiries? It seems that we may make > a tag 1.4, and start to use 1.5 when you give us a green light. Don't > worry, however, it does not need to be *now*. To quote myself from taverna-hackers list following Eddie's request there: Edward Kawas wrote: >> > > Sorry, I don't think that I asked my question properly! >> > > >> > > Basically, I wanted to check whether jmoby.jar, created >> > > with java 1.5, will break Taverna. Have you already made >> > > the switch to 1.5? My thoughts are that you haven't, but >> > > I may be wrong. We are aware that jMoby will switch to java 1.5, and it is one of our arguments against ourself on why we should switch to java 1.5 as a whole. http://twiki.mygrid.org.uk/twiki/bin/view/Mygrid/JavaFiveOMII Will the old jmoby.jar stop working? When? We have a large installed user base of Taverna probably running with Java 1.4. >From this you can conclude that, yes, it's OK for Taverna that you are moving to Java5, we want to do the same, but we are gathering momentum for doing the change. Our 2.0 development will be based on Java5. However, I do sincerely hope that the old jMoby libraries don't just stop working from June 30th, because there's a big base of installed Tavernas out there, and we might not want to bump to Java5 for the next minor release of Taverna. -- Stian Soiland School of Computer Science The University of Manchester http://www.cs.man.ac.uk/~ssoiland/ From Pieter.Neerincx at wur.nl Tue May 2 05:55:51 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 2 May 2006 11:55:51 +0200 Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/output articleNames In-Reply-To: References: Message-ID: Hi all, On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > Hi all, > > A few months ago the spec for service registration was tightened > such that > all inputs and outputs require an articleName. This is now > required also > in Taverna workflows, and as such, many "illegitimate" services > currently > in the registry will not function with Taverna even though they are > perfectly functional in reality. > > Given that these services are not looking for an articleName, it > will do > no harm to them if one were added. Thus the fastest way to bring all > service registrations back into compliance with the API would be > for me to > manipulate the MOBY Central database directly and add "dummy" > articleNames > ("input", "output") to all inputs and outputs that are currently un- > named. > > Would this bother anyone? It's fine with me. Actually I already registered most of my services to use "input" and "output" as dummy articleNames to make sure they worked in Taverna :). I was wondering the following though. Maybe this is a question for Eddie. If * articleName attributes are required for input and output articles and * every service is registered with certain articleNames for their inputs and outputs, * wouldn't it be possible to let Taverna fill in those articleName attributes automatically? Currently I have to fill them in manually all the time and that is a bit boring :(. Furthermore I already spent quite a bit of time staring at XML wondering why something didn't work ... and in the end it was a missing articleName or one with a typo. Cheers, Pi > Please let me know ASAP. > > Mark > > > > > > _______________________________________________ > moby-l mailing list > moby-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-l 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 May 2 09:16:14 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 2 May 2006 06:16:14 -0700 Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/outputarticleNames In-Reply-To: Message-ID: <000301c66dea$97a0caf0$6700a8c0@notebook> Hi Pieter, If you update your version of Taverna, you no longer have to fill in the article name as it is filled in automatically. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Pieter Neerincx > Sent: Tuesday, May 02, 2006 2:56 AM > To: mobydev > Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with > input/outputarticleNames > > Hi all, > > On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > > > Hi all, > > > > A few months ago the spec for service registration was > tightened such > > that all inputs and outputs require an articleName. This is now > > required also in Taverna workflows, and as such, many > "illegitimate" > > services currently in the registry will not function with > Taverna even > > though they are perfectly functional in reality. > > > > Given that these services are not looking for an > articleName, it will > > do no harm to them if one were added. Thus the fastest way > to bring > > all service registrations back into compliance with the API > would be > > for me to manipulate the MOBY Central database directly and add > > "dummy" > > articleNames > > ("input", "output") to all inputs and outputs that are > currently un- > > named. > > > > Would this bother anyone? > > It's fine with me. Actually I already registered most of my > services to use "input" and "output" as dummy articleNames to > make sure they worked in Taverna :). I was wondering the > following though. Maybe this is a question for Eddie. If > * articleName attributes are required for input and output > articles and > * every service is registered with certain articleNames for > their inputs and outputs, > * wouldn't it be possible to let Taverna fill in those > articleName attributes automatically? > > Currently I have to fill them in manually all the time and > that is a bit boring :(. Furthermore I already spent quite a > bit of time staring at XML wondering why something didn't > work ... and in the end it was a missing articleName or one > with a typo. > > Cheers, > > Pi > > > Please let me know ASAP. > > > > Mark > > > > > > > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-l > > > 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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue May 2 09:38:20 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 2 May 2006 13:38:20 +0000 GMT Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/outputarticleNames In-Reply-To: References: Message-ID: <1714899979-1146577161-cardhu_blackberry.rim.net-3771-@engine18-cell01> The newest version of the taverna plugins fills in the article names by itself :-) M -- Mark Wilkinson ...on the road! -----Original Message----- From: Pieter Neerincx Date: Tue, 2 May 2006 11:55:51 To:mobydev Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with input/output articleNames Hi all, On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > Hi all, > > A few months ago the spec for service registration was tightened > such that > all inputs and outputs require an articleName. This is now > required also > in Taverna workflows, and as such, many "illegitimate" services > currently > in the registry will not function with Taverna even though they are > perfectly functional in reality. > > Given that these services are not looking for an articleName, it > will do > no harm to them if one were added. Thus the fastest way to bring all > service registrations back into compliance with the API would be > for me to > manipulate the MOBY Central database directly and add "dummy" > articleNames > ("input", "output") to all inputs and outputs that are currently un- > named. > > Would this bother anyone? It's fine with me. Actually I already registered most of my services to use "input" and "output" as dummy articleNames to make sure they worked in Taverna :). I was wondering the following though. Maybe this is a question for Eddie. If * articleName attributes are required for input and output articles and * every service is registered with certain articleNames for their inputs and outputs, * wouldn't it be possible to let Taverna fill in those articleName attributes automatically? Currently I have to fill them in manually all the time and that is a bit boring :(. Furthermore I already spent quite a bit of time staring at XML wondering why something didn't work ... and in the end it was a missing articleName or one with a typo. Cheers, Pi > Please let me know ASAP. > > Mark > > > > > > _______________________________________________ > moby-l mailing list > moby-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-l 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 lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Tue May 2 10:16:51 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 02 May 2006 08:16:51 -0600 Subject: [MOBY-dev] RFC: jMoby will start using Java 1.5. from June 30, 2006 In-Reply-To: <44571937.70809@cs.man.ac.uk> References: <44571937.70809@cs.man.ac.uk> Message-ID: <445769D3.2010607@ucalgary.ca> I believe our plan was to freeze the Java 1.4 version at that date. We can certainly keep a 1.4 JAR version around, but it would not be updated with new functionality committed after June 30th... > Martin Senger wrote: > >> Eddie, how is going your Taverna 1.5.enquiries? It seems that we may make >> a tag 1.4, and start to use 1.5 when you give us a green light. Don't >> worry, however, it does not need to be *now*. >> > > > To quote myself from taverna-hackers list following Eddie's request there: > > > Edward Kawas wrote: > >>>>> Sorry, I don't think that I asked my question properly! >>>>> >>>>> Basically, I wanted to check whether jmoby.jar, created >>>>> with java 1.5, will break Taverna. Have you already made >>>>> the switch to 1.5? My thoughts are that you haven't, but >>>>> I may be wrong. >>>>> > > We are aware that jMoby will switch to java 1.5, and it is one of our > arguments against ourself on why we should switch to java 1.5 as a whole. > > http://twiki.mygrid.org.uk/twiki/bin/view/Mygrid/JavaFiveOMII > > Will the old jmoby.jar stop working? When? We have a large installed > user base of Taverna probably running with Java 1.4. > > > > > > >From this you can conclude that, yes, it's OK for Taverna that you are > moving to Java5, we want to do the same, but we are gathering momentum > for doing the change. Our 2.0 development will be based on Java5. > > However, I do sincerely hope that the old jMoby libraries don't just > stop working from June 30th, because there's a big base of installed > Tavernas out there, and we might not want to bump to Java5 for the next > minor release of Taverna. > > > From senger at ebi.ac.uk Tue May 2 12:37:14 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 2 May 2006 17:37:14 +0100 (BST) Subject: [MOBY-dev] RFC: jMoby will start using Java 1.5. from June 30, 2006 In-Reply-To: <44571937.70809@cs.man.ac.uk> Message-ID: > To quote myself from taverna-hackers list following Eddie's request there: > I am aware of your reply. But it is not clear what you mean by it. I looked into the page you refer to, and it did not tell me much. Sorry. > We are aware that jMoby will switch to java 1.5, and it is one of our > arguments against ourself on why we should switch to java 1.5 as a whole. > This is the sentence that my English is too weak to comprehend. > Will the old jmoby.jar stop working? > Old jmoby.jar will never stop working. It is working now under 1.5. fine. The problem is that we are suggesting to replace it by a *new* jmoby.jar (which will have some methods that are only available with Java 1.5). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From Pieter.Neerincx at wur.nl Tue May 2 12:51:17 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 2 May 2006 18:51:17 +0200 Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/outputarticleNames In-Reply-To: <000301c66dea$97a0caf0$6700a8c0@notebook> References: <000301c66dea$97a0caf0$6700a8c0@notebook> Message-ID: <85374531-A310-4058-B3F7-A66C9876153F@wur.nl> Hi Eddie, Super, I'll update. Thanks, Pi On 2-May-2006, at 3:16 PM, Edward Kawas wrote: > Hi Pieter, > > If you update your version of Taverna, you no longer have to fill > in the article > name as it is filled in automatically. > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org >> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of >> Pieter Neerincx >> Sent: Tuesday, May 02, 2006 2:56 AM >> To: mobydev >> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with >> input/outputarticleNames >> >> Hi all, >> >> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: >> >>> Hi all, >>> >>> A few months ago the spec for service registration was >> tightened such >>> that all inputs and outputs require an articleName. This is now >>> required also in Taverna workflows, and as such, many >> "illegitimate" >>> services currently in the registry will not function with >> Taverna even >>> though they are perfectly functional in reality. >>> >>> Given that these services are not looking for an >> articleName, it will >>> do no harm to them if one were added. Thus the fastest way >> to bring >>> all service registrations back into compliance with the API >> would be >>> for me to manipulate the MOBY Central database directly and add >>> "dummy" >>> articleNames >>> ("input", "output") to all inputs and outputs that are >> currently un- >>> named. >>> >>> Would this bother anyone? >> >> It's fine with me. Actually I already registered most of my >> services to use "input" and "output" as dummy articleNames to >> make sure they worked in Taverna :). I was wondering the >> following though. Maybe this is a question for Eddie. If >> * articleName attributes are required for input and output >> articles and >> * every service is registered with certain articleNames for >> their inputs and outputs, >> * wouldn't it be possible to let Taverna fill in those >> articleName attributes automatically? >> >> Currently I have to fill them in manually all the time and >> that is a bit boring :(. Furthermore I already spent quite a >> bit of time staring at XML wondering why something didn't >> work ... and in the end it was a missing articleName or one >> with a typo. >> >> Cheers, >> >> Pi >> >>> Please let me know ASAP. >>> >>> Mark >>> >>> >>> >>> >>> >>> _______________________________________________ >>> moby-l mailing list >>> moby-l at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-l >> >> >> 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 lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 ssoiland at cs.man.ac.uk Tue May 2 13:55:29 2006 From: ssoiland at cs.man.ac.uk (Stian Soiland) Date: Tue, 2 May 2006 18:55:29 +0100 Subject: [MOBY-dev] RFC: jMoby will start using Java 1.5. from June 30, 2006 In-Reply-To: References: Message-ID: <30BEFE62-4D84-4EE4-A650-06397645EAE4@cs.man.ac.uk> On 2. mai. 2006, at 17:37, Martin Senger wrote: > I am aware of your reply. But it is not clear what you mean by > it. I > looked into the page you refer to, and it did not tell me much. Sorry. Sorry, it is mainly for internal use, so it was not very relevant. What I tried to say was that we are also slowly switching to Java 1.5, but we are not yet requiring it. Several new features to come will require 1.5 though. >> We are aware that jMoby will switch to java 1.5, and it is one of our >> arguments against ourself on why we should switch to java 1.5 as a >> whole. > This is the sentence that my English is too weak to comprehend We are doing a "Why we need Java 1.5" information gathering (to convince the people who fund us), and that the new jMoby.jar will require 1.5 just adds to the list. As developers we all want to go for 1.5. > Old jmoby.jar will never stop working. It is working now under 1.5. > fine. The problem is that we are suggesting to replace it by a *new* > jmoby.jar (which will have some methods that are only available > with Java > 1.5). This is fine, so users who want the new methods will simply have to upgrade their Java and jmoby.jar, and possibly the plugin for Taverna. -- Stian Soiland School of Computer Science The University of Manchester http://www.cs.man.ac.uk/~ssoiland/ From edward.kawas at gmail.com Tue May 2 09:16:14 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 2 May 2006 06:16:14 -0700 Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/outputarticleNames In-Reply-To: Message-ID: <000301c66dea$97a0caf0$6700a8c0@notebook> Hi Pieter, If you update your version of Taverna, you no longer have to fill in the article name as it is filled in automatically. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Pieter Neerincx > Sent: Tuesday, May 02, 2006 2:56 AM > To: mobydev > Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with > input/outputarticleNames > > Hi all, > > On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > > > Hi all, > > > > A few months ago the spec for service registration was > tightened such > > that all inputs and outputs require an articleName. This is now > > required also in Taverna workflows, and as such, many > "illegitimate" > > services currently in the registry will not function with > Taverna even > > though they are perfectly functional in reality. > > > > Given that these services are not looking for an > articleName, it will > > do no harm to them if one were added. Thus the fastest way > to bring > > all service registrations back into compliance with the API > would be > > for me to manipulate the MOBY Central database directly and add > > "dummy" > > articleNames > > ("input", "output") to all inputs and outputs that are > currently un- > > named. > > > > Would this bother anyone? > > It's fine with me. Actually I already registered most of my > services to use "input" and "output" as dummy articleNames to > make sure they worked in Taverna :). I was wondering the > following though. Maybe this is a question for Eddie. If > * articleName attributes are required for input and output > articles and > * every service is registered with certain articleNames for > their inputs and outputs, > * wouldn't it be possible to let Taverna fill in those > articleName attributes automatically? > > Currently I have to fill them in manually all the time and > that is a bit boring :(. Furthermore I already spent quite a > bit of time staring at XML wondering why something didn't > work ... and in the end it was a missing articleName or one > with a typo. > > Cheers, > > Pi > > > Please let me know ASAP. > > > > Mark > > > > > > > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-l > > > 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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue May 2 19:29:57 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 02 May 2006 16:29:57 -0700 Subject: [MOBY-dev] LSIDs in the ServiceInstance RDF Message-ID: <1146612597.24762.31.camel@bioinfo.icapture.ubc.ca> Hi all, Eddie and I have been going in circles in a discussion of LSIDs in the ServiceInstance RDF, so we're hoping that a wider discussion can help reveal the correct path forward. Here's the issue: 1) The agent-based service update/register/deregister system is going to use the Service Signature RDF document to extract its information 2) At the moment, this document contains an LSID identifying the service instance, of the form: urn:lsid:biomoby.org:serviceinstance: authority,servicename:Timestamp 3) If the service provider updates this RDF with teh intention of calling the agent to update their service, we would expect that the LSID should also be updated. This is because although we only resolve LSID metadata, we have agreed amongst ourselves that it is important for client programs (e.g. Dashboard) to know when the metadata has changed. As such, the LSID timestamp *must* be updated when the service registration is modified, and thus the service provider must do this. 4) We have also agreed that, by convention, the timestamp of the LSID is to take a certain format, and in fact we are allowing certain of our software to parse and interpret that format. 5) we have little control over how the service provider chooses to modify their LSID when they update their Signature RDF. They might change the timestamp format, or they might change the namespace (authURI,servicename), or other things. 6) We, as the LSID authority (biomoby.org) parse the LSID string because we are supposed to be guaranteed to understand its form... but now a third party is generating the LSID's that we are supposed to be parsing and we can no longer guarantee that we will understand it even though we are supposed to be able to resolve it! (A) One option would be to remove the LSID from the Signature RDF so that the service provider cannot change it, but we feel that it is a useful component of that document, especially if the RESOURCES script (getResourceURLs) is used as the primary way that software bulk- downloads the contents of the registry. (B) Another alternative would be for the RESOURCES script (getResourceURLs) to generate RDF that includes the LSID, but for the Signature RDF that is hosted by the service host not to include it. The documents would be otherwise identical. This is an effective solution, but "feels" wrong, since there are now two non-identical RDF descriptions of a service. Personally, I am in favour of option (B) because the service provider will be adding a lot of additional annotation to their service signature anyway, but Eddie doesn't really like that one. Does anyone else have software that would break if we pursued that option? Are there other options we haven't thought of? Is there a strong feeling one way or the other about this from anyone? M -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Wed May 3 08:04:27 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 3 May 2006 13:04:27 +0100 (BST) Subject: [MOBY-dev] LSIDs in the ServiceInstance RDF In-Reply-To: <1146612597.24762.31.camel@bioinfo.icapture.ubc.ca> Message-ID: > This is because although we only resolve LSID metadata, we have agreed > amongst ourselves that it is important for client programs (e.g. > Dashboard) to know when the metadata has changed. > Not really. Dasboard uses only what is in the Biomoby central (I do not know if you call it metadata or not, but I think they are data). You (Biomoby Central) are an LSID authority, you should change version only if you chnage things in your database. No one else has right to change it. All other data (rather metadata) added or updated by service providers can be changed - but the LSID stays - so users can call getMetadata() and get an updated versionb, but they always get the same version when they call getData() (or when they call registry - which is what Dashboard does). I do not understand where is the problem. Our situation seems to be a typical situation as described by the LSID spec: You provide a new LSID version if there is a chnage at your side (meaning: in registry), anybody else (like a service provider) updates and provides metadata. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From duncan.hull at cs.man.ac.uk Wed May 3 13:40:39 2006 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Wed, 03 May 2006 18:40:39 +0100 Subject: [MOBY-dev] Shims in BioMOBY In-Reply-To: <4452848B.2080500@ucalgary.ca> References: <4452848B.2080500@ucalgary.ca> Message-ID: <4458EB17.7070001@cs.man.ac.uk> Hi Paul Paul Gordon wrote: >This is a very general question, especially for non-native-English >speakers. I was going to add a top-level "Shim" category of services >to the ontology, but I'm pretty sure most non-native-English speakers >would have no idea what this means. I'm borrowing the term from > >D Hull, R Stevens, P Lord, C Wroe, C Goble (2004). Treating shimantic >web syndrome with ontologies. First AKT workshop on Semantic Web >Services (AKT-SWS04). > > Since I'm first author of the paper [1] you mention, here are three points on how I think shim services should be described, so that users can find them. According to me, I am the first person to use the term "shim" to describe bioinformatics services, although its been used in hypermedia research [2] to describe similar operations in software. Firstly, it is probably useful to annotate services as a shims, although this is information that the user may not always want to see. A service that maps between equivalent identifiers (GenBank to EMBL for example) in one workflow might be considered a safe or "boring" operation [3], with shim-like properties. However, the same service in a different workflow constructed by a different user, might not be a considered a shim, because the safeness of the operation depends on the GenBank identifier the service takes as input. So it is probably a useful annotation, and a useful concept in your ontology, but the user will not always care wether a given service is a shim or not. Secondly, one thing that characterises shims is the relation between the input and the output. So, for example, a service that extracts the protein sequence from a BLAST_report is a fairly boring shim, because the relation between the input and the output is hasPart eg. a BLAST_report hasPart protein_sequence. I personally think this relation between input and output is one that will help distinguish the shim from other services in the registry, and therefore aid retrieval. So capturing this relation in the registry could be useful. Finally, if you're using a description logic reasoner, an interesting solution would be to describe the properties of shim services, and let the reasoner infer which services are shims based on these properties. This would save you some of the trouble of annotating shims in your registry, and would give you a clear definition of *exactly* what you mean when you say "shim", since the word has several different meanings.... Speaking of which, a shim [4] can also mean a transexual person: "she + him = shim", according to wikipedia :) Duncan [1] http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-122/paper1.pdf [2] http://eprints.ecs.soton.ac.uk/768/02/html/ [3] http://taverna.sourceforge.net/usermanual/docs.word.html#_Toc107043031 [4] http://en.wikipedia.org/wiki/Shim -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From gordonp at ucalgary.ca Wed May 3 16:42:50 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 03 May 2006 14:42:50 -0600 Subject: [MOBY-dev] Shims in BioMOBY In-Reply-To: <4458EB17.7070001@cs.man.ac.uk> References: <4452848B.2080500@ucalgary.ca> <4458EB17.7070001@cs.man.ac.uk> Message-ID: <445915CA.3010104@ucalgary.ca> Sorry, I guess I want to usurp your word then :-) I'd only put in my Shims category the very boring operations on *Object types*, such as DNASequence to FASTA_NA object conversion, or a multiple sequence alignment to a collection of sequences, etc., which are 1. purely syntactic 2. complete (all fields of the target object are meaningfully completed by the source object) 3. applicable for 100% of the possible source objects That way I can present FastA service options to a user with a DNASequence, since the user *already has exactly this information*. These problems exist only because developers didn't agree on using the same ontology object, not because of a fundamental different in the data. There should be no conscious decision necessary here, unlike decomposition and crossreferencing tasks. While you may call these Shims too, I think of these more as Adaptors. I guess this is why I made my original post :-) How about a service type ontology like : Conversion Shims Object types: e.g. DNASequence_to_FASTA, genbank_to_DNASequence Then my program would automatically consider services of type Conversion -> Shims -> Object type and I don't restrict your word :-) > Hi Paul > > Paul Gordon wrote: > >> This is a very general question, especially for non-native-English >> speakers. I was going to add a top-level "Shim" category of >> services to the ontology, but I'm pretty sure most >> non-native-English speakers would have no idea what this means. I'm >> borrowing the term from >> >> D Hull, R Stevens, P Lord, C Wroe, C Goble (2004). Treating shimantic >> web syndrome with ontologies. First AKT workshop on Semantic Web >> Services (AKT-SWS04). >> >> > Since I'm first author of the paper [1] you mention, here are three > points on how I think shim services should be described, so that users > can find them. According to me, I am the first person to use the term > "shim" to describe bioinformatics services, although its been used in > hypermedia research [2] to describe similar operations in software. > > Firstly, it is probably useful to annotate services as a shims, > although this is information that the user may not always want to > see. A service that maps between equivalent identifiers (GenBank to > EMBL for example) in one workflow might be considered a safe or > "boring" operation [3], with shim-like properties. However, the same > service in a different workflow constructed by a different user, might > not be a considered a shim, because the safeness of the operation > depends on the GenBank identifier the service takes as input. So it is > probably a useful annotation, and a useful concept in your ontology, > but the user will not always care wether a given service is a shim or > not. > > Secondly, one thing that characterises shims is the relation between > the input and the output. So, for example, a service that extracts the > protein sequence from a BLAST_report is a fairly boring shim, because > the relation between the input and the output is hasPart eg. a > BLAST_report hasPart protein_sequence. I personally think this > relation between input and output is one that will help distinguish > the shim from other services in the registry, and therefore aid > retrieval. So capturing this relation in the registry could be useful. > > Finally, if you're using a description logic reasoner, an interesting > solution would be to describe the properties of shim services, and let > the reasoner infer which services are shims based on these properties. > This would save you some of the trouble of annotating shims in your > registry, and would give you a clear definition of *exactly* what you > mean when you say "shim", since the word has several different > meanings.... > > Speaking of which, a shim [4] can also mean a transexual person: "she > + him = shim", according to wikipedia :) > > Duncan > > [1] > http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-122/paper1.pdf > > [2] http://eprints.ecs.soton.ac.uk/768/02/html/ [3] > http://taverna.sourceforge.net/usermanual/docs.word.html#_Toc107043031 > [4] http://en.wikipedia.org/wiki/Shim > From markw at illuminae.com Thu May 4 16:36:25 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 04 May 2006 13:36:25 -0700 Subject: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' In-Reply-To: <001101c66fb4$3156db10$6500a8c0@notebook> References: <001101c66fb4$3156db10$6500a8c0@notebook> Message-ID: <1146774985.17174.192.camel@bioinfo.icapture.ubc.ca> Code in the CVS updated. MOBY Central updated and restarted. All tests pass. We should be able to register Boolean secondaries now. Please check Eddie's documentation for instructions, or just use Dashboard :-) Thanks for the fast turnaround on this Eddie! M -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From edward.kawas at gmail.com Thu May 4 17:15:07 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 4 May 2006 14:15:07 -0700 Subject: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' In-Reply-To: <1146774985.17174.192.camel@bioinfo.icapture.ubc.ca> Message-ID: <000401c66fbf$d2d09700$6500a8c0@notebook> For those hosting your own registries, make sure to add the enum field 'Boolean' in the table secondary_input in the db mobycentral. I did this with the following sql statement: ALTER TABLE secondary_input CHANGE COLUMN datatype datatype ENUM('String','Integer','DateTime','Float','Boolean') DEFAULT NULL; Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Mark Wilkinson > Sent: Thursday, May 04, 2006 1:36 PM > To: Ed Kawas > Cc: mobydev > Subject: Re: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' > > Code in the CVS updated. MOBY Central updated and restarted. > All tests pass. > > We should be able to register Boolean secondaries now. > Please check Eddie's documentation for instructions, or just > use Dashboard :-) > > Thanks for the fast turnaround on this Eddie! > > M > > > -- > > -- > 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 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Thu May 4 17:15:07 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 4 May 2006 14:15:07 -0700 Subject: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' In-Reply-To: <1146774985.17174.192.camel@bioinfo.icapture.ubc.ca> Message-ID: <000401c66fbf$d2d09700$6500a8c0@notebook> For those hosting your own registries, make sure to add the enum field 'Boolean' in the table secondary_input in the db mobycentral. I did this with the following sql statement: ALTER TABLE secondary_input CHANGE COLUMN datatype datatype ENUM('String','Integer','DateTime','Float','Boolean') DEFAULT NULL; Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Mark Wilkinson > Sent: Thursday, May 04, 2006 1:36 PM > To: Ed Kawas > Cc: mobydev > Subject: Re: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' > > Code in the CVS updated. MOBY Central updated and restarted. > All tests pass. > > We should be able to register Boolean secondaries now. > Please check Eddie's documentation for instructions, or just > use Dashboard :-) > > Thanks for the fast turnaround on this Eddie! > > M > > > -- > > -- > 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 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Mon May 15 08:17:36 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 15 May 2006 14:17:36 +0200 Subject: [MOBY-dev] Error handling in Taverna (was Re: [MOBY-l] updating MOBY Central with input/outputarticleNames) In-Reply-To: <85374531-A310-4058-B3F7-A66C9876153F@wur.nl> References: <000301c66dea$97a0caf0$6700a8c0@notebook> <85374531-A310-4058-B3F7-A66C9876153F@wur.nl> Message-ID: <7690B374-E7BA-4F56-9DDB-4D64F4466A60@wur.nl> Hi Eddie, I tried the latest Taverna version today and I really enjoyed it :). Automatic addition of articleNames works perfectly and the new "Parse moby data" processor makes decomposing BioMOBY objects a breeze. I also browsed the online documentation again and noticed that the "output" and "input" ports are depreciated and only meant to be used for backwards compatibility. I used them to get the full output from BioMOBY services. This allowed me to have a look at the serviceNotes section in addition to the mobyData section. In Taverna 1.3.2RC1 (with updated *.jar from the BioMOBY site) this behaviour has changed and the legacy input and output ports only return the mobyData block. I realise now that I've been abusing those legacy ports for something they were never made for, but it was the only way to have a peek at diagnostic error massages from the serviceNotes. (Or is there another way?) I'd love to see that kind of functionality return one day... Thanks, Pi On 2-May-2006, at 6:51 PM, Pieter Neerincx wrote: > Hi Eddie, > > Super, I'll update. > > Thanks, > > Pi > > On 2-May-2006, at 3:16 PM, Edward Kawas wrote: > >> Hi Pieter, >> >> If you update your version of Taverna, you no longer have to fill >> in the article >> name as it is filled in automatically. >> >> Eddie >> >> >>> -----Original Message----- >>> From: moby-dev-bounces at lists.open-bio.org >>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of >>> Pieter Neerincx >>> Sent: Tuesday, May 02, 2006 2:56 AM >>> To: mobydev >>> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with >>> input/outputarticleNames >>> >>> Hi all, >>> >>> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: >>> >>>> Hi all, >>>> >>>> A few months ago the spec for service registration was >>> tightened such >>>> that all inputs and outputs require an articleName. This is now >>>> required also in Taverna workflows, and as such, many >>> "illegitimate" >>>> services currently in the registry will not function with >>> Taverna even >>>> though they are perfectly functional in reality. >>>> >>>> Given that these services are not looking for an >>> articleName, it will >>>> do no harm to them if one were added. Thus the fastest way >>> to bring >>>> all service registrations back into compliance with the API >>> would be >>>> for me to manipulate the MOBY Central database directly and add >>>> "dummy" >>>> articleNames >>>> ("input", "output") to all inputs and outputs that are >>> currently un- >>>> named. >>>> >>>> Would this bother anyone? >>> >>> It's fine with me. Actually I already registered most of my >>> services to use "input" and "output" as dummy articleNames to >>> make sure they worked in Taverna :). I was wondering the >>> following though. Maybe this is a question for Eddie. If >>> * articleName attributes are required for input and output >>> articles and >>> * every service is registered with certain articleNames for >>> their inputs and outputs, >>> * wouldn't it be possible to let Taverna fill in those >>> articleName attributes automatically? >>> >>> Currently I have to fill them in manually all the time and >>> that is a bit boring :(. Furthermore I already spent quite a >>> bit of time staring at XML wondering why something didn't >>> work ... and in the end it was a missing articleName or one >>> with a typo. >>> >>> Cheers, >>> >>> Pi >>> >>>> Please let me know ASAP. >>>> >>>> Mark >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> moby-l mailing list >>>> moby-l at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/moby-l >>> >>> >>> 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 lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.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 lists.open-bio.org > http://lists.open-bio.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 May 15 09:28:54 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 15 May 2006 06:28:54 -0700 Subject: [MOBY-dev] Error handling in Taverna (was Re: [MOBY-l] updatingMOBY Central with input/outputarticleNames) In-Reply-To: <7690B374-E7BA-4F56-9DDB-4D64F4466A60@wur.nl> Message-ID: <000301c67823$85db2d40$6700a8c0@notebook> Hi Pieter, Putting the service notes into the the other ports is actually on my todo list. My current objectives were to create the parser processor and support secondarys. These tasks are done, but I am still testing the parser. I am glad that you liked the parser (which must have been hard to find, considering it isnt documented yet). Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Pieter Neerincx > Sent: Monday, May 15, 2006 5:18 AM > To: Core developer announcements > Subject: [MOBY-dev] Error handling in Taverna (was Re: > [MOBY-l] updatingMOBY Central with input/outputarticleNames) > > Hi Eddie, > > I tried the latest Taverna version today and I really enjoyed it :). > Automatic addition of articleNames works perfectly and the > new "Parse moby data" processor makes decomposing BioMOBY > objects a breeze. > > I also browsed the online documentation again and noticed > that the "output" and "input" ports are depreciated and only > meant to be used for backwards compatibility. I used them to > get the full output from BioMOBY services. This allowed me to > have a look at the serviceNotes section in addition to the > mobyData section. In Taverna 1.3.2RC1 (with updated *.jar > from the BioMOBY site) this behaviour has changed and the > legacy input and output ports only return the mobyData block. > I realise now that I've been abusing those legacy ports for > something they were never made for, but it was the only way > to have a peek at diagnostic error massages from the > serviceNotes. (Or is there another > way?) I'd love to see that kind of functionality return one day... > > Thanks, > > Pi > > > On 2-May-2006, at 6:51 PM, Pieter Neerincx wrote: > > > Hi Eddie, > > > > Super, I'll update. > > > > Thanks, > > > > Pi > > > > On 2-May-2006, at 3:16 PM, Edward Kawas wrote: > > > >> Hi Pieter, > >> > >> If you update your version of Taverna, you no longer have > to fill in > >> the article name as it is filled in automatically. > >> > >> Eddie > >> > >> > >>> -----Original Message----- > >>> From: moby-dev-bounces at lists.open-bio.org > >>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Pieter > >>> Neerincx > >>> Sent: Tuesday, May 02, 2006 2:56 AM > >>> To: mobydev > >>> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with > >>> input/outputarticleNames > >>> > >>> Hi all, > >>> > >>> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > >>> > >>>> Hi all, > >>>> > >>>> A few months ago the spec for service registration was > >>> tightened such > >>>> that all inputs and outputs require an articleName. This is now > >>>> required also in Taverna workflows, and as such, many > >>> "illegitimate" > >>>> services currently in the registry will not function with > >>> Taverna even > >>>> though they are perfectly functional in reality. > >>>> > >>>> Given that these services are not looking for an > >>> articleName, it will > >>>> do no harm to them if one were added. Thus the fastest way > >>> to bring > >>>> all service registrations back into compliance with the API > >>> would be > >>>> for me to manipulate the MOBY Central database directly and add > >>>> "dummy" > >>>> articleNames > >>>> ("input", "output") to all inputs and outputs that are > >>> currently un- > >>>> named. > >>>> > >>>> Would this bother anyone? > >>> > >>> It's fine with me. Actually I already registered most of > my services > >>> to use "input" and "output" as dummy articleNames to make > sure they > >>> worked in Taverna :). I was wondering the following though. Maybe > >>> this is a question for Eddie. If > >>> * articleName attributes are required for input and > output articles > >>> and > >>> * every service is registered with certain articleNames for their > >>> inputs and outputs, > >>> * wouldn't it be possible to let Taverna fill in those > articleName > >>> attributes automatically? > >>> > >>> Currently I have to fill them in manually all the time > and that is a > >>> bit boring :(. Furthermore I already spent quite a bit of time > >>> staring at XML wondering why something didn't work ... and in the > >>> end it was a missing articleName or one with a typo. > >>> > >>> Cheers, > >>> > >>> Pi > >>> > >>>> Please let me know ASAP. > >>>> > >>>> Mark > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> moby-l mailing list > >>>> moby-l at lists.open-bio.org > >>>> http://lists.open-bio.org/mailman/listinfo/moby-l > >>> > >>> > >>> 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 lists.open-bio.org > >>> http://lists.open-bio.org/mailman/listinfo/moby-dev > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at lists.open-bio.org > >> http://lists.open-bio.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 lists.open-bio.org > > http://lists.open-bio.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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From spies at ipk-gatersleben.de Thu May 18 08:41:23 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 18 May 2006 14:41:23 +0200 Subject: [MOBY-dev] Summary of recently changes in BioMoby Message-ID: <446C6B73.4010509@ipk-gatersleben.de> Hello, it seems to be that BioMoby changed a lot in the last few months. Will there be an "update paper" or something like that in the future? For me as a newbie this would be interessting. Karl From akerhornou at imim.es Thu May 18 10:40:39 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Thu, 18 May 2006 16:40:39 +0200 Subject: [MOBY-dev] mobycentral too many connections error! Message-ID: <446C8767.5070902@imim.es> Hi, i get these errors when i try to connect to mobycentral to retrieve information about a service, " DBI connect('mobyobject:localhost:3306','moby_internal',...) failed: Too many connections at /usr/lib/perl5/site_perl/5.8.5/MOBY/OntologyServer.pm line 160 ERROR ERROR ERROR " or this one : " DBI connect('mobycentral:localhost:3306','moby_internal',...) failed: Too many connections at /usr/lib/perl5/site_perl/5.8.5/MOBY/Adaptor/moby/queryapi/mysql.pm line 90 ERROR ERROR ERROR " Any idea ? cheers Arnaud From markw at illuminae.com Thu May 18 11:01:51 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 18 May 2006 08:01:51 -0700 Subject: [MOBY-dev] [moby] mobycentral too many connections error! In-Reply-To: <446C8767.5070902@imim.es> References: <446C8767.5070902@imim.es> Message-ID: <1147964511.6562.20.camel@bioinfo.icapture.ubc.ca> I just restarted apache - that seems to have solved the problem M On Thu, 2006-05-18 at 16:40 +0200, Arnaud Kerhornou wrote: > Hi, > > i get these errors when i try to connect to mobycentral to retrieve > information about a service, > > " > DBI connect('mobyobject:localhost:3306','moby_internal',...) failed: Too > many connections at > /usr/lib/perl5/site_perl/5.8.5/MOBY/OntologyServer.pm line 160 > ERROR ERROR ERROR > " > or this one : > " > DBI connect('mobycentral:localhost:3306','moby_internal',...) failed: > Too many connections at > /usr/lib/perl5/site_perl/5.8.5/MOBY/Adaptor/moby/queryapi/mysql.pm line 90 > ERROR ERROR ERROR > " > > Any idea ? > cheers > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu May 18 10:47:58 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 18 May 2006 07:47:58 -0700 Subject: [MOBY-dev] [moby] Summary of recently changes in BioMoby In-Reply-To: <446C6B73.4010509@ipk-gatersleben.de> References: <446C6B73.4010509@ipk-gatersleben.de> Message-ID: <1147963678.6562.18.camel@bioinfo.icapture.ubc.ca> I'm writing a paper right now, and then there will be "the big one" (with all contributors as authors) that we will start writing later this summer - I'd like to get the final word on asynchrony before starting to write that one so... a few months from now, yes. In the meantime, any questions can be sent to the list :-) M On Thu, 2006-05-18 at 14:41 +0200, Karl Spies wrote: > Hello, > > it seems to be that BioMoby changed a lot in the last few months. Will > there be an "update paper" or something like that in the future? > > For me as a newbie this would be interessting. > > Karl > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu May 18 11:01:51 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 18 May 2006 08:01:51 -0700 Subject: [MOBY-dev] [moby] mobycentral too many connections error! In-Reply-To: <446C8767.5070902@imim.es> References: <446C8767.5070902@imim.es> Message-ID: <1147964511.6562.20.camel@bioinfo.icapture.ubc.ca> I just restarted apache - that seems to have solved the problem M On Thu, 2006-05-18 at 16:40 +0200, Arnaud Kerhornou wrote: > Hi, > > i get these errors when i try to connect to mobycentral to retrieve > information about a service, > > " > DBI connect('mobyobject:localhost:3306','moby_internal',...) failed: Too > many connections at > /usr/lib/perl5/site_perl/5.8.5/MOBY/OntologyServer.pm line 160 > ERROR ERROR ERROR > " > or this one : > " > DBI connect('mobycentral:localhost:3306','moby_internal',...) failed: > Too many connections at > /usr/lib/perl5/site_perl/5.8.5/MOBY/Adaptor/moby/queryapi/mysql.pm line 90 > ERROR ERROR ERROR > " > > Any idea ? > cheers > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Thu May 18 13:56:39 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 18 May 2006 19:56:39 +0200 Subject: [MOBY-dev] Error handling in Taverna (was Re: [MOBY-l] updatingMOBY Central with input/outputarticleNames) In-Reply-To: <001a01c6788c$22add510$6700a8c0@notebook> References: <001a01c6788c$22add510$6700a8c0@notebook> Message-ID: Hi Eddie, Wow, this is great! Especially the secondary parameter support rocks. Previously I used Taverna for simple tests and for creating nice flowcharts of my workflows, but for the real work I used custom Perl clients. Now that secondaries are supported as well, I guess those custom Perl clients will start catching dust... I tried a lot and so far I can not find bugs for the handling of Secondaries, serviceNotes and the "Parse moby data - updated (2006)" Local Java widget :). Just a few comments, see further down. The "other" BioMOBY Object parser that is available form the "Moby Service Details" contextual menu doesn't work very well though. I tried to dissect an object with two childs twice. In one case the processor is correctly added to the workflow. Hence the output from the corresponding BioMOBY service goes into this BioMOBY parser processor, but there is only one additional output port (for one of the child objects). For the other child object there's no output port. I ran the workflow this way and I do get the correct output for the cild for which there was an output port. In the second case the parser processor was not connected to the output of the service and there were no output ports for the two child objects. If I decompose objects without children the parser works perfectly, but in that case one might just as well use the Local Java widget. I guess I cheered a bit prematurely for this one and it is a bit more work in progress, but it looks very promising. On 16-May-2006, at 3:57 AM, Edward Kawas wrote: > Hi Pieter, > > I uploaded a new build of Taverna that hopefully addresses the > servicenote > absences. > > Please try it and let me know how it goes. All ports should have > servicenotes if > the service provides them. Works as advertised :). The services I use only provide "human readable" stuff in the notes section of the serviceNotes. If a service has multiple outputs then the same human readable notes are shown multiple times. That is a bit redundant. Unless the BioMOBY plugin handles the latest error handling specs and shows errors specifically for a certain output, maybe it would be better the have an additional output port for the serviceNotes instead. But for now I'm just very happy to see those notes. > The build is available at > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-workbench-1.3.2- > RC1.zip (For those who want to tried this on Linux / Unix machines: make sure to "dos2unix" some of the flat text files in that build.) > As for secondarys, if you context click services that are > configurable from the > 'advanced workflow ...' and choose 'Configure Moby Service' you > will be able to > use secodaries. Works! And even the enumeration lists and default values are supported. There is one thing missing though: I couldn't fetch descriptions for the secondaries. For the secondaries of my own services I know what they are doing, but for a remote service I wouldn't have a clue on how to use them. One final comment about the name for the contextual menus. Now there is: * Moby Service Details: for info about the required input or output Simples and Collections. * Configure Moby Service: for the optional Secondaries. The names of the contextual menus are rather non-descriptive. Why would Secondaries not be part of Moby Service Details? From the contextual menu names I can not figure out that one of them is for required stuff and the other for optional parameters. So it could be a bit more user friendly, but the bottom line is that I have been playing with Taverna for 1,5 day now like a little kid that just got an invaluable Christmas present. (Imagine what happens here when the object decomposition parser works as well :)). > I was pleasantly surprised that you had found this build of Taverna > on the web. > I had originally put it there for mark to download and try out > before I > committed my changes to the cvs. I did think of asking you to try > it, but I > didn't want to bother you. I wouldn't mind of you'd bother me a bit more often with cool tools like this! Thanks, Pi > Thanks, > > Eddie > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org >> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of >> Pieter Neerincx >> Sent: Monday, May 15, 2006 5:18 AM >> To: Core developer announcements >> Subject: [MOBY-dev] Error handling in Taverna (was Re: >> [MOBY-l] updatingMOBY Central with input/outputarticleNames) >> >> Hi Eddie, >> >> I tried the latest Taverna version today and I really enjoyed it :). >> Automatic addition of articleNames works perfectly and the >> new "Parse moby data" processor makes decomposing BioMOBY >> objects a breeze. >> >> I also browsed the online documentation again and noticed >> that the "output" and "input" ports are depreciated and only >> meant to be used for backwards compatibility. I used them to >> get the full output from BioMOBY services. This allowed me to >> have a look at the serviceNotes section in addition to the >> mobyData section. In Taverna 1.3.2RC1 (with updated *.jar >> from the BioMOBY site) this behaviour has changed and the >> legacy input and output ports only return the mobyData block. >> I realise now that I've been abusing those legacy ports for >> something they were never made for, but it was the only way >> to have a peek at diagnostic error massages from the >> serviceNotes. (Or is there another >> way?) I'd love to see that kind of functionality return one day... >> >> Thanks, >> >> Pi >> >> >> On 2-May-2006, at 6:51 PM, Pieter Neerincx wrote: >> >>> Hi Eddie, >>> >>> Super, I'll update. >>> >>> Thanks, >>> >>> Pi >>> >>> On 2-May-2006, at 3:16 PM, Edward Kawas wrote: >>> >>>> Hi Pieter, >>>> >>>> If you update your version of Taverna, you no longer have >> to fill in >>>> the article name as it is filled in automatically. >>>> >>>> Eddie >>>> >>>> >>>>> -----Original Message----- >>>>> From: moby-dev-bounces at lists.open-bio.org >>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Pieter >>>>> Neerincx >>>>> Sent: Tuesday, May 02, 2006 2:56 AM >>>>> To: mobydev >>>>> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with >>>>> input/outputarticleNames >>>>> >>>>> Hi all, >>>>> >>>>> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> A few months ago the spec for service registration was >>>>> tightened such >>>>>> that all inputs and outputs require an articleName. This is now >>>>>> required also in Taverna workflows, and as such, many >>>>> "illegitimate" >>>>>> services currently in the registry will not function with >>>>> Taverna even >>>>>> though they are perfectly functional in reality. >>>>>> >>>>>> Given that these services are not looking for an >>>>> articleName, it will >>>>>> do no harm to them if one were added. Thus the fastest way >>>>> to bring >>>>>> all service registrations back into compliance with the API >>>>> would be >>>>>> for me to manipulate the MOBY Central database directly and add >>>>>> "dummy" >>>>>> articleNames >>>>>> ("input", "output") to all inputs and outputs that are >>>>> currently un- >>>>>> named. >>>>>> >>>>>> Would this bother anyone? >>>>> >>>>> It's fine with me. Actually I already registered most of >> my services >>>>> to use "input" and "output" as dummy articleNames to make >> sure they >>>>> worked in Taverna :). I was wondering the following though. Maybe >>>>> this is a question for Eddie. If >>>>> * articleName attributes are required for input and >> output articles >>>>> and >>>>> * every service is registered with certain articleNames for their >>>>> inputs and outputs, >>>>> * wouldn't it be possible to let Taverna fill in those >> articleName >>>>> attributes automatically? >>>>> >>>>> Currently I have to fill them in manually all the time >> and that is a >>>>> bit boring :(. Furthermore I already spent quite a bit of time >>>>> staring at XML wondering why something didn't work ... and in the >>>>> end it was a missing articleName or one with a typo. >>>>> >>>>> Cheers, >>>>> >>>>> Pi >>>>> >>>>>> Please let me know ASAP. >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> moby-l mailing list >>>>>> moby-l at lists.open-bio.org >>>>>> http://lists.open-bio.org/mailman/listinfo/moby-l >>>>> >>>>> >>>>> 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 lists.open-bio.org >>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at lists.open-bio.org >>>> http://lists.open-bio.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 lists.open-bio.org >>> http://lists.open-bio.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 lists.open-bio.org >> http://lists.open-bio.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 May 19 09:38:57 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 19 May 2006 06:38:57 -0700 Subject: [MOBY-dev] Error handling in Taverna (was Re: [MOBY-l]updatingMOBY Central with input/outputarticleNames) In-Reply-To: Message-ID: <000301c67b49$95017e90$6700a8c0@notebook> Hi Pieter, I was wondering if you could send me a workflow where the parser doesn't work. I am glad that you like the rest of the updates! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Pieter Neerincx > Sent: Thursday, May 18, 2006 10:57 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Error handling in Taverna (was Re: > [MOBY-l]updatingMOBY Central with input/outputarticleNames) > > Hi Eddie, > > Wow, this is great! Especially the secondary parameter > support rocks. > Previously I used Taverna for simple tests and for creating > nice flowcharts of my workflows, but for the real work I used > custom Perl clients. Now that secondaries are supported as > well, I guess those custom Perl clients will start catching dust... > > I tried a lot and so far I can not find bugs for the handling > of Secondaries, serviceNotes and the "Parse moby data - > updated (2006)" > Local Java widget :). Just a few comments, see further down. > > The "other" BioMOBY Object parser that is available form the > "Moby Service Details" contextual menu doesn't work very well > though. I tried to dissect an object with two childs twice. > In one case the processor is correctly added to the workflow. > Hence the output from the corresponding BioMOBY service goes > into this BioMOBY parser processor, but there is only one > additional output port (for one of the child objects). For > the other child object there's no output port. I ran the > workflow this way and I do get the correct output for the > cild for which there was an output port. In the second case > the parser processor was not connected to the output of the > service and there were no output ports for the two child > objects. If I decompose objects without children the parser > works perfectly, but in that case one might just as well use > the Local Java widget. I guess I cheered a bit prematurely > for this one and it is a bit more work in progress, but it > looks very promising. > > On 16-May-2006, at 3:57 AM, Edward Kawas wrote: > > > Hi Pieter, > > > > I uploaded a new build of Taverna that hopefully addresses the > > servicenote absences. > > > > Please try it and let me know how it goes. All ports should have > > servicenotes if the service provides them. > > Works as advertised :). The services I use only provide > "human readable" stuff in the notes section of the > serviceNotes. If a service has multiple outputs then the same > human readable notes are shown multiple times. That is a bit > redundant. Unless the BioMOBY plugin handles the latest error > handling specs and shows errors specifically for a certain > output, maybe it would be better the have an additional > output port for the serviceNotes instead. But for now I'm > just very happy to see those notes. > > > The build is available at > > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-workbench-1.3.2- > > RC1.zip > > (For those who want to tried this on Linux / Unix machines: > make sure to "dos2unix" some of the flat text files in that build.) > > > As for secondarys, if you context click services that are > configurable > > from the 'advanced workflow ...' and choose 'Configure Moby > Service' > > you will be able to use secodaries. > > Works! And even the enumeration lists and default values are > supported. There is one thing missing though: I couldn't > fetch descriptions for the secondaries. For the secondaries > of my own services I know what they are doing, but for a > remote service I wouldn't have a clue on how to use them. One > final comment about the name for the contextual menus. Now there is: > * Moby Service Details: for info about the required input or > output Simples and Collections. > * Configure Moby Service: for the optional Secondaries. > The names of the contextual menus are rather non-descriptive. > Why would Secondaries not be part of Moby Service Details? > From the contextual menu names I can not figure out that one > of them is for required stuff and the other for optional parameters. > > So it could be a bit more user friendly, but the bottom line > is that I have been playing with Taverna for 1,5 day now like > a little kid that just got an invaluable Christmas present. > (Imagine what happens here when the object decomposition > parser works as well :)). > > > I was pleasantly surprised that you had found this build of > Taverna on > > the web. > > I had originally put it there for mark to download and try > out before > > I committed my changes to the cvs. I did think of asking you to try > > it, but I didn't want to bother you. > > I wouldn't mind of you'd bother me a bit more often with cool > tools like this! > > Thanks, > > Pi > > > Thanks, > > > > Eddie > > > >> -----Original Message----- > >> From: moby-dev-bounces at lists.open-bio.org > >> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Pieter > >> Neerincx > >> Sent: Monday, May 15, 2006 5:18 AM > >> To: Core developer announcements > >> Subject: [MOBY-dev] Error handling in Taverna (was Re: > >> [MOBY-l] updatingMOBY Central with input/outputarticleNames) > >> > >> Hi Eddie, > >> > >> I tried the latest Taverna version today and I really > enjoyed it :). > >> Automatic addition of articleNames works perfectly and the > new "Parse > >> moby data" processor makes decomposing BioMOBY objects a breeze. > >> > >> I also browsed the online documentation again and noticed that the > >> "output" and "input" ports are depreciated and only meant > to be used > >> for backwards compatibility. I used them to get the full > output from > >> BioMOBY services. This allowed me to have a look at the > serviceNotes > >> section in addition to the mobyData section. In Taverna 1.3.2RC1 > >> (with updated *.jar from the BioMOBY site) this behaviour > has changed > >> and the legacy input and output ports only return the > mobyData block. > >> I realise now that I've been abusing those legacy ports > for something > >> they were never made for, but it was the only way to have > a peek at > >> diagnostic error massages from the serviceNotes. (Or is > there another > >> way?) I'd love to see that kind of functionality return one day... > >> > >> Thanks, > >> > >> Pi > >> > >> > >> On 2-May-2006, at 6:51 PM, Pieter Neerincx wrote: > >> > >>> Hi Eddie, > >>> > >>> Super, I'll update. > >>> > >>> Thanks, > >>> > >>> Pi > >>> > >>> On 2-May-2006, at 3:16 PM, Edward Kawas wrote: > >>> > >>>> Hi Pieter, > >>>> > >>>> If you update your version of Taverna, you no longer have > >> to fill in > >>>> the article name as it is filled in automatically. > >>>> > >>>> Eddie > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: moby-dev-bounces at lists.open-bio.org > >>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf > Of Pieter > >>>>> Neerincx > >>>>> Sent: Tuesday, May 02, 2006 2:56 AM > >>>>> To: mobydev > >>>>> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with > >>>>> input/outputarticleNames > >>>>> > >>>>> Hi all, > >>>>> > >>>>> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> A few months ago the spec for service registration was > >>>>> tightened such > >>>>>> that all inputs and outputs require an articleName. > This is now > >>>>>> required also in Taverna workflows, and as such, many > >>>>> "illegitimate" > >>>>>> services currently in the registry will not function with > >>>>> Taverna even > >>>>>> though they are perfectly functional in reality. > >>>>>> > >>>>>> Given that these services are not looking for an > >>>>> articleName, it will > >>>>>> do no harm to them if one were added. Thus the fastest way > >>>>> to bring > >>>>>> all service registrations back into compliance with the API > >>>>> would be > >>>>>> for me to manipulate the MOBY Central database > directly and add > >>>>>> "dummy" > >>>>>> articleNames > >>>>>> ("input", "output") to all inputs and outputs that are > >>>>> currently un- > >>>>>> named. > >>>>>> > >>>>>> Would this bother anyone? > >>>>> > >>>>> It's fine with me. Actually I already registered most of > >> my services > >>>>> to use "input" and "output" as dummy articleNames to make > >> sure they > >>>>> worked in Taverna :). I was wondering the following > though. Maybe > >>>>> this is a question for Eddie. If > >>>>> * articleName attributes are required for input and > >> output articles > >>>>> and > >>>>> * every service is registered with certain articleNames > for their > >>>>> inputs and outputs, > >>>>> * wouldn't it be possible to let Taverna fill in those > >> articleName > >>>>> attributes automatically? > >>>>> > >>>>> Currently I have to fill them in manually all the time > >> and that is a > >>>>> bit boring :(. Furthermore I already spent quite a bit of time > >>>>> staring at XML wondering why something didn't work ... > and in the > >>>>> end it was a missing articleName or one with a typo. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Pi > >>>>> > >>>>>> Please let me know ASAP. > >>>>>> > >>>>>> Mark > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> moby-l mailing list > >>>>>> moby-l at lists.open-bio.org > >>>>>> http://lists.open-bio.org/mailman/listinfo/moby-l > >>>>> > >>>>> > >>>>> 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 lists.open-bio.org > >>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev > >>>> > >>>> _______________________________________________ > >>>> MOBY-dev mailing list > >>>> MOBY-dev at lists.open-bio.org > >>>> http://lists.open-bio.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 lists.open-bio.org > >>> http://lists.open-bio.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 lists.open-bio.org > >> http://lists.open-bio.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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From darin.london at duke.edu Mon May 22 11:29:45 2006 From: darin.london at duke.edu (Darin London) Date: Mon, 22 May 2006 11:29:45 -0400 Subject: [MOBY-dev] BOSC 2006 2nd Call for Papers In-Reply-To: <4471CE49.80109@duke.edu> References: <44294B65.4050207@duke.edu> <4471CE49.80109@duke.edu> Message-ID: <4471D8E9.8090109@duke.edu> 2nd CALL FOR SPEAKERS This is the second and last official call for speakers to submit their abstracts to speak at BOSC 2006 in Fortaleza, Brasil. In order to be considered as a potential speaker, an abstract must be recieved by Monday, June 5th, 2006. We look forward to a great conference this year. Please consult The Official BOSC 2006 Website at: http://www.open-bio.org/wiki/BOSC_2006 for more details and information. In addition, a BOSC weblog has been setup to make it easier to desiminate all BOSC related announcements: http://wiki.open-bio.org/boscblog/ And if you have an ICAL compatible Calendar, there is an EventDB calendar set up with all BOSC related deadlines. http://eventful.com/groups/G0-001-000014747-0 More information about ISMB can be found at the Official ISMB 2006 Website: http://ismb2006.cbi.cnptia.embrapa.br/ Thank You, and we look forward to seeing you all, The BOSC Organizing Committee. From darin.london at duke.edu Mon May 22 10:44:25 2006 From: darin.london at duke.edu (Darin London) Date: Mon, 22 May 2006 10:44:25 -0400 Subject: [MOBY-dev] Announcing BOSC 2006 In-Reply-To: <44294B65.4050207@duke.edu> References: <44294B65.4050207@duke.edu> Message-ID: <4471CE49.80109@duke.edu> 2nd CALL FOR SPEAKERS This is the second and last official call for speakers to submit their abstracts to speak at BOSC 2006 in Fortaleza, Brasil. In order to be considered as a potential speaker, an abstract must be recieved by Monday, June 5th, 2006. We look forward to a great conference this year. Please consult The Official BOSC 2006 Website at: http://www.open-bio.org/wiki/BOSC_2006 for more details and information. In addition, a BOSC weblog has been setup to make it easier to desiminate all BOSC related announcements: http://wiki.open-bio.org/boscblog/ And if you have an ICAL compatible Calendar, there is an EventDB calendar set up with all BOSC related deadlines. http://eventful.com/groups/G0-001-000014747-0 More information about ISMB can be found at the Official ISMB 2006 Website: http://ismb2006.cbi.cnptia.embrapa.br/ Thank You, and we look forward to seeing you all, The BOSC Organizing Committee. From darin.london at duke.edu Mon May 22 12:00:55 2006 From: darin.london at duke.edu (Darin London) Date: Mon, 22 May 2006 09:00:55 -0700 Subject: [MOBY-dev] [Bioperl-announce-l] BOSC 2006 2nd Call for Papers In-Reply-To: <4471CE49.80109@duke.edu> References: <44294B65.4050207@duke.edu> <4471CE49.80109@duke.edu> Message-ID: <000301c67db8$e8391f70$6400a8c0@CodonSolutions.local> 2nd CALL FOR SPEAKERS This is the second and last official call for speakers to submit their abstracts to speak at BOSC 2006 in Fortaleza, Brasil. In order to be considered as a potential speaker, an abstract must be recieved by Monday, June 5th, 2006. We look forward to a great conference this year. Please consult The Official BOSC 2006 Website at: http://www.open-bio.org/wiki/BOSC_2006 for more details and information. In addition, a BOSC weblog has been setup to make it easier to desiminate all BOSC related announcements: http://wiki.open-bio.org/boscblog/ And if you have an ICAL compatible Calendar, there is an EventDB calendar set up with all BOSC related deadlines. http://eventful.com/groups/G0-001-000014747-0 More information about ISMB can be found at the Official ISMB 2006 Website: http://ismb2006.cbi.cnptia.embrapa.br/ Thank You, and we look forward to seeing you all, The BOSC Organizing Committee. _______________________________________________ Bioperl-announce-l mailing list Bioperl-announce-l at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/bioperl-announce-l From akerhornou at imim.es Tue May 23 04:01:35 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Tue, 23 May 2006 10:01:35 +0200 Subject: [MOBY-dev] Data comrpession specs Message-ID: <4472C15F.30306@imim.es> Hi, Is there a document that describes the moby specs for data comrpession ? thanks Arnaud From markw at illuminae.com Tue May 23 10:01:25 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 23 May 2006 14:01:25 +0000 GMT Subject: [MOBY-dev] Data comrpession specs In-Reply-To: <4472C15F.30306@imim.es> References: <4472C15F.30306@imim.es> Message-ID: <152890776-1148393000-cardhu_blackberry.rim.net-176-@engine25-cell01> I'm not sure I understand your question. Can you re-word it? M -- Mark Wilkinson ...on the road! -----Original Message----- From: Arnaud Kerhornou Date: Tue, 23 May 2006 10:01:35 To:mobydev Subject: [MOBY-dev] Data comrpession specs Hi, Is there a document that describes the moby specs for data comrpession ? thanks Arnaud _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From akerhornou at imim.es Tue May 23 10:15:29 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Tue, 23 May 2006 16:15:29 +0200 Subject: [MOBY-dev] Data comrpession specs In-Reply-To: <152890776-1148393000-cardhu_blackberry.rim.net-176-@engine25-cell01> References: <4472C15F.30306@imim.es> <152890776-1148393000-cardhu_blackberry.rim.net-176-@engine25-cell01> Message-ID: <44731901.4000501@imim.es> mark wilkinson wrote: > I'm not sure I understand your question. Can you re-word it? > > I would like to submit compressed input data to a service and receive back compressed output data, does moby framework allow it ? the only thing i found was about Moses that is "Supporting automatic data compression". Is this functionality already implemented ? Thanks Arn. > M > > > -- > Mark Wilkinson > ...on the road! > > > -----Original Message----- > From: Arnaud Kerhornou > Date: Tue, 23 May 2006 10:01:35 > To:mobydev > Subject: [MOBY-dev] Data comrpession specs > > Hi, > > Is there a document that describes the moby specs for data comrpession ? > > thanks > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > From senger at ebi.ac.uk Tue May 23 10:28:07 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 23 May 2006 15:28:07 +0100 (BST) Subject: [MOBY-dev] Data comrpession specs In-Reply-To: <4472C15F.30306@imim.es> Message-ID: > Is there a document that describes the moby specs for data comrpession ? > I am not aware of any such document. My understanding is that you can still use compression on the transport protocol level. Biomoby messages between clients and services use HTTP protocol - which can support compression (I think it is called 'content encoding' in the HTTP 1.1 specification). There are also SOAP extensions about compression (I believe). But so far, there was not much efforts to really use it within biomoby (I know that jMoby part of Biomoby has this issues on its TODO list for long long time). Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Tue May 23 10:34:39 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 23 May 2006 15:34:39 +0100 (BST) Subject: [MOBY-dev] Data comrpession specs In-Reply-To: <44731901.4000501@imim.es> Message-ID: > the only thing i found was about Moses that is "Supporting automatic > data compression". Is this functionality already implemented ? > No, not yet. There was no pressure to do it :-) (But this is what I meant by "being on our TODO list".) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Tue May 23 11:58:48 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 23 May 2006 09:58:48 -0600 Subject: [MOBY-dev] Data comrpession specs In-Reply-To: References: Message-ID: <44733138.8000405@ucalgary.ca> There are generally two cases to consider: 1. Compression or responses should be handled at the Application layer (http://en.wikipedia.org/wiki/OSI_model#Layer_7:_Application_Layer) when the server knows it can safely return a compressed response (e.g. if Axis or Firefox, etc. sends an HTTP "Accept-encoding: x-gzip" header with the request). This is transparent to the MOBY protocol itself, and requires no changes to the MOBY spec. 2. The situation of *sending* compressed data (which is your problem now) is more complicated, as far as I know. Because the client is initiating the transaction, it has no a priori knowledge of whether the server will understand a compressed HTTP or SOAP or MOBY XML payload. The only way to guarantee you can safely send a compressed file is to have a standing contract with the service provider. This would require a change to the MOBY service registration, for example, with a new flag saying "I accept zlib and gzip compressed MOBY XML!". You would only be allowed to send compressed data to services whose definition includes that flag. >> the only thing i found was about Moses that is "Supporting automatic >> data compression". Is this functionality already implemented ? >> >> > No, not yet. There was no pressure to do it :-) (But this is what I > meant by "being on our TODO list".) > > Martin > > From senger at ebi.ac.uk Tue May 23 23:47:12 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 May 2006 04:47:12 +0100 (BST) Subject: [MOBY-dev] too many connections again Message-ID: Mark, could you restart the central, or whatever is needed... I cannot get to it, and we need it soon, or even now. Many thanks. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed May 24 10:02:51 2006 From: markw at illuminae.com (mark wilkinson) Date: Wed, 24 May 2006 14:02:51 +0000 GMT Subject: [MOBY-dev] too many connections again In-Reply-To: References: Message-ID: <452632608-1148479488-cardhu_blackberry.rim.net-3392-@engine20-cell01> Done I'm trying to track down what is causing this. We're doing some AJAX stuff here that seems to correspond suspiciously with the onset of the problem. ?? There is nothing obviously suspicious in the logs. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Martin Senger Date: Wed, 24 May 2006 04:47:12 To:Mark Wilkinson Cc:Moby Developers Subject: [MOBY-dev] too many connections again Mark, could you restart the central, or whatever is needed... I cannot get to it, and we need it soon, or even now. Many thanks. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Wed May 24 10:02:51 2006 From: markw at illuminae.com (mark wilkinson) Date: Wed, 24 May 2006 14:02:51 +0000 GMT Subject: [MOBY-dev] too many connections again In-Reply-To: References: Message-ID: <452632608-1148479488-cardhu_blackberry.rim.net-3392-@engine20-cell01> Done I'm trying to track down what is causing this. We're doing some AJAX stuff here that seems to correspond suspiciously with the onset of the problem. ?? There is nothing obviously suspicious in the logs. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Martin Senger Date: Wed, 24 May 2006 04:47:12 To:Mark Wilkinson Cc:Moby Developers Subject: [MOBY-dev] too many connections again Mark, could you restart the central, or whatever is needed... I cannot get to it, and we need it soon, or even now. Many thanks. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Wed May 24 10:19:03 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 May 2006 15:19:03 +0100 (BST) Subject: [MOBY-dev] too many connections again In-Reply-To: <452632608-1148479488-cardhu_blackberry.rim.net-3392-@engine20-cell01> Message-ID: > Done > Thanks. Works now. > I'm trying to track down what is causing this. We're doing some AJAX > stuff here that seems to correspond suspiciously with the onset of the > problem. > A side note: Assuming (perhaps wrongly) that your AJAX requests are directed to a Tomcat server (in other words that your requests are answered by Java code) I suggest to use a third-party connection-pool manager. There are several of them, one of the best (recommended, for example, by hibernate community) is c3p0 (available from sourceforge), another one is DBCP from Apache commons. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed May 24 15:17:27 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 May 2006 12:17:27 -0700 Subject: [MOBY-dev] Too many connections - problem discovered! Message-ID: A certain someone was browsing the MOBY Encyclopedia: OrgName: Google Inc. OrgID: GOGL Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US This is what is causing the "too many connections" problem :-) that should be easy to resolve. I'll get on it right away. M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From senger at ebi.ac.uk Wed May 24 15:26:42 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 May 2006 20:26:42 +0100 (BST) Subject: [MOBY-dev] Too many connections - problem discovered! In-Reply-To: Message-ID: > This is what is causing the "too many connections" problem :-) > that should be easy to resolve. > Why do you think it is easy to resolve? Do you mean that you simple reject google for searching us? Well, you can, perhaps it makes sense - but generally the biomoby central should be prepared for many requests in the short period of time, so leaving google here is a good test that the central reacts properly for many (almost) simultaneous requests. So I would prefer to leave the google doing what it is doing but fix the problem in Central.. What do you think? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From phillip.lord at newcastle.ac.uk Mon May 1 12:12:41 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Mon, 01 May 2006 13:12:41 +0100 Subject: [MOBY-dev] Shims In-Reply-To: <4453E7F5.3000609@cs.man.ac.uk> (Carole Goble's message of "Sat, 29 Apr 2006 23:25:57 +0100") References: <4452848B.2080500@ucalgary.ca> <09EDCBE0-BDD0-4ED1-8B10-F496F989AE7B@cs.man.ac.uk> <4453E7F5.3000609@cs.man.ac.uk> Message-ID: >>>>> "Carole" == Carole Goble writes: Carole> as the person who coined the term shim it is there precisely Carole> because there are a whole range of words that have been Carole> used. mediator, adaptor, conversion etc. not all shims are Carole> conversions. Carole> the new term gives a fresh start. By the way, the first shim Carole> paper not by manchester is now published Carole> Adapters, shims, and glue--service interoperability for in Carole> silico experiments Carole> U. Radetzki, U. Leser, S. C. Schulze-Rauschenbach, Carole> J. Zimmermann, J. Carole> Lussem, T. Bode, and A. B. Cremers Bioinformatics 2006 Carole> 22: 1137-1143. Carole> http://bioinformatics.oxfordjournals.org/cgi/content/abstract/22/9/1137?etoc What we need is an ontology of "words commonly used in computer sciences, which all mean approximately the same thing". Or, perhaps, a structured, controlled vocabulary would be better. I think that the closest word is adaptor, but shim services are slightly different -- adaptors are generally stateless (although they can connect stateful objects), while many shim services require data to operate on. Shim's a nice word: it's kind of old worldy, a bit like widget, or thingumybob, but unlike either of these it has a quite precise technical meaning, at least in engineering... Phil From ssoiland at cs.man.ac.uk Tue May 2 08:32:55 2006 From: ssoiland at cs.man.ac.uk (Stian Soiland) Date: Tue, 02 May 2006 09:32:55 +0100 Subject: [MOBY-dev] RFC: jMoby will start using Java 1.5. from June 30, 2006 In-Reply-To: References: Message-ID: <44571937.70809@cs.man.ac.uk> Martin Senger wrote: > Eddie, how is going your Taverna 1.5.enquiries? It seems that we may make > a tag 1.4, and start to use 1.5 when you give us a green light. Don't > worry, however, it does not need to be *now*. To quote myself from taverna-hackers list following Eddie's request there: Edward Kawas wrote: >> > > Sorry, I don't think that I asked my question properly! >> > > >> > > Basically, I wanted to check whether jmoby.jar, created >> > > with java 1.5, will break Taverna. Have you already made >> > > the switch to 1.5? My thoughts are that you haven't, but >> > > I may be wrong. We are aware that jMoby will switch to java 1.5, and it is one of our arguments against ourself on why we should switch to java 1.5 as a whole. http://twiki.mygrid.org.uk/twiki/bin/view/Mygrid/JavaFiveOMII Will the old jmoby.jar stop working? When? We have a large installed user base of Taverna probably running with Java 1.4. >From this you can conclude that, yes, it's OK for Taverna that you are moving to Java5, we want to do the same, but we are gathering momentum for doing the change. Our 2.0 development will be based on Java5. However, I do sincerely hope that the old jMoby libraries don't just stop working from June 30th, because there's a big base of installed Tavernas out there, and we might not want to bump to Java5 for the next minor release of Taverna. -- Stian Soiland School of Computer Science The University of Manchester http://www.cs.man.ac.uk/~ssoiland/ From Pieter.Neerincx at wur.nl Tue May 2 09:55:51 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 2 May 2006 11:55:51 +0200 Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/output articleNames In-Reply-To: References: Message-ID: Hi all, On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > Hi all, > > A few months ago the spec for service registration was tightened > such that > all inputs and outputs require an articleName. This is now > required also > in Taverna workflows, and as such, many "illegitimate" services > currently > in the registry will not function with Taverna even though they are > perfectly functional in reality. > > Given that these services are not looking for an articleName, it > will do > no harm to them if one were added. Thus the fastest way to bring all > service registrations back into compliance with the API would be > for me to > manipulate the MOBY Central database directly and add "dummy" > articleNames > ("input", "output") to all inputs and outputs that are currently un- > named. > > Would this bother anyone? It's fine with me. Actually I already registered most of my services to use "input" and "output" as dummy articleNames to make sure they worked in Taverna :). I was wondering the following though. Maybe this is a question for Eddie. If * articleName attributes are required for input and output articles and * every service is registered with certain articleNames for their inputs and outputs, * wouldn't it be possible to let Taverna fill in those articleName attributes automatically? Currently I have to fill them in manually all the time and that is a bit boring :(. Furthermore I already spent quite a bit of time staring at XML wondering why something didn't work ... and in the end it was a missing articleName or one with a typo. Cheers, Pi > Please let me know ASAP. > > Mark > > > > > > _______________________________________________ > moby-l mailing list > moby-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-l 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 May 2 13:16:14 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 2 May 2006 06:16:14 -0700 Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/outputarticleNames In-Reply-To: Message-ID: <000301c66dea$97a0caf0$6700a8c0@notebook> Hi Pieter, If you update your version of Taverna, you no longer have to fill in the article name as it is filled in automatically. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Pieter Neerincx > Sent: Tuesday, May 02, 2006 2:56 AM > To: mobydev > Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with > input/outputarticleNames > > Hi all, > > On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > > > Hi all, > > > > A few months ago the spec for service registration was > tightened such > > that all inputs and outputs require an articleName. This is now > > required also in Taverna workflows, and as such, many > "illegitimate" > > services currently in the registry will not function with > Taverna even > > though they are perfectly functional in reality. > > > > Given that these services are not looking for an > articleName, it will > > do no harm to them if one were added. Thus the fastest way > to bring > > all service registrations back into compliance with the API > would be > > for me to manipulate the MOBY Central database directly and add > > "dummy" > > articleNames > > ("input", "output") to all inputs and outputs that are > currently un- > > named. > > > > Would this bother anyone? > > It's fine with me. Actually I already registered most of my > services to use "input" and "output" as dummy articleNames to > make sure they worked in Taverna :). I was wondering the > following though. Maybe this is a question for Eddie. If > * articleName attributes are required for input and output > articles and > * every service is registered with certain articleNames for > their inputs and outputs, > * wouldn't it be possible to let Taverna fill in those > articleName attributes automatically? > > Currently I have to fill them in manually all the time and > that is a bit boring :(. Furthermore I already spent quite a > bit of time staring at XML wondering why something didn't > work ... and in the end it was a missing articleName or one > with a typo. > > Cheers, > > Pi > > > Please let me know ASAP. > > > > Mark > > > > > > > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-l > > > 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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue May 2 13:38:20 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 2 May 2006 13:38:20 +0000 GMT Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/outputarticleNames In-Reply-To: References: Message-ID: <1714899979-1146577161-cardhu_blackberry.rim.net-3771-@engine18-cell01> The newest version of the taverna plugins fills in the article names by itself :-) M -- Mark Wilkinson ...on the road! -----Original Message----- From: Pieter Neerincx Date: Tue, 2 May 2006 11:55:51 To:mobydev Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with input/output articleNames Hi all, On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > Hi all, > > A few months ago the spec for service registration was tightened > such that > all inputs and outputs require an articleName. This is now > required also > in Taverna workflows, and as such, many "illegitimate" services > currently > in the registry will not function with Taverna even though they are > perfectly functional in reality. > > Given that these services are not looking for an articleName, it > will do > no harm to them if one were added. Thus the fastest way to bring all > service registrations back into compliance with the API would be > for me to > manipulate the MOBY Central database directly and add "dummy" > articleNames > ("input", "output") to all inputs and outputs that are currently un- > named. > > Would this bother anyone? It's fine with me. Actually I already registered most of my services to use "input" and "output" as dummy articleNames to make sure they worked in Taverna :). I was wondering the following though. Maybe this is a question for Eddie. If * articleName attributes are required for input and output articles and * every service is registered with certain articleNames for their inputs and outputs, * wouldn't it be possible to let Taverna fill in those articleName attributes automatically? Currently I have to fill them in manually all the time and that is a bit boring :(. Furthermore I already spent quite a bit of time staring at XML wondering why something didn't work ... and in the end it was a missing articleName or one with a typo. Cheers, Pi > Please let me know ASAP. > > Mark > > > > > > _______________________________________________ > moby-l mailing list > moby-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-l 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 lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Tue May 2 14:16:51 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 02 May 2006 08:16:51 -0600 Subject: [MOBY-dev] RFC: jMoby will start using Java 1.5. from June 30, 2006 In-Reply-To: <44571937.70809@cs.man.ac.uk> References: <44571937.70809@cs.man.ac.uk> Message-ID: <445769D3.2010607@ucalgary.ca> I believe our plan was to freeze the Java 1.4 version at that date. We can certainly keep a 1.4 JAR version around, but it would not be updated with new functionality committed after June 30th... > Martin Senger wrote: > >> Eddie, how is going your Taverna 1.5.enquiries? It seems that we may make >> a tag 1.4, and start to use 1.5 when you give us a green light. Don't >> worry, however, it does not need to be *now*. >> > > > To quote myself from taverna-hackers list following Eddie's request there: > > > Edward Kawas wrote: > >>>>> Sorry, I don't think that I asked my question properly! >>>>> >>>>> Basically, I wanted to check whether jmoby.jar, created >>>>> with java 1.5, will break Taverna. Have you already made >>>>> the switch to 1.5? My thoughts are that you haven't, but >>>>> I may be wrong. >>>>> > > We are aware that jMoby will switch to java 1.5, and it is one of our > arguments against ourself on why we should switch to java 1.5 as a whole. > > http://twiki.mygrid.org.uk/twiki/bin/view/Mygrid/JavaFiveOMII > > Will the old jmoby.jar stop working? When? We have a large installed > user base of Taverna probably running with Java 1.4. > > > > > > >From this you can conclude that, yes, it's OK for Taverna that you are > moving to Java5, we want to do the same, but we are gathering momentum > for doing the change. Our 2.0 development will be based on Java5. > > However, I do sincerely hope that the old jMoby libraries don't just > stop working from June 30th, because there's a big base of installed > Tavernas out there, and we might not want to bump to Java5 for the next > minor release of Taverna. > > > From senger at ebi.ac.uk Tue May 2 16:37:14 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 2 May 2006 17:37:14 +0100 (BST) Subject: [MOBY-dev] RFC: jMoby will start using Java 1.5. from June 30, 2006 In-Reply-To: <44571937.70809@cs.man.ac.uk> Message-ID: > To quote myself from taverna-hackers list following Eddie's request there: > I am aware of your reply. But it is not clear what you mean by it. I looked into the page you refer to, and it did not tell me much. Sorry. > We are aware that jMoby will switch to java 1.5, and it is one of our > arguments against ourself on why we should switch to java 1.5 as a whole. > This is the sentence that my English is too weak to comprehend. > Will the old jmoby.jar stop working? > Old jmoby.jar will never stop working. It is working now under 1.5. fine. The problem is that we are suggesting to replace it by a *new* jmoby.jar (which will have some methods that are only available with Java 1.5). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From Pieter.Neerincx at wur.nl Tue May 2 16:51:17 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 2 May 2006 18:51:17 +0200 Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/outputarticleNames In-Reply-To: <000301c66dea$97a0caf0$6700a8c0@notebook> References: <000301c66dea$97a0caf0$6700a8c0@notebook> Message-ID: <85374531-A310-4058-B3F7-A66C9876153F@wur.nl> Hi Eddie, Super, I'll update. Thanks, Pi On 2-May-2006, at 3:16 PM, Edward Kawas wrote: > Hi Pieter, > > If you update your version of Taverna, you no longer have to fill > in the article > name as it is filled in automatically. > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org >> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of >> Pieter Neerincx >> Sent: Tuesday, May 02, 2006 2:56 AM >> To: mobydev >> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with >> input/outputarticleNames >> >> Hi all, >> >> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: >> >>> Hi all, >>> >>> A few months ago the spec for service registration was >> tightened such >>> that all inputs and outputs require an articleName. This is now >>> required also in Taverna workflows, and as such, many >> "illegitimate" >>> services currently in the registry will not function with >> Taverna even >>> though they are perfectly functional in reality. >>> >>> Given that these services are not looking for an >> articleName, it will >>> do no harm to them if one were added. Thus the fastest way >> to bring >>> all service registrations back into compliance with the API >> would be >>> for me to manipulate the MOBY Central database directly and add >>> "dummy" >>> articleNames >>> ("input", "output") to all inputs and outputs that are >> currently un- >>> named. >>> >>> Would this bother anyone? >> >> It's fine with me. Actually I already registered most of my >> services to use "input" and "output" as dummy articleNames to >> make sure they worked in Taverna :). I was wondering the >> following though. Maybe this is a question for Eddie. If >> * articleName attributes are required for input and output >> articles and >> * every service is registered with certain articleNames for >> their inputs and outputs, >> * wouldn't it be possible to let Taverna fill in those >> articleName attributes automatically? >> >> Currently I have to fill them in manually all the time and >> that is a bit boring :(. Furthermore I already spent quite a >> bit of time staring at XML wondering why something didn't >> work ... and in the end it was a missing articleName or one >> with a typo. >> >> Cheers, >> >> Pi >> >>> Please let me know ASAP. >>> >>> Mark >>> >>> >>> >>> >>> >>> _______________________________________________ >>> moby-l mailing list >>> moby-l at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-l >> >> >> 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 lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 ssoiland at cs.man.ac.uk Tue May 2 17:55:29 2006 From: ssoiland at cs.man.ac.uk (Stian Soiland) Date: Tue, 2 May 2006 18:55:29 +0100 Subject: [MOBY-dev] RFC: jMoby will start using Java 1.5. from June 30, 2006 In-Reply-To: References: Message-ID: <30BEFE62-4D84-4EE4-A650-06397645EAE4@cs.man.ac.uk> On 2. mai. 2006, at 17:37, Martin Senger wrote: > I am aware of your reply. But it is not clear what you mean by > it. I > looked into the page you refer to, and it did not tell me much. Sorry. Sorry, it is mainly for internal use, so it was not very relevant. What I tried to say was that we are also slowly switching to Java 1.5, but we are not yet requiring it. Several new features to come will require 1.5 though. >> We are aware that jMoby will switch to java 1.5, and it is one of our >> arguments against ourself on why we should switch to java 1.5 as a >> whole. > This is the sentence that my English is too weak to comprehend We are doing a "Why we need Java 1.5" information gathering (to convince the people who fund us), and that the new jMoby.jar will require 1.5 just adds to the list. As developers we all want to go for 1.5. > Old jmoby.jar will never stop working. It is working now under 1.5. > fine. The problem is that we are suggesting to replace it by a *new* > jmoby.jar (which will have some methods that are only available > with Java > 1.5). This is fine, so users who want the new methods will simply have to upgrade their Java and jmoby.jar, and possibly the plugin for Taverna. -- Stian Soiland School of Computer Science The University of Manchester http://www.cs.man.ac.uk/~ssoiland/ From edward.kawas at gmail.com Tue May 2 13:16:14 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 2 May 2006 06:16:14 -0700 Subject: [MOBY-dev] [MOBY-l] updating MOBY Central with input/outputarticleNames In-Reply-To: Message-ID: <000301c66dea$97a0caf0$6700a8c0@notebook> Hi Pieter, If you update your version of Taverna, you no longer have to fill in the article name as it is filled in automatically. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Pieter Neerincx > Sent: Tuesday, May 02, 2006 2:56 AM > To: mobydev > Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with > input/outputarticleNames > > Hi all, > > On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > > > Hi all, > > > > A few months ago the spec for service registration was > tightened such > > that all inputs and outputs require an articleName. This is now > > required also in Taverna workflows, and as such, many > "illegitimate" > > services currently in the registry will not function with > Taverna even > > though they are perfectly functional in reality. > > > > Given that these services are not looking for an > articleName, it will > > do no harm to them if one were added. Thus the fastest way > to bring > > all service registrations back into compliance with the API > would be > > for me to manipulate the MOBY Central database directly and add > > "dummy" > > articleNames > > ("input", "output") to all inputs and outputs that are > currently un- > > named. > > > > Would this bother anyone? > > It's fine with me. Actually I already registered most of my > services to use "input" and "output" as dummy articleNames to > make sure they worked in Taverna :). I was wondering the > following though. Maybe this is a question for Eddie. If > * articleName attributes are required for input and output > articles and > * every service is registered with certain articleNames for > their inputs and outputs, > * wouldn't it be possible to let Taverna fill in those > articleName attributes automatically? > > Currently I have to fill them in manually all the time and > that is a bit boring :(. Furthermore I already spent quite a > bit of time staring at XML wondering why something didn't > work ... and in the end it was a missing articleName or one > with a typo. > > Cheers, > > Pi > > > Please let me know ASAP. > > > > Mark > > > > > > > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-l > > > 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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue May 2 23:29:57 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 02 May 2006 16:29:57 -0700 Subject: [MOBY-dev] LSIDs in the ServiceInstance RDF Message-ID: <1146612597.24762.31.camel@bioinfo.icapture.ubc.ca> Hi all, Eddie and I have been going in circles in a discussion of LSIDs in the ServiceInstance RDF, so we're hoping that a wider discussion can help reveal the correct path forward. Here's the issue: 1) The agent-based service update/register/deregister system is going to use the Service Signature RDF document to extract its information 2) At the moment, this document contains an LSID identifying the service instance, of the form: urn:lsid:biomoby.org:serviceinstance: authority,servicename:Timestamp 3) If the service provider updates this RDF with teh intention of calling the agent to update their service, we would expect that the LSID should also be updated. This is because although we only resolve LSID metadata, we have agreed amongst ourselves that it is important for client programs (e.g. Dashboard) to know when the metadata has changed. As such, the LSID timestamp *must* be updated when the service registration is modified, and thus the service provider must do this. 4) We have also agreed that, by convention, the timestamp of the LSID is to take a certain format, and in fact we are allowing certain of our software to parse and interpret that format. 5) we have little control over how the service provider chooses to modify their LSID when they update their Signature RDF. They might change the timestamp format, or they might change the namespace (authURI,servicename), or other things. 6) We, as the LSID authority (biomoby.org) parse the LSID string because we are supposed to be guaranteed to understand its form... but now a third party is generating the LSID's that we are supposed to be parsing and we can no longer guarantee that we will understand it even though we are supposed to be able to resolve it! (A) One option would be to remove the LSID from the Signature RDF so that the service provider cannot change it, but we feel that it is a useful component of that document, especially if the RESOURCES script (getResourceURLs) is used as the primary way that software bulk- downloads the contents of the registry. (B) Another alternative would be for the RESOURCES script (getResourceURLs) to generate RDF that includes the LSID, but for the Signature RDF that is hosted by the service host not to include it. The documents would be otherwise identical. This is an effective solution, but "feels" wrong, since there are now two non-identical RDF descriptions of a service. Personally, I am in favour of option (B) because the service provider will be adding a lot of additional annotation to their service signature anyway, but Eddie doesn't really like that one. Does anyone else have software that would break if we pursued that option? Are there other options we haven't thought of? Is there a strong feeling one way or the other about this from anyone? M -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Wed May 3 12:04:27 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 3 May 2006 13:04:27 +0100 (BST) Subject: [MOBY-dev] LSIDs in the ServiceInstance RDF In-Reply-To: <1146612597.24762.31.camel@bioinfo.icapture.ubc.ca> Message-ID: > This is because although we only resolve LSID metadata, we have agreed > amongst ourselves that it is important for client programs (e.g. > Dashboard) to know when the metadata has changed. > Not really. Dasboard uses only what is in the Biomoby central (I do not know if you call it metadata or not, but I think they are data). You (Biomoby Central) are an LSID authority, you should change version only if you chnage things in your database. No one else has right to change it. All other data (rather metadata) added or updated by service providers can be changed - but the LSID stays - so users can call getMetadata() and get an updated versionb, but they always get the same version when they call getData() (or when they call registry - which is what Dashboard does). I do not understand where is the problem. Our situation seems to be a typical situation as described by the LSID spec: You provide a new LSID version if there is a chnage at your side (meaning: in registry), anybody else (like a service provider) updates and provides metadata. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From duncan.hull at cs.man.ac.uk Wed May 3 17:40:39 2006 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Wed, 03 May 2006 18:40:39 +0100 Subject: [MOBY-dev] Shims in BioMOBY In-Reply-To: <4452848B.2080500@ucalgary.ca> References: <4452848B.2080500@ucalgary.ca> Message-ID: <4458EB17.7070001@cs.man.ac.uk> Hi Paul Paul Gordon wrote: >This is a very general question, especially for non-native-English >speakers. I was going to add a top-level "Shim" category of services >to the ontology, but I'm pretty sure most non-native-English speakers >would have no idea what this means. I'm borrowing the term from > >D Hull, R Stevens, P Lord, C Wroe, C Goble (2004). Treating shimantic >web syndrome with ontologies. First AKT workshop on Semantic Web >Services (AKT-SWS04). > > Since I'm first author of the paper [1] you mention, here are three points on how I think shim services should be described, so that users can find them. According to me, I am the first person to use the term "shim" to describe bioinformatics services, although its been used in hypermedia research [2] to describe similar operations in software. Firstly, it is probably useful to annotate services as a shims, although this is information that the user may not always want to see. A service that maps between equivalent identifiers (GenBank to EMBL for example) in one workflow might be considered a safe or "boring" operation [3], with shim-like properties. However, the same service in a different workflow constructed by a different user, might not be a considered a shim, because the safeness of the operation depends on the GenBank identifier the service takes as input. So it is probably a useful annotation, and a useful concept in your ontology, but the user will not always care wether a given service is a shim or not. Secondly, one thing that characterises shims is the relation between the input and the output. So, for example, a service that extracts the protein sequence from a BLAST_report is a fairly boring shim, because the relation between the input and the output is hasPart eg. a BLAST_report hasPart protein_sequence. I personally think this relation between input and output is one that will help distinguish the shim from other services in the registry, and therefore aid retrieval. So capturing this relation in the registry could be useful. Finally, if you're using a description logic reasoner, an interesting solution would be to describe the properties of shim services, and let the reasoner infer which services are shims based on these properties. This would save you some of the trouble of annotating shims in your registry, and would give you a clear definition of *exactly* what you mean when you say "shim", since the word has several different meanings.... Speaking of which, a shim [4] can also mean a transexual person: "she + him = shim", according to wikipedia :) Duncan [1] http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-122/paper1.pdf [2] http://eprints.ecs.soton.ac.uk/768/02/html/ [3] http://taverna.sourceforge.net/usermanual/docs.word.html#_Toc107043031 [4] http://en.wikipedia.org/wiki/Shim -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From gordonp at ucalgary.ca Wed May 3 20:42:50 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 03 May 2006 14:42:50 -0600 Subject: [MOBY-dev] Shims in BioMOBY In-Reply-To: <4458EB17.7070001@cs.man.ac.uk> References: <4452848B.2080500@ucalgary.ca> <4458EB17.7070001@cs.man.ac.uk> Message-ID: <445915CA.3010104@ucalgary.ca> Sorry, I guess I want to usurp your word then :-) I'd only put in my Shims category the very boring operations on *Object types*, such as DNASequence to FASTA_NA object conversion, or a multiple sequence alignment to a collection of sequences, etc., which are 1. purely syntactic 2. complete (all fields of the target object are meaningfully completed by the source object) 3. applicable for 100% of the possible source objects That way I can present FastA service options to a user with a DNASequence, since the user *already has exactly this information*. These problems exist only because developers didn't agree on using the same ontology object, not because of a fundamental different in the data. There should be no conscious decision necessary here, unlike decomposition and crossreferencing tasks. While you may call these Shims too, I think of these more as Adaptors. I guess this is why I made my original post :-) How about a service type ontology like : Conversion Shims Object types: e.g. DNASequence_to_FASTA, genbank_to_DNASequence Then my program would automatically consider services of type Conversion -> Shims -> Object type and I don't restrict your word :-) > Hi Paul > > Paul Gordon wrote: > >> This is a very general question, especially for non-native-English >> speakers. I was going to add a top-level "Shim" category of >> services to the ontology, but I'm pretty sure most >> non-native-English speakers would have no idea what this means. I'm >> borrowing the term from >> >> D Hull, R Stevens, P Lord, C Wroe, C Goble (2004). Treating shimantic >> web syndrome with ontologies. First AKT workshop on Semantic Web >> Services (AKT-SWS04). >> >> > Since I'm first author of the paper [1] you mention, here are three > points on how I think shim services should be described, so that users > can find them. According to me, I am the first person to use the term > "shim" to describe bioinformatics services, although its been used in > hypermedia research [2] to describe similar operations in software. > > Firstly, it is probably useful to annotate services as a shims, > although this is information that the user may not always want to > see. A service that maps between equivalent identifiers (GenBank to > EMBL for example) in one workflow might be considered a safe or > "boring" operation [3], with shim-like properties. However, the same > service in a different workflow constructed by a different user, might > not be a considered a shim, because the safeness of the operation > depends on the GenBank identifier the service takes as input. So it is > probably a useful annotation, and a useful concept in your ontology, > but the user will not always care wether a given service is a shim or > not. > > Secondly, one thing that characterises shims is the relation between > the input and the output. So, for example, a service that extracts the > protein sequence from a BLAST_report is a fairly boring shim, because > the relation between the input and the output is hasPart eg. a > BLAST_report hasPart protein_sequence. I personally think this > relation between input and output is one that will help distinguish > the shim from other services in the registry, and therefore aid > retrieval. So capturing this relation in the registry could be useful. > > Finally, if you're using a description logic reasoner, an interesting > solution would be to describe the properties of shim services, and let > the reasoner infer which services are shims based on these properties. > This would save you some of the trouble of annotating shims in your > registry, and would give you a clear definition of *exactly* what you > mean when you say "shim", since the word has several different > meanings.... > > Speaking of which, a shim [4] can also mean a transexual person: "she > + him = shim", according to wikipedia :) > > Duncan > > [1] > http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-122/paper1.pdf > > [2] http://eprints.ecs.soton.ac.uk/768/02/html/ [3] > http://taverna.sourceforge.net/usermanual/docs.word.html#_Toc107043031 > [4] http://en.wikipedia.org/wiki/Shim > From markw at illuminae.com Thu May 4 20:36:25 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 04 May 2006 13:36:25 -0700 Subject: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' In-Reply-To: <001101c66fb4$3156db10$6500a8c0@notebook> References: <001101c66fb4$3156db10$6500a8c0@notebook> Message-ID: <1146774985.17174.192.camel@bioinfo.icapture.ubc.ca> Code in the CVS updated. MOBY Central updated and restarted. All tests pass. We should be able to register Boolean secondaries now. Please check Eddie's documentation for instructions, or just use Dashboard :-) Thanks for the fast turnaround on this Eddie! M -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From edward.kawas at gmail.com Thu May 4 21:15:07 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 4 May 2006 14:15:07 -0700 Subject: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' In-Reply-To: <1146774985.17174.192.camel@bioinfo.icapture.ubc.ca> Message-ID: <000401c66fbf$d2d09700$6500a8c0@notebook> For those hosting your own registries, make sure to add the enum field 'Boolean' in the table secondary_input in the db mobycentral. I did this with the following sql statement: ALTER TABLE secondary_input CHANGE COLUMN datatype datatype ENUM('String','Integer','DateTime','Float','Boolean') DEFAULT NULL; Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Mark Wilkinson > Sent: Thursday, May 04, 2006 1:36 PM > To: Ed Kawas > Cc: mobydev > Subject: Re: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' > > Code in the CVS updated. MOBY Central updated and restarted. > All tests pass. > > We should be able to register Boolean secondaries now. > Please check Eddie's documentation for instructions, or just > use Dashboard :-) > > Thanks for the fast turnaround on this Eddie! > > M > > > -- > > -- > 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 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Thu May 4 21:15:07 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 4 May 2006 14:15:07 -0700 Subject: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' In-Reply-To: <1146774985.17174.192.camel@bioinfo.icapture.ubc.ca> Message-ID: <000401c66fbf$d2d09700$6500a8c0@notebook> For those hosting your own registries, make sure to add the enum field 'Boolean' in the table secondary_input in the db mobycentral. I did this with the following sql statement: ALTER TABLE secondary_input CHANGE COLUMN datatype datatype ENUM('String','Integer','DateTime','Float','Boolean') DEFAULT NULL; Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Mark Wilkinson > Sent: Thursday, May 04, 2006 1:36 PM > To: Ed Kawas > Cc: mobydev > Subject: Re: [MOBY-dev] [moby] RE: Secondary datatype 'boolean' > > Code in the CVS updated. MOBY Central updated and restarted. > All tests pass. > > We should be able to register Boolean secondaries now. > Please check Eddie's documentation for instructions, or just > use Dashboard :-) > > Thanks for the fast turnaround on this Eddie! > > M > > > -- > > -- > 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 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Mon May 15 12:17:36 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 15 May 2006 14:17:36 +0200 Subject: [MOBY-dev] Error handling in Taverna (was Re: [MOBY-l] updating MOBY Central with input/outputarticleNames) In-Reply-To: <85374531-A310-4058-B3F7-A66C9876153F@wur.nl> References: <000301c66dea$97a0caf0$6700a8c0@notebook> <85374531-A310-4058-B3F7-A66C9876153F@wur.nl> Message-ID: <7690B374-E7BA-4F56-9DDB-4D64F4466A60@wur.nl> Hi Eddie, I tried the latest Taverna version today and I really enjoyed it :). Automatic addition of articleNames works perfectly and the new "Parse moby data" processor makes decomposing BioMOBY objects a breeze. I also browsed the online documentation again and noticed that the "output" and "input" ports are depreciated and only meant to be used for backwards compatibility. I used them to get the full output from BioMOBY services. This allowed me to have a look at the serviceNotes section in addition to the mobyData section. In Taverna 1.3.2RC1 (with updated *.jar from the BioMOBY site) this behaviour has changed and the legacy input and output ports only return the mobyData block. I realise now that I've been abusing those legacy ports for something they were never made for, but it was the only way to have a peek at diagnostic error massages from the serviceNotes. (Or is there another way?) I'd love to see that kind of functionality return one day... Thanks, Pi On 2-May-2006, at 6:51 PM, Pieter Neerincx wrote: > Hi Eddie, > > Super, I'll update. > > Thanks, > > Pi > > On 2-May-2006, at 3:16 PM, Edward Kawas wrote: > >> Hi Pieter, >> >> If you update your version of Taverna, you no longer have to fill >> in the article >> name as it is filled in automatically. >> >> Eddie >> >> >>> -----Original Message----- >>> From: moby-dev-bounces at lists.open-bio.org >>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of >>> Pieter Neerincx >>> Sent: Tuesday, May 02, 2006 2:56 AM >>> To: mobydev >>> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with >>> input/outputarticleNames >>> >>> Hi all, >>> >>> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: >>> >>>> Hi all, >>>> >>>> A few months ago the spec for service registration was >>> tightened such >>>> that all inputs and outputs require an articleName. This is now >>>> required also in Taverna workflows, and as such, many >>> "illegitimate" >>>> services currently in the registry will not function with >>> Taverna even >>>> though they are perfectly functional in reality. >>>> >>>> Given that these services are not looking for an >>> articleName, it will >>>> do no harm to them if one were added. Thus the fastest way >>> to bring >>>> all service registrations back into compliance with the API >>> would be >>>> for me to manipulate the MOBY Central database directly and add >>>> "dummy" >>>> articleNames >>>> ("input", "output") to all inputs and outputs that are >>> currently un- >>>> named. >>>> >>>> Would this bother anyone? >>> >>> It's fine with me. Actually I already registered most of my >>> services to use "input" and "output" as dummy articleNames to >>> make sure they worked in Taverna :). I was wondering the >>> following though. Maybe this is a question for Eddie. If >>> * articleName attributes are required for input and output >>> articles and >>> * every service is registered with certain articleNames for >>> their inputs and outputs, >>> * wouldn't it be possible to let Taverna fill in those >>> articleName attributes automatically? >>> >>> Currently I have to fill them in manually all the time and >>> that is a bit boring :(. Furthermore I already spent quite a >>> bit of time staring at XML wondering why something didn't >>> work ... and in the end it was a missing articleName or one >>> with a typo. >>> >>> Cheers, >>> >>> Pi >>> >>>> Please let me know ASAP. >>>> >>>> Mark >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> moby-l mailing list >>>> moby-l at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/moby-l >>> >>> >>> 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 lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.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 lists.open-bio.org > http://lists.open-bio.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 May 15 13:28:54 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 15 May 2006 06:28:54 -0700 Subject: [MOBY-dev] Error handling in Taverna (was Re: [MOBY-l] updatingMOBY Central with input/outputarticleNames) In-Reply-To: <7690B374-E7BA-4F56-9DDB-4D64F4466A60@wur.nl> Message-ID: <000301c67823$85db2d40$6700a8c0@notebook> Hi Pieter, Putting the service notes into the the other ports is actually on my todo list. My current objectives were to create the parser processor and support secondarys. These tasks are done, but I am still testing the parser. I am glad that you liked the parser (which must have been hard to find, considering it isnt documented yet). Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Pieter Neerincx > Sent: Monday, May 15, 2006 5:18 AM > To: Core developer announcements > Subject: [MOBY-dev] Error handling in Taverna (was Re: > [MOBY-l] updatingMOBY Central with input/outputarticleNames) > > Hi Eddie, > > I tried the latest Taverna version today and I really enjoyed it :). > Automatic addition of articleNames works perfectly and the > new "Parse moby data" processor makes decomposing BioMOBY > objects a breeze. > > I also browsed the online documentation again and noticed > that the "output" and "input" ports are depreciated and only > meant to be used for backwards compatibility. I used them to > get the full output from BioMOBY services. This allowed me to > have a look at the serviceNotes section in addition to the > mobyData section. In Taverna 1.3.2RC1 (with updated *.jar > from the BioMOBY site) this behaviour has changed and the > legacy input and output ports only return the mobyData block. > I realise now that I've been abusing those legacy ports for > something they were never made for, but it was the only way > to have a peek at diagnostic error massages from the > serviceNotes. (Or is there another > way?) I'd love to see that kind of functionality return one day... > > Thanks, > > Pi > > > On 2-May-2006, at 6:51 PM, Pieter Neerincx wrote: > > > Hi Eddie, > > > > Super, I'll update. > > > > Thanks, > > > > Pi > > > > On 2-May-2006, at 3:16 PM, Edward Kawas wrote: > > > >> Hi Pieter, > >> > >> If you update your version of Taverna, you no longer have > to fill in > >> the article name as it is filled in automatically. > >> > >> Eddie > >> > >> > >>> -----Original Message----- > >>> From: moby-dev-bounces at lists.open-bio.org > >>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Pieter > >>> Neerincx > >>> Sent: Tuesday, May 02, 2006 2:56 AM > >>> To: mobydev > >>> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with > >>> input/outputarticleNames > >>> > >>> Hi all, > >>> > >>> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > >>> > >>>> Hi all, > >>>> > >>>> A few months ago the spec for service registration was > >>> tightened such > >>>> that all inputs and outputs require an articleName. This is now > >>>> required also in Taverna workflows, and as such, many > >>> "illegitimate" > >>>> services currently in the registry will not function with > >>> Taverna even > >>>> though they are perfectly functional in reality. > >>>> > >>>> Given that these services are not looking for an > >>> articleName, it will > >>>> do no harm to them if one were added. Thus the fastest way > >>> to bring > >>>> all service registrations back into compliance with the API > >>> would be > >>>> for me to manipulate the MOBY Central database directly and add > >>>> "dummy" > >>>> articleNames > >>>> ("input", "output") to all inputs and outputs that are > >>> currently un- > >>>> named. > >>>> > >>>> Would this bother anyone? > >>> > >>> It's fine with me. Actually I already registered most of > my services > >>> to use "input" and "output" as dummy articleNames to make > sure they > >>> worked in Taverna :). I was wondering the following though. Maybe > >>> this is a question for Eddie. If > >>> * articleName attributes are required for input and > output articles > >>> and > >>> * every service is registered with certain articleNames for their > >>> inputs and outputs, > >>> * wouldn't it be possible to let Taverna fill in those > articleName > >>> attributes automatically? > >>> > >>> Currently I have to fill them in manually all the time > and that is a > >>> bit boring :(. Furthermore I already spent quite a bit of time > >>> staring at XML wondering why something didn't work ... and in the > >>> end it was a missing articleName or one with a typo. > >>> > >>> Cheers, > >>> > >>> Pi > >>> > >>>> Please let me know ASAP. > >>>> > >>>> Mark > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> moby-l mailing list > >>>> moby-l at lists.open-bio.org > >>>> http://lists.open-bio.org/mailman/listinfo/moby-l > >>> > >>> > >>> 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 lists.open-bio.org > >>> http://lists.open-bio.org/mailman/listinfo/moby-dev > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at lists.open-bio.org > >> http://lists.open-bio.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 lists.open-bio.org > > http://lists.open-bio.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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From spies at ipk-gatersleben.de Thu May 18 12:41:23 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 18 May 2006 14:41:23 +0200 Subject: [MOBY-dev] Summary of recently changes in BioMoby Message-ID: <446C6B73.4010509@ipk-gatersleben.de> Hello, it seems to be that BioMoby changed a lot in the last few months. Will there be an "update paper" or something like that in the future? For me as a newbie this would be interessting. Karl From akerhornou at imim.es Thu May 18 14:40:39 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Thu, 18 May 2006 16:40:39 +0200 Subject: [MOBY-dev] mobycentral too many connections error! Message-ID: <446C8767.5070902@imim.es> Hi, i get these errors when i try to connect to mobycentral to retrieve information about a service, " DBI connect('mobyobject:localhost:3306','moby_internal',...) failed: Too many connections at /usr/lib/perl5/site_perl/5.8.5/MOBY/OntologyServer.pm line 160 ERROR ERROR ERROR " or this one : " DBI connect('mobycentral:localhost:3306','moby_internal',...) failed: Too many connections at /usr/lib/perl5/site_perl/5.8.5/MOBY/Adaptor/moby/queryapi/mysql.pm line 90 ERROR ERROR ERROR " Any idea ? cheers Arnaud From markw at illuminae.com Thu May 18 15:01:51 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 18 May 2006 08:01:51 -0700 Subject: [MOBY-dev] [moby] mobycentral too many connections error! In-Reply-To: <446C8767.5070902@imim.es> References: <446C8767.5070902@imim.es> Message-ID: <1147964511.6562.20.camel@bioinfo.icapture.ubc.ca> I just restarted apache - that seems to have solved the problem M On Thu, 2006-05-18 at 16:40 +0200, Arnaud Kerhornou wrote: > Hi, > > i get these errors when i try to connect to mobycentral to retrieve > information about a service, > > " > DBI connect('mobyobject:localhost:3306','moby_internal',...) failed: Too > many connections at > /usr/lib/perl5/site_perl/5.8.5/MOBY/OntologyServer.pm line 160 > ERROR ERROR ERROR > " > or this one : > " > DBI connect('mobycentral:localhost:3306','moby_internal',...) failed: > Too many connections at > /usr/lib/perl5/site_perl/5.8.5/MOBY/Adaptor/moby/queryapi/mysql.pm line 90 > ERROR ERROR ERROR > " > > Any idea ? > cheers > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu May 18 14:47:58 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 18 May 2006 07:47:58 -0700 Subject: [MOBY-dev] [moby] Summary of recently changes in BioMoby In-Reply-To: <446C6B73.4010509@ipk-gatersleben.de> References: <446C6B73.4010509@ipk-gatersleben.de> Message-ID: <1147963678.6562.18.camel@bioinfo.icapture.ubc.ca> I'm writing a paper right now, and then there will be "the big one" (with all contributors as authors) that we will start writing later this summer - I'd like to get the final word on asynchrony before starting to write that one so... a few months from now, yes. In the meantime, any questions can be sent to the list :-) M On Thu, 2006-05-18 at 14:41 +0200, Karl Spies wrote: > Hello, > > it seems to be that BioMoby changed a lot in the last few months. Will > there be an "update paper" or something like that in the future? > > For me as a newbie this would be interessting. > > Karl > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu May 18 15:01:51 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 18 May 2006 08:01:51 -0700 Subject: [MOBY-dev] [moby] mobycentral too many connections error! In-Reply-To: <446C8767.5070902@imim.es> References: <446C8767.5070902@imim.es> Message-ID: <1147964511.6562.20.camel@bioinfo.icapture.ubc.ca> I just restarted apache - that seems to have solved the problem M On Thu, 2006-05-18 at 16:40 +0200, Arnaud Kerhornou wrote: > Hi, > > i get these errors when i try to connect to mobycentral to retrieve > information about a service, > > " > DBI connect('mobyobject:localhost:3306','moby_internal',...) failed: Too > many connections at > /usr/lib/perl5/site_perl/5.8.5/MOBY/OntologyServer.pm line 160 > ERROR ERROR ERROR > " > or this one : > " > DBI connect('mobycentral:localhost:3306','moby_internal',...) failed: > Too many connections at > /usr/lib/perl5/site_perl/5.8.5/MOBY/Adaptor/moby/queryapi/mysql.pm line 90 > ERROR ERROR ERROR > " > > Any idea ? > cheers > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- 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 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Thu May 18 17:56:39 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 18 May 2006 19:56:39 +0200 Subject: [MOBY-dev] Error handling in Taverna (was Re: [MOBY-l] updatingMOBY Central with input/outputarticleNames) In-Reply-To: <001a01c6788c$22add510$6700a8c0@notebook> References: <001a01c6788c$22add510$6700a8c0@notebook> Message-ID: Hi Eddie, Wow, this is great! Especially the secondary parameter support rocks. Previously I used Taverna for simple tests and for creating nice flowcharts of my workflows, but for the real work I used custom Perl clients. Now that secondaries are supported as well, I guess those custom Perl clients will start catching dust... I tried a lot and so far I can not find bugs for the handling of Secondaries, serviceNotes and the "Parse moby data - updated (2006)" Local Java widget :). Just a few comments, see further down. The "other" BioMOBY Object parser that is available form the "Moby Service Details" contextual menu doesn't work very well though. I tried to dissect an object with two childs twice. In one case the processor is correctly added to the workflow. Hence the output from the corresponding BioMOBY service goes into this BioMOBY parser processor, but there is only one additional output port (for one of the child objects). For the other child object there's no output port. I ran the workflow this way and I do get the correct output for the cild for which there was an output port. In the second case the parser processor was not connected to the output of the service and there were no output ports for the two child objects. If I decompose objects without children the parser works perfectly, but in that case one might just as well use the Local Java widget. I guess I cheered a bit prematurely for this one and it is a bit more work in progress, but it looks very promising. On 16-May-2006, at 3:57 AM, Edward Kawas wrote: > Hi Pieter, > > I uploaded a new build of Taverna that hopefully addresses the > servicenote > absences. > > Please try it and let me know how it goes. All ports should have > servicenotes if > the service provides them. Works as advertised :). The services I use only provide "human readable" stuff in the notes section of the serviceNotes. If a service has multiple outputs then the same human readable notes are shown multiple times. That is a bit redundant. Unless the BioMOBY plugin handles the latest error handling specs and shows errors specifically for a certain output, maybe it would be better the have an additional output port for the serviceNotes instead. But for now I'm just very happy to see those notes. > The build is available at > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-workbench-1.3.2- > RC1.zip (For those who want to tried this on Linux / Unix machines: make sure to "dos2unix" some of the flat text files in that build.) > As for secondarys, if you context click services that are > configurable from the > 'advanced workflow ...' and choose 'Configure Moby Service' you > will be able to > use secodaries. Works! And even the enumeration lists and default values are supported. There is one thing missing though: I couldn't fetch descriptions for the secondaries. For the secondaries of my own services I know what they are doing, but for a remote service I wouldn't have a clue on how to use them. One final comment about the name for the contextual menus. Now there is: * Moby Service Details: for info about the required input or output Simples and Collections. * Configure Moby Service: for the optional Secondaries. The names of the contextual menus are rather non-descriptive. Why would Secondaries not be part of Moby Service Details? From the contextual menu names I can not figure out that one of them is for required stuff and the other for optional parameters. So it could be a bit more user friendly, but the bottom line is that I have been playing with Taverna for 1,5 day now like a little kid that just got an invaluable Christmas present. (Imagine what happens here when the object decomposition parser works as well :)). > I was pleasantly surprised that you had found this build of Taverna > on the web. > I had originally put it there for mark to download and try out > before I > committed my changes to the cvs. I did think of asking you to try > it, but I > didn't want to bother you. I wouldn't mind of you'd bother me a bit more often with cool tools like this! Thanks, Pi > Thanks, > > Eddie > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org >> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of >> Pieter Neerincx >> Sent: Monday, May 15, 2006 5:18 AM >> To: Core developer announcements >> Subject: [MOBY-dev] Error handling in Taverna (was Re: >> [MOBY-l] updatingMOBY Central with input/outputarticleNames) >> >> Hi Eddie, >> >> I tried the latest Taverna version today and I really enjoyed it :). >> Automatic addition of articleNames works perfectly and the >> new "Parse moby data" processor makes decomposing BioMOBY >> objects a breeze. >> >> I also browsed the online documentation again and noticed >> that the "output" and "input" ports are depreciated and only >> meant to be used for backwards compatibility. I used them to >> get the full output from BioMOBY services. This allowed me to >> have a look at the serviceNotes section in addition to the >> mobyData section. In Taverna 1.3.2RC1 (with updated *.jar >> from the BioMOBY site) this behaviour has changed and the >> legacy input and output ports only return the mobyData block. >> I realise now that I've been abusing those legacy ports for >> something they were never made for, but it was the only way >> to have a peek at diagnostic error massages from the >> serviceNotes. (Or is there another >> way?) I'd love to see that kind of functionality return one day... >> >> Thanks, >> >> Pi >> >> >> On 2-May-2006, at 6:51 PM, Pieter Neerincx wrote: >> >>> Hi Eddie, >>> >>> Super, I'll update. >>> >>> Thanks, >>> >>> Pi >>> >>> On 2-May-2006, at 3:16 PM, Edward Kawas wrote: >>> >>>> Hi Pieter, >>>> >>>> If you update your version of Taverna, you no longer have >> to fill in >>>> the article name as it is filled in automatically. >>>> >>>> Eddie >>>> >>>> >>>>> -----Original Message----- >>>>> From: moby-dev-bounces at lists.open-bio.org >>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Pieter >>>>> Neerincx >>>>> Sent: Tuesday, May 02, 2006 2:56 AM >>>>> To: mobydev >>>>> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with >>>>> input/outputarticleNames >>>>> >>>>> Hi all, >>>>> >>>>> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> A few months ago the spec for service registration was >>>>> tightened such >>>>>> that all inputs and outputs require an articleName. This is now >>>>>> required also in Taverna workflows, and as such, many >>>>> "illegitimate" >>>>>> services currently in the registry will not function with >>>>> Taverna even >>>>>> though they are perfectly functional in reality. >>>>>> >>>>>> Given that these services are not looking for an >>>>> articleName, it will >>>>>> do no harm to them if one were added. Thus the fastest way >>>>> to bring >>>>>> all service registrations back into compliance with the API >>>>> would be >>>>>> for me to manipulate the MOBY Central database directly and add >>>>>> "dummy" >>>>>> articleNames >>>>>> ("input", "output") to all inputs and outputs that are >>>>> currently un- >>>>>> named. >>>>>> >>>>>> Would this bother anyone? >>>>> >>>>> It's fine with me. Actually I already registered most of >> my services >>>>> to use "input" and "output" as dummy articleNames to make >> sure they >>>>> worked in Taverna :). I was wondering the following though. Maybe >>>>> this is a question for Eddie. If >>>>> * articleName attributes are required for input and >> output articles >>>>> and >>>>> * every service is registered with certain articleNames for their >>>>> inputs and outputs, >>>>> * wouldn't it be possible to let Taverna fill in those >> articleName >>>>> attributes automatically? >>>>> >>>>> Currently I have to fill them in manually all the time >> and that is a >>>>> bit boring :(. Furthermore I already spent quite a bit of time >>>>> staring at XML wondering why something didn't work ... and in the >>>>> end it was a missing articleName or one with a typo. >>>>> >>>>> Cheers, >>>>> >>>>> Pi >>>>> >>>>>> Please let me know ASAP. >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> moby-l mailing list >>>>>> moby-l at lists.open-bio.org >>>>>> http://lists.open-bio.org/mailman/listinfo/moby-l >>>>> >>>>> >>>>> 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 lists.open-bio.org >>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at lists.open-bio.org >>>> http://lists.open-bio.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 lists.open-bio.org >>> http://lists.open-bio.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 lists.open-bio.org >> http://lists.open-bio.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 May 19 13:38:57 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 19 May 2006 06:38:57 -0700 Subject: [MOBY-dev] Error handling in Taverna (was Re: [MOBY-l]updatingMOBY Central with input/outputarticleNames) In-Reply-To: Message-ID: <000301c67b49$95017e90$6700a8c0@notebook> Hi Pieter, I was wondering if you could send me a workflow where the parser doesn't work. I am glad that you like the rest of the updates! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Pieter Neerincx > Sent: Thursday, May 18, 2006 10:57 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Error handling in Taverna (was Re: > [MOBY-l]updatingMOBY Central with input/outputarticleNames) > > Hi Eddie, > > Wow, this is great! Especially the secondary parameter > support rocks. > Previously I used Taverna for simple tests and for creating > nice flowcharts of my workflows, but for the real work I used > custom Perl clients. Now that secondaries are supported as > well, I guess those custom Perl clients will start catching dust... > > I tried a lot and so far I can not find bugs for the handling > of Secondaries, serviceNotes and the "Parse moby data - > updated (2006)" > Local Java widget :). Just a few comments, see further down. > > The "other" BioMOBY Object parser that is available form the > "Moby Service Details" contextual menu doesn't work very well > though. I tried to dissect an object with two childs twice. > In one case the processor is correctly added to the workflow. > Hence the output from the corresponding BioMOBY service goes > into this BioMOBY parser processor, but there is only one > additional output port (for one of the child objects). For > the other child object there's no output port. I ran the > workflow this way and I do get the correct output for the > cild for which there was an output port. In the second case > the parser processor was not connected to the output of the > service and there were no output ports for the two child > objects. If I decompose objects without children the parser > works perfectly, but in that case one might just as well use > the Local Java widget. I guess I cheered a bit prematurely > for this one and it is a bit more work in progress, but it > looks very promising. > > On 16-May-2006, at 3:57 AM, Edward Kawas wrote: > > > Hi Pieter, > > > > I uploaded a new build of Taverna that hopefully addresses the > > servicenote absences. > > > > Please try it and let me know how it goes. All ports should have > > servicenotes if the service provides them. > > Works as advertised :). The services I use only provide > "human readable" stuff in the notes section of the > serviceNotes. If a service has multiple outputs then the same > human readable notes are shown multiple times. That is a bit > redundant. Unless the BioMOBY plugin handles the latest error > handling specs and shows errors specifically for a certain > output, maybe it would be better the have an additional > output port for the serviceNotes instead. But for now I'm > just very happy to see those notes. > > > The build is available at > > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-workbench-1.3.2- > > RC1.zip > > (For those who want to tried this on Linux / Unix machines: > make sure to "dos2unix" some of the flat text files in that build.) > > > As for secondarys, if you context click services that are > configurable > > from the 'advanced workflow ...' and choose 'Configure Moby > Service' > > you will be able to use secodaries. > > Works! And even the enumeration lists and default values are > supported. There is one thing missing though: I couldn't > fetch descriptions for the secondaries. For the secondaries > of my own services I know what they are doing, but for a > remote service I wouldn't have a clue on how to use them. One > final comment about the name for the contextual menus. Now there is: > * Moby Service Details: for info about the required input or > output Simples and Collections. > * Configure Moby Service: for the optional Secondaries. > The names of the contextual menus are rather non-descriptive. > Why would Secondaries not be part of Moby Service Details? > From the contextual menu names I can not figure out that one > of them is for required stuff and the other for optional parameters. > > So it could be a bit more user friendly, but the bottom line > is that I have been playing with Taverna for 1,5 day now like > a little kid that just got an invaluable Christmas present. > (Imagine what happens here when the object decomposition > parser works as well :)). > > > I was pleasantly surprised that you had found this build of > Taverna on > > the web. > > I had originally put it there for mark to download and try > out before > > I committed my changes to the cvs. I did think of asking you to try > > it, but I didn't want to bother you. > > I wouldn't mind of you'd bother me a bit more often with cool > tools like this! > > Thanks, > > Pi > > > Thanks, > > > > Eddie > > > >> -----Original Message----- > >> From: moby-dev-bounces at lists.open-bio.org > >> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Pieter > >> Neerincx > >> Sent: Monday, May 15, 2006 5:18 AM > >> To: Core developer announcements > >> Subject: [MOBY-dev] Error handling in Taverna (was Re: > >> [MOBY-l] updatingMOBY Central with input/outputarticleNames) > >> > >> Hi Eddie, > >> > >> I tried the latest Taverna version today and I really > enjoyed it :). > >> Automatic addition of articleNames works perfectly and the > new "Parse > >> moby data" processor makes decomposing BioMOBY objects a breeze. > >> > >> I also browsed the online documentation again and noticed that the > >> "output" and "input" ports are depreciated and only meant > to be used > >> for backwards compatibility. I used them to get the full > output from > >> BioMOBY services. This allowed me to have a look at the > serviceNotes > >> section in addition to the mobyData section. In Taverna 1.3.2RC1 > >> (with updated *.jar from the BioMOBY site) this behaviour > has changed > >> and the legacy input and output ports only return the > mobyData block. > >> I realise now that I've been abusing those legacy ports > for something > >> they were never made for, but it was the only way to have > a peek at > >> diagnostic error massages from the serviceNotes. (Or is > there another > >> way?) I'd love to see that kind of functionality return one day... > >> > >> Thanks, > >> > >> Pi > >> > >> > >> On 2-May-2006, at 6:51 PM, Pieter Neerincx wrote: > >> > >>> Hi Eddie, > >>> > >>> Super, I'll update. > >>> > >>> Thanks, > >>> > >>> Pi > >>> > >>> On 2-May-2006, at 3:16 PM, Edward Kawas wrote: > >>> > >>>> Hi Pieter, > >>>> > >>>> If you update your version of Taverna, you no longer have > >> to fill in > >>>> the article name as it is filled in automatically. > >>>> > >>>> Eddie > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: moby-dev-bounces at lists.open-bio.org > >>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf > Of Pieter > >>>>> Neerincx > >>>>> Sent: Tuesday, May 02, 2006 2:56 AM > >>>>> To: mobydev > >>>>> Subject: Re: [MOBY-dev] [MOBY-l] updating MOBY Central with > >>>>> input/outputarticleNames > >>>>> > >>>>> Hi all, > >>>>> > >>>>> On 25-Apr-2006, at 4:53 PM, Mark Wilkinson wrote: > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> A few months ago the spec for service registration was > >>>>> tightened such > >>>>>> that all inputs and outputs require an articleName. > This is now > >>>>>> required also in Taverna workflows, and as such, many > >>>>> "illegitimate" > >>>>>> services currently in the registry will not function with > >>>>> Taverna even > >>>>>> though they are perfectly functional in reality. > >>>>>> > >>>>>> Given that these services are not looking for an > >>>>> articleName, it will > >>>>>> do no harm to them if one were added. Thus the fastest way > >>>>> to bring > >>>>>> all service registrations back into compliance with the API > >>>>> would be > >>>>>> for me to manipulate the MOBY Central database > directly and add > >>>>>> "dummy" > >>>>>> articleNames > >>>>>> ("input", "output") to all inputs and outputs that are > >>>>> currently un- > >>>>>> named. > >>>>>> > >>>>>> Would this bother anyone? > >>>>> > >>>>> It's fine with me. Actually I already registered most of > >> my services > >>>>> to use "input" and "output" as dummy articleNames to make > >> sure they > >>>>> worked in Taverna :). I was wondering the following > though. Maybe > >>>>> this is a question for Eddie. If > >>>>> * articleName attributes are required for input and > >> output articles > >>>>> and > >>>>> * every service is registered with certain articleNames > for their > >>>>> inputs and outputs, > >>>>> * wouldn't it be possible to let Taverna fill in those > >> articleName > >>>>> attributes automatically? > >>>>> > >>>>> Currently I have to fill them in manually all the time > >> and that is a > >>>>> bit boring :(. Furthermore I already spent quite a bit of time > >>>>> staring at XML wondering why something didn't work ... > and in the > >>>>> end it was a missing articleName or one with a typo. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Pi > >>>>> > >>>>>> Please let me know ASAP. > >>>>>> > >>>>>> Mark > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> moby-l mailing list > >>>>>> moby-l at lists.open-bio.org > >>>>>> http://lists.open-bio.org/mailman/listinfo/moby-l > >>>>> > >>>>> > >>>>> 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 lists.open-bio.org > >>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev > >>>> > >>>> _______________________________________________ > >>>> MOBY-dev mailing list > >>>> MOBY-dev at lists.open-bio.org > >>>> http://lists.open-bio.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 lists.open-bio.org > >>> http://lists.open-bio.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 lists.open-bio.org > >> http://lists.open-bio.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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From darin.london at duke.edu Mon May 22 15:29:45 2006 From: darin.london at duke.edu (Darin London) Date: Mon, 22 May 2006 11:29:45 -0400 Subject: [MOBY-dev] BOSC 2006 2nd Call for Papers In-Reply-To: <4471CE49.80109@duke.edu> References: <44294B65.4050207@duke.edu> <4471CE49.80109@duke.edu> Message-ID: <4471D8E9.8090109@duke.edu> 2nd CALL FOR SPEAKERS This is the second and last official call for speakers to submit their abstracts to speak at BOSC 2006 in Fortaleza, Brasil. In order to be considered as a potential speaker, an abstract must be recieved by Monday, June 5th, 2006. We look forward to a great conference this year. Please consult The Official BOSC 2006 Website at: http://www.open-bio.org/wiki/BOSC_2006 for more details and information. In addition, a BOSC weblog has been setup to make it easier to desiminate all BOSC related announcements: http://wiki.open-bio.org/boscblog/ And if you have an ICAL compatible Calendar, there is an EventDB calendar set up with all BOSC related deadlines. http://eventful.com/groups/G0-001-000014747-0 More information about ISMB can be found at the Official ISMB 2006 Website: http://ismb2006.cbi.cnptia.embrapa.br/ Thank You, and we look forward to seeing you all, The BOSC Organizing Committee. From darin.london at duke.edu Mon May 22 14:44:25 2006 From: darin.london at duke.edu (Darin London) Date: Mon, 22 May 2006 10:44:25 -0400 Subject: [MOBY-dev] Announcing BOSC 2006 In-Reply-To: <44294B65.4050207@duke.edu> References: <44294B65.4050207@duke.edu> Message-ID: <4471CE49.80109@duke.edu> 2nd CALL FOR SPEAKERS This is the second and last official call for speakers to submit their abstracts to speak at BOSC 2006 in Fortaleza, Brasil. In order to be considered as a potential speaker, an abstract must be recieved by Monday, June 5th, 2006. We look forward to a great conference this year. Please consult The Official BOSC 2006 Website at: http://www.open-bio.org/wiki/BOSC_2006 for more details and information. In addition, a BOSC weblog has been setup to make it easier to desiminate all BOSC related announcements: http://wiki.open-bio.org/boscblog/ And if you have an ICAL compatible Calendar, there is an EventDB calendar set up with all BOSC related deadlines. http://eventful.com/groups/G0-001-000014747-0 More information about ISMB can be found at the Official ISMB 2006 Website: http://ismb2006.cbi.cnptia.embrapa.br/ Thank You, and we look forward to seeing you all, The BOSC Organizing Committee. From darin.london at duke.edu Mon May 22 16:00:55 2006 From: darin.london at duke.edu (Darin London) Date: Mon, 22 May 2006 09:00:55 -0700 Subject: [MOBY-dev] [Bioperl-announce-l] BOSC 2006 2nd Call for Papers In-Reply-To: <4471CE49.80109@duke.edu> References: <44294B65.4050207@duke.edu> <4471CE49.80109@duke.edu> Message-ID: <000301c67db8$e8391f70$6400a8c0@CodonSolutions.local> 2nd CALL FOR SPEAKERS This is the second and last official call for speakers to submit their abstracts to speak at BOSC 2006 in Fortaleza, Brasil. In order to be considered as a potential speaker, an abstract must be recieved by Monday, June 5th, 2006. We look forward to a great conference this year. Please consult The Official BOSC 2006 Website at: http://www.open-bio.org/wiki/BOSC_2006 for more details and information. In addition, a BOSC weblog has been setup to make it easier to desiminate all BOSC related announcements: http://wiki.open-bio.org/boscblog/ And if you have an ICAL compatible Calendar, there is an EventDB calendar set up with all BOSC related deadlines. http://eventful.com/groups/G0-001-000014747-0 More information about ISMB can be found at the Official ISMB 2006 Website: http://ismb2006.cbi.cnptia.embrapa.br/ Thank You, and we look forward to seeing you all, The BOSC Organizing Committee. _______________________________________________ Bioperl-announce-l mailing list Bioperl-announce-l at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/bioperl-announce-l From akerhornou at imim.es Tue May 23 08:01:35 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Tue, 23 May 2006 10:01:35 +0200 Subject: [MOBY-dev] Data comrpession specs Message-ID: <4472C15F.30306@imim.es> Hi, Is there a document that describes the moby specs for data comrpession ? thanks Arnaud From markw at illuminae.com Tue May 23 14:01:25 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 23 May 2006 14:01:25 +0000 GMT Subject: [MOBY-dev] Data comrpession specs In-Reply-To: <4472C15F.30306@imim.es> References: <4472C15F.30306@imim.es> Message-ID: <152890776-1148393000-cardhu_blackberry.rim.net-176-@engine25-cell01> I'm not sure I understand your question. Can you re-word it? M -- Mark Wilkinson ...on the road! -----Original Message----- From: Arnaud Kerhornou Date: Tue, 23 May 2006 10:01:35 To:mobydev Subject: [MOBY-dev] Data comrpession specs Hi, Is there a document that describes the moby specs for data comrpession ? thanks Arnaud _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From akerhornou at imim.es Tue May 23 14:15:29 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Tue, 23 May 2006 16:15:29 +0200 Subject: [MOBY-dev] Data comrpession specs In-Reply-To: <152890776-1148393000-cardhu_blackberry.rim.net-176-@engine25-cell01> References: <4472C15F.30306@imim.es> <152890776-1148393000-cardhu_blackberry.rim.net-176-@engine25-cell01> Message-ID: <44731901.4000501@imim.es> mark wilkinson wrote: > I'm not sure I understand your question. Can you re-word it? > > I would like to submit compressed input data to a service and receive back compressed output data, does moby framework allow it ? the only thing i found was about Moses that is "Supporting automatic data compression". Is this functionality already implemented ? Thanks Arn. > M > > > -- > Mark Wilkinson > ...on the road! > > > -----Original Message----- > From: Arnaud Kerhornou > Date: Tue, 23 May 2006 10:01:35 > To:mobydev > Subject: [MOBY-dev] Data comrpession specs > > Hi, > > Is there a document that describes the moby specs for data comrpession ? > > thanks > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > From senger at ebi.ac.uk Tue May 23 14:28:07 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 23 May 2006 15:28:07 +0100 (BST) Subject: [MOBY-dev] Data comrpession specs In-Reply-To: <4472C15F.30306@imim.es> Message-ID: > Is there a document that describes the moby specs for data comrpession ? > I am not aware of any such document. My understanding is that you can still use compression on the transport protocol level. Biomoby messages between clients and services use HTTP protocol - which can support compression (I think it is called 'content encoding' in the HTTP 1.1 specification). There are also SOAP extensions about compression (I believe). But so far, there was not much efforts to really use it within biomoby (I know that jMoby part of Biomoby has this issues on its TODO list for long long time). Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Tue May 23 14:34:39 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 23 May 2006 15:34:39 +0100 (BST) Subject: [MOBY-dev] Data comrpession specs In-Reply-To: <44731901.4000501@imim.es> Message-ID: > the only thing i found was about Moses that is "Supporting automatic > data compression". Is this functionality already implemented ? > No, not yet. There was no pressure to do it :-) (But this is what I meant by "being on our TODO list".) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Tue May 23 15:58:48 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 23 May 2006 09:58:48 -0600 Subject: [MOBY-dev] Data comrpession specs In-Reply-To: References: Message-ID: <44733138.8000405@ucalgary.ca> There are generally two cases to consider: 1. Compression or responses should be handled at the Application layer (http://en.wikipedia.org/wiki/OSI_model#Layer_7:_Application_Layer) when the server knows it can safely return a compressed response (e.g. if Axis or Firefox, etc. sends an HTTP "Accept-encoding: x-gzip" header with the request). This is transparent to the MOBY protocol itself, and requires no changes to the MOBY spec. 2. The situation of *sending* compressed data (which is your problem now) is more complicated, as far as I know. Because the client is initiating the transaction, it has no a priori knowledge of whether the server will understand a compressed HTTP or SOAP or MOBY XML payload. The only way to guarantee you can safely send a compressed file is to have a standing contract with the service provider. This would require a change to the MOBY service registration, for example, with a new flag saying "I accept zlib and gzip compressed MOBY XML!". You would only be allowed to send compressed data to services whose definition includes that flag. >> the only thing i found was about Moses that is "Supporting automatic >> data compression". Is this functionality already implemented ? >> >> > No, not yet. There was no pressure to do it :-) (But this is what I > meant by "being on our TODO list".) > > Martin > > From senger at ebi.ac.uk Wed May 24 03:47:12 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 May 2006 04:47:12 +0100 (BST) Subject: [MOBY-dev] too many connections again Message-ID: Mark, could you restart the central, or whatever is needed... I cannot get to it, and we need it soon, or even now. Many thanks. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed May 24 14:02:51 2006 From: markw at illuminae.com (mark wilkinson) Date: Wed, 24 May 2006 14:02:51 +0000 GMT Subject: [MOBY-dev] too many connections again In-Reply-To: References: Message-ID: <452632608-1148479488-cardhu_blackberry.rim.net-3392-@engine20-cell01> Done I'm trying to track down what is causing this. We're doing some AJAX stuff here that seems to correspond suspiciously with the onset of the problem. ?? There is nothing obviously suspicious in the logs. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Martin Senger Date: Wed, 24 May 2006 04:47:12 To:Mark Wilkinson Cc:Moby Developers Subject: [MOBY-dev] too many connections again Mark, could you restart the central, or whatever is needed... I cannot get to it, and we need it soon, or even now. Many thanks. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Wed May 24 14:02:51 2006 From: markw at illuminae.com (mark wilkinson) Date: Wed, 24 May 2006 14:02:51 +0000 GMT Subject: [MOBY-dev] too many connections again In-Reply-To: References: Message-ID: <452632608-1148479488-cardhu_blackberry.rim.net-3392-@engine20-cell01> Done I'm trying to track down what is causing this. We're doing some AJAX stuff here that seems to correspond suspiciously with the onset of the problem. ?? There is nothing obviously suspicious in the logs. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Martin Senger Date: Wed, 24 May 2006 04:47:12 To:Mark Wilkinson Cc:Moby Developers Subject: [MOBY-dev] too many connections again Mark, could you restart the central, or whatever is needed... I cannot get to it, and we need it soon, or even now. Many thanks. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Wed May 24 14:19:03 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 May 2006 15:19:03 +0100 (BST) Subject: [MOBY-dev] too many connections again In-Reply-To: <452632608-1148479488-cardhu_blackberry.rim.net-3392-@engine20-cell01> Message-ID: > Done > Thanks. Works now. > I'm trying to track down what is causing this. We're doing some AJAX > stuff here that seems to correspond suspiciously with the onset of the > problem. > A side note: Assuming (perhaps wrongly) that your AJAX requests are directed to a Tomcat server (in other words that your requests are answered by Java code) I suggest to use a third-party connection-pool manager. There are several of them, one of the best (recommended, for example, by hibernate community) is c3p0 (available from sourceforge), another one is DBCP from Apache commons. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed May 24 19:17:27 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 May 2006 12:17:27 -0700 Subject: [MOBY-dev] Too many connections - problem discovered! Message-ID: A certain someone was browsing the MOBY Encyclopedia: OrgName: Google Inc. OrgID: GOGL Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US This is what is causing the "too many connections" problem :-) that should be easy to resolve. I'll get on it right away. M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From senger at ebi.ac.uk Wed May 24 19:26:42 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 May 2006 20:26:42 +0100 (BST) Subject: [MOBY-dev] Too many connections - problem discovered! In-Reply-To: Message-ID: > This is what is causing the "too many connections" problem :-) > that should be easy to resolve. > Why do you think it is easy to resolve? Do you mean that you simple reject google for searching us? Well, you can, perhaps it makes sense - but generally the biomoby central should be prepared for many requests in the short period of time, so leaving google here is a good test that the central reacts properly for many (almost) simultaneous requests. So I would prefer to leave the google doing what it is doing but fix the problem in Central.. What do you think? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger