From Pieter.Neerincx at wur.nl Wed Jun 7 13:24:35 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 7 Jun 2006 19:24:35 +0200 Subject: [MOBY-dev] BioMOBY working with new SOAP:Lite! [was Re: Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken...] In-Reply-To: <6E1B1412-95CC-425E-B46A-F27858BC612C@wur.nl> References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> <1138823258.4897.54.camel@bioinfo.icapture.ubc.ca> <6E1B1412-95CC-425E-B46A-F27858BC612C@wur.nl> Message-ID: Hi all, This is mostly of interest for the Perl Mobifiers on the list. The others better skip this... On 2-Feb-2006, at 6:12 PM, Pieter Neerincx wrote: > > On 1-Feb-2006, at 8:47 PM, Mark Wilkinson wrote: > >> On Mon, 2006-01-30 at 17:53 +0100, Pieter Neerincx wrote: >> >>> No I think you got it right. S::L shouldn't mess it up, but I can >>> predict that fixing it by changing the prefix in BioMOBY is much >>> faster than trying to get a fix into the next "stable" release of >>> S::L. >> >> Please go ahead with this change. > > Ok I'll change the prefix for that namespace from soap to wsoap then. I have to admit that didn't happen yet. It wasn't a complete fix anyway, but this thread is back and I think I found a way to make the BioMOBY modules work with both the old and new versions of S::L and hopefully remain compatible with Java/Python/whatever Mobifiers :). (It should but I haven't tested that thoroughly yet). It is still necessary to change the prefix for that namespace from "soap" to something else. Combined with the proposed changes below that should make the BioMOBY modules compatible with S::L 0.60+. > >> >> The other problems are a bit more frustrating, and harder to deal >> with! >> It isn't just a question of being S::L compatible, it's also a >> question >> of doing the right thing, since we have to be compatible with the >> Java/Python libraries as well. If S::L is wrong, then we need to >> push >> them to change; if *we* are wrong, then we need to recognize that and >> fix the message structure. >> >> I need to do some more reading to figure out which is the case. > > Ok, please let me know what you think. As far as I understand it, the > problem with that 'anyURI' thing is a S::L bug, but for the one with > the double encoding I'm not sure. It doesn't really matter who > encodes the string as long as not both the BioMOBY Perl modules and > S::L try to do it... After a lot of digging in the code I think that the 'anyURI' and the double encoding problem are not easily classifiable. Some will call it a bug (for us it is!), but for others it might be a feature. The best way to get rid off both problems is not to rely on the S::L autotyper and send "raw" xml to S::L. If we do the encoding ourselves (like we did before) and use S::L *only* to transfer the data and not to encode it, it works fine. My problem was how to get that done as the documentation on how to do that is rather limited. Attached to this e-mail you will find a zipped archive with a patched: MOBY::Central.pm, MOBY::CommonSubs.pm, MOBY::Client::Central.pm and MOBY::Client::Service.pm The big picture: Everywhere where a SOAP call is made I've changed the code to do something like this: # # Encode content & create SOAP::Data object of type 'xml'. # We do the encoding ourselves and send raw XML using SOAP::Lite. # By sending raw XML, we don't have to rely on the SOAP::Lite autotyper, # which automatically messes-up in SOAP::Lite versions > 0.60. # my $xml_object_ref = MOBY::CommonSubs::makeSoapDataObject($data); my @payload = $connect->call( $method => $xml_object_ref )- >paramsall; Where data is returned it is now something like this: my $xml_object_ref = MOBY::CommonSubs::makeSoapDataObject($message); return $xml_object_ref; MOBY::CommonSubs::makeSoapDataObject creates a SOAP::Data object of type (raw) 'xml': sub makeSoapDataObject { my ($xml) = @_; # # Encode content. # We do the encoding ourselves and send raw XML using SOAP::Lite. # By sending raw XML, we don't have to rely on the SOAP::Lite autotyper, # which automatically messes-up in SOAP::Lite versions > 0.60. # $xml =~ s"&"&"g; $xml =~ s"\<"<"g; $xml =~ s"\]\]\>"\]\]>"g; # Specify the data type 'xml' to send raw XML and bypass the SOAP::Lite autotyper. $xml = SOAP::Data->type('xml' => $xml); # Return a reference to the SOAP::Data object. # It is essential to return a ref and not the object itself, # as the latter will fail for objects of type 'xml'. return \$xml; } I changed some other small bits as well. Since these changes have an effect on all the messaging (service/object registration, service/ object discovery and service execution) I didn't dare to commit this to the CVS yet. If I overlooked something and it breaks, it messes up really bad :(. Could other Perl Mobifiers please have look at it and give it a try? Please let me know if it works for you or not and which version of S::L you used... Thanks, Pi -------------- next part -------------- A non-text attachment was scrubbed... Name: MOBY.zip Type: application/zip Size: 66119 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20060607/4355d985/attachment-0001.zip -------------- next part -------------- > > Pi > > >> M >> >> >> -- >> -- >> ...his last words were 'Hey guys! Watch this!' >> -- >> Mark Wilkinson >> Asst. Professor >> Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics >> iCAPTURE Centre >> St. Paul's Hospital >> Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Wed Jun 7 14:25:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 07 Jun 2006 11:25:35 -0700 Subject: [MOBY-dev] forwarding filtered message from Pieter Message-ID: <1149704735.20076.5.camel@bioinfo.icapture.ubc.ca> -------------- next part -------------- An embedded message was scrubbed... From: moby-dev-owner at lists.open-bio.org Subject: [spam] MOBY-dev post from pieter.neerincx at wur.nl requires approval Date: Wed, 07 Jun 2006 13:37:05 -0400 Size: 101751 Url: http://lists.open-bio.org/pipermail/moby-dev/attachments/20060607/13dd5f15/attachment-0001.mht From gordonp at ucalgary.ca Wed Jun 21 15:22:57 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 21 Jun 2006 13:22:57 -0600 Subject: [MOBY-dev] Java 1.5 coming... Message-ID: <44999C91.9000800@ucalgary.ca> Hi folks, Back in April we said we'd change to requiring Java 1.5 on June 30th. The only hold up was Taverna compatability. Has this been addressed? I've got Java 1.5 code I'd like to start committing soon... Cheers, Paul From edward.kawas at gmail.com Wed Jun 21 16:55:53 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 21 Jun 2006 13:55:53 -0700 Subject: [MOBY-dev] Java 1.5 coming... In-Reply-To: <44999C91.9000800@ucalgary.ca> Message-ID: <002101c69575$164fd240$6700a8c0@notebook> Hi Paul, Don't let Taverna hold you back. As of this release (or the next one), the Java 1.5 is supported. 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: Wednesday, June 21, 2006 12:23 PM > To: mobydev > Subject: [MOBY-dev] Java 1.5 coming... > > Hi folks, > > Back in April we said we'd change to requiring Java 1.5 on > June 30th. > The only hold up was Taverna compatability. Has this been > addressed? > I've got Java 1.5 code I'd like to start committing soon... > > Cheers, > > Paul > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From tmo at ebi.ac.uk Wed Jun 21 17:42:07 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed, 21 Jun 2006 22:42:07 +0100 Subject: [MOBY-dev] Java 1.5 coming... In-Reply-To: <44999C91.9000800@ucalgary.ca> References: <44999C91.9000800@ucalgary.ca> Message-ID: <4499BD2F.4090001@ebi.ac.uk> Paul Gordon wrote: > Hi folks, > > Back in April we said we'd change to requiring Java 1.5 on June 30th. > The only hold up was Taverna compatability. Has this been addressed? > I've got Java 1.5 code I'd like to start committing soon... We have some java 5 requirements in taverna 1.4 (current version) which are optional but the next release will be constrained to java 5 for other reasons so as far as we're concerned knock yourselves out :) Tom From tmo at ebi.ac.uk Wed Jun 21 17:42:07 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed, 21 Jun 2006 22:42:07 +0100 Subject: [MOBY-dev] Java 1.5 coming... In-Reply-To: <44999C91.9000800@ucalgary.ca> References: <44999C91.9000800@ucalgary.ca> Message-ID: <4499BD2F.4090001@ebi.ac.uk> Paul Gordon wrote: > Hi folks, > > Back in April we said we'd change to requiring Java 1.5 on June 30th. > The only hold up was Taverna compatability. Has this been addressed? > I've got Java 1.5 code I'd like to start committing soon... We have some java 5 requirements in taverna 1.4 (current version) which are optional but the next release will be constrained to java 5 for other reasons so as far as we're concerned knock yourselves out :) Tom From aperezp at uma.es Mon Jun 26 07:06:30 2006 From: aperezp at uma.es (=?ISO-8859-1?Q?=22Antonio_J=2E_P=E9rez=22?=) Date: Mon, 26 Jun 2006 13:06:30 +0200 Subject: [MOBY-dev] XML registration In-Reply-To: <4499BD2F.4090001@ebi.ac.uk> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> Message-ID: <449FBFB6.8010001@uma.es> Hi, I am trying to register a service from a XML file using the Perl API. But the XML coming from findService function is different to that accepted by registerService. Is there any way to register a new service from the XML given by registerService? Thanks in advance, Antonio. From aperezp at uma.es Mon Jun 26 11:29:05 2006 From: aperezp at uma.es (=?ISO-8859-1?Q?=22Antonio_J=2E_P=E9rez=22?=) Date: Mon, 26 Jun 2006 17:29:05 +0200 Subject: [MOBY-dev] XML registration Message-ID: <449FFD41.5060306@uma.es> Hi, I am trying to register a service from a XML file using the Perl API. But the XML coming from findService function is different to that accepted by registerService. Is there any way to register a new service from the XML given by registerService? Thanks in advance, Antonio. From gordonp at ucalgary.ca Mon Jun 26 17:03:03 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 26 Jun 2006 15:03:03 -0600 Subject: [MOBY-dev] Connection problem? Message-ID: <44A04B87.8000602@ucalgary.ca> Anyone else having an issue getting the object ontology RDF from http://biomoby.org/RESOURCES/MOBY-S/Objects ? It seems to hang for me. From senger at ebi.ac.uk Mon Jun 26 19:09:00 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 27 Jun 2006 00:09:00 +0100 (BST) Subject: [MOBY-dev] Connection problem? In-Reply-To: <44A04B87.8000602@ucalgary.ca> Message-ID: > http://biomoby.org/RESOURCES/MOBY-S/Objects > Try to add a slash: http://biomoby.org/RESOURCES/MOBY-S/Objects/ M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From ed.kawas at gmail.com Mon Jun 26 19:37:24 2006 From: ed.kawas at gmail.com (Ed Kawas) Date: Mon, 26 Jun 2006 16:37:24 -0700 Subject: [MOBY-dev] Connection problem? In-Reply-To: <44A04B87.8000602@ucalgary.ca> Message-ID: <002b01c69979$7af61d00$6700a8c0@notebook> Nothing odd happening with the url. When I use the one you posted, I get results in a few seconds. 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: Monday, June 26, 2006 2:03 PM > To: Core developer announcements > Subject: [MOBY-dev] Connection problem? > > Anyone else having an issue getting the object ontology RDF from > > http://biomoby.org/RESOURCES/MOBY-S/Objects > > ? It seems to hang for me. > _______________________________________________ > 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 Jun 27 11:31:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 27 Jun 2006 08:31:10 -0700 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <449FBFB6.8010001@uma.es> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> <449FBFB6.8010001@uma.es> Message-ID: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Hi Antonio, I agree that, in hindsight, it would have made more sense for those two blocks of XML to be identical, but they are not. As such, at the moment you will need to do a small amount of manipulation to derive the registerService XML from the findService XML. I'm going to bounce this over to Eddie, since this problem *HAS* been solved with the RDF-based registration, which is an extension of the MOBY API but not yet part of the official API. Nevertheless, I believe that the functionality exists and is bug-free in the current codebase, so if you wanted to "live on the edge" you could use it. Eddie will be able to indicate what the state of that code is, and when it will become an official part of the API. M On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > Hi, I am trying to register a service from a XML file using the Perl > API. But the XML coming from findService function is different to that > accepted by registerService. Is there any way to register a new service > from the XML given by registerService? > Thanks in advance, > > Antonio. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Tue Jun 27 11:31:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 27 Jun 2006 08:31:10 -0700 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <449FBFB6.8010001@uma.es> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> <449FBFB6.8010001@uma.es> Message-ID: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Hi Antonio, I agree that, in hindsight, it would have made more sense for those two blocks of XML to be identical, but they are not. As such, at the moment you will need to do a small amount of manipulation to derive the registerService XML from the findService XML. I'm going to bounce this over to Eddie, since this problem *HAS* been solved with the RDF-based registration, which is an extension of the MOBY API but not yet part of the official API. Nevertheless, I believe that the functionality exists and is bug-free in the current codebase, so if you wanted to "live on the edge" you could use it. Eddie will be able to indicate what the state of that code is, and when it will become an official part of the API. M On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > Hi, I am trying to register a service from a XML file using the Perl > API. But the XML coming from findService function is different to that > accepted by registerService. Is there any way to register a new service > from the XML given by registerService? > Thanks in advance, > > Antonio. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From aperezp at uma.es Tue Jun 27 12:36:47 2006 From: aperezp at uma.es (=?UTF-8?B?IkFudG9uaW8gSi4gUMOpcmV6Ig==?=) Date: Tue, 27 Jun 2006 18:36:47 +0200 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> <449FBFB6.8010001@uma.es> <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <44A15E9F.3090100@uma.es> Hi Mark and thank you for your help. Now I have dismantled the output from findService and I have built the input to registerService. But it would be nice to use the RDF way. Kind regards, Antonio. Mark Wilkinson escribi?: > Hi Antonio, > > I agree that, in hindsight, it would have made more sense for those two > blocks of XML to be identical, but they are not. As such, at the moment > you will need to do a small amount of manipulation to derive the > registerService XML from the findService XML. > > I'm going to bounce this over to Eddie, since this problem *HAS* been > solved with the RDF-based registration, which is an extension of the > MOBY API but not yet part of the official API. Nevertheless, I believe > that the functionality exists and is bug-free in the current codebase, > so if you wanted to "live on the edge" you could use it. > > Eddie will be able to indicate what the state of that code is, and when > it will become an official part of the API. > > M > > > > On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > >> Hi, I am trying to register a service from a XML file using the Perl >> API. But the XML coming from findService function is different to that >> accepted by registerService. Is there any way to register a new service >> from the XML given by registerService? >> Thanks in advance, >> >> Antonio. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> From aperezp at uma.es Tue Jun 27 12:36:47 2006 From: aperezp at uma.es (=?UTF-8?B?IkFudG9uaW8gSi4gUMOpcmV6Ig==?=) Date: Tue, 27 Jun 2006 18:36:47 +0200 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> <449FBFB6.8010001@uma.es> <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <44A15E9F.3090100@uma.es> Hi Mark and thank you for your help. Now I have dismantled the output from findService and I have built the input to registerService. But it would be nice to use the RDF way. Kind regards, Antonio. Mark Wilkinson escribi?: > Hi Antonio, > > I agree that, in hindsight, it would have made more sense for those two > blocks of XML to be identical, but they are not. As such, at the moment > you will need to do a small amount of manipulation to derive the > registerService XML from the findService XML. > > I'm going to bounce this over to Eddie, since this problem *HAS* been > solved with the RDF-based registration, which is an extension of the > MOBY API but not yet part of the official API. Nevertheless, I believe > that the functionality exists and is bug-free in the current codebase, > so if you wanted to "live on the edge" you could use it. > > Eddie will be able to indicate what the state of that code is, and when > it will become an official part of the API. > > M > > > > On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > >> Hi, I am trying to register a service from a XML file using the Perl >> API. But the XML coming from findService function is different to that >> accepted by registerService. Is there any way to register a new service >> from the XML given by registerService? >> Thanks in advance, >> >> Antonio. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> From ed.kawas at gmail.com Tue Jun 27 11:54:22 2006 From: ed.kawas at gmail.com (Ed Kawas) Date: Tue, 27 Jun 2006 08:54:22 -0700 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <005201c69a01$f7213030$6700a8c0@notebook> Hi Antonio, One way you could perform a bulk registration of services is by using the registerService call with no parameters except for signatureURL (currently undocumented on the moby website, but if you read the comments for the registerService sub in the perl module Central.pm you will find some documentation). SignatureURL would point to a file containing the services that you would like to register in RDF format. One way to get the RDF is to use the LSID resolver (http://mobycentral.icapture.ubc.ca/LSID_resolver.html, useful for mobycentral only), an RDF generating servlet (http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerator?name=parseBlastTe xt&auth=bioinfo.icapture.ubc.ca&uri=YOUR_REGISTRY_NAMESPACE&url=YOUR_REGISTRY_EN DPOINT, and generates RDF based on any registry as long as you fill in the url, uri and specify a servicename (name) and service provider authority (auth). The agent based registration via registerService currently works for mobycentral and the test registery on bioinfo (or any other registry that has deployed, and configured the agent). Let me know if this helps! Eddie > -----Original Message----- > From: Mark Wilkinson [mailto:markw at illuminae.com] > Sent: Tuesday, June 27, 2006 8:31 AM > To: Core developer announcements; Eddie Kawas > Cc: mobydev > Subject: Re: [moby] [MOBY-dev] XML registration > > Hi Antonio, > > I agree that, in hindsight, it would have made more sense for > those two blocks of XML to be identical, but they are not. > As such, at the moment you will need to do a small amount of > manipulation to derive the registerService XML from the > findService XML. > > I'm going to bounce this over to Eddie, since this problem > *HAS* been solved with the RDF-based registration, which is > an extension of the MOBY API but not yet part of the official > API. Nevertheless, I believe that the functionality exists > and is bug-free in the current codebase, so if you wanted to > "live on the edge" you could use it. > > Eddie will be able to indicate what the state of that code > is, and when it will become an official part of the API. > > M > > > > On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > > Hi, I am trying to register a service from a XML file using the > > Perl API. But the XML coming from findService function is > different to > > that accepted by registerService. Is there any way to > register a new > > service from the XML given by registerService? > > Thanks in advance, > > > > Antonio. > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics University of > British Columbia PI in Bioinformatics, iCAPTURE Centre St. > Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > From aperezp at uma.es Wed Jun 28 04:45:49 2006 From: aperezp at uma.es (=?ISO-8859-1?Q?=22Antonio_J=2E_P=E9rez=22?=) Date: Wed, 28 Jun 2006 10:45:49 +0200 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <005201c69a01$f7213030$6700a8c0@notebook> References: <005201c69a01$f7213030$6700a8c0@notebook> Message-ID: <44A241BD.8050902@uma.es> Hi Eddie, thank you for your mail. I will check all your information and I will tell you. Kind regards, Antonio. Ed Kawas escribi?: > Hi Antonio, > > One way you could perform a bulk registration of services is by using the > registerService call with no parameters except for signatureURL (currently > undocumented on the moby website, but if you read the comments for the > registerService sub in the perl module Central.pm you will find some > documentation). > > SignatureURL would point to a file containing the services that you would like > to register in RDF format. One way to get the RDF is to use the LSID resolver > (http://mobycentral.icapture.ubc.ca/LSID_resolver.html, useful for mobycentral > only), an RDF generating servlet > (http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerator?name=parseBlastTe > xt&auth=bioinfo.icapture.ubc.ca&uri=YOUR_REGISTRY_NAMESPACE&url=YOUR_REGISTRY_EN > DPOINT, and generates RDF based on any registry as long as you fill in the url, > uri and specify a servicename (name) and service provider authority (auth). > > The agent based registration via registerService currently works for mobycentral > and the test registery on bioinfo (or any other registry that has deployed, and > configured the agent). > > Let me know if this helps! > > Eddie > > >> -----Original Message----- >> From: Mark Wilkinson [mailto:markw at illuminae.com] >> Sent: Tuesday, June 27, 2006 8:31 AM >> To: Core developer announcements; Eddie Kawas >> Cc: mobydev >> Subject: Re: [moby] [MOBY-dev] XML registration >> >> Hi Antonio, >> >> I agree that, in hindsight, it would have made more sense for >> those two blocks of XML to be identical, but they are not. >> As such, at the moment you will need to do a small amount of >> manipulation to derive the registerService XML from the >> findService XML. >> >> I'm going to bounce this over to Eddie, since this problem >> *HAS* been solved with the RDF-based registration, which is >> an extension of the MOBY API but not yet part of the official >> API. Nevertheless, I believe that the functionality exists >> and is bug-free in the current codebase, so if you wanted to >> "live on the edge" you could use it. >> >> Eddie will be able to indicate what the state of that code >> is, and when it will become an official part of the API. >> >> M >> >> >> >> On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: >> >>> Hi, I am trying to register a service from a XML file using the >>> Perl API. But the XML coming from findService function is >>> >> different to >> >>> that accepted by registerService. Is there any way to >>> >> register a new >> >>> service from the XML given by registerService? >>> Thanks in advance, >>> >>> Antonio. >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> -- >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics University of >> British Columbia PI in Bioinformatics, iCAPTURE Centre St. >> Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > From raulfdez at lcc.uma.es Wed Jun 28 05:24:01 2006 From: raulfdez at lcc.uma.es (Raul) Date: Wed, 28 Jun 2006 11:24:01 +0200 Subject: [MOBY-dev] a por los workflows! In-Reply-To: <44A241BD.8050902@uma.es> Message-ID: <000601c69a94$98b824c0$0bd6d696@hyperion> Hola Antonio, Volviste a probar los workflows en MOWServ? Te funcionan ya? Necesito q me pases algunos de esos workflows q dices q funcionan en Taverna y no funcionan en la aplicaci?n, para ver que pasa. Saludos, Ra?l From senger at ebi.ac.uk Wed Jun 28 12:31:25 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 28 Jun 2006 17:31:25 +0100 (BST) Subject: [MOBY-dev] java 1.5 comming Message-ID: Dear developers, I have (only slighty) changed the documentation and the build.xml file - from now the 'latest' Java is considered the 1.6 one. When you start putting there a real Java 1.5. code, and if it from some reasons does not compile, let me knowasap and I will fix build.xml again. Hopefully, however, everything is fine. I have also made small (invisible) changes in Dashboard - hopefully fixing some bugs. So consider to cvs update. Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Thu Jun 29 14:40:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 29 Jun 2006 11:40:53 -0700 Subject: [MOBY-dev] Request to curate the text* branch of the Object ontology Message-ID: <1151606453.8650.16.camel@bioinfo.icapture.ubc.ca> Hi all, If anyone has noticed, the text* branches of the Object ontology are a total mess! We have: text-plain text_plain text_formatted ISA text_plain text-formatted ISA text-plain text-html text-xml text-base64 I would like to do some manual curation of the ontology to clean this up a bit. What I propose is: text-plain text-formatted text-html text-xml text-xhtml text-base64 We'll need to leave text_plain and its child objects in the ontology for the moment since they are being used, but I'll try to get in touch with the service providers and ask if they would be willing to migrate their services to use the text-plain tree instead. Since these objects are all derived from each other through ISA links alone, it should be safe to do this manipulation (i.e. it will not re- define the structure of any object, so nobody's service will break). It will simply make it more sensible for people to register services that operate on text. At the moment, services that parse text must be registered as consuming Object in order to catch all of the different types of text! Ugh... Are there any objections to me doing this? M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jun 29 16:13:32 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 29 Jun 2006 13:13:32 -0700 Subject: [MOBY-dev] exception reporting Message-ID: Hi all, Has anyone implemented the ability to report exceptions into the Perl services code? M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From Usadel at mpimp-golm.mpg.de Fri Jun 30 08:38:32 2006 From: Usadel at mpimp-golm.mpg.de (Bjoern Usadel) Date: Fri, 30 Jun 2006 14:38:32 +0200 Subject: [MOBY-dev] exception reporting References: Message-ID: <8233DF2244998040848283889E22DBA0040F1A@MAIL.mpimp-golm.mpg.de> Hi, I hope I did, as announced, in CommonSubs 1.91. In responseHeader you now can use the additional variable -exception which should be xml encoded. To get this xml encoded message for one exception I added a sub encodeException -refElement => 'refers to the queryID of the offending input mobyData', -refQueryID => 'refers to the articleName of the offending input Simple or Collection' -severity=>'error' -exceptionCode=>'An error code ' -exceptionMessage=>'a human readable description for the error code' And then there is getExceptions. /all theses subs should be perldoced All services at authority "mapman.mpimp-golm.mpg.de" should use exception reporting (central& testing ones, so if someone from the Java fraction wants to check this I would be happy. Cheers, Bj?rn PS Currently I am on a conference I will include a perl example in the docs when coming back. -----Original Message----- From: moby-dev-bounces at lists.open-bio.org on behalf of Mark Wilkinson Sent: Thu 6/29/2006 10:13 PM To: Core developer announcements Subject: [MOBY-dev] exception reporting Hi all, Has anyone implemented the ability to report exceptions into the Perl services code? M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 3335 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20060630/c4bf2c85/attachment-0001.bin From markw at illuminae.com Fri Jun 30 13:30:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Jun 2006 10:30:53 -0700 Subject: [MOBY-dev] [moby] Re: exception reporting In-Reply-To: <8233DF2244998040848283889E22DBA0040F1A@MAIL.mpimp-golm.mpg.de> References: <8233DF2244998040848283889E22DBA0040F1A@MAIL.mpimp-golm.mpg.de> Message-ID: <1151688653.8248.23.camel@bioinfo.icapture.ubc.ca> Excellent! Cheers! M On Fri, 2006-06-30 at 14:38 +0200, Bjoern Usadel wrote: > Hi, > > I hope I did, as announced, in CommonSubs 1.91. > > In responseHeader you now can use the additional variable -exception which should be xml encoded. > To get this xml encoded message for one exception I added a sub > encodeException > -refElement => 'refers to the queryID of the offending input mobyData', > -refQueryID => 'refers to the articleName of the offending input Simple or Collection' > -severity=>'error' > -exceptionCode=>'An error code ' > -exceptionMessage=>'a human readable description for the error code' > > And then there is getExceptions. > > /all theses subs should be perldoced > > All services at authority "mapman.mpimp-golm.mpg.de" should use exception reporting (central& testing ones, so if someone from the Java fraction wants to check this I would be happy. > > Cheers, > Bj?rn > > PS Currently I am on a conference I will include a perl example in the docs when coming back. > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org on behalf of Mark Wilkinson > Sent: Thu 6/29/2006 10:13 PM > To: Core developer announcements > Subject: [MOBY-dev] exception reporting > > Hi all, > > Has anyone implemented the ability to report exceptions into the Perl > services code? > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Wed Jun 7 17:24:35 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 7 Jun 2006 19:24:35 +0200 Subject: [MOBY-dev] BioMOBY working with new SOAP:Lite! [was Re: Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken...] In-Reply-To: <6E1B1412-95CC-425E-B46A-F27858BC612C@wur.nl> References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> <1138823258.4897.54.camel@bioinfo.icapture.ubc.ca> <6E1B1412-95CC-425E-B46A-F27858BC612C@wur.nl> Message-ID: Hi all, This is mostly of interest for the Perl Mobifiers on the list. The others better skip this... On 2-Feb-2006, at 6:12 PM, Pieter Neerincx wrote: > > On 1-Feb-2006, at 8:47 PM, Mark Wilkinson wrote: > >> On Mon, 2006-01-30 at 17:53 +0100, Pieter Neerincx wrote: >> >>> No I think you got it right. S::L shouldn't mess it up, but I can >>> predict that fixing it by changing the prefix in BioMOBY is much >>> faster than trying to get a fix into the next "stable" release of >>> S::L. >> >> Please go ahead with this change. > > Ok I'll change the prefix for that namespace from soap to wsoap then. I have to admit that didn't happen yet. It wasn't a complete fix anyway, but this thread is back and I think I found a way to make the BioMOBY modules work with both the old and new versions of S::L and hopefully remain compatible with Java/Python/whatever Mobifiers :). (It should but I haven't tested that thoroughly yet). It is still necessary to change the prefix for that namespace from "soap" to something else. Combined with the proposed changes below that should make the BioMOBY modules compatible with S::L 0.60+. > >> >> The other problems are a bit more frustrating, and harder to deal >> with! >> It isn't just a question of being S::L compatible, it's also a >> question >> of doing the right thing, since we have to be compatible with the >> Java/Python libraries as well. If S::L is wrong, then we need to >> push >> them to change; if *we* are wrong, then we need to recognize that and >> fix the message structure. >> >> I need to do some more reading to figure out which is the case. > > Ok, please let me know what you think. As far as I understand it, the > problem with that 'anyURI' thing is a S::L bug, but for the one with > the double encoding I'm not sure. It doesn't really matter who > encodes the string as long as not both the BioMOBY Perl modules and > S::L try to do it... After a lot of digging in the code I think that the 'anyURI' and the double encoding problem are not easily classifiable. Some will call it a bug (for us it is!), but for others it might be a feature. The best way to get rid off both problems is not to rely on the S::L autotyper and send "raw" xml to S::L. If we do the encoding ourselves (like we did before) and use S::L *only* to transfer the data and not to encode it, it works fine. My problem was how to get that done as the documentation on how to do that is rather limited. Attached to this e-mail you will find a zipped archive with a patched: MOBY::Central.pm, MOBY::CommonSubs.pm, MOBY::Client::Central.pm and MOBY::Client::Service.pm The big picture: Everywhere where a SOAP call is made I've changed the code to do something like this: # # Encode content & create SOAP::Data object of type 'xml'. # We do the encoding ourselves and send raw XML using SOAP::Lite. # By sending raw XML, we don't have to rely on the SOAP::Lite autotyper, # which automatically messes-up in SOAP::Lite versions > 0.60. # my $xml_object_ref = MOBY::CommonSubs::makeSoapDataObject($data); my @payload = $connect->call( $method => $xml_object_ref )- >paramsall; Where data is returned it is now something like this: my $xml_object_ref = MOBY::CommonSubs::makeSoapDataObject($message); return $xml_object_ref; MOBY::CommonSubs::makeSoapDataObject creates a SOAP::Data object of type (raw) 'xml': sub makeSoapDataObject { my ($xml) = @_; # # Encode content. # We do the encoding ourselves and send raw XML using SOAP::Lite. # By sending raw XML, we don't have to rely on the SOAP::Lite autotyper, # which automatically messes-up in SOAP::Lite versions > 0.60. # $xml =~ s"&"&"g; $xml =~ s"\<"<"g; $xml =~ s"\]\]\>"\]\]>"g; # Specify the data type 'xml' to send raw XML and bypass the SOAP::Lite autotyper. $xml = SOAP::Data->type('xml' => $xml); # Return a reference to the SOAP::Data object. # It is essential to return a ref and not the object itself, # as the latter will fail for objects of type 'xml'. return \$xml; } I changed some other small bits as well. Since these changes have an effect on all the messaging (service/object registration, service/ object discovery and service execution) I didn't dare to commit this to the CVS yet. If I overlooked something and it breaks, it messes up really bad :(. Could other Perl Mobifiers please have look at it and give it a try? Please let me know if it works for you or not and which version of S::L you used... Thanks, Pi -------------- next part -------------- A non-text attachment was scrubbed... Name: MOBY.zip Type: application/zip Size: 66119 bytes Desc: not available URL: -------------- next part -------------- > > Pi > > >> M >> >> >> -- >> -- >> ...his last words were 'Hey guys! Watch this!' >> -- >> Mark Wilkinson >> Asst. Professor >> Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics >> iCAPTURE Centre >> St. Paul's Hospital >> Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Wed Jun 7 18:25:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 07 Jun 2006 11:25:35 -0700 Subject: [MOBY-dev] forwarding filtered message from Pieter Message-ID: <1149704735.20076.5.camel@bioinfo.icapture.ubc.ca> -------------- next part -------------- An embedded message was scrubbed... From: moby-dev-owner at lists.open-bio.org Subject: [spam] MOBY-dev post from pieter.neerincx at wur.nl requires approval Date: Wed, 07 Jun 2006 13:37:05 -0400 Size: 101751 URL: From gordonp at ucalgary.ca Wed Jun 21 19:22:57 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 21 Jun 2006 13:22:57 -0600 Subject: [MOBY-dev] Java 1.5 coming... Message-ID: <44999C91.9000800@ucalgary.ca> Hi folks, Back in April we said we'd change to requiring Java 1.5 on June 30th. The only hold up was Taverna compatability. Has this been addressed? I've got Java 1.5 code I'd like to start committing soon... Cheers, Paul From edward.kawas at gmail.com Wed Jun 21 20:55:53 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 21 Jun 2006 13:55:53 -0700 Subject: [MOBY-dev] Java 1.5 coming... In-Reply-To: <44999C91.9000800@ucalgary.ca> Message-ID: <002101c69575$164fd240$6700a8c0@notebook> Hi Paul, Don't let Taverna hold you back. As of this release (or the next one), the Java 1.5 is supported. 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: Wednesday, June 21, 2006 12:23 PM > To: mobydev > Subject: [MOBY-dev] Java 1.5 coming... > > Hi folks, > > Back in April we said we'd change to requiring Java 1.5 on > June 30th. > The only hold up was Taverna compatability. Has this been > addressed? > I've got Java 1.5 code I'd like to start committing soon... > > Cheers, > > Paul > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From tmo at ebi.ac.uk Wed Jun 21 21:42:07 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed, 21 Jun 2006 22:42:07 +0100 Subject: [MOBY-dev] Java 1.5 coming... In-Reply-To: <44999C91.9000800@ucalgary.ca> References: <44999C91.9000800@ucalgary.ca> Message-ID: <4499BD2F.4090001@ebi.ac.uk> Paul Gordon wrote: > Hi folks, > > Back in April we said we'd change to requiring Java 1.5 on June 30th. > The only hold up was Taverna compatability. Has this been addressed? > I've got Java 1.5 code I'd like to start committing soon... We have some java 5 requirements in taverna 1.4 (current version) which are optional but the next release will be constrained to java 5 for other reasons so as far as we're concerned knock yourselves out :) Tom From tmo at ebi.ac.uk Wed Jun 21 21:42:07 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed, 21 Jun 2006 22:42:07 +0100 Subject: [MOBY-dev] Java 1.5 coming... In-Reply-To: <44999C91.9000800@ucalgary.ca> References: <44999C91.9000800@ucalgary.ca> Message-ID: <4499BD2F.4090001@ebi.ac.uk> Paul Gordon wrote: > Hi folks, > > Back in April we said we'd change to requiring Java 1.5 on June 30th. > The only hold up was Taverna compatability. Has this been addressed? > I've got Java 1.5 code I'd like to start committing soon... We have some java 5 requirements in taverna 1.4 (current version) which are optional but the next release will be constrained to java 5 for other reasons so as far as we're concerned knock yourselves out :) Tom From aperezp at uma.es Mon Jun 26 11:06:30 2006 From: aperezp at uma.es (=?ISO-8859-1?Q?=22Antonio_J=2E_P=E9rez=22?=) Date: Mon, 26 Jun 2006 13:06:30 +0200 Subject: [MOBY-dev] XML registration In-Reply-To: <4499BD2F.4090001@ebi.ac.uk> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> Message-ID: <449FBFB6.8010001@uma.es> Hi, I am trying to register a service from a XML file using the Perl API. But the XML coming from findService function is different to that accepted by registerService. Is there any way to register a new service from the XML given by registerService? Thanks in advance, Antonio. From aperezp at uma.es Mon Jun 26 15:29:05 2006 From: aperezp at uma.es (=?ISO-8859-1?Q?=22Antonio_J=2E_P=E9rez=22?=) Date: Mon, 26 Jun 2006 17:29:05 +0200 Subject: [MOBY-dev] XML registration Message-ID: <449FFD41.5060306@uma.es> Hi, I am trying to register a service from a XML file using the Perl API. But the XML coming from findService function is different to that accepted by registerService. Is there any way to register a new service from the XML given by registerService? Thanks in advance, Antonio. From gordonp at ucalgary.ca Mon Jun 26 21:03:03 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 26 Jun 2006 15:03:03 -0600 Subject: [MOBY-dev] Connection problem? Message-ID: <44A04B87.8000602@ucalgary.ca> Anyone else having an issue getting the object ontology RDF from http://biomoby.org/RESOURCES/MOBY-S/Objects ? It seems to hang for me. From senger at ebi.ac.uk Mon Jun 26 23:09:00 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 27 Jun 2006 00:09:00 +0100 (BST) Subject: [MOBY-dev] Connection problem? In-Reply-To: <44A04B87.8000602@ucalgary.ca> Message-ID: > http://biomoby.org/RESOURCES/MOBY-S/Objects > Try to add a slash: http://biomoby.org/RESOURCES/MOBY-S/Objects/ M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From ed.kawas at gmail.com Mon Jun 26 23:37:24 2006 From: ed.kawas at gmail.com (Ed Kawas) Date: Mon, 26 Jun 2006 16:37:24 -0700 Subject: [MOBY-dev] Connection problem? In-Reply-To: <44A04B87.8000602@ucalgary.ca> Message-ID: <002b01c69979$7af61d00$6700a8c0@notebook> Nothing odd happening with the url. When I use the one you posted, I get results in a few seconds. 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: Monday, June 26, 2006 2:03 PM > To: Core developer announcements > Subject: [MOBY-dev] Connection problem? > > Anyone else having an issue getting the object ontology RDF from > > http://biomoby.org/RESOURCES/MOBY-S/Objects > > ? It seems to hang for me. > _______________________________________________ > 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 Jun 27 15:31:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 27 Jun 2006 08:31:10 -0700 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <449FBFB6.8010001@uma.es> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> <449FBFB6.8010001@uma.es> Message-ID: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Hi Antonio, I agree that, in hindsight, it would have made more sense for those two blocks of XML to be identical, but they are not. As such, at the moment you will need to do a small amount of manipulation to derive the registerService XML from the findService XML. I'm going to bounce this over to Eddie, since this problem *HAS* been solved with the RDF-based registration, which is an extension of the MOBY API but not yet part of the official API. Nevertheless, I believe that the functionality exists and is bug-free in the current codebase, so if you wanted to "live on the edge" you could use it. Eddie will be able to indicate what the state of that code is, and when it will become an official part of the API. M On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > Hi, I am trying to register a service from a XML file using the Perl > API. But the XML coming from findService function is different to that > accepted by registerService. Is there any way to register a new service > from the XML given by registerService? > Thanks in advance, > > Antonio. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Tue Jun 27 15:31:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 27 Jun 2006 08:31:10 -0700 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <449FBFB6.8010001@uma.es> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> <449FBFB6.8010001@uma.es> Message-ID: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Hi Antonio, I agree that, in hindsight, it would have made more sense for those two blocks of XML to be identical, but they are not. As such, at the moment you will need to do a small amount of manipulation to derive the registerService XML from the findService XML. I'm going to bounce this over to Eddie, since this problem *HAS* been solved with the RDF-based registration, which is an extension of the MOBY API but not yet part of the official API. Nevertheless, I believe that the functionality exists and is bug-free in the current codebase, so if you wanted to "live on the edge" you could use it. Eddie will be able to indicate what the state of that code is, and when it will become an official part of the API. M On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > Hi, I am trying to register a service from a XML file using the Perl > API. But the XML coming from findService function is different to that > accepted by registerService. Is there any way to register a new service > from the XML given by registerService? > Thanks in advance, > > Antonio. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From aperezp at uma.es Tue Jun 27 16:36:47 2006 From: aperezp at uma.es (=?UTF-8?B?IkFudG9uaW8gSi4gUMOpcmV6Ig==?=) Date: Tue, 27 Jun 2006 18:36:47 +0200 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> <449FBFB6.8010001@uma.es> <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <44A15E9F.3090100@uma.es> Hi Mark and thank you for your help. Now I have dismantled the output from findService and I have built the input to registerService. But it would be nice to use the RDF way. Kind regards, Antonio. Mark Wilkinson escribi?: > Hi Antonio, > > I agree that, in hindsight, it would have made more sense for those two > blocks of XML to be identical, but they are not. As such, at the moment > you will need to do a small amount of manipulation to derive the > registerService XML from the findService XML. > > I'm going to bounce this over to Eddie, since this problem *HAS* been > solved with the RDF-based registration, which is an extension of the > MOBY API but not yet part of the official API. Nevertheless, I believe > that the functionality exists and is bug-free in the current codebase, > so if you wanted to "live on the edge" you could use it. > > Eddie will be able to indicate what the state of that code is, and when > it will become an official part of the API. > > M > > > > On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > >> Hi, I am trying to register a service from a XML file using the Perl >> API. But the XML coming from findService function is different to that >> accepted by registerService. Is there any way to register a new service >> from the XML given by registerService? >> Thanks in advance, >> >> Antonio. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> From aperezp at uma.es Tue Jun 27 16:36:47 2006 From: aperezp at uma.es (=?UTF-8?B?IkFudG9uaW8gSi4gUMOpcmV6Ig==?=) Date: Tue, 27 Jun 2006 18:36:47 +0200 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> References: <44999C91.9000800@ucalgary.ca> <4499BD2F.4090001@ebi.ac.uk> <449FBFB6.8010001@uma.es> <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <44A15E9F.3090100@uma.es> Hi Mark and thank you for your help. Now I have dismantled the output from findService and I have built the input to registerService. But it would be nice to use the RDF way. Kind regards, Antonio. Mark Wilkinson escribi?: > Hi Antonio, > > I agree that, in hindsight, it would have made more sense for those two > blocks of XML to be identical, but they are not. As such, at the moment > you will need to do a small amount of manipulation to derive the > registerService XML from the findService XML. > > I'm going to bounce this over to Eddie, since this problem *HAS* been > solved with the RDF-based registration, which is an extension of the > MOBY API but not yet part of the official API. Nevertheless, I believe > that the functionality exists and is bug-free in the current codebase, > so if you wanted to "live on the edge" you could use it. > > Eddie will be able to indicate what the state of that code is, and when > it will become an official part of the API. > > M > > > > On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > >> Hi, I am trying to register a service from a XML file using the Perl >> API. But the XML coming from findService function is different to that >> accepted by registerService. Is there any way to register a new service >> from the XML given by registerService? >> Thanks in advance, >> >> Antonio. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> From ed.kawas at gmail.com Tue Jun 27 15:54:22 2006 From: ed.kawas at gmail.com (Ed Kawas) Date: Tue, 27 Jun 2006 08:54:22 -0700 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <1151422270.26549.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <005201c69a01$f7213030$6700a8c0@notebook> Hi Antonio, One way you could perform a bulk registration of services is by using the registerService call with no parameters except for signatureURL (currently undocumented on the moby website, but if you read the comments for the registerService sub in the perl module Central.pm you will find some documentation). SignatureURL would point to a file containing the services that you would like to register in RDF format. One way to get the RDF is to use the LSID resolver (http://mobycentral.icapture.ubc.ca/LSID_resolver.html, useful for mobycentral only), an RDF generating servlet (http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerator?name=parseBlastTe xt&auth=bioinfo.icapture.ubc.ca&uri=YOUR_REGISTRY_NAMESPACE&url=YOUR_REGISTRY_EN DPOINT, and generates RDF based on any registry as long as you fill in the url, uri and specify a servicename (name) and service provider authority (auth). The agent based registration via registerService currently works for mobycentral and the test registery on bioinfo (or any other registry that has deployed, and configured the agent). Let me know if this helps! Eddie > -----Original Message----- > From: Mark Wilkinson [mailto:markw at illuminae.com] > Sent: Tuesday, June 27, 2006 8:31 AM > To: Core developer announcements; Eddie Kawas > Cc: mobydev > Subject: Re: [moby] [MOBY-dev] XML registration > > Hi Antonio, > > I agree that, in hindsight, it would have made more sense for > those two blocks of XML to be identical, but they are not. > As such, at the moment you will need to do a small amount of > manipulation to derive the registerService XML from the > findService XML. > > I'm going to bounce this over to Eddie, since this problem > *HAS* been solved with the RDF-based registration, which is > an extension of the MOBY API but not yet part of the official > API. Nevertheless, I believe that the functionality exists > and is bug-free in the current codebase, so if you wanted to > "live on the edge" you could use it. > > Eddie will be able to indicate what the state of that code > is, and when it will become an official part of the API. > > M > > > > On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: > > Hi, I am trying to register a service from a XML file using the > > Perl API. But the XML coming from findService function is > different to > > that accepted by registerService. Is there any way to > register a new > > service from the XML given by registerService? > > Thanks in advance, > > > > Antonio. > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics University of > British Columbia PI in Bioinformatics, iCAPTURE Centre St. > Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > From aperezp at uma.es Wed Jun 28 08:45:49 2006 From: aperezp at uma.es (=?ISO-8859-1?Q?=22Antonio_J=2E_P=E9rez=22?=) Date: Wed, 28 Jun 2006 10:45:49 +0200 Subject: [MOBY-dev] [moby] XML registration In-Reply-To: <005201c69a01$f7213030$6700a8c0@notebook> References: <005201c69a01$f7213030$6700a8c0@notebook> Message-ID: <44A241BD.8050902@uma.es> Hi Eddie, thank you for your mail. I will check all your information and I will tell you. Kind regards, Antonio. Ed Kawas escribi?: > Hi Antonio, > > One way you could perform a bulk registration of services is by using the > registerService call with no parameters except for signatureURL (currently > undocumented on the moby website, but if you read the comments for the > registerService sub in the perl module Central.pm you will find some > documentation). > > SignatureURL would point to a file containing the services that you would like > to register in RDF format. One way to get the RDF is to use the LSID resolver > (http://mobycentral.icapture.ubc.ca/LSID_resolver.html, useful for mobycentral > only), an RDF generating servlet > (http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerator?name=parseBlastTe > xt&auth=bioinfo.icapture.ubc.ca&uri=YOUR_REGISTRY_NAMESPACE&url=YOUR_REGISTRY_EN > DPOINT, and generates RDF based on any registry as long as you fill in the url, > uri and specify a servicename (name) and service provider authority (auth). > > The agent based registration via registerService currently works for mobycentral > and the test registery on bioinfo (or any other registry that has deployed, and > configured the agent). > > Let me know if this helps! > > Eddie > > >> -----Original Message----- >> From: Mark Wilkinson [mailto:markw at illuminae.com] >> Sent: Tuesday, June 27, 2006 8:31 AM >> To: Core developer announcements; Eddie Kawas >> Cc: mobydev >> Subject: Re: [moby] [MOBY-dev] XML registration >> >> Hi Antonio, >> >> I agree that, in hindsight, it would have made more sense for >> those two blocks of XML to be identical, but they are not. >> As such, at the moment you will need to do a small amount of >> manipulation to derive the registerService XML from the >> findService XML. >> >> I'm going to bounce this over to Eddie, since this problem >> *HAS* been solved with the RDF-based registration, which is >> an extension of the MOBY API but not yet part of the official >> API. Nevertheless, I believe that the functionality exists >> and is bug-free in the current codebase, so if you wanted to >> "live on the edge" you could use it. >> >> Eddie will be able to indicate what the state of that code >> is, and when it will become an official part of the API. >> >> M >> >> >> >> On Mon, 2006-06-26 at 13:06 +0200, "Antonio J. P?rez" wrote: >> >>> Hi, I am trying to register a service from a XML file using the >>> Perl API. But the XML coming from findService function is >>> >> different to >> >>> that accepted by registerService. Is there any way to >>> >> register a new >> >>> service from the XML given by registerService? >>> Thanks in advance, >>> >>> Antonio. >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> -- >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics University of >> British Columbia PI in Bioinformatics, iCAPTURE Centre St. >> Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > From raulfdez at lcc.uma.es Wed Jun 28 09:24:01 2006 From: raulfdez at lcc.uma.es (Raul) Date: Wed, 28 Jun 2006 11:24:01 +0200 Subject: [MOBY-dev] a por los workflows! In-Reply-To: <44A241BD.8050902@uma.es> Message-ID: <000601c69a94$98b824c0$0bd6d696@hyperion> Hola Antonio, Volviste a probar los workflows en MOWServ? Te funcionan ya? Necesito q me pases algunos de esos workflows q dices q funcionan en Taverna y no funcionan en la aplicaci?n, para ver que pasa. Saludos, Ra?l From senger at ebi.ac.uk Wed Jun 28 16:31:25 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 28 Jun 2006 17:31:25 +0100 (BST) Subject: [MOBY-dev] java 1.5 comming Message-ID: Dear developers, I have (only slighty) changed the documentation and the build.xml file - from now the 'latest' Java is considered the 1.6 one. When you start putting there a real Java 1.5. code, and if it from some reasons does not compile, let me knowasap and I will fix build.xml again. Hopefully, however, everything is fine. I have also made small (invisible) changes in Dashboard - hopefully fixing some bugs. So consider to cvs update. Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Thu Jun 29 18:40:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 29 Jun 2006 11:40:53 -0700 Subject: [MOBY-dev] Request to curate the text* branch of the Object ontology Message-ID: <1151606453.8650.16.camel@bioinfo.icapture.ubc.ca> Hi all, If anyone has noticed, the text* branches of the Object ontology are a total mess! We have: text-plain text_plain text_formatted ISA text_plain text-formatted ISA text-plain text-html text-xml text-base64 I would like to do some manual curation of the ontology to clean this up a bit. What I propose is: text-plain text-formatted text-html text-xml text-xhtml text-base64 We'll need to leave text_plain and its child objects in the ontology for the moment since they are being used, but I'll try to get in touch with the service providers and ask if they would be willing to migrate their services to use the text-plain tree instead. Since these objects are all derived from each other through ISA links alone, it should be safe to do this manipulation (i.e. it will not re- define the structure of any object, so nobody's service will break). It will simply make it more sensible for people to register services that operate on text. At the moment, services that parse text must be registered as consuming Object in order to catch all of the different types of text! Ugh... Are there any objections to me doing this? M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jun 29 20:13:32 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 29 Jun 2006 13:13:32 -0700 Subject: [MOBY-dev] exception reporting Message-ID: Hi all, Has anyone implemented the ability to report exceptions into the Perl services code? M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From Usadel at mpimp-golm.mpg.de Fri Jun 30 12:38:32 2006 From: Usadel at mpimp-golm.mpg.de (Bjoern Usadel) Date: Fri, 30 Jun 2006 14:38:32 +0200 Subject: [MOBY-dev] exception reporting References: Message-ID: <8233DF2244998040848283889E22DBA0040F1A@MAIL.mpimp-golm.mpg.de> Hi, I hope I did, as announced, in CommonSubs 1.91. In responseHeader you now can use the additional variable -exception which should be xml encoded. To get this xml encoded message for one exception I added a sub encodeException -refElement => 'refers to the queryID of the offending input mobyData', -refQueryID => 'refers to the articleName of the offending input Simple or Collection' -severity=>'error' -exceptionCode=>'An error code ' -exceptionMessage=>'a human readable description for the error code' And then there is getExceptions. /all theses subs should be perldoced All services at authority "mapman.mpimp-golm.mpg.de" should use exception reporting (central& testing ones, so if someone from the Java fraction wants to check this I would be happy. Cheers, Bj?rn PS Currently I am on a conference I will include a perl example in the docs when coming back. -----Original Message----- From: moby-dev-bounces at lists.open-bio.org on behalf of Mark Wilkinson Sent: Thu 6/29/2006 10:13 PM To: Core developer announcements Subject: [MOBY-dev] exception reporting Hi all, Has anyone implemented the ability to report exceptions into the Perl services code? M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3335 bytes Desc: not available URL: From markw at illuminae.com Fri Jun 30 17:30:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Jun 2006 10:30:53 -0700 Subject: [MOBY-dev] [moby] Re: exception reporting In-Reply-To: <8233DF2244998040848283889E22DBA0040F1A@MAIL.mpimp-golm.mpg.de> References: <8233DF2244998040848283889E22DBA0040F1A@MAIL.mpimp-golm.mpg.de> Message-ID: <1151688653.8248.23.camel@bioinfo.icapture.ubc.ca> Excellent! Cheers! M On Fri, 2006-06-30 at 14:38 +0200, Bjoern Usadel wrote: > Hi, > > I hope I did, as announced, in CommonSubs 1.91. > > In responseHeader you now can use the additional variable -exception which should be xml encoded. > To get this xml encoded message for one exception I added a sub > encodeException > -refElement => 'refers to the queryID of the offending input mobyData', > -refQueryID => 'refers to the articleName of the offending input Simple or Collection' > -severity=>'error' > -exceptionCode=>'An error code ' > -exceptionMessage=>'a human readable description for the error code' > > And then there is getExceptions. > > /all theses subs should be perldoced > > All services at authority "mapman.mpimp-golm.mpg.de" should use exception reporting (central& testing ones, so if someone from the Java fraction wants to check this I would be happy. > > Cheers, > Bj?rn > > PS Currently I am on a conference I will include a perl example in the docs when coming back. > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org on behalf of Mark Wilkinson > Sent: Thu 6/29/2006 10:13 PM > To: Core developer announcements > Subject: [MOBY-dev] exception reporting > > Hi all, > > Has anyone implemented the ability to report exceptions into the Perl > services code? > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future