From usadel at mpimp-golm.mpg.de Mon Apr 2 05:54:17 2007 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Mon, 02 Apr 2007 11:54:17 +0200 Subject: [MOBY-dev] revised manuscript now in CVS In-Reply-To: References: Message-ID: <4610D2C9.9090009@mpimp-golm.mpg.de> Hi, Nice MS, Just minor points from me. - (page 15) I In this respect, BioMoby data is more reliable and predictable #typo? drop the I -(page 4) and is designed to represent specific data identifiers from known resources an a ell-defined #typo? add w to ell-defined The XML sniplets in Figures 1,2 and 4 look jaggy, is that due to the pdf-conversion or are vector-graphics needed? (If so I guess the work could be split) Personally, I think that exception/error-handling could be a bit longer, but I am very biased there. Something along the lines: Whereas conventional web based tools, when not returning any result often leave the user wondering if this is due to a temporary server malfunction, a genuine empty result or a malformed query, BioMoby's implementation of error handling helps to discriminate, these different reasons. Further, (in the future? #I don't know how things are standing there currently) the BioMoby registry will automatically remove the visibility of services which have major problems. Cheers, Bj?rn Mark Wilkinson wrote: > Thanks to all who read and commented on the Moby 1.0 manuscript so quickly! > > I've made the first set of suggested revisions, and the new manuscript is > uploaded (version 7)to the CVS in the /Docs folder. > > Since we can't track changes using the binary PDF format, perhaps send > your suggestions/edits to the mailing list so that everyone can see them > and comment on them. > > Cheers! > > Mark > _______________________________________________ > 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 Apr 3 13:59:31 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 10:59:31 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices Message-ID: There sure are a lot of "dead" services out there... Are these really "dead" or are they just not responding to the ping properly? M From gordonp at ucalgary.ca Tue Apr 3 14:05:39 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 12:05:39 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: Message-ID: <46129773.5030503@ucalgary.ca> I say kill'em all! If they don't respond to ping, they aren't MOBY compliant (old ones on my servers included!). All it does is make MOBY look bad to new users... > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices > > > > There sure are a lot of "dead" services out there... > > Are these really "dead" or are they just not responding to the ping > properly? > > M > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,461294fe210862398211280! > > > > From duncan.hull at cs.man.ac.uk Tue Apr 3 14:10:34 2007 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Tue, 03 Apr 2007 19:10:34 +0100 Subject: [MOBY-dev] getDeadServices In-Reply-To: References: Message-ID: <4612989A.1070904@cs.man.ac.uk> Mark Mark Wilkinson wrote: > There sure are a lot of "dead" services out there... > Are these really "dead" They're not dead, they are just resting http://www.youtube.com/watch?v=2H6DSoqZz_s -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From edward.kawas at gmail.com Tue Apr 3 14:41:19 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 11:41:19 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <46129773.5030503@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> Message-ID: <003e01c7761f$ac13f000$6800a8c0@notebook> I like Duncan's explanation. Anyways, they aren't all 'invalid' services. And the reason we shouldn't dump them all is that maybe they are behind a firewall that we cant reach, etc. BTW, according to http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getStats=t rue There are 897 alive services and 231 'dead' ones, for a roughly 80% up rate. I would point out that just a year ago, the number of dead services was as high as 40%. I don't like having the dead services around, but there may be reason why we cant hit them and so we shouldn't throw the baby out with the bath water! Hopefully soon in Taverna we will be able to finally optionally filter out dead services and this wont really be an issue! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 11:06 AM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > I say kill'em all! If they don't respond to ping, they aren't MOBY > compliant (old ones on my servers included!). All it does is make MOBY > look bad to new users... > > > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadS > ervices > > > > > > > > There sure are a lot of "dead" services out there... > > > > Are these really "dead" or are they just not responding to the ping > > properly? > > > > M > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > !DSPAM:60005,461294fe210862398211280! > > > > > > > > > > _______________________________________________ > 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 Apr 3 14:18:49 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 11:18:49 -0700 Subject: [MOBY-dev] getDeadServices In-Reply-To: <4612989A.1070904@cs.man.ac.uk> References: <4612989A.1070904@cs.man.ac.uk> Message-ID: Alright then, I'll wake 'em up! HELLO POLLY! M On Tue, 03 Apr 2007 11:10:34 -0700, Duncan Hull wrote: > Mark > > Mark Wilkinson wrote: >> There sure are a lot of "dead" services out there... >> Are these really "dead" > They're not dead, they are just resting > http://www.youtube.com/watch?v=2H6DSoqZz_s > > -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Tue Apr 3 14:15:07 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 11:15:07 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <46129773.5030503@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> Message-ID: On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon wrote: > I say kill'em all! Thanks Nicolae! ;-) M From gordonp at ucalgary.ca Tue Apr 3 14:51:46 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 12:51:46 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> Message-ID: <4612A242.9040308@ucalgary.ca> I was thinking more Metallica :-) Anyway, if we don't kill'em (as Eddie suggests), can we at least include isAlive in the findService response, so client programs can know the status without retrieving all the service metadata? > On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon > wrote: > > >> I say kill'em all! >> > > Thanks Nicolae! ;-) > > M > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,46129f562108692111878! > > > > From edward.kawas at gmail.com Tue Apr 3 14:53:00 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 11:53:00 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <4612A242.9040308@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> Message-ID: <005201c77621$4d866480$6800a8c0@notebook> Hey Paul, isAlive is in the RDF already. Does that help? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 11:52 AM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > I was thinking more Metallica :-) > > Anyway, if we don't kill'em (as Eddie suggests), can we at least include > isAlive in the findService response, so client programs can know the > status without retrieving all the service metadata? > > On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon > > wrote: > > > > > >> I say kill'em all! > >> > > > > Thanks Nicolae! ;-) > > > > M > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > !DSPAM:60005,46129f562108692111878! > > > > > > > > > > _______________________________________________ > 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 Apr 3 14:57:57 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 12:57:57 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <005201c77621$4d866480$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> Message-ID: <4612A3B5.3010506@ucalgary.ca> I know it's in the metadata RDF (see my message below), but I don't want to have to download it. Why? I just disabled this in Seahawk because it took too long to fetch this (either as one big RDF dump, or individually through the LSID resolver). I was building the list of services for my popups, and it would sit there for several minutes as the registry churned, and the only thing I was using above and beyond the findService() answer was the isAlive. So now I show alive and dead services to speed things up, which is not ideal. > Hey Paul, > > isAlive is in the RDF already. Does that help? > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon >> Sent: Tuesday, April 03, 2007 11:52 AM >> To: Core developer announcements >> Subject: Re: [MOBY- >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> eadServices >> >> I was thinking more Metallica :-) >> >> Anyway, if we don't kill'em (as Eddie suggests), can we at least include >> isAlive in the findService response, so client programs can know the >> status without retrieving all the service metadata? >> >>> On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon >>> wrote: >>> >>> >>> >>>> I say kill'em all! >>>> >>>> >>> Thanks Nicolae! ;-) >>> >>> M >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,4612a16f2108651034071! > > > > From edward.kawas at gmail.com Tue Apr 3 15:00:46 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:00:46 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <4612A3B5.3010506@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> Message-ID: <005301c77622$637a6600$6800a8c0@notebook> How about: http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authority= bioinfo.icapture.ubc.ca&service=getGoTerm where you specify the authority and servicename and true or false is returned. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 11:58 AM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > I know it's in the metadata RDF (see my message below), but I don't want > to have to download it. > Why? I just disabled this in Seahawk because it took too long to fetch > this (either as one big RDF dump, or individually through the LSID > resolver). > I was building the list of services for my popups, and it would sit > there for several minutes as the registry churned, and the only thing I > was using above and beyond the findService() answer was the isAlive. So > now I show alive and dead services to speed things up, which is not ideal. > > Hey Paul, > > > > isAlive is in the RDF already. Does that help? > > > > Eddie > > > > > >> -----Original Message----- > >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon > >> Sent: Tuesday, April 03, 2007 11:52 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY- > >> > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > >> eadServices > >> > >> I was thinking more Metallica :-) > >> > >> Anyway, if we don't kill'em (as Eddie suggests), can we at least > include > >> isAlive in the findService response, so client programs can know the > >> status without retrieving all the service metadata? > >> > >>> On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon > >>> wrote: > >>> > >>> > >>> > >>>> I say kill'em all! > >>>> > >>>> > >>> Thanks Nicolae! ;-) > >>> > >>> M > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > !DSPAM:60005,4612a16f2108651034071! > > > > > > > > > > _______________________________________________ > 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 Apr 3 15:07:19 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 13:07:19 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <005301c77622$637a6600$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> Message-ID: <4612A5E7.1030301@ucalgary.ca> Hey, that nice and fast! Can we make this somehow an "official" part of the MOBY spec? > How about: > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authority= > bioinfo.icapture.ubc.ca&service=getGoTerm > > where you specify the authority and servicename and true or false is > returned. > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon >> Sent: Tuesday, April 03, 2007 11:58 AM >> To: Core developer announcements >> Subject: Re: [MOBY- >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> eadServices >> >> I know it's in the metadata RDF (see my message below), but I don't want >> to have to download it. >> Why? I just disabled this in Seahawk because it took too long to fetch >> this (either as one big RDF dump, or individually through the LSID >> resolver). >> I was building the list of services for my popups, and it would sit >> there for several minutes as the registry churned, and the only thing I >> was using above and beyond the findService() answer was the isAlive. So >> now I show alive and dead services to speed things up, which is not ideal. >> >>> Hey Paul, >>> >>> isAlive is in the RDF already. Does that help? >>> >>> Eddie >>> >>> >>> >>>> -----Original Message----- >>>> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- >>>> bounces at lists.open-bio.org] On Behalf Of Paul Gordon >>>> Sent: Tuesday, April 03, 2007 11:52 AM >>>> To: Core developer announcements >>>> Subject: Re: [MOBY- >>>> >>>> >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> >>>> eadServices >>>> >>>> I was thinking more Metallica :-) >>>> >>>> Anyway, if we don't kill'em (as Eddie suggests), can we at least >>>> >> include >> >>>> isAlive in the findService response, so client programs can know the >>>> status without retrieving all the service metadata? >>>> >>>> >>>>> On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> I say kill'em all! >>>>>> >>>>>> >>>>>> >>>>> Thanks Nicolae! ;-) >>>>> >>>>> M >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,4612a33c2108615024834! > > > > From edward.kawas at gmail.com Tue Apr 3 15:09:48 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:09:48 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <4612A5E7.1030301@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook> <4612A5E7.1030301@ucalgary.ca> Message-ID: <005a01c77623$a6acbda0$6800a8c0@notebook> Also, if you don't specify a servicename, you can retrieve a list of isAlive for all services for that particular authority. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 12:07 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > Hey, that nice and fast! Can we make this somehow an "official" part of > the MOBY spec? > > How about: > > > > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authorit > y= > > bioinfo.icapture.ubc.ca&service=getGoTerm > > > > where you specify the authority and servicename and true or false is > > returned. > > > > Eddie > > > > > >> -----Original Message----- > >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon > >> Sent: Tuesday, April 03, 2007 11:58 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY- > >> > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > >> eadServices > >> > >> I know it's in the metadata RDF (see my message below), but I don't > want > >> to have to download it. > >> Why? I just disabled this in Seahawk because it took too long to fetch > >> this (either as one big RDF dump, or individually through the LSID > >> resolver). > >> I was building the list of services for my popups, and it would sit > >> there for several minutes as the registry churned, and the only thing I > >> was using above and beyond the findService() answer was the isAlive. > So > >> now I show alive and dead services to speed things up, which is not > ideal. > >> > >>> Hey Paul, > >>> > >>> isAlive is in the RDF already. Does that help? > >>> > >>> Eddie > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > >>>> bounces at lists.open-bio.org] On Behalf Of Paul Gordon > >>>> Sent: Tuesday, April 03, 2007 11:52 AM > >>>> To: Core developer announcements > >>>> Subject: Re: [MOBY- > >>>> > >>>> > >> > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > >> > >>>> eadServices > >>>> > >>>> I was thinking more Metallica :-) > >>>> > >>>> Anyway, if we don't kill'em (as Eddie suggests), can we at least > >>>> > >> include > >> > >>>> isAlive in the findService response, so client programs can know the > >>>> status without retrieving all the service metadata? > >>>> > >>>> > >>>>> On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon > > >>>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> I say kill'em all! > >>>>>> > >>>>>> > >>>>>> > >>>>> Thanks Nicolae! ;-) > >>>>> > >>>>> M > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > !DSPAM:60005,4612a33c2108615024834! > > > > > > > > > > _______________________________________________ > 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 Apr 3 15:20:43 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 12:20:43 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <005301c77622$637a6600$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> Message-ID: On Tue, 03 Apr 2007 12:00:46 -0700, Edward Kawas wrote: > How about: > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authority= > bioinfo.icapture.ubc.ca&service=getGoTerm > > where you specify the authority and servicename and true or false is > returned. Yeah... but that isn't a part of the Moby API so we don't want to encourage people to code to it. I suspect nobody would object to me adding a tag to the output from findService that included the isAlive information? It's a shame, though... I think it says something important about the Semantic Web in general - all this metadata retrieval can potentially take a long time! Caching isn't going to help much in this case, since the status may change hour by hour (e.g. if a domain disappears briefly). Eddie, do you have a "gut feeling" for why LSID resolution for service instances is so slow? Is it the RDF generation on our end that sucks-up all the time? M From edward.kawas at gmail.com Tue Apr 3 15:23:57 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:23:57 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook> Message-ID: <006e01c77625$a0c17910$6800a8c0@notebook> ServiceInstance rdf generation shouldn't be too slow (all of the time - there is some caching). As for a per instance rdf generation, I don't know. It shouldn't be that slow (~10 secs per service). 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: Tuesday, April 03, 2007 12:21 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > On Tue, 03 Apr 2007 12:00:46 -0700, Edward Kawas > wrote: > > > How about: > > > > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authorit > y= > > bioinfo.icapture.ubc.ca&service=getGoTerm > > > > where you specify the authority and servicename and true or false is > > returned. > > > Yeah... but that isn't a part of the Moby API so we don't want to > encourage people to code to it. I suspect nobody would object to me > adding a tag to the output from findService that included the isAlive > information? > > It's a shame, though... I think it says something important about the > Semantic Web in general - all this metadata retrieval can potentially take > a long time! Caching isn't going to help much in this case, since the > status may change hour by hour (e.g. if a domain disappears briefly). > > Eddie, do you have a "gut feeling" for why LSID resolution for service > instances is so slow? Is it the RDF generation on our end that sucks-up > all the time? > > M > > > _______________________________________________ > 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 Apr 3 15:29:27 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 12:29:27 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <006e01c77625$a0c17910$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> <006e01c77625$a0c17910$6800a8c0@notebook> Message-ID: On Tue, 03 Apr 2007 12:23:57 -0700, Edward Kawas wrote: > ServiceInstance rdf generation shouldn't be too slow (all of the time - > there is some caching). As for a per instance rdf generation, I don't > know. > It shouldn't be that slow (~10 secs per service). LOL! That's pretty slow! M From edward.kawas at gmail.com Tue Apr 3 15:30:47 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:30:47 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook> Message-ID: <007701c77626$94c56df0$6800a8c0@notebook> Hey, that takes into account the whole LSID resolution protocol! 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: Tuesday, April 03, 2007 12:29 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > On Tue, 03 Apr 2007 12:23:57 -0700, Edward Kawas > wrote: > > > ServiceInstance rdf generation shouldn't be too slow (all of the time - > > there is some caching). As for a per instance rdf generation, I don't > > know. > > It shouldn't be that slow (~10 secs per service). > > > LOL! That's pretty slow! > > M > > > > _______________________________________________ > 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 Apr 3 15:34:06 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 13:34:06 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> <006e01c77625$a0c17910$6800a8c0@notebook> Message-ID: <4612AC2E.4040900@ucalgary.ca> ROTFL! When I ask "What can I do with a DNASequence?", I get lets say 150 services, that means I'm waiting 25 minutes to find out if they are pingable...adding it to findService would be a lot nicer as it's a pretty basic piece of information. If you want to be nicer for compatibility, don't report isAlive, but at least allow an incoming fidServicerequest to restrict the answers to those that are alive... > On Tue, 03 Apr 2007 12:23:57 -0700, Edward Kawas > wrote: > > >> ServiceInstance rdf generation shouldn't be too slow (all of the time - >> there is some caching). As for a per instance rdf generation, I don't >> know. >> It shouldn't be that slow (~10 secs per service). >> > > > LOL! That's pretty slow! > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,4612aa092108690393437! > > > > From markw at illuminae.com Tue Apr 3 15:34:27 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 12:34:27 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <007701c77626$94c56df0$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> <006e01c77625$a0c17910$6800a8c0@notebook> <007701c77626$94c56df0$6800a8c0@notebook> Message-ID: On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas wrote: > Hey, that takes into account the whole LSID resolution protocol! Sure, but that's what I mean! If Paul is discovering 100 services, at 10 seconds per service, his users are going to delete Seahawk from their hard-drives faster than they even get their first pop-up menu! I'm not laying blame, I'm just pointing out that we have to either make the LSID stuff run a whole lot faster (like 100X), or we have to abandon it for the time being because it really isn't helping... (and you know that I *love* LSIDs!) M From edward.kawas at gmail.com Tue Apr 3 15:39:26 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:39:26 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> Message-ID: <007901c77627$ca0de9a0$6800a8c0@notebook> Okay, adding that information into findservice wont actually speed things up, because the code will have to get that information somewhere. That somewhere is from lsid ... so the question is, what came first the chicken or the egg ;-) Seriously though, if you want to include this info, isALive will have to become part of the api and be stored in the db. Otherwise, you might save 1-4 seconds, and still wait 6 seconds per service. 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: Tuesday, April 03, 2007 12:34 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas > wrote: > > > Hey, that takes into account the whole LSID resolution protocol! > > Sure, but that's what I mean! If Paul is discovering 100 services, at 10 > seconds per service, his users are going to delete Seahawk from their > hard-drives faster than they even get their first pop-up menu! > > I'm not laying blame, I'm just pointing out that we have to either make > the LSID stuff run a whole lot faster (like 100X), or we have to abandon > it for the time being because it really isn't helping... (and you know > that I *love* LSIDs!) > > M > > _______________________________________________ > 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 Apr 3 17:30:52 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 15:30:52 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <007901c77627$ca0de9a0$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> Message-ID: <4612C78C.7090501@ucalgary.ca> But when I run http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService I get all services back in about 1 second, so you must hold that info somewhere that the registry can use it... > Okay, adding that information into findservice wont actually speed things > up, because the code will have to get that information somewhere. That > somewhere is from lsid ... so the question is, what came first the chicken > or the egg ;-) > > Seriously though, if you want to include this info, isALive will have to > become part of the api and be stored in the db. Otherwise, you might save > 1-4 seconds, and still wait 6 seconds per service. > > 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: Tuesday, April 03, 2007 12:34 PM >> To: Core developer announcements >> Subject: Re: [MOBY- >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> eadServices >> >> On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas >> wrote: >> >> >>> Hey, that takes into account the whole LSID resolution protocol! >>> >> Sure, but that's what I mean! If Paul is discovering 100 services, at 10 >> seconds per service, his users are going to delete Seahawk from their >> hard-drives faster than they even get their first pop-up menu! >> >> I'm not laying blame, I'm just pointing out that we have to either make >> the LSID stuff run a whole lot faster (like 100X), or we have to abandon >> it for the time being because it really isn't helping... (and you know >> that I *love* LSIDs!) >> >> M >> >> _______________________________________________ >> 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 > > !DSPAM:60005,4612ac4a210862854622468! > > > > From edward.kawas at gmail.com Tue Apr 3 17:32:33 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 14:32:33 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <4612C78C.7090501@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> Message-ID: <008501c77637$97a52590$6800a8c0@notebook> Currently, it's held in memory. So if the registry wanted it, it would have to call the url. But since the url isn't in the api, it might be unwise to do so. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 2:31 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > But when I run > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService > > I get all services back in about 1 second, so you must hold that info > somewhere that the registry can use it... > > > Okay, adding that information into findservice wont actually speed > things > > up, because the code will have to get that information somewhere. That > > somewhere is from lsid ... so the question is, what came first the > chicken > > or the egg ;-) > > > > Seriously though, if you want to include this info, isALive will have to > > become part of the api and be stored in the db. Otherwise, you might > save > > 1-4 seconds, and still wait 6 seconds per service. > > > > 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: Tuesday, April 03, 2007 12:34 PM > >> To: Core developer announcements > >> Subject: Re: [MOBY- > >> > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > >> eadServices > >> > >> On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas > > >> wrote: > >> > >> > >>> Hey, that takes into account the whole LSID resolution protocol! > >>> > >> Sure, but that's what I mean! If Paul is discovering 100 services, at > 10 > >> seconds per service, his users are going to delete Seahawk from their > >> hard-drives faster than they even get their first pop-up menu! > >> > >> I'm not laying blame, I'm just pointing out that we have to either make > >> the LSID stuff run a whole lot faster (like 100X), or we have to > abandon > >> it for the time being because it really isn't helping... (and you know > >> that I *love* LSIDs!) > >> > >> M > >> > >> _______________________________________________ > >> 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 > > > > !DSPAM:60005,4612ac4a210862854622468! > > > > > > > > > > _______________________________________________ > 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 Apr 3 17:37:09 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 15:37:09 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <008501c77637$97a52590$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook> Message-ID: <4612C905.4030207@ucalgary.ca> So if we want a findService request to be able to report only alive services (the simplest solution, which is backward compatible), you'd need to regularly dump validateService's table into MobyCentral's SQL DB, right? Is that hard? For the moment, I'll use ValidateService's output in jMOBY, but I think it'd be nice to have such functionality as part of the official API in the long run... > Currently, it's held in memory. > > So if the registry wanted it, it would have to call the url. But since the > url isn't in the api, it might be unwise to do so. > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon >> Sent: Tuesday, April 03, 2007 2:31 PM >> To: Core developer announcements >> Subject: Re: [MOBY- >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> eadServices >> >> But when I run >> >> http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService >> >> I get all services back in about 1 second, so you must hold that info >> somewhere that the registry can use it... >> >> >>> Okay, adding that information into findservice wont actually speed >>> >> things >> >>> up, because the code will have to get that information somewhere. That >>> somewhere is from lsid ... so the question is, what came first the >>> >> chicken >> >>> or the egg ;-) >>> >>> Seriously though, if you want to include this info, isALive will have to >>> become part of the api and be stored in the db. Otherwise, you might >>> >> save >> >>> 1-4 seconds, and still wait 6 seconds per service. >>> >>> 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: Tuesday, April 03, 2007 12:34 PM >>>> To: Core developer announcements >>>> Subject: Re: [MOBY- >>>> >>>> >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> >>>> eadServices >>>> >>>> On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas >>>> >> >> >>>> wrote: >>>> >>>> >>>> >>>>> Hey, that takes into account the whole LSID resolution protocol! >>>>> >>>>> >>>> Sure, but that's what I mean! If Paul is discovering 100 services, at >>>> >> 10 >> >>>> seconds per service, his users are going to delete Seahawk from their >>>> hard-drives faster than they even get their first pop-up menu! >>>> >>>> I'm not laying blame, I'm just pointing out that we have to either make >>>> the LSID stuff run a whole lot faster (like 100X), or we have to >>>> >> abandon >> >>>> it for the time being because it really isn't helping... (and you know >>>> that I *love* LSIDs!) >>>> >>>> M >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> 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 > > !DSPAM:60005,4612c6cf21086226241440! > > > > From gcomesana at cnio.es Wed Apr 4 09:16:40 2007 From: gcomesana at cnio.es (=?ISO-8859-1?Q?=22Guillermo_Comesa=C3=B1a=2E=22?=) Date: Wed, 04 Apr 2007 15:16:40 +0200 Subject: [MOBY-dev] mysterous error In-Reply-To: <4612C905.4030207@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook> <4612C905.4030207@ucalgary.ca> Message-ID: <4613A538.5080104@cnio.es> Hi everybody and sorry about interrupting your arguments, but i get this error: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [ns1:hostname: null] Fault string: java.lang.reflect.InvocationTargetException Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException Fault actor: null When calling: http://ubio.cnio.es:8080/axis/services/MyLogReport {http://biomoby.org/}myLogReport =========== at org.biomoby.client.BaseClient.callBiomobyService(BaseClient.java:190) at org.biomoby.client.BaseClient.callRemoteService(BaseClient.java:255) at org.biomoby.client.BaseCmdLineClient.callRemoteService(BaseCmdLineClient.java:636) at org.biomoby.client.BaseClient.process(BaseClient.java:121) at org.biomoby.client.BaseCmdLineClient.doEverything(BaseCmdLineClient.java:337) at org.biomoby.client.BaseCmdLineClient.main(BaseCmdLineClient.java:740) Caused by: org.tulsoft.shared.GException: ===ERROR=== Fault details: [ns1:hostname: null] Fault string: java.lang.reflect.InvocationTargetException Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException Fault actor: null When calling: http://ubio.cnio.es:8080/axis/services/MyLogReport {http://biomoby.org/}myLogReport =========== at org.tulsoft.tools.soap.axis.AxisCall.doCall(AxisCall.java:164) at org.tulsoft.tools.soap.axis.AxisCall.doCall(AxisCall.java:179) at org.biomoby.client.BaseClient.callBiomobyService(BaseClient.java:185) ... 5 more =========== and i dont know how can i extract information from it. has anybody any suggestion about the source of this error? i mean, has somebody had any error like that one? cheers in advance **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From edward.kawas at gmail.com Wed Apr 4 09:47:58 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 4 Apr 2007 06:47:58 -0700 Subject: [MOBY-dev] mysterous error In-Reply-To: <4613A538.5080104@cnio.es> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook><4612C905.4030207@ucalgary.ca> <4613A538.5080104@cnio.es> Message-ID: <001e01c776bf$db4f58f0$6800a8c0@notebook> What happens when you open http://ubio.cnio.es:8080/axis/services/MyLogReport in a browser? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of "Guillermo Comesa??a." > Sent: Wednesday, April 04, 2007 6:17 AM > To: Core developer announcements > Subject: [MOBY-dev] mysterous error > > Hi everybody and sorry about interrupting your arguments, but i get this > error: > ===ERROR=== > org.biomoby.shared.MobyException: ===ERROR=== > Fault details: > [ns1:hostname: null] > Fault string: java.lang.reflect.InvocationTargetException > Fault code: > {http://schemas.xmlsoap.org/soap/envelope/}Server.userException > Fault actor: null > When calling: > http://ubio.cnio.es:8080/axis/services/MyLogReport > {http://biomoby.org/}myLogReport > =========== > > at > org.biomoby.client.BaseClient.callBiomobyService(BaseClient.java:190) > at > org.biomoby.client.BaseClient.callRemoteService(BaseClient.java:255) > at > org.biomoby.client.BaseCmdLineClient.callRemoteService(BaseCmdLineClient.j > ava:636) > at org.biomoby.client.BaseClient.process(BaseClient.java:121) > at > org.biomoby.client.BaseCmdLineClient.doEverything(BaseCmdLineClient.java:3 > 37) > at > org.biomoby.client.BaseCmdLineClient.main(BaseCmdLineClient.java:740) > Caused by: org.tulsoft.shared.GException: ===ERROR=== > Fault details: > [ns1:hostname: null] > Fault string: java.lang.reflect.InvocationTargetException > Fault code: > {http://schemas.xmlsoap.org/soap/envelope/}Server.userException > Fault actor: null > When calling: > http://ubio.cnio.es:8080/axis/services/MyLogReport > {http://biomoby.org/}myLogReport > =========== > > at org.tulsoft.tools.soap.axis.AxisCall.doCall(AxisCall.java:164) > at org.tulsoft.tools.soap.axis.AxisCall.doCall(AxisCall.java:179) > at > org.biomoby.client.BaseClient.callBiomobyService(BaseClient.java:185) > ... 5 more > =========== > > and i dont know how can i extract information from it. has anybody any > suggestion about the source of this error? i mean, has somebody had any > error like that one? > > cheers in advance > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea el > destinatario. Si usted recibe por error este correo, se ruega comunicarlo > al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments > may contain confidential and privileged information for the sole use of > the designated recipient named above. Distribution, reproduction or any > other use of this transmission by any party other than the intended > recipient is prohibited. If you are not the intended recipient please > contact the sender and delete all copies. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From gcomesana at cnio.es Wed Apr 4 09:59:28 2007 From: gcomesana at cnio.es (=?ISO-8859-1?Q?=22Guillermo_Comesa=C3=B1a=2E=22?=) Date: Wed, 04 Apr 2007 15:59:28 +0200 Subject: [MOBY-dev] mysterous error In-Reply-To: <001e01c776bf$db4f58f0$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook><4612C905.4030207@ucalgary.ca> <4613A538.5080104@cnio.es> <001e01c776bf$db4f58f0$6800a8c0@notebook> Message-ID: <4613AF40.6040404@cnio.es> > What happens when you open > http://ubio.cnio.es:8080/axis/services/MyLogReport in a browser? > > Eddie That seems to work ok. Axis says there is a service in that url but it doesnt give suggestion about invocation. I think the error must be a class problem, but i think i have every necessary jar both in the CLASSPATH and in the axis/WEB-INF/lib directory... and as there is nothing in the logs, i dont know what to think... ah! and i have the same service in my local machine, with tomcat and axis as well, and it works fine. the only difference is the tomcat version, but i dont think there is a big difference between tomcat 5.0.x and tomcat 5.5.x cheers again **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From martin.senger at gmail.com Wed Apr 4 10:11:04 2007 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 4 Apr 2007 15:11:04 +0100 Subject: [MOBY-dev] mysterous error In-Reply-To: <4613A538.5080104@cnio.es> References: <006e01c77625$a0c17910$6800a8c0@notebook> <007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook> <4612C905.4030207@ucalgary.ca> <4613A538.5080104@cnio.es> Message-ID: <4d93f07c0704040711l249c29fct3c693402ff0dae08@mail.gmail.com> Whenever you are desperate and cannot locate an error, start it via tcpmon and see what is going "on the wire". (Or show us the raw XML messages coming out and back from your client to your tomcat.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Wed Apr 4 11:52:23 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 4 Apr 2007 08:52:23 -0700 Subject: [MOBY-dev] mysterous error In-Reply-To: <4613AF40.6040404@cnio.es> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook><4612C905.4030207@ucalgary.ca><4613A538.5080104@cnio.es><001e01c776bf$db4f58f0$6800a8c0@notebook> <4613AF40.6040404@cnio.es> Message-ID: <003801c776d1$3ced5e20$6800a8c0@notebook> I would then try what Martin suggested, look at what is sent over the wire. He suggested you use TCPMON, being on windows, I use tcptrace. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of "Guillermo Comesa??a." > Sent: Wednesday, April 04, 2007 6:59 AM > To: moby-dev at lists.open-bio.org > Subject: Re: [MOBY-dev] mysterous error > > > What happens when you open > > http://ubio.cnio.es:8080/axis/services/MyLogReport in a browser? > > > > Eddie > That seems to work ok. Axis says there is a service in that url but it > doesnt give suggestion about invocation. I think the error must be a > class problem, but i think i have every necessary jar both in the > CLASSPATH and in the axis/WEB-INF/lib directory... and as there is > nothing in the logs, i dont know what to think... > > ah! and i have the same service in my local machine, with tomcat and > axis as well, and it works fine. the only difference is the tomcat > version, but i dont think there is a big difference between tomcat 5.0.x > and tomcat 5.5.x > > cheers again > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea el > destinatario. Si usted recibe por error este correo, se ruega comunicarlo > al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments > may contain confidential and privileged information for the sole use of > the designated recipient named above. Distribution, reproduction or any > other use of this transmission by any party other than the intended > recipient is prohibited. If you are not the intended recipient please > contact the sender and delete all copies. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ivanp at mmb.pcb.ub.es Wed Apr 4 14:13:43 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Wed, 04 Apr 2007 20:13:43 +0200 Subject: [MOBY-dev] MobyDateTime.FULL_FORMAT problem in jMoby Message-ID: <4613EAD7.7040500@mmb.pcb.ub.es> Hi, As long as I understand, the static constant attribute in class MobyDateTime.FULL_FORMAT should be used to construct the SimpleDateFormat to use it to format dates. Something like this: ... import java.text.SimpleDateFormat; import java.util.Date; ... Date now = new Date(); SimpleDateFormat sdf = new SimpleDateFormat(MobyDateTime.FULL_FORMAT); sdf.format( now ); ... But this produces an exception when trying to build the SimpleDateFormat. I've inspected the content of the constant and it is like this: "yyyy-MM-dd\'T\'HH:mm:ss\'Z\'Z" Instead of it I used the following (I know I'm losing some precision) and it worked: "yyyy-MM-dd'T'HH:mm:ss" Cheers, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From ivanp at mmb.pcb.ub.es Thu Apr 5 06:44:50 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 12:44:50 +0200 Subject: [MOBY-dev] Dashboard "confuses" services Message-ID: <4614D322.200@mmb.pcb.ub.es> Hi, In our registry we have several services with the same name (but different authorities) and I have the impression that when I try to call the different ones from "Simple Client" panel in Dashboard, it always tries to use the same service. Regards, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From martin.senger at gmail.com Thu Apr 5 06:53:06 2007 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 5 Apr 2007 11:53:06 +0100 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4614D322.200@mmb.pcb.ub.es> References: <4614D322.200@mmb.pcb.ub.es> Message-ID: <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> > In our registry we have several services with the same name (but > different authorities) and I have the impression that when I try to call > the different ones from "Simple Client" panel in Dashboard, it always > tries to use the same service. That would definitely be a bug. I will look at it. [ Do I have access to your registry? Don't worry if not, I can simulate the situation elsewhere...] Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From ivanp at mmb.pcb.ub.es Thu Apr 5 09:26:49 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 15:26:49 +0200 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> References: <4614D322.200@mmb.pcb.ub.es> <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> Message-ID: <4614F919.3040904@mmb.pcb.ub.es> You have access: http://moby-dev.inab.org/cgi-bin/MOBY-Central.pl http://moby-dev.inab.org/MOBY/Central Iv?n Martin Senger wrote: >>In our registry we have several services with the same name (but >>different authorities) and I have the impression that when I try to call >>the different ones from "Simple Client" panel in Dashboard, it always >>tries to use the same service. >> >> > > >That would definitely be a bug. I will look at it. [ Do I have access to >your registry? Don't worry if not, I can simulate the situation >elsewhere...] > >Martin > > > From ivanp at mmb.pcb.ub.es Thu Apr 5 09:30:24 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 15:30:24 +0200 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> References: <4614D322.200@mmb.pcb.ub.es> <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> Message-ID: <4614F9F0.8000702@mmb.pcb.ub.es> By the way, the service I was trying is called "getStatisticalLog" Cheers, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> In our registry we have several services with the same name (but >> different authorities) and I have the impression that when I try to call >> the different ones from "Simple Client" panel in Dashboard, it always >> tries to use the same service. >> > > > That would definitely be a bug. I will look at it. [ Do I have access to > your registry? Don't worry if not, I can simulate the situation > elsewhere...] > > Martin > > From ivanp at mmb.pcb.ub.es Thu Apr 5 09:43:05 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 15:43:05 +0200 Subject: [MOBY-dev] Dashboard and date types Message-ID: <4614FCE8.70904@mmb.pcb.ub.es> Hi, Dashboard detects when an article name corresponds to a data type and then calls the modal window "Date-Time Chooser" which is great but it seems to me that it doesn't generate ISO 8601 compliant date/times as it should. This is an example of date/time generated: 2007-04-05T15:28:58Z+0200 If I understand well the standard (http://www.w3.org/TR/NOTE-datetime): /"...This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. A standard referencing this profile should permit one or both of these ways of handling time zone offsets..." /- if "Z" is present, this means that we are at UTC time zone and then there shouldn't be anything else after the "Z" - if "Z" is no present, then time zone can be specified as positive/negative offset with respect UTC Some examples (extracted from the previous reference): 1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 1994-11-05T13:15:30Z corresponds to the same instant. I suppose that Dashboard should be corrected to produce date/time ISO 8601 compliant dates and some mechanism to determine the time zone where the client is being executed should be introduced. Please, let me know if I'm wrong. Cheers, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From ivanp at mmb.pcb.ub.es Thu Apr 5 09:58:53 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 15:58:53 +0200 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> References: <4614D322.200@mmb.pcb.ub.es> <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> Message-ID: <4615009D.6050304@mmb.pcb.ub.es> I think it only happens when the option: "Ask registry where service is, and call it" is selected. With the option "Use service's usual endpoint", seems to work properly. Cheers, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> In our registry we have several services with the same name (but >> different authorities) and I have the impression that when I try to call >> the different ones from "Simple Client" panel in Dashboard, it always >> tries to use the same service. >> > > > That would definitely be a bug. I will look at it. [ Do I have access to > your registry? Don't worry if not, I can simulate the situation > elsewhere...] > > Martin > > From martin.senger at gmail.com Thu Apr 5 10:27:51 2007 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 5 Apr 2007 15:27:51 +0100 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4615009D.6050304@mmb.pcb.ub.es> References: <4614D322.200@mmb.pcb.ub.es> <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> <4615009D.6050304@mmb.pcb.ub.es> Message-ID: <4d93f07c0704050727p356b06ewe04a6ddd01279e58@mail.gmail.com> > I think it only happens when the option: "Ask registry where service is, > and call it" is selected. With the option "Use service's usual > endpoint", seems to work properly. Okay, it helps. Looking into it (well, not now, but very soon). Well, not soon, rather now: I have found the culprit (it was quite easy after your comments above). The line (in ServiceCallerModel.java): MobyService clonedService = new MobyService (selService.getName()); must be replaced by line MobyService clonedService = new MobyService (selService.getName(), selService.getAuthority()); which I just did and committed. But I have not tested it (SoftGod forgive me!) - could you test it perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From ivanp at mmb.pcb.ub.es Thu Apr 5 10:41:34 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 16:41:34 +0200 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4d93f07c0704050727p356b06ewe04a6ddd01279e58@mail.gmail.com> References: <4614D322.200@mmb.pcb.ub.es><4d93f07c0704050353t74af5f4em6c34e3a 78415512d@mail.gmail.com><4615009D.6050304@mmb.pcb.ub.es> <4d93f07c0704050727p356b06ewe04a6ddd01279e58@mail.gmail.com> Message-ID: <46150A9E.40609@mmb.pcb.ub.es> It worked! Thanks, Iv?n ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> I think it only happens when the option: "Ask registry where service is, >> and call it" is selected. With the option "Use service's usual >> endpoint", seems to work properly. >> > > > Okay, it helps. Looking into it (well, not now, but very soon). > > Well, not soon, rather now: I have found the culprit (it was quite easy > after your comments above). The line (in ServiceCallerModel.java): > > MobyService clonedService = new MobyService (selService.getName()); > > must be replaced by line > > MobyService clonedService = new MobyService (selService.getName(), > selService.getAuthority()); > > which I just did and committed. But I have not tested it (SoftGod forgive > me!) - could you test it perhaps? > > Thanks, > Martin > > > From duncan.hull at cs.man.ac.uk Wed Apr 11 06:13:43 2007 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Wed, 11 Apr 2007 11:13:43 +0100 Subject: [MOBY-dev] BioMoby at Nature Network Message-ID: <461CB4D7.9050902@cs.man.ac.uk> Hello BioMOBYers You may have already come across http://network.nature.com/about which is a bit like mySpace for Scientists. Its early days at the moment and it remains to be seen how successful this is, but just in case it takes off, I created a BioMOBY group... http://network.nature.com/group/biomoby please join in if you're interested... Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From Pieter.Neerincx at wur.nl Thu Apr 12 10:40:16 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 12 Apr 2007 16:40:16 +0200 Subject: [MOBY-dev] revised manuscript now in CVS In-Reply-To: References: Message-ID: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> Hi Mark, I'm impressed! A very nice manuscript overall and a pleasure to read. Just a few minor comments, most of them spelling issues: * Authors (page 1): please add 'nc' to my last name. Neerix -> Neerincx. Otherwise it sounds like I'm a character from an Asterix and Obelix cartoon :). * BioMoby Web Services ? ?What resources are out there to do it??, second paragraph (page 7): add 'is' ...and the BioMoby API ensures that an ontology term that *is* in- use by any registered service ... * The BioMoby Central Registry ? ?How do I find the resource provider I want??, first paragraph (page 9): remove redundant spaces ...towards its leaf nodes. * *Similarly, and perhaps more ... * BioMoby vs. peer semantic and schema technologies, first paragraph (page 13): add 'm' in systes ...and made many adaptations to these standards in response to perceived limitations and/or complexities in these syste*m*s * Discussion, Closed world, second paragraph (page 10): ..."While showing exciting early success in achieving interoperability between a small number of participating providers, it remains to be seen, as the project expands, if the complexity of reasoning over an open-world system, and/or the potential dilution of compatibility between resources due to the increasing number of ontological possibilities, will interfere with the desired end-point of straight-forward, maximal interoperability between bioinformatics Web resources." That was an extremely long sentence. With five commas and spanning 7 lines it starts to resemble a workflow :). It would be better to shorten it for the sake of readability. Just my 0,02?. Cheers, Pi On 27-Mar-2007, at 11:39 PM, Mark Wilkinson wrote: > Thanks to all who read and commented on the Moby 1.0 manuscript so > quickly! > > I've made the first set of suggested revisions, and the new > manuscript is > uploaded (version 7)to the CVS in the /Docs folder. > > Since we can't track changes using the binary PDF format, perhaps send > your suggestions/edits to the mailing list so that everyone can see > them > and comment on them. > > Cheers! > > Mark > _______________________________________________ > 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 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From gordonp at ucalgary.ca Thu Apr 12 11:08:57 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 12 Apr 2007 09:08:57 -0600 Subject: [MOBY-dev] revised manuscript now in CVS In-Reply-To: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> References: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> Message-ID: <461E4B89.7000606@ucalgary.ca> I believe you mean a wordflow :-D > That was an extremely long sentence. With five commas and spanning > 7 lines it starts to resemble a workflow :). From Pieter.Neerincx at wur.nl Thu Apr 12 11:26:22 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 12 Apr 2007 17:26:22 +0200 Subject: [MOBY-dev] Valid boolean values for primitives and secondary parmeters In-Reply-To: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> References: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> Message-ID: <1110FAE7-868A-4A64-99A8-4190B3F482E7@wur.nl> Hi all, Yesterday I was fiddling with some registration scripts and wondering what are valid values for boolean primary articles a.k.a. primitives and for boolean secondaries? After Googeling and browsing the mailinglist archive I noticed to subject poped up before, but I couldn't figure out what the consensus is... Furthermore I can not find this subject back in the MOBY Services API documentation at http://biomoby.open-bio.org/CVS_CONTENT/ moby-live/Docs/MOBY-S_API/index_API.html Can somebody please enlighten me on the current status, so I can add this to the docs... Cheers, Pi From markw at illuminae.com Thu Apr 12 14:23:01 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 12 Apr 2007 11:23:01 -0700 Subject: [MOBY-dev] Version 11 of the manuscript in the CVS Message-ID: Hi all, I've added everyones changes to the manuscript - version 11 is now in the moby-live/Docs folder of the CVS. This should be the final version, unless there are any objections. Please check teh "authorship" list and tell me ASAP if you think anyone else should be on there. Cheers all! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From ivanp at mmb.pcb.ub.es Wed Apr 18 11:22:22 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Wed, 18 Apr 2007 17:22:22 +0200 Subject: [MOBY-dev] an easy way to see the input/output size when using jMoby? Message-ID: <462637AE.6080303@mmb.pcb.ub.es> Hi, I'd like to register the input size of the requests to my moby services (and the same for results) when I'm using jMoby. At the moment I have a provisional work-around but I was wondering if there is a nice way to do it with the jMoby classes. I don't need byte precission (it's not important for me to register the size of all the SOAP stuff, for example); I need a correlated measurement with the input/output (for example the size of the input/output objects in XML ir right). Thanks, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From edward.kawas at gmail.com Wed Apr 18 11:51:26 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 18 Apr 2007 08:51:26 -0700 Subject: [MOBY-dev] an easy way to see the input/output size when usingjMoby? In-Reply-To: <462637AE.6080303@mmb.pcb.ub.es> References: <462637AE.6080303@mmb.pcb.ub.es> Message-ID: <000901c781d1$6c61b880$6800a8c0@notebook> Hi Ivan, I don?t really understand the problem. Do you think that you could give a concrete example or provide further information? 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 Iv?n P?rraga Garc?a > Sent: Wednesday, April 18, 2007 8:22 AM > To: Core developer announcements > Subject: [MOBY-dev] an easy way to see the input/output size when > usingjMoby? > > Hi, > > I'd like to register the input size of the requests to my moby services > (and the same for results) when I'm using jMoby. At the moment I have a > provisional work-around but I was wondering if there is a nice way to do > it with the jMoby classes. > > I don't need byte precission (it's not important for me to register the > size of all the SOAP stuff, for example); I need a correlated > measurement with the input/output (for example the size of the > input/output objects in XML ir right). > > Thanks, > > -- > ------------------------------------------------ > Iv?n P?rraga Garc?a > Computer Scientist > Molecular Modelling & Bioinformatics Unit > INB - Instituto Nacional de Bioinform?tica > Josep Samitier 1-5 > 08028 Barcelona > Spain > tel.: +34 93 403 71 55 > fax.: +34 93 403 71 57 > e-mail: ivanp at mmb.pcb.ub.es > group page: http://mmb.pcb.ub.es > pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > ------------------------------------------------ > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ivanp at mmb.pcb.ub.es Wed Apr 18 12:11:27 2007 From: ivanp at mmb.pcb.ub.es (=?UTF-8?B?SXbDoW4gUMOhcnJhZ2EgR2FyY8OtYQ==?=) Date: Wed, 18 Apr 2007 18:11:27 +0200 Subject: [MOBY-dev] an easy way to see the input/output size whenusingjMoby? In-Reply-To: <000901c781d1$6c61b880$6800a8c0@notebook> References: <462637AE.6080303@mmb.pcb.ub.es> <000901c781d1$6c61b880$6800a8c0@notebook> Message-ID: <4626432F.5030109@mmb.pcb.ub.es> I'll try to explain better... We're registering info for statistical purposes. Things like time of execution, status at the end, timestamps, etc. One thing that we want to store is how big are the moby input objects (in the service call request) and the same for the response. For example, if one service is taking a Fasta as input, I want to know how many bytes big is this Fasta. I don't mind measuring the "exact" size of the input, I want to retrieve an unit that is proportional to the input size; in other words the number of characters of the XML moby request corresponding to this Fasta object is a good measurement, but it would be also a good measurement the real size in bytes... I want a measurement good enough to decide if two different calls have different input/ouput sizes and in what proportion. However, the best would be to have a realistic size in bytes but it's not a real need. In fact, now I'm doing something similiar to this: MobyJob request... MobyJob response... request.format(0).length(); response.format(0).length(); The main problem of this is that I'm introducing an unnecessary overhead to parse the request/response as an String (and this can be a problem for huge requests/responses). Have I explained myself better? Thanks, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Edward Kawas escribi?: > Hi Ivan, > > I don?t really understand the problem. Do you think that you could give a > concrete example or provide further information? > > 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 Iv?n P?rraga Garc?a >> Sent: Wednesday, April 18, 2007 8:22 AM >> To: Core developer announcements >> Subject: [MOBY-dev] an easy way to see the input/output size when >> usingjMoby? >> >> Hi, >> >> I'd like to register the input size of the requests to my moby services >> (and the same for results) when I'm using jMoby. At the moment I have a >> provisional work-around but I was wondering if there is a nice way to do >> it with the jMoby classes. >> >> I don't need byte precission (it's not important for me to register the >> size of all the SOAP stuff, for example); I need a correlated >> measurement with the input/output (for example the size of the >> input/output objects in XML ir right). >> >> Thanks, >> >> -- >> ------------------------------------------------ >> Iv?n P?rraga Garc?a >> Computer Scientist >> Molecular Modelling & Bioinformatics Unit >> INB - Instituto Nacional de Bioinform?tica >> Josep Samitier 1-5 >> 08028 Barcelona >> Spain >> tel.: +34 93 403 71 55 >> fax.: +34 93 403 71 57 >> e-mail: ivanp at mmb.pcb.ub.es >> group page: http://mmb.pcb.ub.es >> pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc >> ------------------------------------------------ >> >> _______________________________________________ >> 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 > From ivanp at mmb.pcb.ub.es Wed Apr 18 12:22:09 2007 From: ivanp at mmb.pcb.ub.es (=?UTF-8?B?SXbDoW4gUMOhcnJhZ2EgR2FyY8OtYQ==?=) Date: Wed, 18 Apr 2007 18:22:09 +0200 Subject: [MOBY-dev] an easy way to see the input/output sizewhenusingjMoby? In-Reply-To: <4626432F.5030109@mmb.pcb.ub.es> References: <462637AE.6080303@mmb.pcb.ub.es><000901c781d1$6c61b880$6800a8c0@ notebook> <4626432F.5030109@mmb.pcb.ub.es> Message-ID: <462645B1.70207@mmb.pcb.ub.es> Ok, I think the misunderstanding was because the use of the word "register"; I should have said something like "log" or "register statistics at our servers". It could seem that I was trying to "register" something at moby-central... I chose an ambiguous word, sorry. Regards, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Iv?n P?rraga Garc?a escribi?: > I'll try to explain better... > > We're registering info for statistical purposes. Things like time of > execution, status at the end, timestamps, etc. One thing that we want to > store is how big are the moby input objects (in the service call > request) and the same for the response. For example, if one service is > taking a Fasta as input, I want to know how many bytes big is this > Fasta. I don't mind measuring the "exact" size of the input, I want to > retrieve an unit that is proportional to the input size; in other words > the number of characters of the XML moby request corresponding to this > Fasta object is a good measurement, but it would be also a good > measurement the real size in bytes... I want a measurement good enough > to decide if two different calls have different input/ouput sizes and in > what proportion. > > However, the best would be to have a realistic size in bytes but it's > not a real need. > > In fact, now I'm doing something similiar to this: > > MobyJob request... > MobyJob response... > > request.format(0).length(); > response.format(0).length(); > > The main problem of this is that I'm introducing an unnecessary overhead > to parse the request/response as an String (and this can be a problem > for huge requests/responses). > > Have I explained myself better? > > Thanks, > > ------------------------------------------------ > Iv?n P?rraga Garc?a > Computer Scientist > Molecular Modelling & Bioinformatics Unit > INB - Instituto Nacional de Bioinform?tica > Josep Samitier 1-5 > 08028 Barcelona > Spain > tel.: +34 93 403 71 55 > fax.: +34 93 403 71 57 > e-mail: ivanp at mmb.pcb.ub.es > group page: http://mmb.pcb.ub.es > pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > ------------------------------------------------ > > > > Edward Kawas escribi?: > >> Hi Ivan, >> >> I don?t really understand the problem. Do you think that you could give a >> concrete example or provide further information? >> >> 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 Iv?n P?rraga Garc?a >>> Sent: Wednesday, April 18, 2007 8:22 AM >>> To: Core developer announcements >>> Subject: [MOBY-dev] an easy way to see the input/output size when >>> usingjMoby? >>> >>> Hi, >>> >>> I'd like to register the input size of the requests to my moby services >>> (and the same for results) when I'm using jMoby. At the moment I have a >>> provisional work-around but I was wondering if there is a nice way to do >>> it with the jMoby classes. >>> >>> I don't need byte precission (it's not important for me to register the >>> size of all the SOAP stuff, for example); I need a correlated >>> measurement with the input/output (for example the size of the >>> input/output objects in XML ir right). >>> >>> Thanks, >>> >>> -- >>> ------------------------------------------------ >>> Iv?n P?rraga Garc?a >>> Computer Scientist >>> Molecular Modelling & Bioinformatics Unit >>> INB - Instituto Nacional de Bioinform?tica >>> Josep Samitier 1-5 >>> 08028 Barcelona >>> Spain >>> tel.: +34 93 403 71 55 >>> fax.: +34 93 403 71 57 >>> e-mail: ivanp at mmb.pcb.ub.es >>> group page: http://mmb.pcb.ub.es >>> pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc >>> ------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> >> > _______________________________________________ > 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 Wed Apr 18 16:23:15 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 18 Apr 2007 13:23:15 -0700 Subject: [MOBY-dev] an easy way to see the input/outputsizewhenusingjMoby? In-Reply-To: <462645B1.70207@mmb.pcb.ub.es> References: <462637AE.6080303@mmb.pcb.ub.es><000901c781d1$6c61b880$6800a8c0@ notebook><4626432F.5030109@mmb.pcb.ub.es> <462645B1.70207@mmb.pcb.ub.es> Message-ID: <003201c781f7$65a11830$6800a8c0@notebook> Hi Ivan, Thanks for clarifying. I don?t know anything off the top of my head, but I will think about it. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Iv?n P?rraga Garc?a > Sent: Wednesday, April 18, 2007 9:22 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] an easy way to see the > input/outputsizewhenusingjMoby? > > Ok, I think the misunderstanding was because the use of the word > "register"; I should have said something like "log" or "register > statistics at our servers". It could seem that I was trying to > "register" something at moby-central... I chose an ambiguous word, sorry. > > Regards, > > ------------------------------------------------ > Iv?n P?rraga Garc?a > Computer Scientist > Molecular Modelling & Bioinformatics Unit > INB - Instituto Nacional de Bioinform?tica > Josep Samitier 1-5 > 08028 Barcelona > Spain > tel.: +34 93 403 71 55 > fax.: +34 93 403 71 57 > e-mail: ivanp at mmb.pcb.ub.es > group page: http://mmb.pcb.ub.es > pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > ------------------------------------------------ > > > > Iv?n P?rraga Garc?a escribi?: > > I'll try to explain better... > > > > We're registering info for statistical purposes. Things like time of > > execution, status at the end, timestamps, etc. One thing that we want to > > store is how big are the moby input objects (in the service call > > request) and the same for the response. For example, if one service is > > taking a Fasta as input, I want to know how many bytes big is this > > Fasta. I don't mind measuring the "exact" size of the input, I want to > > retrieve an unit that is proportional to the input size; in other words > > the number of characters of the XML moby request corresponding to this > > Fasta object is a good measurement, but it would be also a good > > measurement the real size in bytes... I want a measurement good enough > > to decide if two different calls have different input/ouput sizes and in > > what proportion. > > > > However, the best would be to have a realistic size in bytes but it's > > not a real need. > > > > In fact, now I'm doing something similiar to this: > > > > MobyJob request... > > MobyJob response... > > > > request.format(0).length(); > > response.format(0).length(); > > > > The main problem of this is that I'm introducing an unnecessary overhead > > to parse the request/response as an String (and this can be a problem > > for huge requests/responses). > > > > Have I explained myself better? > > > > Thanks, > > > > ------------------------------------------------ > > Iv?n P?rraga Garc?a > > Computer Scientist > > Molecular Modelling & Bioinformatics Unit > > INB - Instituto Nacional de Bioinform?tica > > Josep Samitier 1-5 > > 08028 Barcelona > > Spain > > tel.: +34 93 403 71 55 > > fax.: +34 93 403 71 57 > > e-mail: ivanp at mmb.pcb.ub.es > > group page: http://mmb.pcb.ub.es > > pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > > ------------------------------------------------ > > > > > > > > Edward Kawas escribi?: > > > >> Hi Ivan, > >> > >> I don?t really understand the problem. Do you think that you could give > a > >> concrete example or provide further information? > >> > >> 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 Iv?n P?rraga Garc?a > >>> Sent: Wednesday, April 18, 2007 8:22 AM > >>> To: Core developer announcements > >>> Subject: [MOBY-dev] an easy way to see the input/output size when > >>> usingjMoby? > >>> > >>> Hi, > >>> > >>> I'd like to register the input size of the requests to my moby > services > >>> (and the same for results) when I'm using jMoby. At the moment I have > a > >>> provisional work-around but I was wondering if there is a nice way to > do > >>> it with the jMoby classes. > >>> > >>> I don't need byte precission (it's not important for me to register > the > >>> size of all the SOAP stuff, for example); I need a correlated > >>> measurement with the input/output (for example the size of the > >>> input/output objects in XML ir right). > >>> > >>> Thanks, > >>> > >>> -- > >>> ------------------------------------------------ > >>> Iv?n P?rraga Garc?a > >>> Computer Scientist > >>> Molecular Modelling & Bioinformatics Unit > >>> INB - Instituto Nacional de Bioinform?tica > >>> Josep Samitier 1-5 > >>> 08028 Barcelona > >>> Spain > >>> tel.: +34 93 403 71 55 > >>> fax.: +34 93 403 71 57 > >>> e-mail: ivanp at mmb.pcb.ub.es > >>> group page: http://mmb.pcb.ub.es > >>> pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > >>> ------------------------------------------------ > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > > _______________________________________________ > > 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 From markw at illuminae.com Fri Apr 20 19:51:44 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 20 Apr 2007 16:51:44 -0700 Subject: [MOBY-dev] Fingers crossed! Message-ID: I just submitted the 1.0 manuscript to PLoS. fingers crossed everyone! M From dmitry.repchevski at bsc.es Mon Apr 23 06:40:18 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 23 Apr 2007 12:40:18 +0200 Subject: [MOBY-dev] soap encoding Message-ID: <462C8D12.9090606@bsc.es> Hello, My name is Dmitry and I was contracted by INB (Spain) to work on web services (JMoby). Reading some papers from JMoby I have implemented some services using MoSeS and by now have a jboss 4.03sp1 working. The problem is that JMoby uses "soap encoding" (section 5) while this encoding is considered obsolete and unfortunately no any modern java application servers support it. Actually JBoss dropped support starting from 4.04 when they passed to JEE5 compatible web services stack (jax-ws compatible). The java skeleton generated by MoSeS generates the service endpoint method passing an Object to it (while according moby wsdl it should be a string). There is no problem to change the Object to String (this is the only change needed) to generate equal wsdl (otherwise wsdl generated by wsdp contains "xsd:anyType" that is incompatible with web services WS-I specification). Even more this change would permit to generate the web service with "rpc-literal" encoding. We have tested generated web-service with both types of clients - "soap-encoding" and "rpc-literal" encoding on both platforms (java & perl). It works well. The idea is to make (at least java, not sure for perl) webservices that supports both encoding thinking that in a future we could migrate also clients (actually the only thing needed is to recompile it with new generated wsdl. This would permit us to move to JBoss5 or any JEE compatible server in a future. Here I attach some example of wsdl generated with and without "literal" note: the soap-encoding version actually is not that one generated from MoSeS interface, because MoSeS generates "Object" that translates to "xsd:anyType" ***************************************************** ***************************************************** ***************************************************** ***************************************************** Yours Sincerely, Dmitry, From martin.senger at gmail.com Mon Apr 23 08:58:13 2007 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 23 Apr 2007 14:58:13 +0200 Subject: [MOBY-dev] soap encoding In-Reply-To: <462C8D12.9090606@bsc.es> References: <462C8D12.9090606@bsc.es> Message-ID: <4d93f07c0704230558q50989ac3q9e40f1f4263686e8@mail.gmail.com> Hi, The problem is that JMoby uses "soap encoding" (section 5) while this > encoding is considered obsolete and unfortunately no any modern java > application servers support it. I think (please correct me if I am wrong) that jMoby implements what BioMOBY API (specification) asks for. jMoby is tied by this spec. We cannot suddenly switch to a different protocol without breaking existing software, can we? The java skeleton generated by MoSeS generates the service endpoint > method passing an Object to it (while according moby wsdl it should be a > string). Java skeleton does what BioMOBY spec dictates. If you take it, however, and try to use it for generating a WSDL, it is you are doing things that the skeleton was designed for. The BioMOBY spec has its own API call to get WSDL for each service (and which, from various reasons, cannot give you the full WSDL, anyway). Please let me know if I am interpreted your comment wrongly, or if I am missing something. There is no problem to change the Object to String But the point is to have a skeleton that deals with Java objects, not with MOBY data types. But perhaps give me an example of service you have in mind. Probably (I guess) that you are barking on the wrong tree because you are using the skeleton for generating wsdl. The idea is to make (at least java, not sure for perl) webservices that > supports both encoding That's fine with me and I agree with this vision. But it requires to change BioMOBY API. Ask for it the community. When we agree on it, I will make changes in MoSeS to support it. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From dmitry.repchevski at bsc.es Mon Apr 23 13:45:15 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 23 Apr 2007 19:45:15 +0200 Subject: [MOBY-dev] soap encoding Message-ID: <462CF0AB.5050705@bsc.es> Hello Martin, >I think (please correct me if I am wrong) that jMoby implements what BioMOBY >API (specification) asks for. jMoby is tied by this spec. We cannot >suddenly switch to a different protocol without breaking existing software, >can we? Well I am new to jMoby as well as BioMoby, so what is the specification you talk about? Could you please give me a link? >Java skeleton does what BioMOBY spec dictates. If you take it, however, and >try to use it for generating a WSDL, it is you are doing things that the >skeleton was designed for. The BioMOBY spec has its own API call to get WSDL >for each service (and which, from various reasons, cannot give you the full >WSDL, anyway). Please let me know if I am interpreted your comment wrongly, >or if I am missing something. Well you got the point. Actually I use the generated skeleton to generate my end point, not the wsdl from BioMoby. What I'm talking is that the generated skeleton is not strictly compatible with BioMoby wsdl. The WSDL I'm getting through BioMoby expects that end point accepts xsd:string, but the skeleton accepts an Object. I am not talking here about the ontology. Actually BioMoby do not use web services architecture (correct me if I'm wrong), but rather just sends a plain xml file that you have to parse later to get the parameters. So the web service is always the same - 1 parameter (xsd:string) in, another out. Using java.lang.Object in an endpoint is against of WS-I specification. So by now my request is just to change the endpoint generated by MoSeS to accept the String according both (WS-I and BioMoby). Such a thing makes both WSDL (from BioMoby and generated from endpoint) 100% equal. >There is no problem to change the Object to String :-) >But the point is to have a skeleton that deals with Java objects, not with >MOBY data types. But perhaps give me an example of service you have in mind. **************************************************************************************************************** abstract public class runEmbossAntigenicFromSequenceSkel extends BaseService { /************************************************************************** * Default constructor. *************************************************************************/ public runEmbossAntigenicFromSequenceSkel() { super(); } /************************************************************************** * The main method (available as a Web Service).

*************************************************************************/ public String runEmbossAntigenicFromSequence (String data) { // Just change Object -> String MobyPackage mobyOutput = null; try { // reading the whole input MobyPackage mobyInput = MobyPackage.createFromXML (data, "AminoAcidSequence"); **************************************************************************************************************** so in wsdl we will get **************************************************************************************************************** **************************************************************************************************************** EXACTLY AS IS FROM WSDL THAT I GET FROM MOBY!!! >Probably (I guess) that you are barking on the wrong tree because you are >using the skeleton for generating wsdl. Well, if they done well they MUST be compatible. I use netbeans 5.5.1 that allows me to generate all the things from my endpoint and generates WAR file for me, so I do not have to use an ant script. It takes me 2 seconds to change the service, deploy it to jboss and even debug it on another machine. Another way could be to generate an endpoint from moby's wsdl, but in this case I have to parse the string (xml) by myself and I still didn't went so deep. >That's fine with me and I agree with this vision. But it requires to change >BioMOBY API. Ask for it the community. When we agree on it, I will make >changes in MoSeS to support it. Well if we are talking about changing an Object to String - no any another changes needed. My NEXT point was that (at least in JBoss < 4.04) the generated service supports both encodings "soap encoding" and "rpc-literar". As you pointed it's up to the community to move forward out the obsolete encoding... ;-) Regards, Dmitry From groscurt at mpiz-koeln.mpg.de Wed Apr 25 09:06:23 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Wed, 25 Apr 2007 15:06:23 +0200 Subject: [MOBY-dev] How to change a service with a signatureURL via the dashboard Message-ID: <200704251506.23696.groscurt@mpiz-koeln.mpg.de> Hi everyone, the following situation: I have a service which I register with an signatureURL at a repository. Now I want to change the service and update it in the registry. The procedure I know is to unregister the service and then to register it again. If I'm using a signatureURL I cant unregister the service... so is there a way to update the service via the dashboard or do I have to go the long way to delete the rdf, waiting for the agent to unregister my service, then register it again and putting up the rdf ? Thanks andreas From edward.kawas at gmail.com Wed Apr 25 09:39:20 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 25 Apr 2007 06:39:20 -0700 Subject: [MOBY-dev] How to change a service with a signatureURL via thedashboard In-Reply-To: <200704251506.23696.groscurt@mpiz-koeln.mpg.de> References: <200704251506.23696.groscurt@mpiz-koeln.mpg.de> Message-ID: <003501c7873f$218c9820$6800a8c0@notebook> Hi Andreas, You can either modify the RDF and the agent will pick up the changes, or you can remove the document and the agent will remove all services in that document. You don't have to wait for the agent to visit you; you can make the agent visit you by performing a registerservice call with only the signatureURL filled in or if you use dashboard, by using the bottom that says 'Call agent' (or something like that ...). Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Andreas Groscurth > Sent: Wednesday, April 25, 2007 6:06 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] How to change a service with a signatureURL via > thedashboard > > Hi everyone, > > the following situation: > > I have a service which I register with an signatureURL at a repository. > Now I want to change the service and update it in the registry. The > procedure > I know is to unregister the service and then to register it again. > If I'm using a signatureURL I cant unregister the service... > > so is there a way to update the service via the dashboard or do I have to > go > the long way to delete the rdf, waiting for the agent to unregister my > service, then register it again and putting up the rdf ? > > Thanks > andreas > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From groscurt at mpiz-koeln.mpg.de Wed Apr 25 10:04:26 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Wed, 25 Apr 2007 16:04:26 +0200 Subject: [MOBY-dev] RDF creation at the Test central Message-ID: <200704251604.26713.groscurt@mpiz-koeln.mpg.de> Hi, we encountered something and dont know if this is on purpose or a bug. If we register a service at a local repository with "Use RDF Signature" enabled the service is registered and the RDF is created (register time takes about 2min). If we register the same service at the Moby TestCentral the service is registered, but no RDF is created (register time takes seconds). Is this intended that on the test central no RDF creation is happening ? Thanks -- Andreas Groscurth Diplom Bioinformatik - PhD Student Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-447 From markw at illuminae.com Wed Apr 25 12:51:55 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 25 Apr 2007 09:51:55 -0700 Subject: [MOBY-dev] RDF creation at the Test central In-Reply-To: <200704251604.26713.groscurt@mpiz-koeln.mpg.de> References: <200704251604.26713.groscurt@mpiz-koeln.mpg.de> Message-ID: Probably the code for TestCentral is out-of-sync. I'll try to update it today. I also suspect that there is no agent system running on TestCentral, since it wasn't intended to be a registry that needs to be updated, but I'll ask Eddie to deploy it there too. M On Wed, 25 Apr 2007 07:04:26 -0700, Andreas Groscurth wrote: > Hi, > > we encountered something and dont know if this is on purpose or a bug. > > If we register a service at a local repository with "Use RDF Signature" > enabled the service is registered and the RDF is created (register time > takes > about 2min). > > If we register the same service at the Moby TestCentral the service is > registered, but no RDF is created (register time takes seconds). > > Is this intended that on the test central no RDF creation is happening ? > > Thanks -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Thu Apr 26 11:53:48 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Apr 2007 08:53:48 -0700 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio Message-ID: Rejected! "we do not publish papers on software alone" They have suggested PLoS ONE as an alternative, but there are other (open access) journals that we could try... I'm quite fond of the BMC Journals, but I tend to be spamming them with papers in the past 12 months, so they may be getting tired of me ;-) Opinions welcome! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From gordonp at ucalgary.ca Thu Apr 26 11:59:28 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 26 Apr 2007 09:59:28 -0600 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: References: Message-ID: <4630CC60.7070401@ucalgary.ca> How about Nucleic Acids Research, as a "Methods" paper? They have a pretty quick turnaround time at least... > Rejected! > > "we do not publish papers on software alone" > > They have suggested PLoS ONE as an alternative, but there are other (open > access) journals that we could try... I'm quite fond of the BMC Journals, > but I tend to be spamming them with papers in the past 12 months, so they > may be getting tired of me ;-) > > Opinions welcome! > > Mark > > From markw at illuminae.com Thu Apr 26 12:26:48 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Apr 2007 09:26:48 -0700 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: <4630CC60.7070401@ucalgary.ca> References: <4630CC60.7070401@ucalgary.ca> Message-ID: That's a possibility... but it appears that UBC is not a member-institution for NAR, which bumps the publication charges way high - $2370. The manuscript is pretty lengthy, and they allow only 9 pages, with $170/page after that! May be you and I can convince Christoph that we can afford it out of the Platform award ;-) M On Thu, 26 Apr 2007 08:59:28 -0700, Paul Gordon wrote: > How about Nucleic Acids Research, as a "Methods" paper? They have a > pretty quick turnaround time at least... >> Rejected! >> >> "we do not publish papers on software alone" >> >> They have suggested PLoS ONE as an alternative, but there are other >> (open >> access) journals that we could try... I'm quite fond of the BMC >> Journals, >> but I tend to be spamming them with papers in the past 12 months, so >> they >> may be getting tired of me ;-) >> >> Opinions welcome! >> >> Mark >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From phillip.lord at newcastle.ac.uk Fri Apr 27 09:26:17 2007 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 27 Apr 2007 14:26:17 +0100 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: (Mark Wilkinson's message of "Thu\, 26 Apr 2007 08\:53\:48 -0700") References: Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Rejected! Mark> "we do not publish papers on software alone" Mark> They have suggested PLoS ONE as an alternative, but there are Mark> other (open access) journals that we could try... I'm quite Mark> fond of the BMC Journals, but I tend to be spamming them with Mark> papers in the past 12 months, so they may be getting tired of Mark> me ;-) If they are tired of you, then the worse that they can do is reject you. BMC Bioinformatics or PLoS ONE would both be quite fun; the former has the best citation impact (obviously, as PLoS one is new). Phil From phillip.lord at newcastle.ac.uk Fri Apr 27 09:26:17 2007 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 27 Apr 2007 14:26:17 +0100 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: (Mark Wilkinson's message of "Thu\, 26 Apr 2007 08\:53\:48 -0700") References: Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Rejected! Mark> "we do not publish papers on software alone" Mark> They have suggested PLoS ONE as an alternative, but there are Mark> other (open access) journals that we could try... I'm quite Mark> fond of the BMC Journals, but I tend to be spamming them with Mark> papers in the past 12 months, so they may be getting tired of Mark> me ;-) If they are tired of you, then the worse that they can do is reject you. BMC Bioinformatics or PLoS ONE would both be quite fun; the former has the best citation impact (obviously, as PLoS one is new). Phil From duncan.hull at cs.man.ac.uk Mon Apr 30 08:17:35 2007 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Mon, 30 Apr 2007 13:17:35 +0100 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: References: <4630CC60.7070401@ucalgary.ca> Message-ID: <4635DE5F.6090408@cs.man.ac.uk> Mark Wilkinson wrote: > That's a possibility... but it appears that UBC is not a > member-institution for NAR, which bumps the publication charges way high - NAR is expensive, but a logical place for BioMOBY would be their annual web server issue [1]. The deadline for the 2007 issue is long gone, but there is always next year (deadline in December 2007, publication June 2008) http://www.nodalpoint.org/2006/12/01/nar_web_server_issue_2007 publication turnaround times are a glacial... 6 months! Howabout Source Code for Biology and Medicine? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From markw at illuminae.com Mon Apr 30 09:45:18 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Apr 2007 06:45:18 -0700 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: <4635DE5F.6090408@cs.man.ac.uk> References: <4630CC60.7070401@ucalgary.ca> <4635DE5F.6090408@cs.man.ac.uk> Message-ID: I'm already planning to submit Moby to the NAR WS issue, which is another reason I am loathe to submit it there for the 1.0 publication. SCFBM is fine too, but I think PLoS ONE might be a better location due to the broader audience. I havn't heard any objections, so I'm going to go ahead and submit it there today. Cheers all! M On Mon, 30 Apr 2007 05:17:35 -0700, Duncan Hull wrote: > Mark Wilkinson wrote: >> That's a possibility... but it appears that UBC is not a >> member-institution for NAR, which bumps the publication charges way >> high - > > NAR is expensive, but a logical place for BioMOBY would be their annual > web server issue [1]. The deadline for the 2007 issue is long gone, but > there is always next year (deadline in December 2007, publication June > 2008) > > http://www.nodalpoint.org/2006/12/01/nar_web_server_issue_2007 > > publication turnaround times are a glacial... 6 months! > > Howabout Source Code for Biology and Medicine? > > > Duncan > -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From usadel at mpimp-golm.mpg.de Mon Apr 2 09:54:17 2007 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Mon, 02 Apr 2007 11:54:17 +0200 Subject: [MOBY-dev] revised manuscript now in CVS In-Reply-To: References: Message-ID: <4610D2C9.9090009@mpimp-golm.mpg.de> Hi, Nice MS, Just minor points from me. - (page 15) I In this respect, BioMoby data is more reliable and predictable #typo? drop the I -(page 4) and is designed to represent specific data identifiers from known resources an a ell-defined #typo? add w to ell-defined The XML sniplets in Figures 1,2 and 4 look jaggy, is that due to the pdf-conversion or are vector-graphics needed? (If so I guess the work could be split) Personally, I think that exception/error-handling could be a bit longer, but I am very biased there. Something along the lines: Whereas conventional web based tools, when not returning any result often leave the user wondering if this is due to a temporary server malfunction, a genuine empty result or a malformed query, BioMoby's implementation of error handling helps to discriminate, these different reasons. Further, (in the future? #I don't know how things are standing there currently) the BioMoby registry will automatically remove the visibility of services which have major problems. Cheers, Bj?rn Mark Wilkinson wrote: > Thanks to all who read and commented on the Moby 1.0 manuscript so quickly! > > I've made the first set of suggested revisions, and the new manuscript is > uploaded (version 7)to the CVS in the /Docs folder. > > Since we can't track changes using the binary PDF format, perhaps send > your suggestions/edits to the mailing list so that everyone can see them > and comment on them. > > Cheers! > > Mark > _______________________________________________ > 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 Apr 3 17:59:31 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 10:59:31 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices Message-ID: There sure are a lot of "dead" services out there... Are these really "dead" or are they just not responding to the ping properly? M From gordonp at ucalgary.ca Tue Apr 3 18:05:39 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 12:05:39 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: Message-ID: <46129773.5030503@ucalgary.ca> I say kill'em all! If they don't respond to ping, they aren't MOBY compliant (old ones on my servers included!). All it does is make MOBY look bad to new users... > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices > > > > There sure are a lot of "dead" services out there... > > Are these really "dead" or are they just not responding to the ping > properly? > > M > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,461294fe210862398211280! > > > > From duncan.hull at cs.man.ac.uk Tue Apr 3 18:10:34 2007 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Tue, 03 Apr 2007 19:10:34 +0100 Subject: [MOBY-dev] getDeadServices In-Reply-To: References: Message-ID: <4612989A.1070904@cs.man.ac.uk> Mark Mark Wilkinson wrote: > There sure are a lot of "dead" services out there... > Are these really "dead" They're not dead, they are just resting http://www.youtube.com/watch?v=2H6DSoqZz_s -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From edward.kawas at gmail.com Tue Apr 3 18:41:19 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 11:41:19 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <46129773.5030503@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> Message-ID: <003e01c7761f$ac13f000$6800a8c0@notebook> I like Duncan's explanation. Anyways, they aren't all 'invalid' services. And the reason we shouldn't dump them all is that maybe they are behind a firewall that we cant reach, etc. BTW, according to http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getStats=t rue There are 897 alive services and 231 'dead' ones, for a roughly 80% up rate. I would point out that just a year ago, the number of dead services was as high as 40%. I don't like having the dead services around, but there may be reason why we cant hit them and so we shouldn't throw the baby out with the bath water! Hopefully soon in Taverna we will be able to finally optionally filter out dead services and this wont really be an issue! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 11:06 AM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > I say kill'em all! If they don't respond to ping, they aren't MOBY > compliant (old ones on my servers included!). All it does is make MOBY > look bad to new users... > > > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadS > ervices > > > > > > > > There sure are a lot of "dead" services out there... > > > > Are these really "dead" or are they just not responding to the ping > > properly? > > > > M > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > !DSPAM:60005,461294fe210862398211280! > > > > > > > > > > _______________________________________________ > 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 Apr 3 18:18:49 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 11:18:49 -0700 Subject: [MOBY-dev] getDeadServices In-Reply-To: <4612989A.1070904@cs.man.ac.uk> References: <4612989A.1070904@cs.man.ac.uk> Message-ID: Alright then, I'll wake 'em up! HELLO POLLY! M On Tue, 03 Apr 2007 11:10:34 -0700, Duncan Hull wrote: > Mark > > Mark Wilkinson wrote: >> There sure are a lot of "dead" services out there... >> Are these really "dead" > They're not dead, they are just resting > http://www.youtube.com/watch?v=2H6DSoqZz_s > > -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Tue Apr 3 18:15:07 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 11:15:07 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <46129773.5030503@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> Message-ID: On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon wrote: > I say kill'em all! Thanks Nicolae! ;-) M From gordonp at ucalgary.ca Tue Apr 3 18:51:46 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 12:51:46 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> Message-ID: <4612A242.9040308@ucalgary.ca> I was thinking more Metallica :-) Anyway, if we don't kill'em (as Eddie suggests), can we at least include isAlive in the findService response, so client programs can know the status without retrieving all the service metadata? > On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon > wrote: > > >> I say kill'em all! >> > > Thanks Nicolae! ;-) > > M > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,46129f562108692111878! > > > > From edward.kawas at gmail.com Tue Apr 3 18:53:00 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 11:53:00 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <4612A242.9040308@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> Message-ID: <005201c77621$4d866480$6800a8c0@notebook> Hey Paul, isAlive is in the RDF already. Does that help? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 11:52 AM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > I was thinking more Metallica :-) > > Anyway, if we don't kill'em (as Eddie suggests), can we at least include > isAlive in the findService response, so client programs can know the > status without retrieving all the service metadata? > > On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon > > wrote: > > > > > >> I say kill'em all! > >> > > > > Thanks Nicolae! ;-) > > > > M > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > !DSPAM:60005,46129f562108692111878! > > > > > > > > > > _______________________________________________ > 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 Apr 3 18:57:57 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 12:57:57 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <005201c77621$4d866480$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> Message-ID: <4612A3B5.3010506@ucalgary.ca> I know it's in the metadata RDF (see my message below), but I don't want to have to download it. Why? I just disabled this in Seahawk because it took too long to fetch this (either as one big RDF dump, or individually through the LSID resolver). I was building the list of services for my popups, and it would sit there for several minutes as the registry churned, and the only thing I was using above and beyond the findService() answer was the isAlive. So now I show alive and dead services to speed things up, which is not ideal. > Hey Paul, > > isAlive is in the RDF already. Does that help? > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon >> Sent: Tuesday, April 03, 2007 11:52 AM >> To: Core developer announcements >> Subject: Re: [MOBY- >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> eadServices >> >> I was thinking more Metallica :-) >> >> Anyway, if we don't kill'em (as Eddie suggests), can we at least include >> isAlive in the findService response, so client programs can know the >> status without retrieving all the service metadata? >> >>> On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon >>> wrote: >>> >>> >>> >>>> I say kill'em all! >>>> >>>> >>> Thanks Nicolae! ;-) >>> >>> M >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,4612a16f2108651034071! > > > > From edward.kawas at gmail.com Tue Apr 3 19:00:46 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:00:46 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <4612A3B5.3010506@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> Message-ID: <005301c77622$637a6600$6800a8c0@notebook> How about: http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authority= bioinfo.icapture.ubc.ca&service=getGoTerm where you specify the authority and servicename and true or false is returned. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 11:58 AM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > I know it's in the metadata RDF (see my message below), but I don't want > to have to download it. > Why? I just disabled this in Seahawk because it took too long to fetch > this (either as one big RDF dump, or individually through the LSID > resolver). > I was building the list of services for my popups, and it would sit > there for several minutes as the registry churned, and the only thing I > was using above and beyond the findService() answer was the isAlive. So > now I show alive and dead services to speed things up, which is not ideal. > > Hey Paul, > > > > isAlive is in the RDF already. Does that help? > > > > Eddie > > > > > >> -----Original Message----- > >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon > >> Sent: Tuesday, April 03, 2007 11:52 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY- > >> > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > >> eadServices > >> > >> I was thinking more Metallica :-) > >> > >> Anyway, if we don't kill'em (as Eddie suggests), can we at least > include > >> isAlive in the findService response, so client programs can know the > >> status without retrieving all the service metadata? > >> > >>> On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon > >>> wrote: > >>> > >>> > >>> > >>>> I say kill'em all! > >>>> > >>>> > >>> Thanks Nicolae! ;-) > >>> > >>> M > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > !DSPAM:60005,4612a16f2108651034071! > > > > > > > > > > _______________________________________________ > 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 Apr 3 19:07:19 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 13:07:19 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <005301c77622$637a6600$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> Message-ID: <4612A5E7.1030301@ucalgary.ca> Hey, that nice and fast! Can we make this somehow an "official" part of the MOBY spec? > How about: > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authority= > bioinfo.icapture.ubc.ca&service=getGoTerm > > where you specify the authority and servicename and true or false is > returned. > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon >> Sent: Tuesday, April 03, 2007 11:58 AM >> To: Core developer announcements >> Subject: Re: [MOBY- >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> eadServices >> >> I know it's in the metadata RDF (see my message below), but I don't want >> to have to download it. >> Why? I just disabled this in Seahawk because it took too long to fetch >> this (either as one big RDF dump, or individually through the LSID >> resolver). >> I was building the list of services for my popups, and it would sit >> there for several minutes as the registry churned, and the only thing I >> was using above and beyond the findService() answer was the isAlive. So >> now I show alive and dead services to speed things up, which is not ideal. >> >>> Hey Paul, >>> >>> isAlive is in the RDF already. Does that help? >>> >>> Eddie >>> >>> >>> >>>> -----Original Message----- >>>> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- >>>> bounces at lists.open-bio.org] On Behalf Of Paul Gordon >>>> Sent: Tuesday, April 03, 2007 11:52 AM >>>> To: Core developer announcements >>>> Subject: Re: [MOBY- >>>> >>>> >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> >>>> eadServices >>>> >>>> I was thinking more Metallica :-) >>>> >>>> Anyway, if we don't kill'em (as Eddie suggests), can we at least >>>> >> include >> >>>> isAlive in the findService response, so client programs can know the >>>> status without retrieving all the service metadata? >>>> >>>> >>>>> On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> I say kill'em all! >>>>>> >>>>>> >>>>>> >>>>> Thanks Nicolae! ;-) >>>>> >>>>> M >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,4612a33c2108615024834! > > > > From edward.kawas at gmail.com Tue Apr 3 19:09:48 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:09:48 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <4612A5E7.1030301@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook> <4612A5E7.1030301@ucalgary.ca> Message-ID: <005a01c77623$a6acbda0$6800a8c0@notebook> Also, if you don't specify a servicename, you can retrieve a list of isAlive for all services for that particular authority. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 12:07 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > Hey, that nice and fast! Can we make this somehow an "official" part of > the MOBY spec? > > How about: > > > > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authorit > y= > > bioinfo.icapture.ubc.ca&service=getGoTerm > > > > where you specify the authority and servicename and true or false is > > returned. > > > > Eddie > > > > > >> -----Original Message----- > >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon > >> Sent: Tuesday, April 03, 2007 11:58 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY- > >> > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > >> eadServices > >> > >> I know it's in the metadata RDF (see my message below), but I don't > want > >> to have to download it. > >> Why? I just disabled this in Seahawk because it took too long to fetch > >> this (either as one big RDF dump, or individually through the LSID > >> resolver). > >> I was building the list of services for my popups, and it would sit > >> there for several minutes as the registry churned, and the only thing I > >> was using above and beyond the findService() answer was the isAlive. > So > >> now I show alive and dead services to speed things up, which is not > ideal. > >> > >>> Hey Paul, > >>> > >>> isAlive is in the RDF already. Does that help? > >>> > >>> Eddie > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > >>>> bounces at lists.open-bio.org] On Behalf Of Paul Gordon > >>>> Sent: Tuesday, April 03, 2007 11:52 AM > >>>> To: Core developer announcements > >>>> Subject: Re: [MOBY- > >>>> > >>>> > >> > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > >> > >>>> eadServices > >>>> > >>>> I was thinking more Metallica :-) > >>>> > >>>> Anyway, if we don't kill'em (as Eddie suggests), can we at least > >>>> > >> include > >> > >>>> isAlive in the findService response, so client programs can know the > >>>> status without retrieving all the service metadata? > >>>> > >>>> > >>>>> On Tue, 03 Apr 2007 11:05:39 -0700, Paul Gordon > > >>>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> I say kill'em all! > >>>>>> > >>>>>> > >>>>>> > >>>>> Thanks Nicolae! ;-) > >>>>> > >>>>> M > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > !DSPAM:60005,4612a33c2108615024834! > > > > > > > > > > _______________________________________________ > 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 Apr 3 19:20:43 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 12:20:43 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <005301c77622$637a6600$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> Message-ID: On Tue, 03 Apr 2007 12:00:46 -0700, Edward Kawas wrote: > How about: > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authority= > bioinfo.icapture.ubc.ca&service=getGoTerm > > where you specify the authority and servicename and true or false is > returned. Yeah... but that isn't a part of the Moby API so we don't want to encourage people to code to it. I suspect nobody would object to me adding a tag to the output from findService that included the isAlive information? It's a shame, though... I think it says something important about the Semantic Web in general - all this metadata retrieval can potentially take a long time! Caching isn't going to help much in this case, since the status may change hour by hour (e.g. if a domain disappears briefly). Eddie, do you have a "gut feeling" for why LSID resolution for service instances is so slow? Is it the RDF generation on our end that sucks-up all the time? M From edward.kawas at gmail.com Tue Apr 3 19:23:57 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:23:57 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook> Message-ID: <006e01c77625$a0c17910$6800a8c0@notebook> ServiceInstance rdf generation shouldn't be too slow (all of the time - there is some caching). As for a per instance rdf generation, I don't know. It shouldn't be that slow (~10 secs per service). 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: Tuesday, April 03, 2007 12:21 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > On Tue, 03 Apr 2007 12:00:46 -0700, Edward Kawas > wrote: > > > How about: > > > > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?authorit > y= > > bioinfo.icapture.ubc.ca&service=getGoTerm > > > > where you specify the authority and servicename and true or false is > > returned. > > > Yeah... but that isn't a part of the Moby API so we don't want to > encourage people to code to it. I suspect nobody would object to me > adding a tag to the output from findService that included the isAlive > information? > > It's a shame, though... I think it says something important about the > Semantic Web in general - all this metadata retrieval can potentially take > a long time! Caching isn't going to help much in this case, since the > status may change hour by hour (e.g. if a domain disappears briefly). > > Eddie, do you have a "gut feeling" for why LSID resolution for service > instances is so slow? Is it the RDF generation on our end that sucks-up > all the time? > > M > > > _______________________________________________ > 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 Apr 3 19:29:27 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 12:29:27 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <006e01c77625$a0c17910$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> <006e01c77625$a0c17910$6800a8c0@notebook> Message-ID: On Tue, 03 Apr 2007 12:23:57 -0700, Edward Kawas wrote: > ServiceInstance rdf generation shouldn't be too slow (all of the time - > there is some caching). As for a per instance rdf generation, I don't > know. > It shouldn't be that slow (~10 secs per service). LOL! That's pretty slow! M From edward.kawas at gmail.com Tue Apr 3 19:30:47 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:30:47 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook> Message-ID: <007701c77626$94c56df0$6800a8c0@notebook> Hey, that takes into account the whole LSID resolution protocol! 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: Tuesday, April 03, 2007 12:29 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > On Tue, 03 Apr 2007 12:23:57 -0700, Edward Kawas > wrote: > > > ServiceInstance rdf generation shouldn't be too slow (all of the time - > > there is some caching). As for a per instance rdf generation, I don't > > know. > > It shouldn't be that slow (~10 secs per service). > > > LOL! That's pretty slow! > > M > > > > _______________________________________________ > 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 Apr 3 19:34:06 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 13:34:06 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> <006e01c77625$a0c17910$6800a8c0@notebook> Message-ID: <4612AC2E.4040900@ucalgary.ca> ROTFL! When I ask "What can I do with a DNASequence?", I get lets say 150 services, that means I'm waiting 25 minutes to find out if they are pingable...adding it to findService would be a lot nicer as it's a pretty basic piece of information. If you want to be nicer for compatibility, don't report isAlive, but at least allow an incoming fidServicerequest to restrict the answers to those that are alive... > On Tue, 03 Apr 2007 12:23:57 -0700, Edward Kawas > wrote: > > >> ServiceInstance rdf generation shouldn't be too slow (all of the time - >> there is some caching). As for a per instance rdf generation, I don't >> know. >> It shouldn't be that slow (~10 secs per service). >> > > > LOL! That's pretty slow! > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,4612aa092108690393437! > > > > From markw at illuminae.com Tue Apr 3 19:34:27 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 03 Apr 2007 12:34:27 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <007701c77626$94c56df0$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca> <005201c77621$4d866480$6800a8c0@notebook> <4612A3B5.3010506@ucalgary.ca> <005301c77622$637a6600$6800a8c0@notebook> <006e01c77625$a0c17910$6800a8c0@notebook> <007701c77626$94c56df0$6800a8c0@notebook> Message-ID: On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas wrote: > Hey, that takes into account the whole LSID resolution protocol! Sure, but that's what I mean! If Paul is discovering 100 services, at 10 seconds per service, his users are going to delete Seahawk from their hard-drives faster than they even get their first pop-up menu! I'm not laying blame, I'm just pointing out that we have to either make the LSID stuff run a whole lot faster (like 100X), or we have to abandon it for the time being because it really isn't helping... (and you know that I *love* LSIDs!) M From edward.kawas at gmail.com Tue Apr 3 19:39:26 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 12:39:26 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> Message-ID: <007901c77627$ca0de9a0$6800a8c0@notebook> Okay, adding that information into findservice wont actually speed things up, because the code will have to get that information somewhere. That somewhere is from lsid ... so the question is, what came first the chicken or the egg ;-) Seriously though, if you want to include this info, isALive will have to become part of the api and be stored in the db. Otherwise, you might save 1-4 seconds, and still wait 6 seconds per service. 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: Tuesday, April 03, 2007 12:34 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas > wrote: > > > Hey, that takes into account the whole LSID resolution protocol! > > Sure, but that's what I mean! If Paul is discovering 100 services, at 10 > seconds per service, his users are going to delete Seahawk from their > hard-drives faster than they even get their first pop-up menu! > > I'm not laying blame, I'm just pointing out that we have to either make > the LSID stuff run a whole lot faster (like 100X), or we have to abandon > it for the time being because it really isn't helping... (and you know > that I *love* LSIDs!) > > M > > _______________________________________________ > 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 Apr 3 21:30:52 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 15:30:52 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <007901c77627$ca0de9a0$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> Message-ID: <4612C78C.7090501@ucalgary.ca> But when I run http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService I get all services back in about 1 second, so you must hold that info somewhere that the registry can use it... > Okay, adding that information into findservice wont actually speed things > up, because the code will have to get that information somewhere. That > somewhere is from lsid ... so the question is, what came first the chicken > or the egg ;-) > > Seriously though, if you want to include this info, isALive will have to > become part of the api and be stored in the db. Otherwise, you might save > 1-4 seconds, and still wait 6 seconds per service. > > 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: Tuesday, April 03, 2007 12:34 PM >> To: Core developer announcements >> Subject: Re: [MOBY- >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> eadServices >> >> On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas >> wrote: >> >> >>> Hey, that takes into account the whole LSID resolution protocol! >>> >> Sure, but that's what I mean! If Paul is discovering 100 services, at 10 >> seconds per service, his users are going to delete Seahawk from their >> hard-drives faster than they even get their first pop-up menu! >> >> I'm not laying blame, I'm just pointing out that we have to either make >> the LSID stuff run a whole lot faster (like 100X), or we have to abandon >> it for the time being because it really isn't helping... (and you know >> that I *love* LSIDs!) >> >> M >> >> _______________________________________________ >> 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 > > !DSPAM:60005,4612ac4a210862854622468! > > > > From edward.kawas at gmail.com Tue Apr 3 21:32:33 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 3 Apr 2007 14:32:33 -0700 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <4612C78C.7090501@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> Message-ID: <008501c77637$97a52590$6800a8c0@notebook> Currently, it's held in memory. So if the registry wanted it, it would have to call the url. But since the url isn't in the api, it might be unwise to do so. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Tuesday, April 03, 2007 2:31 PM > To: Core developer announcements > Subject: Re: [MOBY- > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > eadServices > > But when I run > > http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService > > I get all services back in about 1 second, so you must hold that info > somewhere that the registry can use it... > > > Okay, adding that information into findservice wont actually speed > things > > up, because the code will have to get that information somewhere. That > > somewhere is from lsid ... so the question is, what came first the > chicken > > or the egg ;-) > > > > Seriously though, if you want to include this info, isALive will have to > > become part of the api and be stored in the db. Otherwise, you might > save > > 1-4 seconds, and still wait 6 seconds per service. > > > > 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: Tuesday, April 03, 2007 12:34 PM > >> To: Core developer announcements > >> Subject: Re: [MOBY- > >> > dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD > >> eadServices > >> > >> On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas > > >> wrote: > >> > >> > >>> Hey, that takes into account the whole LSID resolution protocol! > >>> > >> Sure, but that's what I mean! If Paul is discovering 100 services, at > 10 > >> seconds per service, his users are going to delete Seahawk from their > >> hard-drives faster than they even get their first pop-up menu! > >> > >> I'm not laying blame, I'm just pointing out that we have to either make > >> the LSID stuff run a whole lot faster (like 100X), or we have to > abandon > >> it for the time being because it really isn't helping... (and you know > >> that I *love* LSIDs!) > >> > >> M > >> > >> _______________________________________________ > >> 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 > > > > !DSPAM:60005,4612ac4a210862854622468! > > > > > > > > > > _______________________________________________ > 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 Apr 3 21:37:09 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 03 Apr 2007 15:37:09 -0600 Subject: [MOBY-dev] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getDeadServices In-Reply-To: <008501c77637$97a52590$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook> Message-ID: <4612C905.4030207@ucalgary.ca> So if we want a findService request to be able to report only alive services (the simplest solution, which is backward compatible), you'd need to regularly dump validateService's table into MobyCentral's SQL DB, right? Is that hard? For the moment, I'll use ValidateService's output in jMOBY, but I think it'd be nice to have such functionality as part of the official API in the long run... > Currently, it's held in memory. > > So if the registry wanted it, it would have to call the url. But since the > url isn't in the api, it might be unwise to do so. > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- >> bounces at lists.open-bio.org] On Behalf Of Paul Gordon >> Sent: Tuesday, April 03, 2007 2:31 PM >> To: Core developer announcements >> Subject: Re: [MOBY- >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> eadServices >> >> But when I run >> >> http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService >> >> I get all services back in about 1 second, so you must hold that info >> somewhere that the registry can use it... >> >> >>> Okay, adding that information into findservice wont actually speed >>> >> things >> >>> up, because the code will have to get that information somewhere. That >>> somewhere is from lsid ... so the question is, what came first the >>> >> chicken >> >>> or the egg ;-) >>> >>> Seriously though, if you want to include this info, isALive will have to >>> become part of the api and be stored in the db. Otherwise, you might >>> >> save >> >>> 1-4 seconds, and still wait 6 seconds per service. >>> >>> 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: Tuesday, April 03, 2007 12:34 PM >>>> To: Core developer announcements >>>> Subject: Re: [MOBY- >>>> >>>> >> dev]http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?getD >> >>>> eadServices >>>> >>>> On Tue, 03 Apr 2007 12:30:47 -0700, Edward Kawas >>>> >> >> >>>> wrote: >>>> >>>> >>>> >>>>> Hey, that takes into account the whole LSID resolution protocol! >>>>> >>>>> >>>> Sure, but that's what I mean! If Paul is discovering 100 services, at >>>> >> 10 >> >>>> seconds per service, his users are going to delete Seahawk from their >>>> hard-drives faster than they even get their first pop-up menu! >>>> >>>> I'm not laying blame, I'm just pointing out that we have to either make >>>> the LSID stuff run a whole lot faster (like 100X), or we have to >>>> >> abandon >> >>>> it for the time being because it really isn't helping... (and you know >>>> that I *love* LSIDs!) >>>> >>>> M >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> 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 > > !DSPAM:60005,4612c6cf21086226241440! > > > > From gcomesana at cnio.es Wed Apr 4 13:16:40 2007 From: gcomesana at cnio.es (=?ISO-8859-1?Q?=22Guillermo_Comesa=C3=B1a=2E=22?=) Date: Wed, 04 Apr 2007 15:16:40 +0200 Subject: [MOBY-dev] mysterous error In-Reply-To: <4612C905.4030207@ucalgary.ca> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook> <4612C905.4030207@ucalgary.ca> Message-ID: <4613A538.5080104@cnio.es> Hi everybody and sorry about interrupting your arguments, but i get this error: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [ns1:hostname: null] Fault string: java.lang.reflect.InvocationTargetException Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException Fault actor: null When calling: http://ubio.cnio.es:8080/axis/services/MyLogReport {http://biomoby.org/}myLogReport =========== at org.biomoby.client.BaseClient.callBiomobyService(BaseClient.java:190) at org.biomoby.client.BaseClient.callRemoteService(BaseClient.java:255) at org.biomoby.client.BaseCmdLineClient.callRemoteService(BaseCmdLineClient.java:636) at org.biomoby.client.BaseClient.process(BaseClient.java:121) at org.biomoby.client.BaseCmdLineClient.doEverything(BaseCmdLineClient.java:337) at org.biomoby.client.BaseCmdLineClient.main(BaseCmdLineClient.java:740) Caused by: org.tulsoft.shared.GException: ===ERROR=== Fault details: [ns1:hostname: null] Fault string: java.lang.reflect.InvocationTargetException Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException Fault actor: null When calling: http://ubio.cnio.es:8080/axis/services/MyLogReport {http://biomoby.org/}myLogReport =========== at org.tulsoft.tools.soap.axis.AxisCall.doCall(AxisCall.java:164) at org.tulsoft.tools.soap.axis.AxisCall.doCall(AxisCall.java:179) at org.biomoby.client.BaseClient.callBiomobyService(BaseClient.java:185) ... 5 more =========== and i dont know how can i extract information from it. has anybody any suggestion about the source of this error? i mean, has somebody had any error like that one? cheers in advance **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From edward.kawas at gmail.com Wed Apr 4 13:47:58 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 4 Apr 2007 06:47:58 -0700 Subject: [MOBY-dev] mysterous error In-Reply-To: <4613A538.5080104@cnio.es> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook><4612C905.4030207@ucalgary.ca> <4613A538.5080104@cnio.es> Message-ID: <001e01c776bf$db4f58f0$6800a8c0@notebook> What happens when you open http://ubio.cnio.es:8080/axis/services/MyLogReport in a browser? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of "Guillermo Comesa??a." > Sent: Wednesday, April 04, 2007 6:17 AM > To: Core developer announcements > Subject: [MOBY-dev] mysterous error > > Hi everybody and sorry about interrupting your arguments, but i get this > error: > ===ERROR=== > org.biomoby.shared.MobyException: ===ERROR=== > Fault details: > [ns1:hostname: null] > Fault string: java.lang.reflect.InvocationTargetException > Fault code: > {http://schemas.xmlsoap.org/soap/envelope/}Server.userException > Fault actor: null > When calling: > http://ubio.cnio.es:8080/axis/services/MyLogReport > {http://biomoby.org/}myLogReport > =========== > > at > org.biomoby.client.BaseClient.callBiomobyService(BaseClient.java:190) > at > org.biomoby.client.BaseClient.callRemoteService(BaseClient.java:255) > at > org.biomoby.client.BaseCmdLineClient.callRemoteService(BaseCmdLineClient.j > ava:636) > at org.biomoby.client.BaseClient.process(BaseClient.java:121) > at > org.biomoby.client.BaseCmdLineClient.doEverything(BaseCmdLineClient.java:3 > 37) > at > org.biomoby.client.BaseCmdLineClient.main(BaseCmdLineClient.java:740) > Caused by: org.tulsoft.shared.GException: ===ERROR=== > Fault details: > [ns1:hostname: null] > Fault string: java.lang.reflect.InvocationTargetException > Fault code: > {http://schemas.xmlsoap.org/soap/envelope/}Server.userException > Fault actor: null > When calling: > http://ubio.cnio.es:8080/axis/services/MyLogReport > {http://biomoby.org/}myLogReport > =========== > > at org.tulsoft.tools.soap.axis.AxisCall.doCall(AxisCall.java:164) > at org.tulsoft.tools.soap.axis.AxisCall.doCall(AxisCall.java:179) > at > org.biomoby.client.BaseClient.callBiomobyService(BaseClient.java:185) > ... 5 more > =========== > > and i dont know how can i extract information from it. has anybody any > suggestion about the source of this error? i mean, has somebody had any > error like that one? > > cheers in advance > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea el > destinatario. Si usted recibe por error este correo, se ruega comunicarlo > al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments > may contain confidential and privileged information for the sole use of > the designated recipient named above. Distribution, reproduction or any > other use of this transmission by any party other than the intended > recipient is prohibited. If you are not the intended recipient please > contact the sender and delete all copies. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From gcomesana at cnio.es Wed Apr 4 13:59:28 2007 From: gcomesana at cnio.es (=?ISO-8859-1?Q?=22Guillermo_Comesa=C3=B1a=2E=22?=) Date: Wed, 04 Apr 2007 15:59:28 +0200 Subject: [MOBY-dev] mysterous error In-Reply-To: <001e01c776bf$db4f58f0$6800a8c0@notebook> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook><4612C905.4030207@ucalgary.ca> <4613A538.5080104@cnio.es> <001e01c776bf$db4f58f0$6800a8c0@notebook> Message-ID: <4613AF40.6040404@cnio.es> > What happens when you open > http://ubio.cnio.es:8080/axis/services/MyLogReport in a browser? > > Eddie That seems to work ok. Axis says there is a service in that url but it doesnt give suggestion about invocation. I think the error must be a class problem, but i think i have every necessary jar both in the CLASSPATH and in the axis/WEB-INF/lib directory... and as there is nothing in the logs, i dont know what to think... ah! and i have the same service in my local machine, with tomcat and axis as well, and it works fine. the only difference is the tomcat version, but i dont think there is a big difference between tomcat 5.0.x and tomcat 5.5.x cheers again **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From martin.senger at gmail.com Wed Apr 4 14:11:04 2007 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 4 Apr 2007 15:11:04 +0100 Subject: [MOBY-dev] mysterous error In-Reply-To: <4613A538.5080104@cnio.es> References: <006e01c77625$a0c17910$6800a8c0@notebook> <007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook> <4612C905.4030207@ucalgary.ca> <4613A538.5080104@cnio.es> Message-ID: <4d93f07c0704040711l249c29fct3c693402ff0dae08@mail.gmail.com> Whenever you are desperate and cannot locate an error, start it via tcpmon and see what is going "on the wire". (Or show us the raw XML messages coming out and back from your client to your tomcat.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Wed Apr 4 15:52:23 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 4 Apr 2007 08:52:23 -0700 Subject: [MOBY-dev] mysterous error In-Reply-To: <4613AF40.6040404@cnio.es> References: <46129773.5030503@ucalgary.ca> <4612A242.9040308@ucalgary.ca><005201c77621$4d866480$6800a8c0@notebook><4612A3B5.3010506@ucalgary.ca><005301c77622$637a6600$6800a8c0@notebook><006e01c77625$a0c17910$6800a8c0@notebook><007701c77626$94c56df0$6800a8c0@notebook> <007901c77627$ca0de9a0$6800a8c0@notebook> <4612C78C.7090501@ucalgary.ca> <008501c77637$97a52590$6800a8c0@notebook><4612C905.4030207@ucalgary.ca><4613A538.5080104@cnio.es><001e01c776bf$db4f58f0$6800a8c0@notebook> <4613AF40.6040404@cnio.es> Message-ID: <003801c776d1$3ced5e20$6800a8c0@notebook> I would then try what Martin suggested, look at what is sent over the wire. He suggested you use TCPMON, being on windows, I use tcptrace. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of "Guillermo Comesa??a." > Sent: Wednesday, April 04, 2007 6:59 AM > To: moby-dev at lists.open-bio.org > Subject: Re: [MOBY-dev] mysterous error > > > What happens when you open > > http://ubio.cnio.es:8080/axis/services/MyLogReport in a browser? > > > > Eddie > That seems to work ok. Axis says there is a service in that url but it > doesnt give suggestion about invocation. I think the error must be a > class problem, but i think i have every necessary jar both in the > CLASSPATH and in the axis/WEB-INF/lib directory... and as there is > nothing in the logs, i dont know what to think... > > ah! and i have the same service in my local machine, with tomcat and > axis as well, and it works fine. the only difference is the tomcat > version, but i dont think there is a big difference between tomcat 5.0.x > and tomcat 5.5.x > > cheers again > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea el > destinatario. Si usted recibe por error este correo, se ruega comunicarlo > al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments > may contain confidential and privileged information for the sole use of > the designated recipient named above. Distribution, reproduction or any > other use of this transmission by any party other than the intended > recipient is prohibited. If you are not the intended recipient please > contact the sender and delete all copies. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ivanp at mmb.pcb.ub.es Wed Apr 4 18:13:43 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Wed, 04 Apr 2007 20:13:43 +0200 Subject: [MOBY-dev] MobyDateTime.FULL_FORMAT problem in jMoby Message-ID: <4613EAD7.7040500@mmb.pcb.ub.es> Hi, As long as I understand, the static constant attribute in class MobyDateTime.FULL_FORMAT should be used to construct the SimpleDateFormat to use it to format dates. Something like this: ... import java.text.SimpleDateFormat; import java.util.Date; ... Date now = new Date(); SimpleDateFormat sdf = new SimpleDateFormat(MobyDateTime.FULL_FORMAT); sdf.format( now ); ... But this produces an exception when trying to build the SimpleDateFormat. I've inspected the content of the constant and it is like this: "yyyy-MM-dd\'T\'HH:mm:ss\'Z\'Z" Instead of it I used the following (I know I'm losing some precision) and it worked: "yyyy-MM-dd'T'HH:mm:ss" Cheers, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From ivanp at mmb.pcb.ub.es Thu Apr 5 10:44:50 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 12:44:50 +0200 Subject: [MOBY-dev] Dashboard "confuses" services Message-ID: <4614D322.200@mmb.pcb.ub.es> Hi, In our registry we have several services with the same name (but different authorities) and I have the impression that when I try to call the different ones from "Simple Client" panel in Dashboard, it always tries to use the same service. Regards, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From martin.senger at gmail.com Thu Apr 5 10:53:06 2007 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 5 Apr 2007 11:53:06 +0100 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4614D322.200@mmb.pcb.ub.es> References: <4614D322.200@mmb.pcb.ub.es> Message-ID: <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> > In our registry we have several services with the same name (but > different authorities) and I have the impression that when I try to call > the different ones from "Simple Client" panel in Dashboard, it always > tries to use the same service. That would definitely be a bug. I will look at it. [ Do I have access to your registry? Don't worry if not, I can simulate the situation elsewhere...] Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From ivanp at mmb.pcb.ub.es Thu Apr 5 13:26:49 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 15:26:49 +0200 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> References: <4614D322.200@mmb.pcb.ub.es> <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> Message-ID: <4614F919.3040904@mmb.pcb.ub.es> You have access: http://moby-dev.inab.org/cgi-bin/MOBY-Central.pl http://moby-dev.inab.org/MOBY/Central Iv?n Martin Senger wrote: >>In our registry we have several services with the same name (but >>different authorities) and I have the impression that when I try to call >>the different ones from "Simple Client" panel in Dashboard, it always >>tries to use the same service. >> >> > > >That would definitely be a bug. I will look at it. [ Do I have access to >your registry? Don't worry if not, I can simulate the situation >elsewhere...] > >Martin > > > From ivanp at mmb.pcb.ub.es Thu Apr 5 13:30:24 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 15:30:24 +0200 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> References: <4614D322.200@mmb.pcb.ub.es> <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> Message-ID: <4614F9F0.8000702@mmb.pcb.ub.es> By the way, the service I was trying is called "getStatisticalLog" Cheers, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> In our registry we have several services with the same name (but >> different authorities) and I have the impression that when I try to call >> the different ones from "Simple Client" panel in Dashboard, it always >> tries to use the same service. >> > > > That would definitely be a bug. I will look at it. [ Do I have access to > your registry? Don't worry if not, I can simulate the situation > elsewhere...] > > Martin > > From ivanp at mmb.pcb.ub.es Thu Apr 5 13:43:05 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 15:43:05 +0200 Subject: [MOBY-dev] Dashboard and date types Message-ID: <4614FCE8.70904@mmb.pcb.ub.es> Hi, Dashboard detects when an article name corresponds to a data type and then calls the modal window "Date-Time Chooser" which is great but it seems to me that it doesn't generate ISO 8601 compliant date/times as it should. This is an example of date/time generated: 2007-04-05T15:28:58Z+0200 If I understand well the standard (http://www.w3.org/TR/NOTE-datetime): /"...This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. A standard referencing this profile should permit one or both of these ways of handling time zone offsets..." /- if "Z" is present, this means that we are at UTC time zone and then there shouldn't be anything else after the "Z" - if "Z" is no present, then time zone can be specified as positive/negative offset with respect UTC Some examples (extracted from the previous reference): 1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 1994-11-05T13:15:30Z corresponds to the same instant. I suppose that Dashboard should be corrected to produce date/time ISO 8601 compliant dates and some mechanism to determine the time zone where the client is being executed should be introduced. Please, let me know if I'm wrong. Cheers, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From ivanp at mmb.pcb.ub.es Thu Apr 5 13:58:53 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 15:58:53 +0200 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> References: <4614D322.200@mmb.pcb.ub.es> <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> Message-ID: <4615009D.6050304@mmb.pcb.ub.es> I think it only happens when the option: "Ask registry where service is, and call it" is selected. With the option "Use service's usual endpoint", seems to work properly. Cheers, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> In our registry we have several services with the same name (but >> different authorities) and I have the impression that when I try to call >> the different ones from "Simple Client" panel in Dashboard, it always >> tries to use the same service. >> > > > That would definitely be a bug. I will look at it. [ Do I have access to > your registry? Don't worry if not, I can simulate the situation > elsewhere...] > > Martin > > From martin.senger at gmail.com Thu Apr 5 14:27:51 2007 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 5 Apr 2007 15:27:51 +0100 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4615009D.6050304@mmb.pcb.ub.es> References: <4614D322.200@mmb.pcb.ub.es> <4d93f07c0704050353t74af5f4em6c34e3a78415512d@mail.gmail.com> <4615009D.6050304@mmb.pcb.ub.es> Message-ID: <4d93f07c0704050727p356b06ewe04a6ddd01279e58@mail.gmail.com> > I think it only happens when the option: "Ask registry where service is, > and call it" is selected. With the option "Use service's usual > endpoint", seems to work properly. Okay, it helps. Looking into it (well, not now, but very soon). Well, not soon, rather now: I have found the culprit (it was quite easy after your comments above). The line (in ServiceCallerModel.java): MobyService clonedService = new MobyService (selService.getName()); must be replaced by line MobyService clonedService = new MobyService (selService.getName(), selService.getAuthority()); which I just did and committed. But I have not tested it (SoftGod forgive me!) - could you test it perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From ivanp at mmb.pcb.ub.es Thu Apr 5 14:41:34 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Thu, 05 Apr 2007 16:41:34 +0200 Subject: [MOBY-dev] Dashboard "confuses" services In-Reply-To: <4d93f07c0704050727p356b06ewe04a6ddd01279e58@mail.gmail.com> References: <4614D322.200@mmb.pcb.ub.es><4d93f07c0704050353t74af5f4em6c34e3a 78415512d@mail.gmail.com><4615009D.6050304@mmb.pcb.ub.es> <4d93f07c0704050727p356b06ewe04a6ddd01279e58@mail.gmail.com> Message-ID: <46150A9E.40609@mmb.pcb.ub.es> It worked! Thanks, Iv?n ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> I think it only happens when the option: "Ask registry where service is, >> and call it" is selected. With the option "Use service's usual >> endpoint", seems to work properly. >> > > > Okay, it helps. Looking into it (well, not now, but very soon). > > Well, not soon, rather now: I have found the culprit (it was quite easy > after your comments above). The line (in ServiceCallerModel.java): > > MobyService clonedService = new MobyService (selService.getName()); > > must be replaced by line > > MobyService clonedService = new MobyService (selService.getName(), > selService.getAuthority()); > > which I just did and committed. But I have not tested it (SoftGod forgive > me!) - could you test it perhaps? > > Thanks, > Martin > > > From duncan.hull at cs.man.ac.uk Wed Apr 11 10:13:43 2007 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Wed, 11 Apr 2007 11:13:43 +0100 Subject: [MOBY-dev] BioMoby at Nature Network Message-ID: <461CB4D7.9050902@cs.man.ac.uk> Hello BioMOBYers You may have already come across http://network.nature.com/about which is a bit like mySpace for Scientists. Its early days at the moment and it remains to be seen how successful this is, but just in case it takes off, I created a BioMOBY group... http://network.nature.com/group/biomoby please join in if you're interested... Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From Pieter.Neerincx at wur.nl Thu Apr 12 14:40:16 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 12 Apr 2007 16:40:16 +0200 Subject: [MOBY-dev] revised manuscript now in CVS In-Reply-To: References: Message-ID: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> Hi Mark, I'm impressed! A very nice manuscript overall and a pleasure to read. Just a few minor comments, most of them spelling issues: * Authors (page 1): please add 'nc' to my last name. Neerix -> Neerincx. Otherwise it sounds like I'm a character from an Asterix and Obelix cartoon :). * BioMoby Web Services ? ?What resources are out there to do it??, second paragraph (page 7): add 'is' ...and the BioMoby API ensures that an ontology term that *is* in- use by any registered service ... * The BioMoby Central Registry ? ?How do I find the resource provider I want??, first paragraph (page 9): remove redundant spaces ...towards its leaf nodes. * *Similarly, and perhaps more ... * BioMoby vs. peer semantic and schema technologies, first paragraph (page 13): add 'm' in systes ...and made many adaptations to these standards in response to perceived limitations and/or complexities in these syste*m*s * Discussion, Closed world, second paragraph (page 10): ..."While showing exciting early success in achieving interoperability between a small number of participating providers, it remains to be seen, as the project expands, if the complexity of reasoning over an open-world system, and/or the potential dilution of compatibility between resources due to the increasing number of ontological possibilities, will interfere with the desired end-point of straight-forward, maximal interoperability between bioinformatics Web resources." That was an extremely long sentence. With five commas and spanning 7 lines it starts to resemble a workflow :). It would be better to shorten it for the sake of readability. Just my 0,02?. Cheers, Pi On 27-Mar-2007, at 11:39 PM, Mark Wilkinson wrote: > Thanks to all who read and commented on the Moby 1.0 manuscript so > quickly! > > I've made the first set of suggested revisions, and the new > manuscript is > uploaded (version 7)to the CVS in the /Docs folder. > > Since we can't track changes using the binary PDF format, perhaps send > your suggestions/edits to the mailing list so that everyone can see > them > and comment on them. > > Cheers! > > Mark > _______________________________________________ > 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 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From gordonp at ucalgary.ca Thu Apr 12 15:08:57 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 12 Apr 2007 09:08:57 -0600 Subject: [MOBY-dev] revised manuscript now in CVS In-Reply-To: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> References: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> Message-ID: <461E4B89.7000606@ucalgary.ca> I believe you mean a wordflow :-D > That was an extremely long sentence. With five commas and spanning > 7 lines it starts to resemble a workflow :). From Pieter.Neerincx at wur.nl Thu Apr 12 15:26:22 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 12 Apr 2007 17:26:22 +0200 Subject: [MOBY-dev] Valid boolean values for primitives and secondary parmeters In-Reply-To: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> References: <4B17EA1B-A5DC-4175-BF81-573CF997789A@wur.nl> Message-ID: <1110FAE7-868A-4A64-99A8-4190B3F482E7@wur.nl> Hi all, Yesterday I was fiddling with some registration scripts and wondering what are valid values for boolean primary articles a.k.a. primitives and for boolean secondaries? After Googeling and browsing the mailinglist archive I noticed to subject poped up before, but I couldn't figure out what the consensus is... Furthermore I can not find this subject back in the MOBY Services API documentation at http://biomoby.open-bio.org/CVS_CONTENT/ moby-live/Docs/MOBY-S_API/index_API.html Can somebody please enlighten me on the current status, so I can add this to the docs... Cheers, Pi From markw at illuminae.com Thu Apr 12 18:23:01 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 12 Apr 2007 11:23:01 -0700 Subject: [MOBY-dev] Version 11 of the manuscript in the CVS Message-ID: Hi all, I've added everyones changes to the manuscript - version 11 is now in the moby-live/Docs folder of the CVS. This should be the final version, unless there are any objections. Please check teh "authorship" list and tell me ASAP if you think anyone else should be on there. Cheers all! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From ivanp at mmb.pcb.ub.es Wed Apr 18 15:22:22 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Wed, 18 Apr 2007 17:22:22 +0200 Subject: [MOBY-dev] an easy way to see the input/output size when using jMoby? Message-ID: <462637AE.6080303@mmb.pcb.ub.es> Hi, I'd like to register the input size of the requests to my moby services (and the same for results) when I'm using jMoby. At the moment I have a provisional work-around but I was wondering if there is a nice way to do it with the jMoby classes. I don't need byte precission (it's not important for me to register the size of all the SOAP stuff, for example); I need a correlated measurement with the input/output (for example the size of the input/output objects in XML ir right). Thanks, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From edward.kawas at gmail.com Wed Apr 18 15:51:26 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 18 Apr 2007 08:51:26 -0700 Subject: [MOBY-dev] an easy way to see the input/output size when usingjMoby? In-Reply-To: <462637AE.6080303@mmb.pcb.ub.es> References: <462637AE.6080303@mmb.pcb.ub.es> Message-ID: <000901c781d1$6c61b880$6800a8c0@notebook> Hi Ivan, I don?t really understand the problem. Do you think that you could give a concrete example or provide further information? 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 Iv?n P?rraga Garc?a > Sent: Wednesday, April 18, 2007 8:22 AM > To: Core developer announcements > Subject: [MOBY-dev] an easy way to see the input/output size when > usingjMoby? > > Hi, > > I'd like to register the input size of the requests to my moby services > (and the same for results) when I'm using jMoby. At the moment I have a > provisional work-around but I was wondering if there is a nice way to do > it with the jMoby classes. > > I don't need byte precission (it's not important for me to register the > size of all the SOAP stuff, for example); I need a correlated > measurement with the input/output (for example the size of the > input/output objects in XML ir right). > > Thanks, > > -- > ------------------------------------------------ > Iv?n P?rraga Garc?a > Computer Scientist > Molecular Modelling & Bioinformatics Unit > INB - Instituto Nacional de Bioinform?tica > Josep Samitier 1-5 > 08028 Barcelona > Spain > tel.: +34 93 403 71 55 > fax.: +34 93 403 71 57 > e-mail: ivanp at mmb.pcb.ub.es > group page: http://mmb.pcb.ub.es > pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > ------------------------------------------------ > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ivanp at mmb.pcb.ub.es Wed Apr 18 16:11:27 2007 From: ivanp at mmb.pcb.ub.es (=?UTF-8?B?SXbDoW4gUMOhcnJhZ2EgR2FyY8OtYQ==?=) Date: Wed, 18 Apr 2007 18:11:27 +0200 Subject: [MOBY-dev] an easy way to see the input/output size whenusingjMoby? In-Reply-To: <000901c781d1$6c61b880$6800a8c0@notebook> References: <462637AE.6080303@mmb.pcb.ub.es> <000901c781d1$6c61b880$6800a8c0@notebook> Message-ID: <4626432F.5030109@mmb.pcb.ub.es> I'll try to explain better... We're registering info for statistical purposes. Things like time of execution, status at the end, timestamps, etc. One thing that we want to store is how big are the moby input objects (in the service call request) and the same for the response. For example, if one service is taking a Fasta as input, I want to know how many bytes big is this Fasta. I don't mind measuring the "exact" size of the input, I want to retrieve an unit that is proportional to the input size; in other words the number of characters of the XML moby request corresponding to this Fasta object is a good measurement, but it would be also a good measurement the real size in bytes... I want a measurement good enough to decide if two different calls have different input/ouput sizes and in what proportion. However, the best would be to have a realistic size in bytes but it's not a real need. In fact, now I'm doing something similiar to this: MobyJob request... MobyJob response... request.format(0).length(); response.format(0).length(); The main problem of this is that I'm introducing an unnecessary overhead to parse the request/response as an String (and this can be a problem for huge requests/responses). Have I explained myself better? Thanks, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Edward Kawas escribi?: > Hi Ivan, > > I don?t really understand the problem. Do you think that you could give a > concrete example or provide further information? > > 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 Iv?n P?rraga Garc?a >> Sent: Wednesday, April 18, 2007 8:22 AM >> To: Core developer announcements >> Subject: [MOBY-dev] an easy way to see the input/output size when >> usingjMoby? >> >> Hi, >> >> I'd like to register the input size of the requests to my moby services >> (and the same for results) when I'm using jMoby. At the moment I have a >> provisional work-around but I was wondering if there is a nice way to do >> it with the jMoby classes. >> >> I don't need byte precission (it's not important for me to register the >> size of all the SOAP stuff, for example); I need a correlated >> measurement with the input/output (for example the size of the >> input/output objects in XML ir right). >> >> Thanks, >> >> -- >> ------------------------------------------------ >> Iv?n P?rraga Garc?a >> Computer Scientist >> Molecular Modelling & Bioinformatics Unit >> INB - Instituto Nacional de Bioinform?tica >> Josep Samitier 1-5 >> 08028 Barcelona >> Spain >> tel.: +34 93 403 71 55 >> fax.: +34 93 403 71 57 >> e-mail: ivanp at mmb.pcb.ub.es >> group page: http://mmb.pcb.ub.es >> pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc >> ------------------------------------------------ >> >> _______________________________________________ >> 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 > From ivanp at mmb.pcb.ub.es Wed Apr 18 16:22:09 2007 From: ivanp at mmb.pcb.ub.es (=?UTF-8?B?SXbDoW4gUMOhcnJhZ2EgR2FyY8OtYQ==?=) Date: Wed, 18 Apr 2007 18:22:09 +0200 Subject: [MOBY-dev] an easy way to see the input/output sizewhenusingjMoby? In-Reply-To: <4626432F.5030109@mmb.pcb.ub.es> References: <462637AE.6080303@mmb.pcb.ub.es><000901c781d1$6c61b880$6800a8c0@ notebook> <4626432F.5030109@mmb.pcb.ub.es> Message-ID: <462645B1.70207@mmb.pcb.ub.es> Ok, I think the misunderstanding was because the use of the word "register"; I should have said something like "log" or "register statistics at our servers". It could seem that I was trying to "register" something at moby-central... I chose an ambiguous word, sorry. Regards, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Iv?n P?rraga Garc?a escribi?: > I'll try to explain better... > > We're registering info for statistical purposes. Things like time of > execution, status at the end, timestamps, etc. One thing that we want to > store is how big are the moby input objects (in the service call > request) and the same for the response. For example, if one service is > taking a Fasta as input, I want to know how many bytes big is this > Fasta. I don't mind measuring the "exact" size of the input, I want to > retrieve an unit that is proportional to the input size; in other words > the number of characters of the XML moby request corresponding to this > Fasta object is a good measurement, but it would be also a good > measurement the real size in bytes... I want a measurement good enough > to decide if two different calls have different input/ouput sizes and in > what proportion. > > However, the best would be to have a realistic size in bytes but it's > not a real need. > > In fact, now I'm doing something similiar to this: > > MobyJob request... > MobyJob response... > > request.format(0).length(); > response.format(0).length(); > > The main problem of this is that I'm introducing an unnecessary overhead > to parse the request/response as an String (and this can be a problem > for huge requests/responses). > > Have I explained myself better? > > Thanks, > > ------------------------------------------------ > Iv?n P?rraga Garc?a > Computer Scientist > Molecular Modelling & Bioinformatics Unit > INB - Instituto Nacional de Bioinform?tica > Josep Samitier 1-5 > 08028 Barcelona > Spain > tel.: +34 93 403 71 55 > fax.: +34 93 403 71 57 > e-mail: ivanp at mmb.pcb.ub.es > group page: http://mmb.pcb.ub.es > pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > ------------------------------------------------ > > > > Edward Kawas escribi?: > >> Hi Ivan, >> >> I don?t really understand the problem. Do you think that you could give a >> concrete example or provide further information? >> >> 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 Iv?n P?rraga Garc?a >>> Sent: Wednesday, April 18, 2007 8:22 AM >>> To: Core developer announcements >>> Subject: [MOBY-dev] an easy way to see the input/output size when >>> usingjMoby? >>> >>> Hi, >>> >>> I'd like to register the input size of the requests to my moby services >>> (and the same for results) when I'm using jMoby. At the moment I have a >>> provisional work-around but I was wondering if there is a nice way to do >>> it with the jMoby classes. >>> >>> I don't need byte precission (it's not important for me to register the >>> size of all the SOAP stuff, for example); I need a correlated >>> measurement with the input/output (for example the size of the >>> input/output objects in XML ir right). >>> >>> Thanks, >>> >>> -- >>> ------------------------------------------------ >>> Iv?n P?rraga Garc?a >>> Computer Scientist >>> Molecular Modelling & Bioinformatics Unit >>> INB - Instituto Nacional de Bioinform?tica >>> Josep Samitier 1-5 >>> 08028 Barcelona >>> Spain >>> tel.: +34 93 403 71 55 >>> fax.: +34 93 403 71 57 >>> e-mail: ivanp at mmb.pcb.ub.es >>> group page: http://mmb.pcb.ub.es >>> pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc >>> ------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> >> > _______________________________________________ > 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 Wed Apr 18 20:23:15 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 18 Apr 2007 13:23:15 -0700 Subject: [MOBY-dev] an easy way to see the input/outputsizewhenusingjMoby? In-Reply-To: <462645B1.70207@mmb.pcb.ub.es> References: <462637AE.6080303@mmb.pcb.ub.es><000901c781d1$6c61b880$6800a8c0@ notebook><4626432F.5030109@mmb.pcb.ub.es> <462645B1.70207@mmb.pcb.ub.es> Message-ID: <003201c781f7$65a11830$6800a8c0@notebook> Hi Ivan, Thanks for clarifying. I don?t know anything off the top of my head, but I will think about it. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Iv?n P?rraga Garc?a > Sent: Wednesday, April 18, 2007 9:22 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] an easy way to see the > input/outputsizewhenusingjMoby? > > Ok, I think the misunderstanding was because the use of the word > "register"; I should have said something like "log" or "register > statistics at our servers". It could seem that I was trying to > "register" something at moby-central... I chose an ambiguous word, sorry. > > Regards, > > ------------------------------------------------ > Iv?n P?rraga Garc?a > Computer Scientist > Molecular Modelling & Bioinformatics Unit > INB - Instituto Nacional de Bioinform?tica > Josep Samitier 1-5 > 08028 Barcelona > Spain > tel.: +34 93 403 71 55 > fax.: +34 93 403 71 57 > e-mail: ivanp at mmb.pcb.ub.es > group page: http://mmb.pcb.ub.es > pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > ------------------------------------------------ > > > > Iv?n P?rraga Garc?a escribi?: > > I'll try to explain better... > > > > We're registering info for statistical purposes. Things like time of > > execution, status at the end, timestamps, etc. One thing that we want to > > store is how big are the moby input objects (in the service call > > request) and the same for the response. For example, if one service is > > taking a Fasta as input, I want to know how many bytes big is this > > Fasta. I don't mind measuring the "exact" size of the input, I want to > > retrieve an unit that is proportional to the input size; in other words > > the number of characters of the XML moby request corresponding to this > > Fasta object is a good measurement, but it would be also a good > > measurement the real size in bytes... I want a measurement good enough > > to decide if two different calls have different input/ouput sizes and in > > what proportion. > > > > However, the best would be to have a realistic size in bytes but it's > > not a real need. > > > > In fact, now I'm doing something similiar to this: > > > > MobyJob request... > > MobyJob response... > > > > request.format(0).length(); > > response.format(0).length(); > > > > The main problem of this is that I'm introducing an unnecessary overhead > > to parse the request/response as an String (and this can be a problem > > for huge requests/responses). > > > > Have I explained myself better? > > > > Thanks, > > > > ------------------------------------------------ > > Iv?n P?rraga Garc?a > > Computer Scientist > > Molecular Modelling & Bioinformatics Unit > > INB - Instituto Nacional de Bioinform?tica > > Josep Samitier 1-5 > > 08028 Barcelona > > Spain > > tel.: +34 93 403 71 55 > > fax.: +34 93 403 71 57 > > e-mail: ivanp at mmb.pcb.ub.es > > group page: http://mmb.pcb.ub.es > > pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > > ------------------------------------------------ > > > > > > > > Edward Kawas escribi?: > > > >> Hi Ivan, > >> > >> I don?t really understand the problem. Do you think that you could give > a > >> concrete example or provide further information? > >> > >> 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 Iv?n P?rraga Garc?a > >>> Sent: Wednesday, April 18, 2007 8:22 AM > >>> To: Core developer announcements > >>> Subject: [MOBY-dev] an easy way to see the input/output size when > >>> usingjMoby? > >>> > >>> Hi, > >>> > >>> I'd like to register the input size of the requests to my moby > services > >>> (and the same for results) when I'm using jMoby. At the moment I have > a > >>> provisional work-around but I was wondering if there is a nice way to > do > >>> it with the jMoby classes. > >>> > >>> I don't need byte precission (it's not important for me to register > the > >>> size of all the SOAP stuff, for example); I need a correlated > >>> measurement with the input/output (for example the size of the > >>> input/output objects in XML ir right). > >>> > >>> Thanks, > >>> > >>> -- > >>> ------------------------------------------------ > >>> Iv?n P?rraga Garc?a > >>> Computer Scientist > >>> Molecular Modelling & Bioinformatics Unit > >>> INB - Instituto Nacional de Bioinform?tica > >>> Josep Samitier 1-5 > >>> 08028 Barcelona > >>> Spain > >>> tel.: +34 93 403 71 55 > >>> fax.: +34 93 403 71 57 > >>> e-mail: ivanp at mmb.pcb.ub.es > >>> group page: http://mmb.pcb.ub.es > >>> pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc > >>> ------------------------------------------------ > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > > _______________________________________________ > > 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 From markw at illuminae.com Fri Apr 20 23:51:44 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 20 Apr 2007 16:51:44 -0700 Subject: [MOBY-dev] Fingers crossed! Message-ID: I just submitted the 1.0 manuscript to PLoS. fingers crossed everyone! M From dmitry.repchevski at bsc.es Mon Apr 23 10:40:18 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 23 Apr 2007 12:40:18 +0200 Subject: [MOBY-dev] soap encoding Message-ID: <462C8D12.9090606@bsc.es> Hello, My name is Dmitry and I was contracted by INB (Spain) to work on web services (JMoby). Reading some papers from JMoby I have implemented some services using MoSeS and by now have a jboss 4.03sp1 working. The problem is that JMoby uses "soap encoding" (section 5) while this encoding is considered obsolete and unfortunately no any modern java application servers support it. Actually JBoss dropped support starting from 4.04 when they passed to JEE5 compatible web services stack (jax-ws compatible). The java skeleton generated by MoSeS generates the service endpoint method passing an Object to it (while according moby wsdl it should be a string). There is no problem to change the Object to String (this is the only change needed) to generate equal wsdl (otherwise wsdl generated by wsdp contains "xsd:anyType" that is incompatible with web services WS-I specification). Even more this change would permit to generate the web service with "rpc-literal" encoding. We have tested generated web-service with both types of clients - "soap-encoding" and "rpc-literal" encoding on both platforms (java & perl). It works well. The idea is to make (at least java, not sure for perl) webservices that supports both encoding thinking that in a future we could migrate also clients (actually the only thing needed is to recompile it with new generated wsdl. This would permit us to move to JBoss5 or any JEE compatible server in a future. Here I attach some example of wsdl generated with and without "literal" note: the soap-encoding version actually is not that one generated from MoSeS interface, because MoSeS generates "Object" that translates to "xsd:anyType" ***************************************************** ***************************************************** ***************************************************** ***************************************************** Yours Sincerely, Dmitry, From martin.senger at gmail.com Mon Apr 23 12:58:13 2007 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 23 Apr 2007 14:58:13 +0200 Subject: [MOBY-dev] soap encoding In-Reply-To: <462C8D12.9090606@bsc.es> References: <462C8D12.9090606@bsc.es> Message-ID: <4d93f07c0704230558q50989ac3q9e40f1f4263686e8@mail.gmail.com> Hi, The problem is that JMoby uses "soap encoding" (section 5) while this > encoding is considered obsolete and unfortunately no any modern java > application servers support it. I think (please correct me if I am wrong) that jMoby implements what BioMOBY API (specification) asks for. jMoby is tied by this spec. We cannot suddenly switch to a different protocol without breaking existing software, can we? The java skeleton generated by MoSeS generates the service endpoint > method passing an Object to it (while according moby wsdl it should be a > string). Java skeleton does what BioMOBY spec dictates. If you take it, however, and try to use it for generating a WSDL, it is you are doing things that the skeleton was designed for. The BioMOBY spec has its own API call to get WSDL for each service (and which, from various reasons, cannot give you the full WSDL, anyway). Please let me know if I am interpreted your comment wrongly, or if I am missing something. There is no problem to change the Object to String But the point is to have a skeleton that deals with Java objects, not with MOBY data types. But perhaps give me an example of service you have in mind. Probably (I guess) that you are barking on the wrong tree because you are using the skeleton for generating wsdl. The idea is to make (at least java, not sure for perl) webservices that > supports both encoding That's fine with me and I agree with this vision. But it requires to change BioMOBY API. Ask for it the community. When we agree on it, I will make changes in MoSeS to support it. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From dmitry.repchevski at bsc.es Mon Apr 23 17:45:15 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 23 Apr 2007 19:45:15 +0200 Subject: [MOBY-dev] soap encoding Message-ID: <462CF0AB.5050705@bsc.es> Hello Martin, >I think (please correct me if I am wrong) that jMoby implements what BioMOBY >API (specification) asks for. jMoby is tied by this spec. We cannot >suddenly switch to a different protocol without breaking existing software, >can we? Well I am new to jMoby as well as BioMoby, so what is the specification you talk about? Could you please give me a link? >Java skeleton does what BioMOBY spec dictates. If you take it, however, and >try to use it for generating a WSDL, it is you are doing things that the >skeleton was designed for. The BioMOBY spec has its own API call to get WSDL >for each service (and which, from various reasons, cannot give you the full >WSDL, anyway). Please let me know if I am interpreted your comment wrongly, >or if I am missing something. Well you got the point. Actually I use the generated skeleton to generate my end point, not the wsdl from BioMoby. What I'm talking is that the generated skeleton is not strictly compatible with BioMoby wsdl. The WSDL I'm getting through BioMoby expects that end point accepts xsd:string, but the skeleton accepts an Object. I am not talking here about the ontology. Actually BioMoby do not use web services architecture (correct me if I'm wrong), but rather just sends a plain xml file that you have to parse later to get the parameters. So the web service is always the same - 1 parameter (xsd:string) in, another out. Using java.lang.Object in an endpoint is against of WS-I specification. So by now my request is just to change the endpoint generated by MoSeS to accept the String according both (WS-I and BioMoby). Such a thing makes both WSDL (from BioMoby and generated from endpoint) 100% equal. >There is no problem to change the Object to String :-) >But the point is to have a skeleton that deals with Java objects, not with >MOBY data types. But perhaps give me an example of service you have in mind. **************************************************************************************************************** abstract public class runEmbossAntigenicFromSequenceSkel extends BaseService { /************************************************************************** * Default constructor. *************************************************************************/ public runEmbossAntigenicFromSequenceSkel() { super(); } /************************************************************************** * The main method (available as a Web Service).

*************************************************************************/ public String runEmbossAntigenicFromSequence (String data) { // Just change Object -> String MobyPackage mobyOutput = null; try { // reading the whole input MobyPackage mobyInput = MobyPackage.createFromXML (data, "AminoAcidSequence"); **************************************************************************************************************** so in wsdl we will get **************************************************************************************************************** **************************************************************************************************************** EXACTLY AS IS FROM WSDL THAT I GET FROM MOBY!!! >Probably (I guess) that you are barking on the wrong tree because you are >using the skeleton for generating wsdl. Well, if they done well they MUST be compatible. I use netbeans 5.5.1 that allows me to generate all the things from my endpoint and generates WAR file for me, so I do not have to use an ant script. It takes me 2 seconds to change the service, deploy it to jboss and even debug it on another machine. Another way could be to generate an endpoint from moby's wsdl, but in this case I have to parse the string (xml) by myself and I still didn't went so deep. >That's fine with me and I agree with this vision. But it requires to change >BioMOBY API. Ask for it the community. When we agree on it, I will make >changes in MoSeS to support it. Well if we are talking about changing an Object to String - no any another changes needed. My NEXT point was that (at least in JBoss < 4.04) the generated service supports both encodings "soap encoding" and "rpc-literar". As you pointed it's up to the community to move forward out the obsolete encoding... ;-) Regards, Dmitry From groscurt at mpiz-koeln.mpg.de Wed Apr 25 13:06:23 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Wed, 25 Apr 2007 15:06:23 +0200 Subject: [MOBY-dev] How to change a service with a signatureURL via the dashboard Message-ID: <200704251506.23696.groscurt@mpiz-koeln.mpg.de> Hi everyone, the following situation: I have a service which I register with an signatureURL at a repository. Now I want to change the service and update it in the registry. The procedure I know is to unregister the service and then to register it again. If I'm using a signatureURL I cant unregister the service... so is there a way to update the service via the dashboard or do I have to go the long way to delete the rdf, waiting for the agent to unregister my service, then register it again and putting up the rdf ? Thanks andreas From edward.kawas at gmail.com Wed Apr 25 13:39:20 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 25 Apr 2007 06:39:20 -0700 Subject: [MOBY-dev] How to change a service with a signatureURL via thedashboard In-Reply-To: <200704251506.23696.groscurt@mpiz-koeln.mpg.de> References: <200704251506.23696.groscurt@mpiz-koeln.mpg.de> Message-ID: <003501c7873f$218c9820$6800a8c0@notebook> Hi Andreas, You can either modify the RDF and the agent will pick up the changes, or you can remove the document and the agent will remove all services in that document. You don't have to wait for the agent to visit you; you can make the agent visit you by performing a registerservice call with only the signatureURL filled in or if you use dashboard, by using the bottom that says 'Call agent' (or something like that ...). Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev- > bounces at lists.open-bio.org] On Behalf Of Andreas Groscurth > Sent: Wednesday, April 25, 2007 6:06 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] How to change a service with a signatureURL via > thedashboard > > Hi everyone, > > the following situation: > > I have a service which I register with an signatureURL at a repository. > Now I want to change the service and update it in the registry. The > procedure > I know is to unregister the service and then to register it again. > If I'm using a signatureURL I cant unregister the service... > > so is there a way to update the service via the dashboard or do I have to > go > the long way to delete the rdf, waiting for the agent to unregister my > service, then register it again and putting up the rdf ? > > Thanks > andreas > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From groscurt at mpiz-koeln.mpg.de Wed Apr 25 14:04:26 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Wed, 25 Apr 2007 16:04:26 +0200 Subject: [MOBY-dev] RDF creation at the Test central Message-ID: <200704251604.26713.groscurt@mpiz-koeln.mpg.de> Hi, we encountered something and dont know if this is on purpose or a bug. If we register a service at a local repository with "Use RDF Signature" enabled the service is registered and the RDF is created (register time takes about 2min). If we register the same service at the Moby TestCentral the service is registered, but no RDF is created (register time takes seconds). Is this intended that on the test central no RDF creation is happening ? Thanks -- Andreas Groscurth Diplom Bioinformatik - PhD Student Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-447 From markw at illuminae.com Wed Apr 25 16:51:55 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 25 Apr 2007 09:51:55 -0700 Subject: [MOBY-dev] RDF creation at the Test central In-Reply-To: <200704251604.26713.groscurt@mpiz-koeln.mpg.de> References: <200704251604.26713.groscurt@mpiz-koeln.mpg.de> Message-ID: Probably the code for TestCentral is out-of-sync. I'll try to update it today. I also suspect that there is no agent system running on TestCentral, since it wasn't intended to be a registry that needs to be updated, but I'll ask Eddie to deploy it there too. M On Wed, 25 Apr 2007 07:04:26 -0700, Andreas Groscurth wrote: > Hi, > > we encountered something and dont know if this is on purpose or a bug. > > If we register a service at a local repository with "Use RDF Signature" > enabled the service is registered and the RDF is created (register time > takes > about 2min). > > If we register the same service at the Moby TestCentral the service is > registered, but no RDF is created (register time takes seconds). > > Is this intended that on the test central no RDF creation is happening ? > > Thanks -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Thu Apr 26 15:53:48 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Apr 2007 08:53:48 -0700 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio Message-ID: Rejected! "we do not publish papers on software alone" They have suggested PLoS ONE as an alternative, but there are other (open access) journals that we could try... I'm quite fond of the BMC Journals, but I tend to be spamming them with papers in the past 12 months, so they may be getting tired of me ;-) Opinions welcome! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From gordonp at ucalgary.ca Thu Apr 26 15:59:28 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 26 Apr 2007 09:59:28 -0600 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: References: Message-ID: <4630CC60.7070401@ucalgary.ca> How about Nucleic Acids Research, as a "Methods" paper? They have a pretty quick turnaround time at least... > Rejected! > > "we do not publish papers on software alone" > > They have suggested PLoS ONE as an alternative, but there are other (open > access) journals that we could try... I'm quite fond of the BMC Journals, > but I tend to be spamming them with papers in the past 12 months, so they > may be getting tired of me ;-) > > Opinions welcome! > > Mark > > From markw at illuminae.com Thu Apr 26 16:26:48 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Apr 2007 09:26:48 -0700 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: <4630CC60.7070401@ucalgary.ca> References: <4630CC60.7070401@ucalgary.ca> Message-ID: That's a possibility... but it appears that UBC is not a member-institution for NAR, which bumps the publication charges way high - $2370. The manuscript is pretty lengthy, and they allow only 9 pages, with $170/page after that! May be you and I can convince Christoph that we can afford it out of the Platform award ;-) M On Thu, 26 Apr 2007 08:59:28 -0700, Paul Gordon wrote: > How about Nucleic Acids Research, as a "Methods" paper? They have a > pretty quick turnaround time at least... >> Rejected! >> >> "we do not publish papers on software alone" >> >> They have suggested PLoS ONE as an alternative, but there are other >> (open >> access) journals that we could try... I'm quite fond of the BMC >> Journals, >> but I tend to be spamming them with papers in the past 12 months, so >> they >> may be getting tired of me ;-) >> >> Opinions welcome! >> >> Mark >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From phillip.lord at newcastle.ac.uk Fri Apr 27 13:26:17 2007 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 27 Apr 2007 14:26:17 +0100 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: (Mark Wilkinson's message of "Thu\, 26 Apr 2007 08\:53\:48 -0700") References: Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Rejected! Mark> "we do not publish papers on software alone" Mark> They have suggested PLoS ONE as an alternative, but there are Mark> other (open access) journals that we could try... I'm quite Mark> fond of the BMC Journals, but I tend to be spamming them with Mark> papers in the past 12 months, so they may be getting tired of Mark> me ;-) If they are tired of you, then the worse that they can do is reject you. BMC Bioinformatics or PLoS ONE would both be quite fun; the former has the best citation impact (obviously, as PLoS one is new). Phil From phillip.lord at newcastle.ac.uk Fri Apr 27 13:26:17 2007 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 27 Apr 2007 14:26:17 +0100 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: (Mark Wilkinson's message of "Thu\, 26 Apr 2007 08\:53\:48 -0700") References: Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Rejected! Mark> "we do not publish papers on software alone" Mark> They have suggested PLoS ONE as an alternative, but there are Mark> other (open access) journals that we could try... I'm quite Mark> fond of the BMC Journals, but I tend to be spamming them with Mark> papers in the past 12 months, so they may be getting tired of Mark> me ;-) If they are tired of you, then the worse that they can do is reject you. BMC Bioinformatics or PLoS ONE would both be quite fun; the former has the best citation impact (obviously, as PLoS one is new). Phil From duncan.hull at cs.man.ac.uk Mon Apr 30 12:17:35 2007 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Mon, 30 Apr 2007 13:17:35 +0100 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: References: <4630CC60.7070401@ucalgary.ca> Message-ID: <4635DE5F.6090408@cs.man.ac.uk> Mark Wilkinson wrote: > That's a possibility... but it appears that UBC is not a > member-institution for NAR, which bumps the publication charges way high - NAR is expensive, but a logical place for BioMOBY would be their annual web server issue [1]. The deadline for the 2007 issue is long gone, but there is always next year (deadline in December 2007, publication June 2008) http://www.nodalpoint.org/2006/12/01/nar_web_server_issue_2007 publication turnaround times are a glacial... 6 months! Howabout Source Code for Biology and Medicine? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From markw at illuminae.com Mon Apr 30 13:45:18 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Apr 2007 06:45:18 -0700 Subject: [MOBY-dev] Moby 1.0 manuscript inappropriate for PLoS Comp Bio In-Reply-To: <4635DE5F.6090408@cs.man.ac.uk> References: <4630CC60.7070401@ucalgary.ca> <4635DE5F.6090408@cs.man.ac.uk> Message-ID: I'm already planning to submit Moby to the NAR WS issue, which is another reason I am loathe to submit it there for the 1.0 publication. SCFBM is fine too, but I think PLoS ONE might be a better location due to the broader audience. I havn't heard any objections, so I'm going to go ahead and submit it there today. Cheers all! M On Mon, 30 Apr 2007 05:17:35 -0700, Duncan Hull wrote: > Mark Wilkinson wrote: >> That's a possibility... but it appears that UBC is not a >> member-institution for NAR, which bumps the publication charges way >> high - > > NAR is expensive, but a logical place for BioMOBY would be their annual > web server issue [1]. The deadline for the 2007 issue is long gone, but > there is always next year (deadline in December 2007, publication June > 2008) > > http://www.nodalpoint.org/2006/12/01/nar_web_server_issue_2007 > > publication turnaround times are a glacial... 6 months! > > Howabout Source Code for Biology and Medicine? > > > Duncan > -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system.