From d.haase at gsf.de Tue Dec 5 10:10:25 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 5 Dec 2006 16:10:25 +0100 Subject: [MOBY-dev] PlaNet registry shutdown Message-ID: <200612051610.27170.d.haase@gsf.de> Hi all, I'd like to announce that the PlaNet Moby Central at MIPS is very soon to shut down. The reasons are very simple: PlaNet ran out in 2005 and maintenance of a registry costs time - which is not funded anymore. This already led to limited functionality, the LSID resolver was never set up which made it unusable in Taverna. I tried to convince maintainers of PlaNet exclusive services to move their stuff to Canada and was somehow successful. So hardly any (working) service will get lost for the community. This message is mainly for those who run clients which may access PlaNet central. Please remove any pointers to http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl from your applications. I guess by Christmas requests on this URL will result in a 404. Of course, this has no effect on the PlaNet portal which will still be available under http://mips.gsf.de/projects/plants/PlaNetPortal/ Thanks and regards, dirk PS: sorry if you received this twice, there were some problems when I first sent it... From groscurt at mpiz-koeln.mpg.de Tue Dec 5 11:02:55 2006 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Tue, 5 Dec 2006 17:02:55 +0100 Subject: [MOBY-dev] =?iso-8859-1?q?RFC_-_Synchronization_of_Biomoby_second?= =?iso-8859-1?q?ary=A0=A0=A0=A0repositories?= Message-ID: <200612051702.56039.groscurt@mpiz-koeln.mpg.de> >The amount of RSS-RDF ? >we would have to maintain on MOBY Central in order to have a complete ? >history that would allow a mirror to reliably re-construct the current ? >state of the database is... well... large! ?At the moment, I keep only the ? >last... 100?... changes. ?If you don't pick-up the feed for a day, or if ? >someone registers 1000 new services, you wont see them in the feed. ? You are definitely right, if a secondary fails to synchronize with the central for a long time the number of changes are enormously large, but therefore the time stamp plays its role. Each secondary stores the time stamp of its last synchronization - furthermore in the RSS the latest 30 / 100 (or whatever) changes are written also with the time stamp of the actual change. So with each RSS fetching, the secondary is able to determine whether it is out of sync. And if so, the secondary calls the central to retrieve a specific RSS for the changes it lacks. So this is independent from the 'normal' RSS. Also it is discussable whether to force the secondary to fetch the RSS feed at least once a day or any other frequency. So one can shorten that frequency but not extend it. I'm not quite sure whether i said something completely inappropriate according your concerns - Heiko will clear that out I guess if so ;-) Cheers Andreas From martin.senger at gmail.com Tue Dec 5 12:20:19 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 5 Dec 2006 17:20:19 +0000 Subject: [MOBY-dev] PlaNet registry shutdown In-Reply-To: <200612051610.27170.d.haase@gsf.de> References: <200612051610.27170.d.haase@gsf.de> Message-ID: <4d93f07c0612050920k61365009gf05bcb27202e5fd@mail.gmail.com> Sorry to hear it, but thanks for the info. I have removed the following from Jmoby and Perl-jMoby. Please CVS update. Cheers, Martin new Registry ("MIPS", "http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl", "http://mips.gsf.de/MOBY/Central", "MIPS, Germany", "Dirk Haase (d.haase at gsf.de)", true, ""), -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Wed Dec 6 12:30:52 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 06 Dec 2006 10:30:52 -0700 Subject: [MOBY-dev] New MobyServlet methodology Message-ID: <4576FE4C.2030805@ucalgary.ca> Hi all, FYI, I have made a major change to the way MobyServlet works. It now uses Java annotations to define service meta-data. For those of you not familiar with this Java 1.5 feature, here is how you'd write a service: import org.biomoby.shared.data.*; import org.biomoby.service.*; @mobyService(name="ConvertAAtoFASTA_AA", type="FormatConversion", provider="moby.ucalgary.ca", author="gordonp at ucalgary.ca", in={"inseq:AminoAcidSequence"}, out={"outseq:FASTA_AA"}, description={"Converts amino acid objects into FastA formatted records, ", "primarily to increase inter-service compatibility"}) public class ConvertAAtoFASTA_AA extends MobyServlet{ public void processRequest(MobyDataJob request, MobyDataJob result) throws Exception{ // insert your code here... } } That's it! We've created an Ant build file (and an associated properties file) to support this, the highlights being: ant test ant war ant registerService Please see the detailed tutorial at http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html If anyone's got an Oracle or IBM servlet engine to test this on, I'd appreciate the feedback. Regards, Paul (with Quang Trinh's help on the Ant stuff) From natalia.jimenez at pcm.uam.es Thu Dec 7 06:04:47 2006 From: natalia.jimenez at pcm.uam.es (Natalia Jimenez Lozano) Date: Thu, 07 Dec 2006 12:04:47 +0100 Subject: [MOBY-dev] registering INB services in Canada Message-ID: <4577F54F.5020903@pcm.uam.es> Hi, I would like to open a discussion about ontologies. I belong to the INB where we have currently a lot of working services. We would like to register all of our services in Canada but due to the differences between both ontologies (Canada and Spain), we could ran into the following problems: a) Identical objects (objects that share the same name and the same hierarchy): in this case there would be no problem using the object previously registered in Canada. b) Analogous objects (objects that share the same name but different hierarchy): it would be possible to register in Canada the object with the same name but different hierarchy? If it would be possible we would be "breaking" the Canadian ontology :-( Some examples of this situation can be easily found: b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of text_formatted node but in Canadian ontology is a son of BLAST-Report that is at the same time a son of Sequence_alignment_report. b.2. There is a lot of common objects like Clustalw_Evaluated_Text, FASTA, GFF ..., etc which only difference is their depencency: in Canadian ontology, these objects are depending on text-formatted node but in the Spanish ontology on text_formatted (the only difference is hyphen/underscore!). c) Similar objects (different name -similar, upper-case/lower case, underscore/hyphen- and/or different hierarchy but same meaning): to fit to this last situation, we have several options: - To register INB objects -> this would not "break" the Canadian ontology but would "blur" it. - To adjust each one of the INB services to the Canadian ontology -> This would mean the modification of the code of each one of the services and it would require an extra work. - To modify INB ontology to adjust to Canadian ontology -> This would be a thorny issue because since INB beginnings we have work very hard in this sense. Even we organized an ontology committee to give advise on each new object to be registered. Moreover, few months ago we restructured our ontology with the aim of removing inconsistencies. In my opinion, we have currently a very solid ontology. Suggestions about how to register INB services in a easily and not damaging way? Thank you very much in advance, Regards, Natalia From markw at illuminae.com Sat Dec 9 22:48:09 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 09 Dec 2006 19:48:09 -0800 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: <4577F54F.5020903@pcm.uam.es> References: <4577F54F.5020903@pcm.uam.es> Message-ID: The immortal words of Phillip Lord are ringing in my head right now... "An ontology is not an ontology unless it is SHARED!" :-) This is a topic that has been discussed (perhaps not on-list?) for many years - going all the way back to the first group (PlaNet) who set up their own registry. If you "fork" the ontology, then everything breaks, unfortunately. I don't think we have ever found a workable solution to this situation. Next-generation MOBY, with RDF/OWL and reasoning and such, may be able to deal with this problem, but MOBY-S is pretty much stuck with one, centralized ontology (which, in our defence, is how the vast majority of ontologies work at this point in Web history). I'm just catching up with my emails after being away for 10 days. I don't see anyone else responding to this so far. I don't have any suggestions to help you at the moment, but I can raise it at my next lab meeting and perhaps an idea will come up...?? I have a feeling that there isn't a "magic" solution. MOBY works *because* we all agree on the ontology. If you don't agree on the ontology, then you aren't interoperable... it's pretty much the core principle of the project... M On Thu, 07 Dec 2006 03:04:47 -0800, Natalia Jimenez Lozano wrote: > Hi, > > I would like to open a discussion about ontologies. I belong to the INB > where we have currently a lot of working services. We would like to > register all of our services in Canada but due to the differences > between both ontologies (Canada and Spain), we could ran into the > following problems: > > a) Identical objects (objects that share the same name and the same > hierarchy): in this case there would be no problem using the object > previously registered in Canada. > > b) Analogous objects (objects that share the same name but different > hierarchy): it would be possible to register in Canada the object with > the same name but different hierarchy? If it would be possible we would > be "breaking" the Canadian ontology :-( > > Some examples of this situation can be easily found: > > b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of > text_formatted node but in Canadian ontology is a son of BLAST-Report > that is at the same time a son of Sequence_alignment_report. > b.2. There is a lot of common objects like Clustalw_Evaluated_Text, > FASTA, GFF ..., etc which only difference is their depencency: in > Canadian ontology, these objects are depending on text-formatted node > but in the Spanish ontology on text_formatted (the only difference is > hyphen/underscore!). > > c) Similar objects (different name -similar, upper-case/lower case, > underscore/hyphen- and/or different hierarchy but same meaning): to fit > to this last situation, we have several options: > > - To register INB objects -> this would not "break" the Canadian > ontology but would "blur" it. > - To adjust each one of the INB services to the Canadian ontology -> > This would mean the modification of the code of each one of the services > and it would require an extra work. > - To modify INB ontology to adjust to Canadian ontology -> This > would be a thorny issue because since INB beginnings we have work very > hard in this sense. Even we organized an ontology committee to give > advise on each new object to be registered. Moreover, few months ago we > restructured our ontology with the aim of removing inconsistencies. In > my opinion, we have currently a very solid ontology. > > Suggestions about how to register INB services in a easily and not > damaging way? > Thank you very much in advance, > Regards, > Natalia > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From martin.senger at gmail.com Sun Dec 10 08:08:31 2006 From: martin.senger at gmail.com (Martin Senger) Date: Sun, 10 Dec 2006 14:08:31 +0100 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: References: <4577F54F.5020903@pcm.uam.es> Message-ID: <4d93f07c0612100508t2e420b61m53d306421bc77afa@mail.gmail.com> > I don't see anyone else responding to this so far. Well, I have not replied because I did not know how to say politely "what you are asking for sucks" :-). I am 100% with you - we either share or we are dead. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Sun Dec 10 10:25:20 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Sun, 10 Dec 2006 08:25:20 -0700 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: References: <4577F54F.5020903@pcm.uam.es> Message-ID: <457C26E0.6060403@ucalgary.ca> Right. Fixing this type of issue systematically (as opposed to one-off manually) is the kind of stuff that makes up a computer science PhD thesis... :-) > If you "fork" the ontology, then everything breaks, > unfortunately. I don't think we have ever found a workable solution to > this situation. Next-generation MOBY, with RDF/OWL and reasoning and > such, may be able to deal with this problem, but MOBY-S is pretty much > stuck with one, centralized ontology (which, in our defence, is how the > vast majority of ontologies work at this point in Web history). > From Pieter.Neerincx at wur.nl Sun Dec 10 10:57:59 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sun, 10 Dec 2006 16:57:59 +0100 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: <4d93f07c0612100508t2e420b61m53d306421bc77afa@mail.gmail.com> References: <4577F54F.5020903@pcm.uam.es> <4d93f07c0612100508t2e420b61m53d306421bc77afa@mail.gmail.com> Message-ID: <750FD1D2-77A6-4F0A-B360-5DFB34BB7EC3@wur.nl> On 10 Dec 2006, at 14:08, Martin Senger wrote: >> I don't see anyone else responding to this so far. > > > Well, I have not replied because I did not know how to say politely > "what > you are asking for sucks" :-). I am 100% with you - we either > share or we > are dead. I agree. This sounds to me like the same problem which occurs when people find out someone else has already registered their favorite internet domain name: too bad you are too late! BioMOBY works only well if we share the same ontology which works with a first come, first registered policy. On the other hand the idea of a manually curated ontology does not sound bad too me. Surely it causes extra work, but lets look at the past. There are many biological concepts that were first labeled more or less at random causing a big mess with synonyms, homonyms, etc. Later on standardization committees were appointed to clean up the ambiguity. It happened to species names, genes, proteins, chemical compounds, you name it... Groups like HUGO are doing a fine job, but especially gene and protein names are still a disaster for data- and text-mining software. Maybe we should have started curating the ontology yesterday... So I like the idea of manually curating the ontology (and I volunteer for some of the work that might cause), but I would have liked the idea even more if the people at INB would have made it a community effort from the start :). Cheers, Pi > > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From phillip.lord at newcastle.ac.uk Mon Dec 11 11:06:12 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Mon, 11 Dec 2006 16:06:12 +0000 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: (Mark Wilkinson's message of "Sat, 09 Dec 2006 19:48:09 -0800") References: <4577F54F.5020903@pcm.uam.es> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> The immortal words of Phillip Lord are ringing in my head Mark> right now... "An ontology is not an ontology unless it is Mark> SHARED!" :-) I'm sure that I stole it from somewhere. Mark> This is a topic that has been discussed (perhaps not on-list?) Mark> for many years - going all the way back to the first group Mark> (PlaNet) who set up their own registry. If you "fork" the Mark> ontology, then everything breaks, unfortunately. I don't Mark> think we have ever found a workable solution to this Mark> situation. Next-generation MOBY, with RDF/OWL and reasoning Mark> and such, may be able to deal with this problem, but MOBY-S is Mark> pretty much stuck with one, centralized ontology (which, in Mark> our defence, is how the vast majority of ontologies work at Mark> this point in Web history). Mark> I'm just catching up with my emails after being away for 10 Mark> days. I don't see anyone else responding to this so far. I Mark> don't have any suggestions to help you at the moment, but I Mark> can raise it at my next lab meeting and perhaps an idea will Mark> come up...?? I have a feeling that there isn't a "magic" Mark> solution. MOBY works *because* we all agree on the ontology. Mark> If you don't agree on the ontology, then you aren't Mark> interoperable... it's pretty much the core principle of the Mark> project... If I may be so bold, I think Natalia has a point, but not necessarily the right solution. INB could easily register their services by knocking out a mapping between the two ontologies and then they could translate. But this would be a pain, and error prone. So the question has to be, why have two ontologies arisen. My suspicion is that there is not enough discussion and change within the existing ontology allowing it to extend to their purposes. After all, I've read lots of stuff on this list about code enhancement (and not read far more), but relatively little about ontology extensions. Perhaps the INB ontology can be used to integrate into the Canadian ontology, to the value of both? Of course, I'm only really a lurker on this mailing list, so my apologies if I am way of the mark. BTW, reasoning and RDF/OWL is never going to deal with this problem; it might make the problem less severe, but it's still going to be an issue. Phil From gordonp at ucalgary.ca Mon Dec 11 11:05:48 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 11 Dec 2006 09:05:48 -0700 Subject: [MOBY-dev] CVS messed up? Message-ID: <457D81DC.1070606@ucalgary.ca> Anyone else getting weird error messages on CVS commands on MOBY? cvs diff: failed to create lock directory for `/home/repository/moby/********************' (/home/repository/moby/********************/#cvs.lock): No such file or directory Other weird, non-printing characters show up as directory names too... From gordonp at ucalgary.ca Mon Dec 11 13:52:16 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 11 Dec 2006 11:52:16 -0700 Subject: [MOBY-dev] Collections vs. Simples in registry service searches, a bug? Message-ID: <457DA8E0.4020806@ucalgary.ca> Hi all, Is there any reason that a service taking a *collection* of DNASequences as input is returned when I perform a query asking for services that take a *simple* DNASequence as input? e.g. the GenerateCodonPairTable service takes a collection and is returned on a simple DNASequence search. Here is the relevant part of the RDF from the registry: inputSequences And the request is: DNASequence seahawk moby 1 1 0 From martin.senger at gmail.com Mon Dec 11 11:36:06 2006 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 11 Dec 2006 16:36:06 +0000 Subject: [MOBY-dev] CVS messed up? In-Reply-To: <457D81DC.1070606@ucalgary.ca> References: <457D81DC.1070606@ucalgary.ca> Message-ID: <4d93f07c0612110836i4e6702efg267cf559337bbd3@mail.gmail.com> On 12/11/06, Paul Gordon wrote: > > Anyone else getting weird error messages on CVS commands on MOBY? > > cvs diff: failed to create lock directory for > `/home/repository/moby/********************' > (/home/repository/moby/********************/#cvs.lock): No such file or > directory > > Other weird, non-printing characters show up as directory names too... I have not noticed (but I have not committed anything recently). I am cc-ing your email to Chris (who is in chrage of all open-bio servers, and many more). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From d.haase at gsf.de Tue Dec 12 10:18:02 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 12 Dec 2006 16:18:02 +0100 Subject: [MOBY-dev] getSignatureForm down Message-ID: <200612121618.02536.d.haase@gsf.de> Hi, it seems that the getSignatureForm servlet (http://mobycentral.icapture.ubc.ca:8090/servlets/forms/getSignatureForm) is down - I think already for a couple of days now. Can somebody fix that? Thanks, dirk From jdr0887 at renci.org Tue Dec 12 11:18:21 2006 From: jdr0887 at renci.org (Jason Reilly) Date: Tue, 12 Dec 2006 11:18:21 -0500 Subject: [MOBY-dev] empty collections Message-ID: <457ED64D.7010603@renci.org> Hi all, I have encountered an issue and want to get some feedback. The issue is concerning empty collections. Say, for example, I have a Taverna workflow where a Moby service takes a collection that passes *optional* parameters to the service. In the case I am using, I wrote a blast service where it takes a few parameters like 'database' and 'blastType' (required), as well as a collection of parameters (optional) to be passed to the blast service. When I run the workflow from Taverna and I leave the input for the collection empty/null, I get an NPE in the generated moby skeleton when it tries to synchronize. If I just create a collection, but don't populate anything in it, Taverna throws a ServiceFailure ("At least one mobySimple object is needed to build the moby collection") . I would propose just wrapping the synchronize block in a not null check, but it would be very easy to create another service....one with parameters and one without. What is the intent of not allowing empty collections? Is this a feature or a bug? From edward.kawas at gmail.com Tue Dec 12 12:57:34 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 12 Dec 2006 09:57:34 -0800 Subject: [MOBY-dev] empty collections In-Reply-To: <457ED64D.7010603@renci.org> Message-ID: <003101c71e17$01f40980$6900a8c0@notebook> Hi Jason, Currently, if a service doesn't have input parameters, it wouldn't be invoked in Taverna. I will attempt to address this in the very near future! It makes complete sense to support services that don't have inputs but do have outputs. For my own information, what service are you attempting to use? 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 Jason Reilly > Sent: Tuesday, December 12, 2006 8:18 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] empty collections > > Hi all, > > I have encountered an issue and want to get some feedback. > The issue is concerning empty collections. Say, for example, > I have a Taverna workflow where a Moby service takes a > collection that passes *optional* parameters to the service. > In the case I am using, I wrote a blast service where it > takes a few parameters like 'database' and 'blastType' > (required), as well as a collection of parameters (optional) > to be passed to the blast service. When I run the workflow > from Taverna and I leave the input for the collection > empty/null, I get an NPE in the generated moby skeleton when > it tries to synchronize. If I just create a collection, but > don't populate anything in it, Taverna throws a > ServiceFailure ("At least one mobySimple object is needed to > build the moby collection") . > > I would propose just wrapping the synchronize block in a not > null check, but it would be very easy to create another > service....one with parameters and one without. What is the > intent of not allowing empty collections? Is this a feature or a bug? > > > > > _______________________________________________ > 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 Tue Dec 12 11:25:44 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 12 Dec 2006 08:25:44 -0800 Subject: [MOBY-dev] getSignatureForm down In-Reply-To: <200612121618.02536.d.haase@gsf.de> Message-ID: <001b01c71e0a$2d6839e0$6900a8c0@notebook> Hi Dirk, The page has moved to http://mobycentral.icapture.ubc.ca:8090/authority/forms/getSignatureForm. Where is that old reference? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, December 12, 2006 7:18 AM > To: Core developer announcements > Subject: [MOBY-dev] getSignatureForm down > > Hi, > > it seems that the getSignatureForm servlet > (http://mobycentral.icapture.ubc.ca:8090/servlets/forms/getSig > natureForm) is down - I think already for a couple of days now. > > Can somebody fix that? > > Thanks, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From nassar at renci.org Tue Dec 12 15:36:11 2006 From: nassar at renci.org (Nassib Nassar) Date: Tue, 12 Dec 2006 15:36:11 -0500 Subject: [MOBY-dev] sequence datatypes Message-ID: <20061212203611.GA9247@renci.org> Hi, I'd like to start explaining a little bit about our use of biomoby and also request feedback... We're using biomoby mainly with taverna workflows, and gradually migrating current web services over to become biomoby services (under biomoby.renci.org). The workflows we develop are talking to services that for the most part are based here within our servers. As a result we end up passing a very large amount of duplicated sequence data over the network between taverna and services, often more data than taverna is happy about. To get around this we have started passing sequences by reference using a FASTA-like format that is non-standard but fits well into our system and the taverna UI. I'm calling this the "RENCI sequence" format, and it's basically similar to GenBank, while allowing an "abbreviated" (truncated) form that consists of only a partial header line with at least one namespace/id. (The architecture is described in http://www.renci.org/~nassar/sequence_registry.ppt ) We've added some new datatypes under "RenciSequence" for this purpose, analogous to the existing "GenericSequence". In general we are using the existing biomoby datatypes, but for sequences our format seems unusual enough that we thought it needed its own datatype to avoid confusion. Nassib From gordonp at ucalgary.ca Tue Dec 12 16:40:45 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 12 Dec 2006 14:40:45 -0700 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <20061212203611.GA9247@renci.org> References: <20061212203611.GA9247@renci.org> Message-ID: <457F21DD.7030904@ucalgary.ca> Hi Nassib, I looked at the presentation, and I'm not sure why you can't just use a VirtualSequence instead. You can then have all of the combinations you want, as long as you register the namespaces: 1500 1500 1500 1500 ATG... etc., etc. > Hi, > > I'd like to start explaining a little bit about our use of biomoby and > also request feedback... > > We're using biomoby mainly with taverna workflows, and gradually > migrating current web services over to become biomoby services (under > biomoby.renci.org). The workflows we develop are talking to services > that for the most part are based here within our servers. As a result > we end up passing a very large amount of duplicated sequence data over > the network between taverna and services, often more data than taverna > is happy about. To get around this we have started passing sequences > by reference using a FASTA-like format that is non-standard but fits > well into our system and the taverna UI. I'm calling this the "RENCI > sequence" format, and it's basically similar to GenBank, while > allowing an "abbreviated" (truncated) form that consists of only a > partial header line with at least one namespace/id. (The architecture > is described in http://www.renci.org/~nassar/sequence_registry.ppt ) > > We've added some new datatypes under "RenciSequence" for this purpose, > analogous to the existing "GenericSequence". In general we are using > the existing biomoby datatypes, but for sequences our format seems > unusual enough that we thought it needed its own datatype to avoid > confusion. > > Nassib > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From Yogaraj.Khanal at usd.edu Wed Dec 13 00:53:53 2006 From: Yogaraj.Khanal at usd.edu (Yogaraj.Khanal at usd.edu) Date: Tue, 12 Dec 2006 23:53:53 -0600 Subject: [MOBY-dev] sequence datatypes Message-ID: <416d7a0416d85b.416d85b416d7a0@usd.edu> hi to all, i got problem executing this web service can anyone help me /* * Moby.java * * Created on December 3, 2006, 9:33 AM * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ import org.biomoby.client.*; import org.biomoby.shared.*; import org.biomoby.shared.data.*; /** * * @author yogaraj.khanal */ public class Moby { /** Creates a new instance of Moby */ public Moby() { } /** * @param args the command line arguments */ public static void main(String[] args) throws Exception{ Central worker = new CentralImpl(); MobyService templateService = new MobyService("runGeneIDGFF"); System.out.println(templateService.getName()); System.out.println(templateService.getUniqueName()); System.out.println(templateService.getAuthority()); MobyPrimaryData[] priinput=templateService.getPrimaryInputs(); System.out.println(priinput); MobyService[] validServices = worker.findService(templateService.getId()); System.out.println(validServices); MobyRequest mr = new MobyRequest(worker); //mr.setService(validServices[0]); //mr.setInput(new MobyDataObject("", "")); System.out.println(mr.invokeService().toString()); //MobyRequest mr = new MobyRequest(worker); mr.setService(validServices[10]); mr.setInput(new MobyDataObject("NCBI_gi", "111076")); MobyDataType dataType=new MobyDataType("AminoAcidSequence"); mr.setInput(new MobyDataObject("AminoAcidSequence")); MobyDataSecondaryInstance[] secondaryData=new MobyDataSecondaryInstance[5]; MobySecondaryData p1=new MobySecondaryData("strand"); p1.setDataType("String"); p1.setDefaultValue("Reverse"); MobySecondaryData p2=new MobySecondaryData("profile"); p2.setDataType("String"); p2.setDefaultValue("Arabidopsis thalina(weed)"); MobySecondaryData p3=new MobySecondaryData("engine"); p3.setDataType("String"); p3.setDefaultValue("Exon Mode"); MobySecondaryData p4=new MobySecondaryData("signals"); p4.setDataType("String"); p4.setDefaultValue("Start condons"); MobySecondaryData p5=new MobySecondaryData("exons"); p5.setDataType("String"); p5.setDefaultValue("All exons"); secondaryData[0]=new MobyDataSecondaryInstance(p1); secondaryData[1]=new MobyDataSecondaryInstance(p2); secondaryData[2]=new MobyDataSecondaryInstance(p3); secondaryData[3]=new MobyDataSecondaryInstance(p4); secondaryData[4]=new MobyDataSecondaryInstance(p5); mr.setSecondaryInput(secondaryData); System.out.println(mr.invokeService().toString()); // TODO code application logic here } } ----- Original Message ----- From: Paul Gordon Date: Tuesday, December 12, 2006 3:40 pm Subject: Re: [MOBY-dev] sequence datatypes > Hi Nassib, > > I looked at the presentation, and I'm not sure why you can't just > use a > VirtualSequence instead. You can then have all of the > combinations you > want, as long as you register the namespaces: > > > 1500 > > > > 1500 > > > > 1500 > > > > 1500 > id="">ATG... > > etc., etc. > > Hi, > > > > I'd like to start explaining a little bit about our use of > biomoby and > > also request feedback... > > > > We're using biomoby mainly with taverna workflows, and gradually > > migrating current web services over to become biomoby services > (under> biomoby.renci.org). The workflows we develop are talking > to services > > that for the most part are based here within our servers. As a > result> we end up passing a very large amount of duplicated > sequence data over > > the network between taverna and services, often more data than > taverna> is happy about. To get around this we have started > passing sequences > > by reference using a FASTA-like format that is non-standard but fits > > well into our system and the taverna UI. I'm calling this the > "RENCI> sequence" format, and it's basically similar to GenBank, while > > allowing an "abbreviated" (truncated) form that consists of only a > > partial header line with at least one namespace/id. (The > architecture> is described in > http://www.renci.org/~nassar/sequence_registry.ppt ) > > > > We've added some new datatypes under "RenciSequence" for this > purpose,> analogous to the existing "GenericSequence". In general > we are using > > the existing biomoby datatypes, but for sequences our format seems > > unusual enough that we thought it needed its own datatype to avoid > > confusion. > > > > Nassib > > _______________________________________________ > > 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 Yogaraj.Khanal at usd.edu Wed Dec 13 00:55:18 2006 From: Yogaraj.Khanal at usd.edu (Yogaraj.Khanal at usd.edu) Date: Tue, 12 Dec 2006 23:55:18 -0600 Subject: [MOBY-dev] getSignatureForm down Message-ID: <416f0bc416aaca.416aaca416f0bc@usd.edu> hi is the execution of my program related to the current problem with the moby can anyone help me? /* * Moby.java * * Created on December 3, 2006, 9:33 AM * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ import org.biomoby.client.*; import org.biomoby.shared.*; import org.biomoby.shared.data.*; /** * * @author yogaraj.khanal */ public class Moby { /** Creates a new instance of Moby */ public Moby() { } /** * @param args the command line arguments */ public static void main(String[] args) throws Exception{ Central worker = new CentralImpl(); MobyService templateService = new MobyService("runGeneIDGFF"); System.out.println(templateService.getName()); System.out.println(templateService.getUniqueName()); System.out.println(templateService.getAuthority()); MobyPrimaryData[] priinput=templateService.getPrimaryInputs(); System.out.println(priinput); MobyService[] validServices = worker.findService(templateService.getId()); System.out.println(validServices); MobyRequest mr = new MobyRequest(worker); //mr.setService(validServices[0]); //mr.setInput(new MobyDataObject("", "")); System.out.println(mr.invokeService().toString()); //MobyRequest mr = new MobyRequest(worker); mr.setService(validServices[10]); mr.setInput(new MobyDataObject("NCBI_gi", "111076")); MobyDataType dataType=new MobyDataType("AminoAcidSequence"); mr.setInput(new MobyDataObject("AminoAcidSequence")); MobyDataSecondaryInstance[] secondaryData=new MobyDataSecondaryInstance[5]; MobySecondaryData p1=new MobySecondaryData("strand"); p1.setDataType("String"); p1.setDefaultValue("Reverse"); MobySecondaryData p2=new MobySecondaryData("profile"); p2.setDataType("String"); p2.setDefaultValue("Arabidopsis thalina(weed)"); MobySecondaryData p3=new MobySecondaryData("engine"); p3.setDataType("String"); p3.setDefaultValue("Exon Mode"); MobySecondaryData p4=new MobySecondaryData("signals"); p4.setDataType("String"); p4.setDefaultValue("Start condons"); MobySecondaryData p5=new MobySecondaryData("exons"); p5.setDataType("String"); p5.setDefaultValue("All exons"); secondaryData[0]=new MobyDataSecondaryInstance(p1); secondaryData[1]=new MobyDataSecondaryInstance(p2); secondaryData[2]=new MobyDataSecondaryInstance(p3); secondaryData[3]=new MobyDataSecondaryInstance(p4); secondaryData[4]=new MobyDataSecondaryInstance(p5); mr.setSecondaryInput(secondaryData); System.out.println(mr.invokeService().toString()); // TODO code application logic here } } ----- Original Message ----- From: Edward Kawas Date: Tuesday, December 12, 2006 10:25 am Subject: Re: [MOBY-dev] getSignatureForm down > Hi Dirk, > > The page has moved to > http://mobycentral.icapture.ubc.ca:8090/authority/forms/getSignatureForm. Where > is that old reference? > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at lists.open-bio.org > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > > Sent: Tuesday, December 12, 2006 7:18 AM > > To: Core developer announcements > > Subject: [MOBY-dev] getSignatureForm down > > > > Hi, > > > > it seems that the getSignatureForm servlet > > (http://mobycentral.icapture.ubc.ca:8090/servlets/forms/getSig > > natureForm) is down - I think already for a couple of days now. > > > > Can somebody fix that? > > > > Thanks, > > dirk > > _______________________________________________ > > 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 d.haase at gsf.de Wed Dec 13 03:43:19 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 13 Dec 2006 09:43:19 +0100 Subject: [MOBY-dev] getSignatureForm down In-Reply-To: <001b01c71e0a$2d6839e0$6900a8c0@notebook> References: <001b01c71e0a$2d6839e0$6900a8c0@notebook> Message-ID: <200612130943.19578.d.haase@gsf.de> On Tuesday 12 December 2006 17:25, Edward Kawas wrote: > Hi Dirk, > > The page has moved to > http://mobycentral.icapture.ubc.ca:8090/authority/forms/getSignatureForm. > Where is that old reference? It was on the RDF FAQ on our project site (http://bioinfo.mpiz-koeln.mpg.de/araws/documentation/help/rdf-faq), but I fixed it now. It would be nice if you would post this kind of changes to the list. Or you did and I just missed it? Best, dirk From d.haase at gsf.de Wed Dec 13 08:36:10 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 13 Dec 2006 14:36:10 +0100 Subject: [MOBY-dev] missing SignatureURL in RDF Message-ID: <200612131436.11284.d.haase@gsf.de> Hi, one of our collaborators experienced a problem with an RDF returned by MOBY Central when he registered a service ( getTrypticPeptideSequenceByAGI) using the PERL library methods. He called 'registerService' with a fully filled argument hash, including a value for 'SignatureURL'. He received an RDF description but the element where the signature URL should appear was empty. Moreover, the signatureURL was not registered (at least not displayed in dashboard). Are we missing something? dirk From martin.senger at gmail.com Wed Dec 13 11:21:09 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 13 Dec 2006 17:21:09 +0100 Subject: [MOBY-dev] getSignatureForm down In-Reply-To: <416f0bc416aaca.416aaca416f0bc@usd.edu> References: <416f0bc416aaca.416aaca416f0bc@usd.edu> Message-ID: <4d93f07c0612130821n1f07644brdc4ec8da8d238f0e@mail.gmail.com> > is the execution of my program related to the current problem with the > moby Not sure what you mean. What is the "current problem"? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Wed Dec 13 11:47:01 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 13 Dec 2006 09:47:01 -0700 Subject: [MOBY-dev] getSignatureForm down In-Reply-To: <4d93f07c0612130821n1f07644brdc4ec8da8d238f0e@mail.gmail.com> References: <416f0bc416aaca.416aaca416f0bc@usd.edu> <4d93f07c0612130821n1f07644brdc4ec8da8d238f0e@mail.gmail.com> Message-ID: <45802E85.5020708@ucalgary.ca> What is wrong with his code is pretty much everything. :-) I made a working version of it, but will wait on posting until I fix an issue related to CrossReference deserialization I came across while doing this (in an hour or so). >> is the execution of my program related to the current problem with the >> moby >> > > > Not sure what you mean. What is the "current problem"? > Martin > > > From martin.senger at gmail.com Wed Dec 13 11:15:37 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 13 Dec 2006 17:15:37 +0100 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <416d7a0416d85b.416d85b416d7a0@usd.edu> References: <416d7a0416d85b.416d85b416d7a0@usd.edu> Message-ID: <4d93f07c0612130815n7db7019fn57a3307343365cca@mail.gmail.com> > i got problem executing this web service What problem? Be please more specific. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Wed Dec 13 13:06:04 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 13 Dec 2006 11:06:04 -0700 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <416d7a0416d85b.416d85b416d7a0@usd.edu> References: <416d7a0416d85b.416d85b416d7a0@usd.edu> Message-ID: <4580410C.90707@ucalgary.ca> Hi Yogaraj, There are several fundamental issues wrong with your original program, but the most salient are: -You don't have a sequence -The sequence you tried to specify in amino acid, but the service you want to run (runGeneIDGFF) takes DNA -You're executing the request before the data is set Below is an example that does as close as I can tell to want you intended: -Fetches a DNASequence from a genbank gi number (using the MOBYSHoundGetGenBankWhateverSequence) -Executes runGeneIDGFF on the DNASequence -The secondary parameters already existing in association with the service, so you don't need to create them from scratch Enjoy! P.S. Please do a CVS update, I made a few changes to deal with the crossreferences MOBYSHoundGetGenBankWhateverSequence returns -------------- import org.biomoby.client.*; import org.biomoby.shared.*; import org.biomoby.shared.data.*; /** * * @author Paul Gordon */ public class Moby { /** * @param args the command line arguments */ public static void main(String[] args) throws Exception{ Central worker = new CentralImpl(); MobyRequest mr = new MobyRequest(worker); // Retrieve the DNASequence from the NCBI GI ID MobyService templateService = new MobyService("MOBYSHoundGetGenBankWhateverSequence"); MobyService[] validServices = worker.findService(templateService); mr.setService(validServices[0]); // id -> dna mr.setInput(new MobyDataObject("NCBI_gi","54695")); MobyContentInstance responses = mr.invokeService(); // Retrieve the GFF predictions for each DNASequence returned // (should be only one for this service, but the API doesn't know that) templateService = new MobyService("runGeneIDGFF"); validServices = worker.findService(templateService); mr.setService(validServices[0]); // dna -> gff for(MobyDataJob response: responses.values()){ for(MobyDataObject dna: response.getPrimaryDataObjects()){ mr.setInput(dna); setSecondaries(mr, validServices[0]); System.out.println(mr.invokeService().toString()); } } } public static void setSecondaries(MobyRequest mr, MobyService service){ MobySecondaryData[] secondaryData = service.getSecondaryInputs(); MobyDataSecondaryInstance[] secondaryInstances = new MobyDataSecondaryInstance[secondaryData.length]; for(int i = 0; i < secondaryData.length; i++){ MobySecondaryData param = secondaryData[i]; // Set specific values for the following params if(param.getName().equals("strand")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "Reverse"); } else if(param.getName().equals("profile")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "Arabidopsis thaliana (weed)"); } else if(param.getName().equals("engine")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "Exon Mode"); } else if(param.getName().equals("signals")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "Start codons"); } else if(param.getName().equals("exons")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "All exons"); } // Use default value for other parameters (if any) else{ secondaryInstances[i] = new MobyDataSecondaryInstance(param); } } mr.setSecondaryInput(secondaryInstances); } } > hi to all, > i got problem executing this web service can anyone help me > > /* > * Moby.java > * > * Created on December 3, 2006, 9:33 AM > * > * To change this template, choose Tools | Options and locate the template under > * the Source Creation and Management node. Right-click the template and choose > * Open. You can then make changes to the template in the Source Editor. > */ > import org.biomoby.client.*; > import org.biomoby.shared.*; > import org.biomoby.shared.data.*; > /** > * > * @author yogaraj.khanal > */ > public class Moby { > > /** Creates a new instance of Moby */ > public Moby() { > } > > /** > * @param args the command line arguments > */ > public static void main(String[] args) throws Exception{ > Central worker = new CentralImpl(); > MobyService templateService = new MobyService("runGeneIDGFF"); > System.out.println(templateService.getName()); > System.out.println(templateService.getUniqueName()); > System.out.println(templateService.getAuthority()); > MobyPrimaryData[] priinput=templateService.getPrimaryInputs(); > System.out.println(priinput); > > MobyService[] validServices = worker.findService(templateService.getId()); > System.out.println(validServices); > MobyRequest mr = new MobyRequest(worker); > //mr.setService(validServices[0]); > > //mr.setInput(new MobyDataObject("", "")); > System.out.println(mr.invokeService().toString()); > > //MobyRequest mr = new MobyRequest(worker); > mr.setService(validServices[10]); > > mr.setInput(new MobyDataObject("NCBI_gi", "111076")); > MobyDataType dataType=new MobyDataType("AminoAcidSequence"); > mr.setInput(new MobyDataObject("AminoAcidSequence")); > MobyDataSecondaryInstance[] secondaryData=new MobyDataSecondaryInstance[5]; > MobySecondaryData p1=new MobySecondaryData("strand"); > p1.setDataType("String"); > p1.setDefaultValue("Reverse"); > MobySecondaryData p2=new MobySecondaryData("profile"); > p2.setDataType("String"); > p2.setDefaultValue("Arabidopsis thalina(weed)"); > MobySecondaryData p3=new MobySecondaryData("engine"); > p3.setDataType("String"); > p3.setDefaultValue("Exon Mode"); > MobySecondaryData p4=new MobySecondaryData("signals"); > p4.setDataType("String"); > p4.setDefaultValue("Start condons"); > MobySecondaryData p5=new MobySecondaryData("exons"); > p5.setDataType("String"); > p5.setDefaultValue("All exons"); > > secondaryData[0]=new MobyDataSecondaryInstance(p1); > secondaryData[1]=new MobyDataSecondaryInstance(p2); > secondaryData[2]=new MobyDataSecondaryInstance(p3); > secondaryData[3]=new MobyDataSecondaryInstance(p4); > secondaryData[4]=new MobyDataSecondaryInstance(p5); > mr.setSecondaryInput(secondaryData); > > System.out.println(mr.invokeService().toString()); > // TODO code application logic here > } > > } > > ----- Original Message ----- > From: Paul Gordon > Date: Tuesday, December 12, 2006 3:40 pm > Subject: Re: [MOBY-dev] sequence datatypes > > >> Hi Nassib, >> >> I looked at the presentation, and I'm not sure why you can't just >> use a >> VirtualSequence instead. You can then have all of the >> combinations you >> want, as long as you register the namespaces: >> >> >> 1500 >> >> >> >> 1500 >> >> >> >> 1500 >> >> >> >> 1500 >> > id="">ATG... >> >> etc., etc. >> >>> Hi, >>> >>> I'd like to start explaining a little bit about our use of >>> >> biomoby and >> >>> also request feedback... >>> >>> We're using biomoby mainly with taverna workflows, and gradually >>> migrating current web services over to become biomoby services >>> >> (under> biomoby.renci.org). The workflows we develop are talking >> to services >> >>> that for the most part are based here within our servers. As a >>> >> result> we end up passing a very large amount of duplicated >> sequence data over >> >>> the network between taverna and services, often more data than >>> >> taverna> is happy about. To get around this we have started >> passing sequences >> >>> by reference using a FASTA-like format that is non-standard but fits >>> well into our system and the taverna UI. I'm calling this the >>> >> "RENCI> sequence" format, and it's basically similar to GenBank, while >> >>> allowing an "abbreviated" (truncated) form that consists of only a >>> partial header line with at least one namespace/id. (The >>> >> architecture> is described in >> http://www.renci.org/~nassar/sequence_registry.ppt ) >> >>> We've added some new datatypes under "RenciSequence" for this >>> >> purpose,> analogous to the existing "GenericSequence". In general >> we are using >> >>> the existing biomoby datatypes, but for sequences our format seems >>> unusual enough that we thought it needed its own datatype to avoid >>> confusion. >>> >>> Nassib >>> _______________________________________________ >>> 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 ots at ac.uma.es Wed Dec 13 13:45:21 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Wed, 13 Dec 2006 19:45:21 +0100 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: References: <4577F54F.5020903@pcm.uam.es> Message-ID: <45804A41.3050903@ac.uma.es> I'd like to provide some additional information to help understanding our perspective. 1) When we were developing the INB system we realise on the need for ensuring availability and service inter-connection based on the moby ontology. However, several mails from the moby community warned us on the importance of a curate catalogue. (i.e.) "Right now in the registry if I send a generic object I get over a hundred services back, almost none of which will actually consume the object without dying a horrible death." (Gordon, Feb 17th), or this other more explicit, "MOBY Central has become increasingly useless over the past couple of years as it got filled with junk, badly registered services, dead services, "localhost" services, test services, and all manner of other registration artifacts (M.W. response)" 2) In this sense we made a great effort in the registering procedure. We hold several internal meetings with some invited experts from the moby community to introduce, comment, discuss and get feedback about our strategy. So, it is not a new issue. 3) Natalias?s email correctly states the real-problem of different catalogues. In several previous emails the equivalent issues of federated ontologies, disperse catalogues, etc. were at least enumerated. So, it is opportune to launch the discussion. 4) My group at the GNV5-INB University of Malaga- is open to contribute in the discussion of the technical and procedural aspects involved in this issue, oriented to propose a global solution. 5) In our opinion, Natalia?s email is not the problem but part of the solution (our system works properly?at the moment at least !) with regards, O. PS, I?d like to thanks all mobiers that having nothing constructive to say have avoided reply with unfortunate emails. and finally I suspect that the Phillip Lord phrase regards **good** ontologies. Mark Wilkinson escribi?: > The immortal words of Phillip Lord are ringing in my head right now... "An > ontology is not an ontology unless it is SHARED!" :-) > > This is a topic that has been discussed (perhaps not on-list?) for many > years - going all the way back to the first group (PlaNet) who set up > their own registry. If you "fork" the ontology, then everything breaks, > unfortunately. I don't think we have ever found a workable solution to > this situation. Next-generation MOBY, with RDF/OWL and reasoning and > such, may be able to deal with this problem, but MOBY-S is pretty much > stuck with one, centralized ontology (which, in our defence, is how the > vast majority of ontologies work at this point in Web history). > > I'm just catching up with my emails after being away for 10 days. I don't > see anyone else responding to this so far. I don't have any suggestions > to help you at the moment, but I can raise it at my next lab meeting and > perhaps an idea will come up...?? I have a feeling that there isn't a > "magic" solution. MOBY works *because* we all agree on the ontology. If > you don't agree on the ontology, then you aren't interoperable... it's > pretty much the core principle of the project... > > M > > > > > On Thu, 07 Dec 2006 03:04:47 -0800, Natalia Jimenez Lozano > wrote: > > >> Hi, >> >> I would like to open a discussion about ontologies. I belong to the INB >> where we have currently a lot of working services. We would like to >> register all of our services in Canada but due to the differences >> between both ontologies (Canada and Spain), we could ran into the >> following problems: >> >> a) Identical objects (objects that share the same name and the same >> hierarchy): in this case there would be no problem using the object >> previously registered in Canada. >> >> b) Analogous objects (objects that share the same name but different >> hierarchy): it would be possible to register in Canada the object with >> the same name but different hierarchy? If it would be possible we would >> be "breaking" the Canadian ontology :-( >> >> Some examples of this situation can be easily found: >> >> b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of >> text_formatted node but in Canadian ontology is a son of BLAST-Report >> that is at the same time a son of Sequence_alignment_report. >> b.2. There is a lot of common objects like Clustalw_Evaluated_Text, >> FASTA, GFF ..., etc which only difference is their depencency: in >> Canadian ontology, these objects are depending on text-formatted node >> but in the Spanish ontology on text_formatted (the only difference is >> hyphen/underscore!). >> >> c) Similar objects (different name -similar, upper-case/lower case, >> underscore/hyphen- and/or different hierarchy but same meaning): to fit >> to this last situation, we have several options: >> >> - To register INB objects -> this would not "break" the Canadian >> ontology but would "blur" it. >> - To adjust each one of the INB services to the Canadian ontology -> >> This would mean the modification of the code of each one of the services >> and it would require an extra work. >> - To modify INB ontology to adjust to Canadian ontology -> This >> would be a thorny issue because since INB beginnings we have work very >> hard in this sense. Even we organized an ontology committee to give >> advise on each new object to be registered. Moreover, few months ago we >> restructured our ontology with the aim of removing inconsistencies. In >> my opinion, we have currently a very solid ontology. >> >> Suggestions about how to register INB services in a easily and not >> damaging way? >> Thank you very much in advance, >> Regards, >> Natalia >> >> >> _______________________________________________ >> 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 Thu Dec 14 17:45:00 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 14 Dec 2006 14:45:00 -0800 Subject: [MOBY-dev] [moby] Re: registering INB services in Canada In-Reply-To: <45804A41.3050903@ac.uma.es> References: <4577F54F.5020903@pcm.uam.es> <45804A41.3050903@ac.uma.es> Message-ID: <1166136300.12669.45.camel@bioinfo.icapture.ubc.ca> Hi Oswaldo, I think the most important thing is to thank you for your team's willingness to contribute to the code-base and the public registry and ontologies. It is greatly appreciated, as are all of the INB contributions! I have no doubt at all that your registry works far better than the public one because it has been hand-curated and carefully controlled from the outset. I think that, for academic interest, the chaos of the public registry and ontologies has been interesting to observe, since one of the major research questions of my laboratory is "can a useful ontology arise through a completely open and non-curated process"[1]. Economically we adopted a non-curated approach because our original development budget was barely enough to get the project off the ground at all. And finally philosophically the public registry has a "laissez faire" attitude towards what we allow people to register in it, because we specifically avoid telling people what data-types, service types, etc. they should use in order to be as open as possible to all participants. Nevertheless, as you correctly point out, and a variety of us have noted several times on the discussion list, this makes the public registry an uncomfortably "wild" place to do any real work! The various projects who have set-up independent registries have all handled this in different ways. The PlaNet project registered data-types in their local registry as well as in the public one on an ongoing basis in order to keep their ontologies as synchronized as possible with the public ones; the GCP project created a "branch" of the public ontology (the GCP_* Objects) containing several structurally identical or semantically similar objects to those in other parts of the public ontology, but in a hierarchy that was specifically meaningful and useful to them; and the INB created it's own ontologies entirely from scratch. Of these approaches, only the PlaNet approach retained true interoperability with those outside of their own project. This is not a criticism of any approach, it is simply an observation that the concept of "ontology sharing" is critical to the functionality of MOBY (the question of whether the shared public ontology is "good" or "not good" is an entirely different story...) The issue of how to re-integrate two forked copies of the ontology is, therefore, a very complex one, since none of our software is currently prepared to deal with this problem in any automated way, and automated ontology-alignment is still largely wishful thinking anyway [2]. It is undesirable for the INB to have to re-code their services since this is extra work, and it is similarly undesirable (in fact, more or less impossible) for us to ask the other public services to re-write their code to adapt to the INB objects, even if they are "better". Short-term, I honestly don't see a straightforward solution to the problem for every case. Obviously the objects that can be registered in the public ontology without naming clashes can be registered there whenever you wish. However, for those that have identical names...?? I guess the first step would be to check if the objects in the public registry are being used at all. If they are not, then you are welcome to de-register them as per the API. Second, you could check if the services that use that object are functional. At the moment, about 15% of the services in the public registry are non-functional [3]. If a service is non-functional, you could contact the provider and ask if they are still maintaining the service at all, and if not, ask them to de-register the service such that you can de-register the objects that it uses. Finally, if there were only one or two services that use the object you wish to remove, you could ask them if they would be willing to change their service to adopt your new object. They may say no, of course, but... you could ask :-) Longer-term, we might be able to solve this problem at the level of XML namespaces (i.e. identify which of the two ontologies the object came from based on its XML namespace); however as I said, none of the code currently can handle this situation, so it isn't a solution in the short-term, and moreover I would much prefer to see the project move toward an RDF-based data representation system versus continuing to develop code for and refine the existing custom-MOBY-XML standard. If we plan to support multiple ontologies in the future, I think it would make more sense to do so under one of the W3C ontology standards versus invest more resources in making the current MOBY "standard" do what these other standards can already do (to some limited extent...) So... I honestly don't have a suggestion that solves all of the problems without requiring someone to do some re-coding of their services. I guess this is what I said in my original response, but it seems to have caused some offense, so I hope this more verbose response is less controversial. Regardless, any contribution your team is willing to make is always welcome and appreciated, Best wishes, Mark [1] http://helix-web.stanford.edu/psb06/good.pdf [2] http://www.atl.lmco.com/projects/ontology/ [3] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService? getDeadServices On Wed, 2006-12-13 at 19:45 +0100, Oswaldo Trelles wrote: > I'd like to provide some additional information to help understanding > our perspective. > > 1) When we were developing the INB system we realise on the need for > ensuring availability and service inter-connection based on the moby > ontology. However, several mails from the moby community warned us on > the importance of a curate catalogue. (i.e.) "Right now in the registry > if I send a generic object I get over a hundred services back, almost > none of which will actually consume the object without dying a horrible > death." (Gordon, Feb 17th), or this other more explicit, "MOBY Central > has become increasingly useless over the past couple of years as it got > filled with junk, badly registered services, dead services, "localhost" > services, test services, and all manner of other registration artifacts > (M.W. response)" > > 2) In this sense we made a great effort in the registering procedure. We > hold several internal meetings with some invited experts from the moby > community to introduce, comment, discuss and get feedback about our > strategy. So, it is not a new issue. > 3) Natalias?s email correctly states the real-problem of different > catalogues. In several previous emails the equivalent issues of > federated ontologies, disperse catalogues, etc. were at least > enumerated. So, it is opportune to launch the discussion. > 4) My group at the GNV5-INB University of Malaga- is open to contribute > in the discussion of the technical and procedural aspects involved in > this issue, oriented to propose a global solution. > 5) In our opinion, Natalia?s email is not the problem but part of the > solution (our system works properly?at the moment at least !) > > with regards, > > O. > > PS, I?d like to thanks all mobiers that having nothing constructive to > say have avoided reply with unfortunate emails. > > and finally I suspect that the Phillip Lord phrase regards **good** > ontologies. > > > > Mark Wilkinson escribi?: > > The immortal words of Phillip Lord are ringing in my head right now... "An > > ontology is not an ontology unless it is SHARED!" :-) > > > > This is a topic that has been discussed (perhaps not on-list?) for many > > years - going all the way back to the first group (PlaNet) who set up > > their own registry. If you "fork" the ontology, then everything breaks, > > unfortunately. I don't think we have ever found a workable solution to > > this situation. Next-generation MOBY, with RDF/OWL and reasoning and > > such, may be able to deal with this problem, but MOBY-S is pretty much > > stuck with one, centralized ontology (which, in our defence, is how the > > vast majority of ontologies work at this point in Web history). > > > > I'm just catching up with my emails after being away for 10 days. I don't > > see anyone else responding to this so far. I don't have any suggestions > > to help you at the moment, but I can raise it at my next lab meeting and > > perhaps an idea will come up...?? I have a feeling that there isn't a > > "magic" solution. MOBY works *because* we all agree on the ontology. If > > you don't agree on the ontology, then you aren't interoperable... it's > > pretty much the core principle of the project... > > > > M > > > > > > > > > > On Thu, 07 Dec 2006 03:04:47 -0800, Natalia Jimenez Lozano > > wrote: > > > > > >> Hi, > >> > >> I would like to open a discussion about ontologies. I belong to the INB > >> where we have currently a lot of working services. We would like to > >> register all of our services in Canada but due to the differences > >> between both ontologies (Canada and Spain), we could ran into the > >> following problems: > >> > >> a) Identical objects (objects that share the same name and the same > >> hierarchy): in this case there would be no problem using the object > >> previously registered in Canada. > >> > >> b) Analogous objects (objects that share the same name but different > >> hierarchy): it would be possible to register in Canada the object with > >> the same name but different hierarchy? If it would be possible we would > >> be "breaking" the Canadian ontology :-( > >> > >> Some examples of this situation can be easily found: > >> > >> b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of > >> text_formatted node but in Canadian ontology is a son of BLAST-Report > >> that is at the same time a son of Sequence_alignment_report. > >> b.2. There is a lot of common objects like Clustalw_Evaluated_Text, > >> FASTA, GFF ..., etc which only difference is their depencency: in > >> Canadian ontology, these objects are depending on text-formatted node > >> but in the Spanish ontology on text_formatted (the only difference is > >> hyphen/underscore!). > >> > >> c) Similar objects (different name -similar, upper-case/lower case, > >> underscore/hyphen- and/or different hierarchy but same meaning): to fit > >> to this last situation, we have several options: > >> > >> - To register INB objects -> this would not "break" the Canadian > >> ontology but would "blur" it. > >> - To adjust each one of the INB services to the Canadian ontology -> > >> This would mean the modification of the code of each one of the services > >> and it would require an extra work. > >> - To modify INB ontology to adjust to Canadian ontology -> This > >> would be a thorny issue because since INB beginnings we have work very > >> hard in this sense. Even we organized an ontology committee to give > >> advise on each new object to be registered. Moreover, few months ago we > >> restructured our ontology with the aim of removing inconsistencies. In > >> my opinion, we have currently a very solid ontology. > >> > >> Suggestions about how to register INB services in a easily and not > >> damaging way? > >> Thank you very much in advance, > >> Regards, > >> Natalia > >> > >> > >> _______________________________________________ > >> 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 ots at ac.uma.es Fri Dec 15 14:18:20 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 15 Dec 2006 20:18:20 +0100 Subject: [MOBY-dev] Collections vs. Simples in registry service searches, a bug? In-Reply-To: <457DA8E0.4020806@ucalgary.ca> References: <457DA8E0.4020806@ucalgary.ca> Message-ID: <4582F4FC.7040606@ac.uma.es> Hi some time ago we start developing a strategy to deal with collection. An initial idea was that MOWServ would allows call a simple-input/simple-output service with a collection (MOWServ should split the collection, invoke iteratively the service with each simple and collect all the results providing a collection as output (all simple/simple, simple/collec, collec/simple and collec/colecc cases were analysed properly). Under this idea, in MOWServ when you perform a query asking for services that take a simple as input, also, those services that uses a collection (of the same type, of course) are returned. (however we have not make a final decission and implementation, and we are re-analysing our ideas) regards, O. (and sorry for delay in posting this comment but have a mountain of pending emails) Paul Gordon escribi?: > Hi all, > > Is there any reason that a service taking a *collection* of DNASequences > as input is returned when I perform a query asking for services that > take a *simple* DNASequence as input? e.g. the GenerateCodonPairTable > service takes a collection and is returned on a simple DNASequence > search. Here is the relevant part of the RDF from the registry: > > > > > > > > inputSequences > > > > > > > And the request is: > > > > > DNASequence > seahawk > > > > > > > > moby > > 1 > 1 > 0 > > > > _______________________________________________ > 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 Fri Dec 15 16:05:34 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 15 Dec 2006 14:05:34 -0700 Subject: [MOBY-dev] Collections vs. Simples in registry service searches, a bug? In-Reply-To: <4582F4FC.7040606@ac.uma.es> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> Message-ID: <45830E1E.4030303@ucalgary.ca> Hi all, While I agree that makes sense for a *client* such as MOWServ to do this type of splitting if it wants, my major problem is that the *registry* treats both equally. Collections should only be registered as input types where a collection is actually used as a single entity, e.g. multiple sequence alignments. If you want to allow multiple DNASequences to be fed into a request for a BLAST service, the service should take a single DNASequence, and you can put multiple mobyData blocks in the request. Currently, I must check through the services returned by the registry and exclude those that take DNASequence Collections in order to avoid errors in my Seahawk client...this seems very wrong. Mark? Eddie? > Hi > some time ago we start developing a strategy to deal with collection. An > initial idea was that MOWServ would allows call a > simple-input/simple-output service with a collection (MOWServ should > split the collection, invoke iteratively the service with each simple > and collect all the results providing a collection as output (all > simple/simple, simple/collec, collec/simple and collec/colecc cases were > analysed properly). > > Under this idea, in MOWServ when you perform a query asking for services > that take a simple as input, also, those services that uses a collection > (of the same type, of course) are returned. > > (however we have not make a final decission and implementation, and we > are re-analysing our ideas) > > regards, > O. (and sorry for delay in posting this comment but have a mountain of > pending emails) > > > > > Paul Gordon escribi?: > >> Hi all, >> >> Is there any reason that a service taking a *collection* of DNASequences >> as input is returned when I perform a query asking for services that >> take a *simple* DNASequence as input? e.g. the GenerateCodonPairTable >> service takes a collection and is returned on a simple DNASequence >> search. Here is the relevant part of the RDF from the registry: >> >> >> >> >> >> >> >> inputSequences >> >> >> >> >> >> >> And the request is: >> >> >> >> >> DNASequence >> seahawk >> >> >> >> >> >> >> >> moby >> >> 1 >> 1 >> 0 >> >> >> >> _______________________________________________ >> 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 Dec 15 16:38:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 15 Dec 2006 13:38:40 -0800 Subject: [MOBY-dev] [moby] Re: Collections vs. Simples in registry service searches, a bug? In-Reply-To: <45830E1E.4030303@ucalgary.ca> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> <45830E1E.4030303@ucalgary.ca> Message-ID: <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca> Hi Paul, I'm a bit snowed-under with four GC Tech Development applications in preparation. Could you check the code yourself and see if there's an obvious reason for the behavior you are observing? I'm not sure if searches for collections was ever implemented... ever?!? but it was almost 5 years ago now, so my memory is a bit rusty ;-) M On Fri, 2006-12-15 at 14:05 -0700, Paul Gordon wrote: > Hi all, > > While I agree that makes sense for a *client* such as MOWServ to do this > type of splitting if it wants, my major problem is that the *registry* > treats both equally. Collections should only be registered as input > types where a collection is actually used as a single entity, e.g. > multiple sequence alignments. If you want to allow multiple > DNASequences to be fed into a request for a BLAST service, the service > should take a single DNASequence, and you can put multiple mobyData > blocks in the request. > > Currently, I must check through the services returned by the registry > and exclude those that take DNASequence Collections in order to avoid > errors in my Seahawk client...this seems very wrong. Mark? Eddie? > > Hi > > some time ago we start developing a strategy to deal with collection. An > > initial idea was that MOWServ would allows call a > > simple-input/simple-output service with a collection (MOWServ should > > split the collection, invoke iteratively the service with each simple > > and collect all the results providing a collection as output (all > > simple/simple, simple/collec, collec/simple and collec/colecc cases were > > analysed properly). > > > > Under this idea, in MOWServ when you perform a query asking for services > > that take a simple as input, also, those services that uses a collection > > (of the same type, of course) are returned. > > > > (however we have not make a final decission and implementation, and we > > are re-analysing our ideas) > > > > regards, > > O. (and sorry for delay in posting this comment but have a mountain of > > pending emails) > > > > > > > > > > Paul Gordon escribi?: > > > >> Hi all, > >> > >> Is there any reason that a service taking a *collection* of DNASequences > >> as input is returned when I perform a query asking for services that > >> take a *simple* DNASequence as input? e.g. the GenerateCodonPairTable > >> service takes a collection and is returned on a simple DNASequence > >> search. Here is the relevant part of the RDF from the registry: > >> > >> > >> > >> > >> > >> > >> > >> inputSequences > >> > >> > >> > >> > >> > >> > >> And the request is: > >> > >> > >> > >> > >> DNASequence > >> seahawk > >> > >> > >> > >> > >> > >> > >> > >> moby > >> > >> 1 > >> 1 > >> 0 > >> > >> > >> > >> _______________________________________________ > >> 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 gordonp at ucalgary.ca Fri Dec 15 23:13:05 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 15 Dec 2006 21:13:05 -0700 Subject: [MOBY-dev] [moby] Re: Collections vs. Simples in registry service searches, a bug? In-Reply-To: <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> <45830E1E.4030303@ucalgary.ca> <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca> Message-ID: <45837251.9040704@ucalgary.ca> Geesh! The things you have to do for service around here! :-) After poking around in the registry SQL tables for a bit, I think I found the culprit. I'm not super familiar with this part of the code, so I'll let you (Mark or Eddie) do the honours: Switch MOBY/Adaptor/moby/queryapi/mysql.pm, line 1212's SQL statement from: From gordonp at ucalgary.ca Fri Dec 15 23:17:42 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 15 Dec 2006 21:17:42 -0700 Subject: [MOBY-dev] [moby] Re: Collections vs. Simples in registry service searches, a bug? In-Reply-To: <45837251.9040704@ucalgary.ca> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> <45830E1E.4030303@ucalgary.ca> <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca> <45837251.9040704@ucalgary.ca> Message-ID: <45837366.2000900@ucalgary.ca> Sorry, last message got cut off for some reason (mailing list filter?). Again, change MOBY/Adaptor/moby/queryapi/mysql.pm line 1212 from select service_instance_id, namespace_type_uris from simple_$inout where object_type_uri in ($ancestor_string) and service_instance_id IS NOT NULL to select service_instance_id, namespace_type_uris from simple_$inout where object_type_uri in ($ancestor_string) and collection_input_id IS NULL From markw at illuminae.com Fri Dec 15 23:24:51 2006 From: markw at illuminae.com (mark wilkinson) Date: Sat, 16 Dec 2006 04:24:51 +0000 GMT Subject: [MOBY-dev] [moby] Re: Collections vs. Simplesin registry service searches, a bug? In-Reply-To: <45837366.2000900@ucalgary.ca> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> <45830E1E.4030303@ucalgary.ca> <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca><45837251.9040704@ucalgary.ca> <45837366.2000900@ucalgary.ca> Message-ID: <1224425260-1166243135-cardhu_blackberry.rim.net-21612-@engine25-cell01> Thanks Paul :-) remember that your nickname used to be "Perl" Gordon, and that you are (were?) Funded from the same pot of money as I am... So you are not allowed to complain about service! :-) I'll make the change tomorrow and bring all of the other INB changes and the ones that Heiko and I made last week into the live registry at the same time. Big changes to the Moby API, but nothing that disturbs anyone. We need to document these changes ASAP so that others can use them!!! Paul, can I ask you to change the relevant docs to correctly explain what the search for collections does? At the moment I don't think it is documented at all... M -- Mark Wilkinson ...on the road! -----Original Message----- From: Paul Gordon Date: Fri, 15 Dec 2006 21:17:42 To:Core developer announcements Cc:markw at illuminae.com Subject: Re: [MOBY-dev] [moby] Re: Collections vs. Simples in registry service searches, a bug? Sorry, last message got cut off for some reason (mailing list filter?). Again, change MOBY/Adaptor/moby/queryapi/mysql.pm line 1212 from select service_instance_id, namespace_type_uris from simple_$inout where object_type_uri in ($ancestor_string) and service_instance_id IS NOT NULL to select service_instance_id, namespace_type_uris from simple_$inout where object_type_uri in ($ancestor_string) and collection_input_id IS NULL _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Dec 19 03:14:32 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 19 Dec 2006 09:14:32 +0100 Subject: [MOBY-dev] Test Central Down Message-ID: <200612190914.33434.d.haase@gsf.de> Eddie, or whoever feels responsible, the test registry seems to be down since yesterday. Whenever I try to connect I get an internal server error. Is this something serious or did just nobody notice yet? Best, dirk From edward.kawas at gmail.com Tue Dec 19 09:47:44 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 19 Dec 2006 06:47:44 -0800 Subject: [MOBY-dev] Test Central Down In-Reply-To: <200612190914.33434.d.haase@gsf.de> Message-ID: <002701c7237c$a585e180$6900a8c0@notebook> Hi Dirk, I fixed it (and committed code to the repository). Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, December 19, 2006 12:15 AM > To: Core developer announcements > Subject: [MOBY-dev] Test Central Down > > Eddie, > > or whoever feels responsible, the test registry seems to be > down since yesterday. Whenever I try to connect I get an > internal server error. Is this something serious or did just > nobody notice yet? > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From nassar at renci.org Wed Dec 20 16:43:05 2006 From: nassar at renci.org (Nassib Nassar) Date: Wed, 20 Dec 2006 16:43:05 -0500 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <457F21DD.7030904@ucalgary.ca> References: <20061212203611.GA9247@renci.org> <457F21DD.7030904@ucalgary.ca> Message-ID: <20061220214305.GA4523@renci.org> Hi Paul, Sorry for the slow reply.... What you suggest was our original intention, but we found it too complicated to explain the difference at the taverna level between passing data into the namespace/id vs. value fields. More importantly, I think, it's convenient for the workflow developers to be able to pass sequences either by reference or by value along a single pathway, anywhere in a workflow where sequences are being processed. The register and lookup services are used like filters to abbreviate and expand sequences, but all of our services will accept either the standard or abbreviated forms. This is rather experimental, but so far it seems to be working very well. Nassib On Tue, Dec 12, 2006 at 02:40:45PM -0700, Paul Gordon wrote: > Hi Nassib, > > I looked at the presentation, and I'm not sure why you can't just use a > VirtualSequence instead. You can then have all of the combinations you > want, as long as you register the namespaces: > > > 1500 > > > > 1500 > > > > 1500 > > > > 1500 > ATG... > > > etc., etc. > > Hi, > > > > I'd like to start explaining a little bit about our use of biomoby and > > also request feedback... > > > > We're using biomoby mainly with taverna workflows, and gradually > > migrating current web services over to become biomoby services (under > > biomoby.renci.org). The workflows we develop are talking to services > > that for the most part are based here within our servers. As a result > > we end up passing a very large amount of duplicated sequence data over > > the network between taverna and services, often more data than taverna > > is happy about. To get around this we have started passing sequences > > by reference using a FASTA-like format that is non-standard but fits > > well into our system and the taverna UI. I'm calling this the "RENCI > > sequence" format, and it's basically similar to GenBank, while > > allowing an "abbreviated" (truncated) form that consists of only a > > partial header line with at least one namespace/id. (The architecture > > is described in http://www.renci.org/~nassar/sequence_registry.ppt ) > > > > We've added some new datatypes under "RenciSequence" for this purpose, > > analogous to the existing "GenericSequence". In general we are using > > the existing biomoby datatypes, but for sequences our format seems > > unusual enough that we thought it needed its own datatype to avoid > > confusion. > > > > Nassib > > _______________________________________________ > > 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 ots at ac.uma.es Thu Dec 21 02:52:28 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 21 Dec 2006 08:52:28 +0100 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <20061220214305.GA4523@renci.org> References: <20061212203611.GA9247@renci.org> <457F21DD.7030904@ucalgary.ca> <20061220214305.GA4523@renci.org> Message-ID: <458A3D3C.2000303@ac.uma.es> Hi, We are aware about the problem of network overload produced by large data transmission, even when services are located in local networks or even in the same server (i.e. most of our services are located in two servers, so in general, partial data transmission is unnecessary). In this line we are analysing two alternatives: a) sub-workflows (or jobs) to submit a set of tasks to be executed in the same server (a scheduler module, as is the case of MOWServ could identify the set of related tasks). We need to review the documentation to ensure that only the last service returns the output (intermediate results could be requested using the asynch protocol). b) a more general (ergo, more interesting) alternative goes in the way to define a pointer/reference to a local object (an object currently stored in the local file system). Of course we should avoid defining a new object (the corresponding couple-object) for each object (sequences, gene-expression data, structures, etc etc and subtypes). So we could agree in a label/tag or whatever other alternative in the appropriated position of the xml to recognise this type of specification. of course these are only initial ideas regarding a real problem that should be discussed (and solved) best regards, O. GNV5-INB Nassib Nassar escribi?: > Hi Paul, > > Sorry for the slow reply.... What you suggest was our original > intention, but we found it too complicated to explain the difference > at the taverna level between passing data into the namespace/id > vs. value fields. More importantly, I think, it's convenient for the > workflow developers to be able to pass sequences either by reference > or by value along a single pathway, anywhere in a workflow where > sequences are being processed. The register and lookup services are > used like filters to abbreviate and expand sequences, but all of our > services will accept either the standard or abbreviated forms. This > is rather experimental, but so far it seems to be working very well. > > Nassib > > > On Tue, Dec 12, 2006 at 02:40:45PM -0700, Paul Gordon wrote: > >> Hi Nassib, >> >> I looked at the presentation, and I'm not sure why you can't just use a >> VirtualSequence instead. You can then have all of the combinations you >> want, as long as you register the namespaces: >> >> >> 1500 >> >> >> >> 1500 >> >> >> >> 1500 >> >> >> >> 1500 >> ATG... >> >> >> etc., etc. >> >>> Hi, >>> >>> I'd like to start explaining a little bit about our use of biomoby and >>> also request feedback... >>> >>> We're using biomoby mainly with taverna workflows, and gradually >>> migrating current web services over to become biomoby services (under >>> biomoby.renci.org). The workflows we develop are talking to services >>> that for the most part are based here within our servers. As a result >>> we end up passing a very large amount of duplicated sequence data over >>> the network between taverna and services, often more data than taverna >>> is happy about. To get around this we have started passing sequences >>> by reference using a FASTA-like format that is non-standard but fits >>> well into our system and the taverna UI. I'm calling this the "RENCI >>> sequence" format, and it's basically similar to GenBank, while >>> allowing an "abbreviated" (truncated) form that consists of only a >>> partial header line with at least one namespace/id. (The architecture >>> is described in http://www.renci.org/~nassar/sequence_registry.ppt ) >>> >>> We've added some new datatypes under "RenciSequence" for this purpose, >>> analogous to the existing "GenericSequence". In general we are using >>> the existing biomoby datatypes, but for sequences our format seems >>> unusual enough that we thought it needed its own datatype to avoid >>> confusion. >>> >>> Nassib >>> _______________________________________________ >>> 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 Dec 29 10:33:13 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 29 Dec 2006 07:33:13 -0800 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <458A3D3C.2000303@ac.uma.es> References: <20061212203611.GA9247@renci.org> <457F21DD.7030904@ucalgary.ca> <20061220214305.GA4523@renci.org> <458A3D3C.2000303@ac.uma.es> Message-ID: Hi all, just a quick question v.v. this thread: The work that Heiko and I did together a couple of weeks ago while I was in Germany allows the provision of services using HTTP POST. The idea being that you pass a (rather than ) message into a service by POST and it returns a message in response. It seems to me (though we haven't tried it, nor written any code for it yet) that it would be possible to set up: a) a service that "streams" its output continuously, rather than waiting for the service to finish entirely, and b) A client-side SAX parser to deal with the "streaming" output. The SAX parser will be quite tricky to build given that a MOBY service is allowed to output any object that is a child of whatever object it registered (so the trigger would have to respond to every case), but still... it seems that this architecture would solve the problem we are discussing here in a quite simplistic way... it might also overcome *some* of the timeout issues, since the service could output the header information in order to keep the connection alive (and perhaps even output some header "commentary" on a regular basis to keep the connection alive). v.v. legacy: existing clients would not discover these services, because they are registered as Category="moby-post", so there's no problem with breaking anyone. Does this help at all?? M On Wed, 20 Dec 2006 23:52:28 -0800, Oswaldo Trelles wrote: > Hi, > > We are aware about the problem of network overload produced by large > data transmission, even when services are located in local networks or > even in the same server (i.e. most of our services are located in two > servers, so in general, partial data transmission is unnecessary). > > In this line we are analysing two alternatives: > a) sub-workflows (or jobs) to submit a set of tasks to be executed in > the same server (a scheduler module, as is the case of MOWServ could > identify the set of related tasks). We need to review the documentation > to ensure that only the last service returns the output (intermediate > results could be requested using the asynch protocol). > b) a more general (ergo, more interesting) alternative goes in the way > to define a pointer/reference to a local object (an object currently > stored in the local file system). Of course we should avoid defining a > new object (the corresponding couple-object) for each object (sequences, > gene-expression data, structures, etc etc and subtypes). So we could > agree in a label/tag or whatever other alternative in the appropriated > position of the xml to recognise this type of specification. > > of course these are only initial ideas regarding a real problem that > should be discussed (and solved) > > best regards, O. > > GNV5-INB > > > > > Nassib Nassar escribi?: >> Hi Paul, >> >> Sorry for the slow reply.... What you suggest was our original >> intention, but we found it too complicated to explain the difference >> at the taverna level between passing data into the namespace/id >> vs. value fields. More importantly, I think, it's convenient for the >> workflow developers to be able to pass sequences either by reference >> or by value along a single pathway, anywhere in a workflow where >> sequences are being processed. The register and lookup services are >> used like filters to abbreviate and expand sequences, but all of our >> services will accept either the standard or abbreviated forms. This >> is rather experimental, but so far it seems to be working very well. >> >> Nassib >> >> >> On Tue, Dec 12, 2006 at 02:40:45PM -0700, Paul Gordon wrote: >> >>> Hi Nassib, >>> >>> I looked at the presentation, and I'm not sure why you can't just use a >>> VirtualSequence instead. You can then have all of the combinations you >>> want, as long as you register the namespaces: >>> >>> >>> 1500 >>> >>> >>> >>> 1500 >>> >>> >>> >>> 1500 >>> >>> >>> >>> 1500 >>> ATG... >>> >>> >>> etc., etc. >>> >>>> Hi, >>>> >>>> I'd like to start explaining a little bit about our use of biomoby and >>>> also request feedback... >>>> >>>> We're using biomoby mainly with taverna workflows, and gradually >>>> migrating current web services over to become biomoby services (under >>>> biomoby.renci.org). The workflows we develop are talking to services >>>> that for the most part are based here within our servers. As a result >>>> we end up passing a very large amount of duplicated sequence data over >>>> the network between taverna and services, often more data than taverna >>>> is happy about. To get around this we have started passing sequences >>>> by reference using a FASTA-like format that is non-standard but fits >>>> well into our system and the taverna UI. I'm calling this the "RENCI >>>> sequence" format, and it's basically similar to GenBank, while >>>> allowing an "abbreviated" (truncated) form that consists of only a >>>> partial header line with at least one namespace/id. (The architecture >>>> is described in http://www.renci.org/~nassar/sequence_registry.ppt ) >>>> >>>> We've added some new datatypes under "RenciSequence" for this purpose, >>>> analogous to the existing "GenericSequence". In general we are using >>>> the existing biomoby datatypes, but for sequences our format seems >>>> unusual enough that we thought it needed its own datatype to avoid >>>> confusion. >>>> >>>> Nassib >>>> _______________________________________________ >>>> 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 -- -- 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 d.haase at gsf.de Tue Dec 5 15:10:25 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 5 Dec 2006 16:10:25 +0100 Subject: [MOBY-dev] PlaNet registry shutdown Message-ID: <200612051610.27170.d.haase@gsf.de> Hi all, I'd like to announce that the PlaNet Moby Central at MIPS is very soon to shut down. The reasons are very simple: PlaNet ran out in 2005 and maintenance of a registry costs time - which is not funded anymore. This already led to limited functionality, the LSID resolver was never set up which made it unusable in Taverna. I tried to convince maintainers of PlaNet exclusive services to move their stuff to Canada and was somehow successful. So hardly any (working) service will get lost for the community. This message is mainly for those who run clients which may access PlaNet central. Please remove any pointers to http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl from your applications. I guess by Christmas requests on this URL will result in a 404. Of course, this has no effect on the PlaNet portal which will still be available under http://mips.gsf.de/projects/plants/PlaNetPortal/ Thanks and regards, dirk PS: sorry if you received this twice, there were some problems when I first sent it... From groscurt at mpiz-koeln.mpg.de Tue Dec 5 16:02:55 2006 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Tue, 5 Dec 2006 17:02:55 +0100 Subject: [MOBY-dev] =?iso-8859-1?q?RFC_-_Synchronization_of_Biomoby_second?= =?iso-8859-1?q?ary=A0=A0=A0=A0repositories?= Message-ID: <200612051702.56039.groscurt@mpiz-koeln.mpg.de> >The amount of RSS-RDF ? >we would have to maintain on MOBY Central in order to have a complete ? >history that would allow a mirror to reliably re-construct the current ? >state of the database is... well... large! ?At the moment, I keep only the ? >last... 100?... changes. ?If you don't pick-up the feed for a day, or if ? >someone registers 1000 new services, you wont see them in the feed. ? You are definitely right, if a secondary fails to synchronize with the central for a long time the number of changes are enormously large, but therefore the time stamp plays its role. Each secondary stores the time stamp of its last synchronization - furthermore in the RSS the latest 30 / 100 (or whatever) changes are written also with the time stamp of the actual change. So with each RSS fetching, the secondary is able to determine whether it is out of sync. And if so, the secondary calls the central to retrieve a specific RSS for the changes it lacks. So this is independent from the 'normal' RSS. Also it is discussable whether to force the secondary to fetch the RSS feed at least once a day or any other frequency. So one can shorten that frequency but not extend it. I'm not quite sure whether i said something completely inappropriate according your concerns - Heiko will clear that out I guess if so ;-) Cheers Andreas From martin.senger at gmail.com Tue Dec 5 17:20:19 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 5 Dec 2006 17:20:19 +0000 Subject: [MOBY-dev] PlaNet registry shutdown In-Reply-To: <200612051610.27170.d.haase@gsf.de> References: <200612051610.27170.d.haase@gsf.de> Message-ID: <4d93f07c0612050920k61365009gf05bcb27202e5fd@mail.gmail.com> Sorry to hear it, but thanks for the info. I have removed the following from Jmoby and Perl-jMoby. Please CVS update. Cheers, Martin new Registry ("MIPS", "http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl", "http://mips.gsf.de/MOBY/Central", "MIPS, Germany", "Dirk Haase (d.haase at gsf.de)", true, ""), -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Wed Dec 6 17:30:52 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 06 Dec 2006 10:30:52 -0700 Subject: [MOBY-dev] New MobyServlet methodology Message-ID: <4576FE4C.2030805@ucalgary.ca> Hi all, FYI, I have made a major change to the way MobyServlet works. It now uses Java annotations to define service meta-data. For those of you not familiar with this Java 1.5 feature, here is how you'd write a service: import org.biomoby.shared.data.*; import org.biomoby.service.*; @mobyService(name="ConvertAAtoFASTA_AA", type="FormatConversion", provider="moby.ucalgary.ca", author="gordonp at ucalgary.ca", in={"inseq:AminoAcidSequence"}, out={"outseq:FASTA_AA"}, description={"Converts amino acid objects into FastA formatted records, ", "primarily to increase inter-service compatibility"}) public class ConvertAAtoFASTA_AA extends MobyServlet{ public void processRequest(MobyDataJob request, MobyDataJob result) throws Exception{ // insert your code here... } } That's it! We've created an Ant build file (and an associated properties file) to support this, the highlights being: ant test ant war ant registerService Please see the detailed tutorial at http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html If anyone's got an Oracle or IBM servlet engine to test this on, I'd appreciate the feedback. Regards, Paul (with Quang Trinh's help on the Ant stuff) From natalia.jimenez at pcm.uam.es Thu Dec 7 11:04:47 2006 From: natalia.jimenez at pcm.uam.es (Natalia Jimenez Lozano) Date: Thu, 07 Dec 2006 12:04:47 +0100 Subject: [MOBY-dev] registering INB services in Canada Message-ID: <4577F54F.5020903@pcm.uam.es> Hi, I would like to open a discussion about ontologies. I belong to the INB where we have currently a lot of working services. We would like to register all of our services in Canada but due to the differences between both ontologies (Canada and Spain), we could ran into the following problems: a) Identical objects (objects that share the same name and the same hierarchy): in this case there would be no problem using the object previously registered in Canada. b) Analogous objects (objects that share the same name but different hierarchy): it would be possible to register in Canada the object with the same name but different hierarchy? If it would be possible we would be "breaking" the Canadian ontology :-( Some examples of this situation can be easily found: b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of text_formatted node but in Canadian ontology is a son of BLAST-Report that is at the same time a son of Sequence_alignment_report. b.2. There is a lot of common objects like Clustalw_Evaluated_Text, FASTA, GFF ..., etc which only difference is their depencency: in Canadian ontology, these objects are depending on text-formatted node but in the Spanish ontology on text_formatted (the only difference is hyphen/underscore!). c) Similar objects (different name -similar, upper-case/lower case, underscore/hyphen- and/or different hierarchy but same meaning): to fit to this last situation, we have several options: - To register INB objects -> this would not "break" the Canadian ontology but would "blur" it. - To adjust each one of the INB services to the Canadian ontology -> This would mean the modification of the code of each one of the services and it would require an extra work. - To modify INB ontology to adjust to Canadian ontology -> This would be a thorny issue because since INB beginnings we have work very hard in this sense. Even we organized an ontology committee to give advise on each new object to be registered. Moreover, few months ago we restructured our ontology with the aim of removing inconsistencies. In my opinion, we have currently a very solid ontology. Suggestions about how to register INB services in a easily and not damaging way? Thank you very much in advance, Regards, Natalia From markw at illuminae.com Sun Dec 10 03:48:09 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 09 Dec 2006 19:48:09 -0800 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: <4577F54F.5020903@pcm.uam.es> References: <4577F54F.5020903@pcm.uam.es> Message-ID: The immortal words of Phillip Lord are ringing in my head right now... "An ontology is not an ontology unless it is SHARED!" :-) This is a topic that has been discussed (perhaps not on-list?) for many years - going all the way back to the first group (PlaNet) who set up their own registry. If you "fork" the ontology, then everything breaks, unfortunately. I don't think we have ever found a workable solution to this situation. Next-generation MOBY, with RDF/OWL and reasoning and such, may be able to deal with this problem, but MOBY-S is pretty much stuck with one, centralized ontology (which, in our defence, is how the vast majority of ontologies work at this point in Web history). I'm just catching up with my emails after being away for 10 days. I don't see anyone else responding to this so far. I don't have any suggestions to help you at the moment, but I can raise it at my next lab meeting and perhaps an idea will come up...?? I have a feeling that there isn't a "magic" solution. MOBY works *because* we all agree on the ontology. If you don't agree on the ontology, then you aren't interoperable... it's pretty much the core principle of the project... M On Thu, 07 Dec 2006 03:04:47 -0800, Natalia Jimenez Lozano wrote: > Hi, > > I would like to open a discussion about ontologies. I belong to the INB > where we have currently a lot of working services. We would like to > register all of our services in Canada but due to the differences > between both ontologies (Canada and Spain), we could ran into the > following problems: > > a) Identical objects (objects that share the same name and the same > hierarchy): in this case there would be no problem using the object > previously registered in Canada. > > b) Analogous objects (objects that share the same name but different > hierarchy): it would be possible to register in Canada the object with > the same name but different hierarchy? If it would be possible we would > be "breaking" the Canadian ontology :-( > > Some examples of this situation can be easily found: > > b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of > text_formatted node but in Canadian ontology is a son of BLAST-Report > that is at the same time a son of Sequence_alignment_report. > b.2. There is a lot of common objects like Clustalw_Evaluated_Text, > FASTA, GFF ..., etc which only difference is their depencency: in > Canadian ontology, these objects are depending on text-formatted node > but in the Spanish ontology on text_formatted (the only difference is > hyphen/underscore!). > > c) Similar objects (different name -similar, upper-case/lower case, > underscore/hyphen- and/or different hierarchy but same meaning): to fit > to this last situation, we have several options: > > - To register INB objects -> this would not "break" the Canadian > ontology but would "blur" it. > - To adjust each one of the INB services to the Canadian ontology -> > This would mean the modification of the code of each one of the services > and it would require an extra work. > - To modify INB ontology to adjust to Canadian ontology -> This > would be a thorny issue because since INB beginnings we have work very > hard in this sense. Even we organized an ontology committee to give > advise on each new object to be registered. Moreover, few months ago we > restructured our ontology with the aim of removing inconsistencies. In > my opinion, we have currently a very solid ontology. > > Suggestions about how to register INB services in a easily and not > damaging way? > Thank you very much in advance, > Regards, > Natalia > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From martin.senger at gmail.com Sun Dec 10 13:08:31 2006 From: martin.senger at gmail.com (Martin Senger) Date: Sun, 10 Dec 2006 14:08:31 +0100 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: References: <4577F54F.5020903@pcm.uam.es> Message-ID: <4d93f07c0612100508t2e420b61m53d306421bc77afa@mail.gmail.com> > I don't see anyone else responding to this so far. Well, I have not replied because I did not know how to say politely "what you are asking for sucks" :-). I am 100% with you - we either share or we are dead. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Sun Dec 10 15:25:20 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Sun, 10 Dec 2006 08:25:20 -0700 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: References: <4577F54F.5020903@pcm.uam.es> Message-ID: <457C26E0.6060403@ucalgary.ca> Right. Fixing this type of issue systematically (as opposed to one-off manually) is the kind of stuff that makes up a computer science PhD thesis... :-) > If you "fork" the ontology, then everything breaks, > unfortunately. I don't think we have ever found a workable solution to > this situation. Next-generation MOBY, with RDF/OWL and reasoning and > such, may be able to deal with this problem, but MOBY-S is pretty much > stuck with one, centralized ontology (which, in our defence, is how the > vast majority of ontologies work at this point in Web history). > From Pieter.Neerincx at wur.nl Sun Dec 10 15:57:59 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sun, 10 Dec 2006 16:57:59 +0100 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: <4d93f07c0612100508t2e420b61m53d306421bc77afa@mail.gmail.com> References: <4577F54F.5020903@pcm.uam.es> <4d93f07c0612100508t2e420b61m53d306421bc77afa@mail.gmail.com> Message-ID: <750FD1D2-77A6-4F0A-B360-5DFB34BB7EC3@wur.nl> On 10 Dec 2006, at 14:08, Martin Senger wrote: >> I don't see anyone else responding to this so far. > > > Well, I have not replied because I did not know how to say politely > "what > you are asking for sucks" :-). I am 100% with you - we either > share or we > are dead. I agree. This sounds to me like the same problem which occurs when people find out someone else has already registered their favorite internet domain name: too bad you are too late! BioMOBY works only well if we share the same ontology which works with a first come, first registered policy. On the other hand the idea of a manually curated ontology does not sound bad too me. Surely it causes extra work, but lets look at the past. There are many biological concepts that were first labeled more or less at random causing a big mess with synonyms, homonyms, etc. Later on standardization committees were appointed to clean up the ambiguity. It happened to species names, genes, proteins, chemical compounds, you name it... Groups like HUGO are doing a fine job, but especially gene and protein names are still a disaster for data- and text-mining software. Maybe we should have started curating the ontology yesterday... So I like the idea of manually curating the ontology (and I volunteer for some of the work that might cause), but I would have liked the idea even more if the people at INB would have made it a community effort from the start :). Cheers, Pi > > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From phillip.lord at newcastle.ac.uk Mon Dec 11 16:06:12 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Mon, 11 Dec 2006 16:06:12 +0000 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: (Mark Wilkinson's message of "Sat, 09 Dec 2006 19:48:09 -0800") References: <4577F54F.5020903@pcm.uam.es> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> The immortal words of Phillip Lord are ringing in my head Mark> right now... "An ontology is not an ontology unless it is Mark> SHARED!" :-) I'm sure that I stole it from somewhere. Mark> This is a topic that has been discussed (perhaps not on-list?) Mark> for many years - going all the way back to the first group Mark> (PlaNet) who set up their own registry. If you "fork" the Mark> ontology, then everything breaks, unfortunately. I don't Mark> think we have ever found a workable solution to this Mark> situation. Next-generation MOBY, with RDF/OWL and reasoning Mark> and such, may be able to deal with this problem, but MOBY-S is Mark> pretty much stuck with one, centralized ontology (which, in Mark> our defence, is how the vast majority of ontologies work at Mark> this point in Web history). Mark> I'm just catching up with my emails after being away for 10 Mark> days. I don't see anyone else responding to this so far. I Mark> don't have any suggestions to help you at the moment, but I Mark> can raise it at my next lab meeting and perhaps an idea will Mark> come up...?? I have a feeling that there isn't a "magic" Mark> solution. MOBY works *because* we all agree on the ontology. Mark> If you don't agree on the ontology, then you aren't Mark> interoperable... it's pretty much the core principle of the Mark> project... If I may be so bold, I think Natalia has a point, but not necessarily the right solution. INB could easily register their services by knocking out a mapping between the two ontologies and then they could translate. But this would be a pain, and error prone. So the question has to be, why have two ontologies arisen. My suspicion is that there is not enough discussion and change within the existing ontology allowing it to extend to their purposes. After all, I've read lots of stuff on this list about code enhancement (and not read far more), but relatively little about ontology extensions. Perhaps the INB ontology can be used to integrate into the Canadian ontology, to the value of both? Of course, I'm only really a lurker on this mailing list, so my apologies if I am way of the mark. BTW, reasoning and RDF/OWL is never going to deal with this problem; it might make the problem less severe, but it's still going to be an issue. Phil From gordonp at ucalgary.ca Mon Dec 11 16:05:48 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 11 Dec 2006 09:05:48 -0700 Subject: [MOBY-dev] CVS messed up? Message-ID: <457D81DC.1070606@ucalgary.ca> Anyone else getting weird error messages on CVS commands on MOBY? cvs diff: failed to create lock directory for `/home/repository/moby/********************' (/home/repository/moby/********************/#cvs.lock): No such file or directory Other weird, non-printing characters show up as directory names too... From gordonp at ucalgary.ca Mon Dec 11 18:52:16 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 11 Dec 2006 11:52:16 -0700 Subject: [MOBY-dev] Collections vs. Simples in registry service searches, a bug? Message-ID: <457DA8E0.4020806@ucalgary.ca> Hi all, Is there any reason that a service taking a *collection* of DNASequences as input is returned when I perform a query asking for services that take a *simple* DNASequence as input? e.g. the GenerateCodonPairTable service takes a collection and is returned on a simple DNASequence search. Here is the relevant part of the RDF from the registry: inputSequences And the request is: DNASequence seahawk moby 1 1 0 From martin.senger at gmail.com Mon Dec 11 16:36:06 2006 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 11 Dec 2006 16:36:06 +0000 Subject: [MOBY-dev] CVS messed up? In-Reply-To: <457D81DC.1070606@ucalgary.ca> References: <457D81DC.1070606@ucalgary.ca> Message-ID: <4d93f07c0612110836i4e6702efg267cf559337bbd3@mail.gmail.com> On 12/11/06, Paul Gordon wrote: > > Anyone else getting weird error messages on CVS commands on MOBY? > > cvs diff: failed to create lock directory for > `/home/repository/moby/********************' > (/home/repository/moby/********************/#cvs.lock): No such file or > directory > > Other weird, non-printing characters show up as directory names too... I have not noticed (but I have not committed anything recently). I am cc-ing your email to Chris (who is in chrage of all open-bio servers, and many more). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From d.haase at gsf.de Tue Dec 12 15:18:02 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 12 Dec 2006 16:18:02 +0100 Subject: [MOBY-dev] getSignatureForm down Message-ID: <200612121618.02536.d.haase@gsf.de> Hi, it seems that the getSignatureForm servlet (http://mobycentral.icapture.ubc.ca:8090/servlets/forms/getSignatureForm) is down - I think already for a couple of days now. Can somebody fix that? Thanks, dirk From jdr0887 at renci.org Tue Dec 12 16:18:21 2006 From: jdr0887 at renci.org (Jason Reilly) Date: Tue, 12 Dec 2006 11:18:21 -0500 Subject: [MOBY-dev] empty collections Message-ID: <457ED64D.7010603@renci.org> Hi all, I have encountered an issue and want to get some feedback. The issue is concerning empty collections. Say, for example, I have a Taverna workflow where a Moby service takes a collection that passes *optional* parameters to the service. In the case I am using, I wrote a blast service where it takes a few parameters like 'database' and 'blastType' (required), as well as a collection of parameters (optional) to be passed to the blast service. When I run the workflow from Taverna and I leave the input for the collection empty/null, I get an NPE in the generated moby skeleton when it tries to synchronize. If I just create a collection, but don't populate anything in it, Taverna throws a ServiceFailure ("At least one mobySimple object is needed to build the moby collection") . I would propose just wrapping the synchronize block in a not null check, but it would be very easy to create another service....one with parameters and one without. What is the intent of not allowing empty collections? Is this a feature or a bug? From edward.kawas at gmail.com Tue Dec 12 17:57:34 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 12 Dec 2006 09:57:34 -0800 Subject: [MOBY-dev] empty collections In-Reply-To: <457ED64D.7010603@renci.org> Message-ID: <003101c71e17$01f40980$6900a8c0@notebook> Hi Jason, Currently, if a service doesn't have input parameters, it wouldn't be invoked in Taverna. I will attempt to address this in the very near future! It makes complete sense to support services that don't have inputs but do have outputs. For my own information, what service are you attempting to use? 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 Jason Reilly > Sent: Tuesday, December 12, 2006 8:18 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] empty collections > > Hi all, > > I have encountered an issue and want to get some feedback. > The issue is concerning empty collections. Say, for example, > I have a Taverna workflow where a Moby service takes a > collection that passes *optional* parameters to the service. > In the case I am using, I wrote a blast service where it > takes a few parameters like 'database' and 'blastType' > (required), as well as a collection of parameters (optional) > to be passed to the blast service. When I run the workflow > from Taverna and I leave the input for the collection > empty/null, I get an NPE in the generated moby skeleton when > it tries to synchronize. If I just create a collection, but > don't populate anything in it, Taverna throws a > ServiceFailure ("At least one mobySimple object is needed to > build the moby collection") . > > I would propose just wrapping the synchronize block in a not > null check, but it would be very easy to create another > service....one with parameters and one without. What is the > intent of not allowing empty collections? Is this a feature or a bug? > > > > > _______________________________________________ > 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 Tue Dec 12 16:25:44 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 12 Dec 2006 08:25:44 -0800 Subject: [MOBY-dev] getSignatureForm down In-Reply-To: <200612121618.02536.d.haase@gsf.de> Message-ID: <001b01c71e0a$2d6839e0$6900a8c0@notebook> Hi Dirk, The page has moved to http://mobycentral.icapture.ubc.ca:8090/authority/forms/getSignatureForm. Where is that old reference? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, December 12, 2006 7:18 AM > To: Core developer announcements > Subject: [MOBY-dev] getSignatureForm down > > Hi, > > it seems that the getSignatureForm servlet > (http://mobycentral.icapture.ubc.ca:8090/servlets/forms/getSig > natureForm) is down - I think already for a couple of days now. > > Can somebody fix that? > > Thanks, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From nassar at renci.org Tue Dec 12 20:36:11 2006 From: nassar at renci.org (Nassib Nassar) Date: Tue, 12 Dec 2006 15:36:11 -0500 Subject: [MOBY-dev] sequence datatypes Message-ID: <20061212203611.GA9247@renci.org> Hi, I'd like to start explaining a little bit about our use of biomoby and also request feedback... We're using biomoby mainly with taverna workflows, and gradually migrating current web services over to become biomoby services (under biomoby.renci.org). The workflows we develop are talking to services that for the most part are based here within our servers. As a result we end up passing a very large amount of duplicated sequence data over the network between taverna and services, often more data than taverna is happy about. To get around this we have started passing sequences by reference using a FASTA-like format that is non-standard but fits well into our system and the taverna UI. I'm calling this the "RENCI sequence" format, and it's basically similar to GenBank, while allowing an "abbreviated" (truncated) form that consists of only a partial header line with at least one namespace/id. (The architecture is described in http://www.renci.org/~nassar/sequence_registry.ppt ) We've added some new datatypes under "RenciSequence" for this purpose, analogous to the existing "GenericSequence". In general we are using the existing biomoby datatypes, but for sequences our format seems unusual enough that we thought it needed its own datatype to avoid confusion. Nassib From gordonp at ucalgary.ca Tue Dec 12 21:40:45 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 12 Dec 2006 14:40:45 -0700 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <20061212203611.GA9247@renci.org> References: <20061212203611.GA9247@renci.org> Message-ID: <457F21DD.7030904@ucalgary.ca> Hi Nassib, I looked at the presentation, and I'm not sure why you can't just use a VirtualSequence instead. You can then have all of the combinations you want, as long as you register the namespaces: 1500 1500 1500 1500 ATG... etc., etc. > Hi, > > I'd like to start explaining a little bit about our use of biomoby and > also request feedback... > > We're using biomoby mainly with taverna workflows, and gradually > migrating current web services over to become biomoby services (under > biomoby.renci.org). The workflows we develop are talking to services > that for the most part are based here within our servers. As a result > we end up passing a very large amount of duplicated sequence data over > the network between taverna and services, often more data than taverna > is happy about. To get around this we have started passing sequences > by reference using a FASTA-like format that is non-standard but fits > well into our system and the taverna UI. I'm calling this the "RENCI > sequence" format, and it's basically similar to GenBank, while > allowing an "abbreviated" (truncated) form that consists of only a > partial header line with at least one namespace/id. (The architecture > is described in http://www.renci.org/~nassar/sequence_registry.ppt ) > > We've added some new datatypes under "RenciSequence" for this purpose, > analogous to the existing "GenericSequence". In general we are using > the existing biomoby datatypes, but for sequences our format seems > unusual enough that we thought it needed its own datatype to avoid > confusion. > > Nassib > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From Yogaraj.Khanal at usd.edu Wed Dec 13 05:53:53 2006 From: Yogaraj.Khanal at usd.edu (Yogaraj.Khanal at usd.edu) Date: Tue, 12 Dec 2006 23:53:53 -0600 Subject: [MOBY-dev] sequence datatypes Message-ID: <416d7a0416d85b.416d85b416d7a0@usd.edu> hi to all, i got problem executing this web service can anyone help me /* * Moby.java * * Created on December 3, 2006, 9:33 AM * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ import org.biomoby.client.*; import org.biomoby.shared.*; import org.biomoby.shared.data.*; /** * * @author yogaraj.khanal */ public class Moby { /** Creates a new instance of Moby */ public Moby() { } /** * @param args the command line arguments */ public static void main(String[] args) throws Exception{ Central worker = new CentralImpl(); MobyService templateService = new MobyService("runGeneIDGFF"); System.out.println(templateService.getName()); System.out.println(templateService.getUniqueName()); System.out.println(templateService.getAuthority()); MobyPrimaryData[] priinput=templateService.getPrimaryInputs(); System.out.println(priinput); MobyService[] validServices = worker.findService(templateService.getId()); System.out.println(validServices); MobyRequest mr = new MobyRequest(worker); //mr.setService(validServices[0]); //mr.setInput(new MobyDataObject("", "")); System.out.println(mr.invokeService().toString()); //MobyRequest mr = new MobyRequest(worker); mr.setService(validServices[10]); mr.setInput(new MobyDataObject("NCBI_gi", "111076")); MobyDataType dataType=new MobyDataType("AminoAcidSequence"); mr.setInput(new MobyDataObject("AminoAcidSequence")); MobyDataSecondaryInstance[] secondaryData=new MobyDataSecondaryInstance[5]; MobySecondaryData p1=new MobySecondaryData("strand"); p1.setDataType("String"); p1.setDefaultValue("Reverse"); MobySecondaryData p2=new MobySecondaryData("profile"); p2.setDataType("String"); p2.setDefaultValue("Arabidopsis thalina(weed)"); MobySecondaryData p3=new MobySecondaryData("engine"); p3.setDataType("String"); p3.setDefaultValue("Exon Mode"); MobySecondaryData p4=new MobySecondaryData("signals"); p4.setDataType("String"); p4.setDefaultValue("Start condons"); MobySecondaryData p5=new MobySecondaryData("exons"); p5.setDataType("String"); p5.setDefaultValue("All exons"); secondaryData[0]=new MobyDataSecondaryInstance(p1); secondaryData[1]=new MobyDataSecondaryInstance(p2); secondaryData[2]=new MobyDataSecondaryInstance(p3); secondaryData[3]=new MobyDataSecondaryInstance(p4); secondaryData[4]=new MobyDataSecondaryInstance(p5); mr.setSecondaryInput(secondaryData); System.out.println(mr.invokeService().toString()); // TODO code application logic here } } ----- Original Message ----- From: Paul Gordon Date: Tuesday, December 12, 2006 3:40 pm Subject: Re: [MOBY-dev] sequence datatypes > Hi Nassib, > > I looked at the presentation, and I'm not sure why you can't just > use a > VirtualSequence instead. You can then have all of the > combinations you > want, as long as you register the namespaces: > > > 1500 > > > > 1500 > > > > 1500 > > > > 1500 > id="">ATG... > > etc., etc. > > Hi, > > > > I'd like to start explaining a little bit about our use of > biomoby and > > also request feedback... > > > > We're using biomoby mainly with taverna workflows, and gradually > > migrating current web services over to become biomoby services > (under> biomoby.renci.org). The workflows we develop are talking > to services > > that for the most part are based here within our servers. As a > result> we end up passing a very large amount of duplicated > sequence data over > > the network between taverna and services, often more data than > taverna> is happy about. To get around this we have started > passing sequences > > by reference using a FASTA-like format that is non-standard but fits > > well into our system and the taverna UI. I'm calling this the > "RENCI> sequence" format, and it's basically similar to GenBank, while > > allowing an "abbreviated" (truncated) form that consists of only a > > partial header line with at least one namespace/id. (The > architecture> is described in > http://www.renci.org/~nassar/sequence_registry.ppt ) > > > > We've added some new datatypes under "RenciSequence" for this > purpose,> analogous to the existing "GenericSequence". In general > we are using > > the existing biomoby datatypes, but for sequences our format seems > > unusual enough that we thought it needed its own datatype to avoid > > confusion. > > > > Nassib > > _______________________________________________ > > 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 Yogaraj.Khanal at usd.edu Wed Dec 13 05:55:18 2006 From: Yogaraj.Khanal at usd.edu (Yogaraj.Khanal at usd.edu) Date: Tue, 12 Dec 2006 23:55:18 -0600 Subject: [MOBY-dev] getSignatureForm down Message-ID: <416f0bc416aaca.416aaca416f0bc@usd.edu> hi is the execution of my program related to the current problem with the moby can anyone help me? /* * Moby.java * * Created on December 3, 2006, 9:33 AM * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ import org.biomoby.client.*; import org.biomoby.shared.*; import org.biomoby.shared.data.*; /** * * @author yogaraj.khanal */ public class Moby { /** Creates a new instance of Moby */ public Moby() { } /** * @param args the command line arguments */ public static void main(String[] args) throws Exception{ Central worker = new CentralImpl(); MobyService templateService = new MobyService("runGeneIDGFF"); System.out.println(templateService.getName()); System.out.println(templateService.getUniqueName()); System.out.println(templateService.getAuthority()); MobyPrimaryData[] priinput=templateService.getPrimaryInputs(); System.out.println(priinput); MobyService[] validServices = worker.findService(templateService.getId()); System.out.println(validServices); MobyRequest mr = new MobyRequest(worker); //mr.setService(validServices[0]); //mr.setInput(new MobyDataObject("", "")); System.out.println(mr.invokeService().toString()); //MobyRequest mr = new MobyRequest(worker); mr.setService(validServices[10]); mr.setInput(new MobyDataObject("NCBI_gi", "111076")); MobyDataType dataType=new MobyDataType("AminoAcidSequence"); mr.setInput(new MobyDataObject("AminoAcidSequence")); MobyDataSecondaryInstance[] secondaryData=new MobyDataSecondaryInstance[5]; MobySecondaryData p1=new MobySecondaryData("strand"); p1.setDataType("String"); p1.setDefaultValue("Reverse"); MobySecondaryData p2=new MobySecondaryData("profile"); p2.setDataType("String"); p2.setDefaultValue("Arabidopsis thalina(weed)"); MobySecondaryData p3=new MobySecondaryData("engine"); p3.setDataType("String"); p3.setDefaultValue("Exon Mode"); MobySecondaryData p4=new MobySecondaryData("signals"); p4.setDataType("String"); p4.setDefaultValue("Start condons"); MobySecondaryData p5=new MobySecondaryData("exons"); p5.setDataType("String"); p5.setDefaultValue("All exons"); secondaryData[0]=new MobyDataSecondaryInstance(p1); secondaryData[1]=new MobyDataSecondaryInstance(p2); secondaryData[2]=new MobyDataSecondaryInstance(p3); secondaryData[3]=new MobyDataSecondaryInstance(p4); secondaryData[4]=new MobyDataSecondaryInstance(p5); mr.setSecondaryInput(secondaryData); System.out.println(mr.invokeService().toString()); // TODO code application logic here } } ----- Original Message ----- From: Edward Kawas Date: Tuesday, December 12, 2006 10:25 am Subject: Re: [MOBY-dev] getSignatureForm down > Hi Dirk, > > The page has moved to > http://mobycentral.icapture.ubc.ca:8090/authority/forms/getSignatureForm. Where > is that old reference? > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at lists.open-bio.org > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > > Sent: Tuesday, December 12, 2006 7:18 AM > > To: Core developer announcements > > Subject: [MOBY-dev] getSignatureForm down > > > > Hi, > > > > it seems that the getSignatureForm servlet > > (http://mobycentral.icapture.ubc.ca:8090/servlets/forms/getSig > > natureForm) is down - I think already for a couple of days now. > > > > Can somebody fix that? > > > > Thanks, > > dirk > > _______________________________________________ > > 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 d.haase at gsf.de Wed Dec 13 08:43:19 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 13 Dec 2006 09:43:19 +0100 Subject: [MOBY-dev] getSignatureForm down In-Reply-To: <001b01c71e0a$2d6839e0$6900a8c0@notebook> References: <001b01c71e0a$2d6839e0$6900a8c0@notebook> Message-ID: <200612130943.19578.d.haase@gsf.de> On Tuesday 12 December 2006 17:25, Edward Kawas wrote: > Hi Dirk, > > The page has moved to > http://mobycentral.icapture.ubc.ca:8090/authority/forms/getSignatureForm. > Where is that old reference? It was on the RDF FAQ on our project site (http://bioinfo.mpiz-koeln.mpg.de/araws/documentation/help/rdf-faq), but I fixed it now. It would be nice if you would post this kind of changes to the list. Or you did and I just missed it? Best, dirk From d.haase at gsf.de Wed Dec 13 13:36:10 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 13 Dec 2006 14:36:10 +0100 Subject: [MOBY-dev] missing SignatureURL in RDF Message-ID: <200612131436.11284.d.haase@gsf.de> Hi, one of our collaborators experienced a problem with an RDF returned by MOBY Central when he registered a service ( getTrypticPeptideSequenceByAGI) using the PERL library methods. He called 'registerService' with a fully filled argument hash, including a value for 'SignatureURL'. He received an RDF description but the element where the signature URL should appear was empty. Moreover, the signatureURL was not registered (at least not displayed in dashboard). Are we missing something? dirk From martin.senger at gmail.com Wed Dec 13 16:21:09 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 13 Dec 2006 17:21:09 +0100 Subject: [MOBY-dev] getSignatureForm down In-Reply-To: <416f0bc416aaca.416aaca416f0bc@usd.edu> References: <416f0bc416aaca.416aaca416f0bc@usd.edu> Message-ID: <4d93f07c0612130821n1f07644brdc4ec8da8d238f0e@mail.gmail.com> > is the execution of my program related to the current problem with the > moby Not sure what you mean. What is the "current problem"? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Wed Dec 13 16:47:01 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 13 Dec 2006 09:47:01 -0700 Subject: [MOBY-dev] getSignatureForm down In-Reply-To: <4d93f07c0612130821n1f07644brdc4ec8da8d238f0e@mail.gmail.com> References: <416f0bc416aaca.416aaca416f0bc@usd.edu> <4d93f07c0612130821n1f07644brdc4ec8da8d238f0e@mail.gmail.com> Message-ID: <45802E85.5020708@ucalgary.ca> What is wrong with his code is pretty much everything. :-) I made a working version of it, but will wait on posting until I fix an issue related to CrossReference deserialization I came across while doing this (in an hour or so). >> is the execution of my program related to the current problem with the >> moby >> > > > Not sure what you mean. What is the "current problem"? > Martin > > > From martin.senger at gmail.com Wed Dec 13 16:15:37 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 13 Dec 2006 17:15:37 +0100 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <416d7a0416d85b.416d85b416d7a0@usd.edu> References: <416d7a0416d85b.416d85b416d7a0@usd.edu> Message-ID: <4d93f07c0612130815n7db7019fn57a3307343365cca@mail.gmail.com> > i got problem executing this web service What problem? Be please more specific. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Wed Dec 13 18:06:04 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 13 Dec 2006 11:06:04 -0700 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <416d7a0416d85b.416d85b416d7a0@usd.edu> References: <416d7a0416d85b.416d85b416d7a0@usd.edu> Message-ID: <4580410C.90707@ucalgary.ca> Hi Yogaraj, There are several fundamental issues wrong with your original program, but the most salient are: -You don't have a sequence -The sequence you tried to specify in amino acid, but the service you want to run (runGeneIDGFF) takes DNA -You're executing the request before the data is set Below is an example that does as close as I can tell to want you intended: -Fetches a DNASequence from a genbank gi number (using the MOBYSHoundGetGenBankWhateverSequence) -Executes runGeneIDGFF on the DNASequence -The secondary parameters already existing in association with the service, so you don't need to create them from scratch Enjoy! P.S. Please do a CVS update, I made a few changes to deal with the crossreferences MOBYSHoundGetGenBankWhateverSequence returns -------------- import org.biomoby.client.*; import org.biomoby.shared.*; import org.biomoby.shared.data.*; /** * * @author Paul Gordon */ public class Moby { /** * @param args the command line arguments */ public static void main(String[] args) throws Exception{ Central worker = new CentralImpl(); MobyRequest mr = new MobyRequest(worker); // Retrieve the DNASequence from the NCBI GI ID MobyService templateService = new MobyService("MOBYSHoundGetGenBankWhateverSequence"); MobyService[] validServices = worker.findService(templateService); mr.setService(validServices[0]); // id -> dna mr.setInput(new MobyDataObject("NCBI_gi","54695")); MobyContentInstance responses = mr.invokeService(); // Retrieve the GFF predictions for each DNASequence returned // (should be only one for this service, but the API doesn't know that) templateService = new MobyService("runGeneIDGFF"); validServices = worker.findService(templateService); mr.setService(validServices[0]); // dna -> gff for(MobyDataJob response: responses.values()){ for(MobyDataObject dna: response.getPrimaryDataObjects()){ mr.setInput(dna); setSecondaries(mr, validServices[0]); System.out.println(mr.invokeService().toString()); } } } public static void setSecondaries(MobyRequest mr, MobyService service){ MobySecondaryData[] secondaryData = service.getSecondaryInputs(); MobyDataSecondaryInstance[] secondaryInstances = new MobyDataSecondaryInstance[secondaryData.length]; for(int i = 0; i < secondaryData.length; i++){ MobySecondaryData param = secondaryData[i]; // Set specific values for the following params if(param.getName().equals("strand")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "Reverse"); } else if(param.getName().equals("profile")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "Arabidopsis thaliana (weed)"); } else if(param.getName().equals("engine")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "Exon Mode"); } else if(param.getName().equals("signals")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "Start codons"); } else if(param.getName().equals("exons")){ secondaryInstances[i] = new MobyDataSecondaryInstance(param, "All exons"); } // Use default value for other parameters (if any) else{ secondaryInstances[i] = new MobyDataSecondaryInstance(param); } } mr.setSecondaryInput(secondaryInstances); } } > hi to all, > i got problem executing this web service can anyone help me > > /* > * Moby.java > * > * Created on December 3, 2006, 9:33 AM > * > * To change this template, choose Tools | Options and locate the template under > * the Source Creation and Management node. Right-click the template and choose > * Open. You can then make changes to the template in the Source Editor. > */ > import org.biomoby.client.*; > import org.biomoby.shared.*; > import org.biomoby.shared.data.*; > /** > * > * @author yogaraj.khanal > */ > public class Moby { > > /** Creates a new instance of Moby */ > public Moby() { > } > > /** > * @param args the command line arguments > */ > public static void main(String[] args) throws Exception{ > Central worker = new CentralImpl(); > MobyService templateService = new MobyService("runGeneIDGFF"); > System.out.println(templateService.getName()); > System.out.println(templateService.getUniqueName()); > System.out.println(templateService.getAuthority()); > MobyPrimaryData[] priinput=templateService.getPrimaryInputs(); > System.out.println(priinput); > > MobyService[] validServices = worker.findService(templateService.getId()); > System.out.println(validServices); > MobyRequest mr = new MobyRequest(worker); > //mr.setService(validServices[0]); > > //mr.setInput(new MobyDataObject("", "")); > System.out.println(mr.invokeService().toString()); > > //MobyRequest mr = new MobyRequest(worker); > mr.setService(validServices[10]); > > mr.setInput(new MobyDataObject("NCBI_gi", "111076")); > MobyDataType dataType=new MobyDataType("AminoAcidSequence"); > mr.setInput(new MobyDataObject("AminoAcidSequence")); > MobyDataSecondaryInstance[] secondaryData=new MobyDataSecondaryInstance[5]; > MobySecondaryData p1=new MobySecondaryData("strand"); > p1.setDataType("String"); > p1.setDefaultValue("Reverse"); > MobySecondaryData p2=new MobySecondaryData("profile"); > p2.setDataType("String"); > p2.setDefaultValue("Arabidopsis thalina(weed)"); > MobySecondaryData p3=new MobySecondaryData("engine"); > p3.setDataType("String"); > p3.setDefaultValue("Exon Mode"); > MobySecondaryData p4=new MobySecondaryData("signals"); > p4.setDataType("String"); > p4.setDefaultValue("Start condons"); > MobySecondaryData p5=new MobySecondaryData("exons"); > p5.setDataType("String"); > p5.setDefaultValue("All exons"); > > secondaryData[0]=new MobyDataSecondaryInstance(p1); > secondaryData[1]=new MobyDataSecondaryInstance(p2); > secondaryData[2]=new MobyDataSecondaryInstance(p3); > secondaryData[3]=new MobyDataSecondaryInstance(p4); > secondaryData[4]=new MobyDataSecondaryInstance(p5); > mr.setSecondaryInput(secondaryData); > > System.out.println(mr.invokeService().toString()); > // TODO code application logic here > } > > } > > ----- Original Message ----- > From: Paul Gordon > Date: Tuesday, December 12, 2006 3:40 pm > Subject: Re: [MOBY-dev] sequence datatypes > > >> Hi Nassib, >> >> I looked at the presentation, and I'm not sure why you can't just >> use a >> VirtualSequence instead. You can then have all of the >> combinations you >> want, as long as you register the namespaces: >> >> >> 1500 >> >> >> >> 1500 >> >> >> >> 1500 >> >> >> >> 1500 >> > id="">ATG... >> >> etc., etc. >> >>> Hi, >>> >>> I'd like to start explaining a little bit about our use of >>> >> biomoby and >> >>> also request feedback... >>> >>> We're using biomoby mainly with taverna workflows, and gradually >>> migrating current web services over to become biomoby services >>> >> (under> biomoby.renci.org). The workflows we develop are talking >> to services >> >>> that for the most part are based here within our servers. As a >>> >> result> we end up passing a very large amount of duplicated >> sequence data over >> >>> the network between taverna and services, often more data than >>> >> taverna> is happy about. To get around this we have started >> passing sequences >> >>> by reference using a FASTA-like format that is non-standard but fits >>> well into our system and the taverna UI. I'm calling this the >>> >> "RENCI> sequence" format, and it's basically similar to GenBank, while >> >>> allowing an "abbreviated" (truncated) form that consists of only a >>> partial header line with at least one namespace/id. (The >>> >> architecture> is described in >> http://www.renci.org/~nassar/sequence_registry.ppt ) >> >>> We've added some new datatypes under "RenciSequence" for this >>> >> purpose,> analogous to the existing "GenericSequence". In general >> we are using >> >>> the existing biomoby datatypes, but for sequences our format seems >>> unusual enough that we thought it needed its own datatype to avoid >>> confusion. >>> >>> Nassib >>> _______________________________________________ >>> 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 ots at ac.uma.es Wed Dec 13 18:45:21 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Wed, 13 Dec 2006 19:45:21 +0100 Subject: [MOBY-dev] registering INB services in Canada In-Reply-To: References: <4577F54F.5020903@pcm.uam.es> Message-ID: <45804A41.3050903@ac.uma.es> I'd like to provide some additional information to help understanding our perspective. 1) When we were developing the INB system we realise on the need for ensuring availability and service inter-connection based on the moby ontology. However, several mails from the moby community warned us on the importance of a curate catalogue. (i.e.) "Right now in the registry if I send a generic object I get over a hundred services back, almost none of which will actually consume the object without dying a horrible death." (Gordon, Feb 17th), or this other more explicit, "MOBY Central has become increasingly useless over the past couple of years as it got filled with junk, badly registered services, dead services, "localhost" services, test services, and all manner of other registration artifacts (M.W. response)" 2) In this sense we made a great effort in the registering procedure. We hold several internal meetings with some invited experts from the moby community to introduce, comment, discuss and get feedback about our strategy. So, it is not a new issue. 3) Natalias?s email correctly states the real-problem of different catalogues. In several previous emails the equivalent issues of federated ontologies, disperse catalogues, etc. were at least enumerated. So, it is opportune to launch the discussion. 4) My group at the GNV5-INB University of Malaga- is open to contribute in the discussion of the technical and procedural aspects involved in this issue, oriented to propose a global solution. 5) In our opinion, Natalia?s email is not the problem but part of the solution (our system works properly?at the moment at least !) with regards, O. PS, I?d like to thanks all mobiers that having nothing constructive to say have avoided reply with unfortunate emails. and finally I suspect that the Phillip Lord phrase regards **good** ontologies. Mark Wilkinson escribi?: > The immortal words of Phillip Lord are ringing in my head right now... "An > ontology is not an ontology unless it is SHARED!" :-) > > This is a topic that has been discussed (perhaps not on-list?) for many > years - going all the way back to the first group (PlaNet) who set up > their own registry. If you "fork" the ontology, then everything breaks, > unfortunately. I don't think we have ever found a workable solution to > this situation. Next-generation MOBY, with RDF/OWL and reasoning and > such, may be able to deal with this problem, but MOBY-S is pretty much > stuck with one, centralized ontology (which, in our defence, is how the > vast majority of ontologies work at this point in Web history). > > I'm just catching up with my emails after being away for 10 days. I don't > see anyone else responding to this so far. I don't have any suggestions > to help you at the moment, but I can raise it at my next lab meeting and > perhaps an idea will come up...?? I have a feeling that there isn't a > "magic" solution. MOBY works *because* we all agree on the ontology. If > you don't agree on the ontology, then you aren't interoperable... it's > pretty much the core principle of the project... > > M > > > > > On Thu, 07 Dec 2006 03:04:47 -0800, Natalia Jimenez Lozano > wrote: > > >> Hi, >> >> I would like to open a discussion about ontologies. I belong to the INB >> where we have currently a lot of working services. We would like to >> register all of our services in Canada but due to the differences >> between both ontologies (Canada and Spain), we could ran into the >> following problems: >> >> a) Identical objects (objects that share the same name and the same >> hierarchy): in this case there would be no problem using the object >> previously registered in Canada. >> >> b) Analogous objects (objects that share the same name but different >> hierarchy): it would be possible to register in Canada the object with >> the same name but different hierarchy? If it would be possible we would >> be "breaking" the Canadian ontology :-( >> >> Some examples of this situation can be easily found: >> >> b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of >> text_formatted node but in Canadian ontology is a son of BLAST-Report >> that is at the same time a son of Sequence_alignment_report. >> b.2. There is a lot of common objects like Clustalw_Evaluated_Text, >> FASTA, GFF ..., etc which only difference is their depencency: in >> Canadian ontology, these objects are depending on text-formatted node >> but in the Spanish ontology on text_formatted (the only difference is >> hyphen/underscore!). >> >> c) Similar objects (different name -similar, upper-case/lower case, >> underscore/hyphen- and/or different hierarchy but same meaning): to fit >> to this last situation, we have several options: >> >> - To register INB objects -> this would not "break" the Canadian >> ontology but would "blur" it. >> - To adjust each one of the INB services to the Canadian ontology -> >> This would mean the modification of the code of each one of the services >> and it would require an extra work. >> - To modify INB ontology to adjust to Canadian ontology -> This >> would be a thorny issue because since INB beginnings we have work very >> hard in this sense. Even we organized an ontology committee to give >> advise on each new object to be registered. Moreover, few months ago we >> restructured our ontology with the aim of removing inconsistencies. In >> my opinion, we have currently a very solid ontology. >> >> Suggestions about how to register INB services in a easily and not >> damaging way? >> Thank you very much in advance, >> Regards, >> Natalia >> >> >> _______________________________________________ >> 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 Thu Dec 14 22:45:00 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 14 Dec 2006 14:45:00 -0800 Subject: [MOBY-dev] [moby] Re: registering INB services in Canada In-Reply-To: <45804A41.3050903@ac.uma.es> References: <4577F54F.5020903@pcm.uam.es> <45804A41.3050903@ac.uma.es> Message-ID: <1166136300.12669.45.camel@bioinfo.icapture.ubc.ca> Hi Oswaldo, I think the most important thing is to thank you for your team's willingness to contribute to the code-base and the public registry and ontologies. It is greatly appreciated, as are all of the INB contributions! I have no doubt at all that your registry works far better than the public one because it has been hand-curated and carefully controlled from the outset. I think that, for academic interest, the chaos of the public registry and ontologies has been interesting to observe, since one of the major research questions of my laboratory is "can a useful ontology arise through a completely open and non-curated process"[1]. Economically we adopted a non-curated approach because our original development budget was barely enough to get the project off the ground at all. And finally philosophically the public registry has a "laissez faire" attitude towards what we allow people to register in it, because we specifically avoid telling people what data-types, service types, etc. they should use in order to be as open as possible to all participants. Nevertheless, as you correctly point out, and a variety of us have noted several times on the discussion list, this makes the public registry an uncomfortably "wild" place to do any real work! The various projects who have set-up independent registries have all handled this in different ways. The PlaNet project registered data-types in their local registry as well as in the public one on an ongoing basis in order to keep their ontologies as synchronized as possible with the public ones; the GCP project created a "branch" of the public ontology (the GCP_* Objects) containing several structurally identical or semantically similar objects to those in other parts of the public ontology, but in a hierarchy that was specifically meaningful and useful to them; and the INB created it's own ontologies entirely from scratch. Of these approaches, only the PlaNet approach retained true interoperability with those outside of their own project. This is not a criticism of any approach, it is simply an observation that the concept of "ontology sharing" is critical to the functionality of MOBY (the question of whether the shared public ontology is "good" or "not good" is an entirely different story...) The issue of how to re-integrate two forked copies of the ontology is, therefore, a very complex one, since none of our software is currently prepared to deal with this problem in any automated way, and automated ontology-alignment is still largely wishful thinking anyway [2]. It is undesirable for the INB to have to re-code their services since this is extra work, and it is similarly undesirable (in fact, more or less impossible) for us to ask the other public services to re-write their code to adapt to the INB objects, even if they are "better". Short-term, I honestly don't see a straightforward solution to the problem for every case. Obviously the objects that can be registered in the public ontology without naming clashes can be registered there whenever you wish. However, for those that have identical names...?? I guess the first step would be to check if the objects in the public registry are being used at all. If they are not, then you are welcome to de-register them as per the API. Second, you could check if the services that use that object are functional. At the moment, about 15% of the services in the public registry are non-functional [3]. If a service is non-functional, you could contact the provider and ask if they are still maintaining the service at all, and if not, ask them to de-register the service such that you can de-register the objects that it uses. Finally, if there were only one or two services that use the object you wish to remove, you could ask them if they would be willing to change their service to adopt your new object. They may say no, of course, but... you could ask :-) Longer-term, we might be able to solve this problem at the level of XML namespaces (i.e. identify which of the two ontologies the object came from based on its XML namespace); however as I said, none of the code currently can handle this situation, so it isn't a solution in the short-term, and moreover I would much prefer to see the project move toward an RDF-based data representation system versus continuing to develop code for and refine the existing custom-MOBY-XML standard. If we plan to support multiple ontologies in the future, I think it would make more sense to do so under one of the W3C ontology standards versus invest more resources in making the current MOBY "standard" do what these other standards can already do (to some limited extent...) So... I honestly don't have a suggestion that solves all of the problems without requiring someone to do some re-coding of their services. I guess this is what I said in my original response, but it seems to have caused some offense, so I hope this more verbose response is less controversial. Regardless, any contribution your team is willing to make is always welcome and appreciated, Best wishes, Mark [1] http://helix-web.stanford.edu/psb06/good.pdf [2] http://www.atl.lmco.com/projects/ontology/ [3] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService? getDeadServices On Wed, 2006-12-13 at 19:45 +0100, Oswaldo Trelles wrote: > I'd like to provide some additional information to help understanding > our perspective. > > 1) When we were developing the INB system we realise on the need for > ensuring availability and service inter-connection based on the moby > ontology. However, several mails from the moby community warned us on > the importance of a curate catalogue. (i.e.) "Right now in the registry > if I send a generic object I get over a hundred services back, almost > none of which will actually consume the object without dying a horrible > death." (Gordon, Feb 17th), or this other more explicit, "MOBY Central > has become increasingly useless over the past couple of years as it got > filled with junk, badly registered services, dead services, "localhost" > services, test services, and all manner of other registration artifacts > (M.W. response)" > > 2) In this sense we made a great effort in the registering procedure. We > hold several internal meetings with some invited experts from the moby > community to introduce, comment, discuss and get feedback about our > strategy. So, it is not a new issue. > 3) Natalias?s email correctly states the real-problem of different > catalogues. In several previous emails the equivalent issues of > federated ontologies, disperse catalogues, etc. were at least > enumerated. So, it is opportune to launch the discussion. > 4) My group at the GNV5-INB University of Malaga- is open to contribute > in the discussion of the technical and procedural aspects involved in > this issue, oriented to propose a global solution. > 5) In our opinion, Natalia?s email is not the problem but part of the > solution (our system works properly?at the moment at least !) > > with regards, > > O. > > PS, I?d like to thanks all mobiers that having nothing constructive to > say have avoided reply with unfortunate emails. > > and finally I suspect that the Phillip Lord phrase regards **good** > ontologies. > > > > Mark Wilkinson escribi?: > > The immortal words of Phillip Lord are ringing in my head right now... "An > > ontology is not an ontology unless it is SHARED!" :-) > > > > This is a topic that has been discussed (perhaps not on-list?) for many > > years - going all the way back to the first group (PlaNet) who set up > > their own registry. If you "fork" the ontology, then everything breaks, > > unfortunately. I don't think we have ever found a workable solution to > > this situation. Next-generation MOBY, with RDF/OWL and reasoning and > > such, may be able to deal with this problem, but MOBY-S is pretty much > > stuck with one, centralized ontology (which, in our defence, is how the > > vast majority of ontologies work at this point in Web history). > > > > I'm just catching up with my emails after being away for 10 days. I don't > > see anyone else responding to this so far. I don't have any suggestions > > to help you at the moment, but I can raise it at my next lab meeting and > > perhaps an idea will come up...?? I have a feeling that there isn't a > > "magic" solution. MOBY works *because* we all agree on the ontology. If > > you don't agree on the ontology, then you aren't interoperable... it's > > pretty much the core principle of the project... > > > > M > > > > > > > > > > On Thu, 07 Dec 2006 03:04:47 -0800, Natalia Jimenez Lozano > > wrote: > > > > > >> Hi, > >> > >> I would like to open a discussion about ontologies. I belong to the INB > >> where we have currently a lot of working services. We would like to > >> register all of our services in Canada but due to the differences > >> between both ontologies (Canada and Spain), we could ran into the > >> following problems: > >> > >> a) Identical objects (objects that share the same name and the same > >> hierarchy): in this case there would be no problem using the object > >> previously registered in Canada. > >> > >> b) Analogous objects (objects that share the same name but different > >> hierarchy): it would be possible to register in Canada the object with > >> the same name but different hierarchy? If it would be possible we would > >> be "breaking" the Canadian ontology :-( > >> > >> Some examples of this situation can be easily found: > >> > >> b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of > >> text_formatted node but in Canadian ontology is a son of BLAST-Report > >> that is at the same time a son of Sequence_alignment_report. > >> b.2. There is a lot of common objects like Clustalw_Evaluated_Text, > >> FASTA, GFF ..., etc which only difference is their depencency: in > >> Canadian ontology, these objects are depending on text-formatted node > >> but in the Spanish ontology on text_formatted (the only difference is > >> hyphen/underscore!). > >> > >> c) Similar objects (different name -similar, upper-case/lower case, > >> underscore/hyphen- and/or different hierarchy but same meaning): to fit > >> to this last situation, we have several options: > >> > >> - To register INB objects -> this would not "break" the Canadian > >> ontology but would "blur" it. > >> - To adjust each one of the INB services to the Canadian ontology -> > >> This would mean the modification of the code of each one of the services > >> and it would require an extra work. > >> - To modify INB ontology to adjust to Canadian ontology -> This > >> would be a thorny issue because since INB beginnings we have work very > >> hard in this sense. Even we organized an ontology committee to give > >> advise on each new object to be registered. Moreover, few months ago we > >> restructured our ontology with the aim of removing inconsistencies. In > >> my opinion, we have currently a very solid ontology. > >> > >> Suggestions about how to register INB services in a easily and not > >> damaging way? > >> Thank you very much in advance, > >> Regards, > >> Natalia > >> > >> > >> _______________________________________________ > >> 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 ots at ac.uma.es Fri Dec 15 19:18:20 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 15 Dec 2006 20:18:20 +0100 Subject: [MOBY-dev] Collections vs. Simples in registry service searches, a bug? In-Reply-To: <457DA8E0.4020806@ucalgary.ca> References: <457DA8E0.4020806@ucalgary.ca> Message-ID: <4582F4FC.7040606@ac.uma.es> Hi some time ago we start developing a strategy to deal with collection. An initial idea was that MOWServ would allows call a simple-input/simple-output service with a collection (MOWServ should split the collection, invoke iteratively the service with each simple and collect all the results providing a collection as output (all simple/simple, simple/collec, collec/simple and collec/colecc cases were analysed properly). Under this idea, in MOWServ when you perform a query asking for services that take a simple as input, also, those services that uses a collection (of the same type, of course) are returned. (however we have not make a final decission and implementation, and we are re-analysing our ideas) regards, O. (and sorry for delay in posting this comment but have a mountain of pending emails) Paul Gordon escribi?: > Hi all, > > Is there any reason that a service taking a *collection* of DNASequences > as input is returned when I perform a query asking for services that > take a *simple* DNASequence as input? e.g. the GenerateCodonPairTable > service takes a collection and is returned on a simple DNASequence > search. Here is the relevant part of the RDF from the registry: > > > > > > > > inputSequences > > > > > > > And the request is: > > > > > DNASequence > seahawk > > > > > > > > moby > > 1 > 1 > 0 > > > > _______________________________________________ > 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 Fri Dec 15 21:05:34 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 15 Dec 2006 14:05:34 -0700 Subject: [MOBY-dev] Collections vs. Simples in registry service searches, a bug? In-Reply-To: <4582F4FC.7040606@ac.uma.es> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> Message-ID: <45830E1E.4030303@ucalgary.ca> Hi all, While I agree that makes sense for a *client* such as MOWServ to do this type of splitting if it wants, my major problem is that the *registry* treats both equally. Collections should only be registered as input types where a collection is actually used as a single entity, e.g. multiple sequence alignments. If you want to allow multiple DNASequences to be fed into a request for a BLAST service, the service should take a single DNASequence, and you can put multiple mobyData blocks in the request. Currently, I must check through the services returned by the registry and exclude those that take DNASequence Collections in order to avoid errors in my Seahawk client...this seems very wrong. Mark? Eddie? > Hi > some time ago we start developing a strategy to deal with collection. An > initial idea was that MOWServ would allows call a > simple-input/simple-output service with a collection (MOWServ should > split the collection, invoke iteratively the service with each simple > and collect all the results providing a collection as output (all > simple/simple, simple/collec, collec/simple and collec/colecc cases were > analysed properly). > > Under this idea, in MOWServ when you perform a query asking for services > that take a simple as input, also, those services that uses a collection > (of the same type, of course) are returned. > > (however we have not make a final decission and implementation, and we > are re-analysing our ideas) > > regards, > O. (and sorry for delay in posting this comment but have a mountain of > pending emails) > > > > > Paul Gordon escribi?: > >> Hi all, >> >> Is there any reason that a service taking a *collection* of DNASequences >> as input is returned when I perform a query asking for services that >> take a *simple* DNASequence as input? e.g. the GenerateCodonPairTable >> service takes a collection and is returned on a simple DNASequence >> search. Here is the relevant part of the RDF from the registry: >> >> >> >> >> >> >> >> inputSequences >> >> >> >> >> >> >> And the request is: >> >> >> >> >> DNASequence >> seahawk >> >> >> >> >> >> >> >> moby >> >> 1 >> 1 >> 0 >> >> >> >> _______________________________________________ >> 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 Dec 15 21:38:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 15 Dec 2006 13:38:40 -0800 Subject: [MOBY-dev] [moby] Re: Collections vs. Simples in registry service searches, a bug? In-Reply-To: <45830E1E.4030303@ucalgary.ca> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> <45830E1E.4030303@ucalgary.ca> Message-ID: <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca> Hi Paul, I'm a bit snowed-under with four GC Tech Development applications in preparation. Could you check the code yourself and see if there's an obvious reason for the behavior you are observing? I'm not sure if searches for collections was ever implemented... ever?!? but it was almost 5 years ago now, so my memory is a bit rusty ;-) M On Fri, 2006-12-15 at 14:05 -0700, Paul Gordon wrote: > Hi all, > > While I agree that makes sense for a *client* such as MOWServ to do this > type of splitting if it wants, my major problem is that the *registry* > treats both equally. Collections should only be registered as input > types where a collection is actually used as a single entity, e.g. > multiple sequence alignments. If you want to allow multiple > DNASequences to be fed into a request for a BLAST service, the service > should take a single DNASequence, and you can put multiple mobyData > blocks in the request. > > Currently, I must check through the services returned by the registry > and exclude those that take DNASequence Collections in order to avoid > errors in my Seahawk client...this seems very wrong. Mark? Eddie? > > Hi > > some time ago we start developing a strategy to deal with collection. An > > initial idea was that MOWServ would allows call a > > simple-input/simple-output service with a collection (MOWServ should > > split the collection, invoke iteratively the service with each simple > > and collect all the results providing a collection as output (all > > simple/simple, simple/collec, collec/simple and collec/colecc cases were > > analysed properly). > > > > Under this idea, in MOWServ when you perform a query asking for services > > that take a simple as input, also, those services that uses a collection > > (of the same type, of course) are returned. > > > > (however we have not make a final decission and implementation, and we > > are re-analysing our ideas) > > > > regards, > > O. (and sorry for delay in posting this comment but have a mountain of > > pending emails) > > > > > > > > > > Paul Gordon escribi?: > > > >> Hi all, > >> > >> Is there any reason that a service taking a *collection* of DNASequences > >> as input is returned when I perform a query asking for services that > >> take a *simple* DNASequence as input? e.g. the GenerateCodonPairTable > >> service takes a collection and is returned on a simple DNASequence > >> search. Here is the relevant part of the RDF from the registry: > >> > >> > >> > >> > >> > >> > >> > >> inputSequences > >> > >> > >> > >> > >> > >> > >> And the request is: > >> > >> > >> > >> > >> DNASequence > >> seahawk > >> > >> > >> > >> > >> > >> > >> > >> moby > >> > >> 1 > >> 1 > >> 0 > >> > >> > >> > >> _______________________________________________ > >> 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 gordonp at ucalgary.ca Sat Dec 16 04:13:05 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 15 Dec 2006 21:13:05 -0700 Subject: [MOBY-dev] [moby] Re: Collections vs. Simples in registry service searches, a bug? In-Reply-To: <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> <45830E1E.4030303@ucalgary.ca> <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca> Message-ID: <45837251.9040704@ucalgary.ca> Geesh! The things you have to do for service around here! :-) After poking around in the registry SQL tables for a bit, I think I found the culprit. I'm not super familiar with this part of the code, so I'll let you (Mark or Eddie) do the honours: Switch MOBY/Adaptor/moby/queryapi/mysql.pm, line 1212's SQL statement from: From gordonp at ucalgary.ca Sat Dec 16 04:17:42 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 15 Dec 2006 21:17:42 -0700 Subject: [MOBY-dev] [moby] Re: Collections vs. Simples in registry service searches, a bug? In-Reply-To: <45837251.9040704@ucalgary.ca> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> <45830E1E.4030303@ucalgary.ca> <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca> <45837251.9040704@ucalgary.ca> Message-ID: <45837366.2000900@ucalgary.ca> Sorry, last message got cut off for some reason (mailing list filter?). Again, change MOBY/Adaptor/moby/queryapi/mysql.pm line 1212 from select service_instance_id, namespace_type_uris from simple_$inout where object_type_uri in ($ancestor_string) and service_instance_id IS NOT NULL to select service_instance_id, namespace_type_uris from simple_$inout where object_type_uri in ($ancestor_string) and collection_input_id IS NULL From markw at illuminae.com Sat Dec 16 04:24:51 2006 From: markw at illuminae.com (mark wilkinson) Date: Sat, 16 Dec 2006 04:24:51 +0000 GMT Subject: [MOBY-dev] [moby] Re: Collections vs. Simplesin registry service searches, a bug? In-Reply-To: <45837366.2000900@ucalgary.ca> References: <457DA8E0.4020806@ucalgary.ca> <4582F4FC.7040606@ac.uma.es> <45830E1E.4030303@ucalgary.ca> <1166218720.16226.4.camel@bioinfo.icapture.ubc.ca><45837251.9040704@ucalgary.ca> <45837366.2000900@ucalgary.ca> Message-ID: <1224425260-1166243135-cardhu_blackberry.rim.net-21612-@engine25-cell01> Thanks Paul :-) remember that your nickname used to be "Perl" Gordon, and that you are (were?) Funded from the same pot of money as I am... So you are not allowed to complain about service! :-) I'll make the change tomorrow and bring all of the other INB changes and the ones that Heiko and I made last week into the live registry at the same time. Big changes to the Moby API, but nothing that disturbs anyone. We need to document these changes ASAP so that others can use them!!! Paul, can I ask you to change the relevant docs to correctly explain what the search for collections does? At the moment I don't think it is documented at all... M -- Mark Wilkinson ...on the road! -----Original Message----- From: Paul Gordon Date: Fri, 15 Dec 2006 21:17:42 To:Core developer announcements Cc:markw at illuminae.com Subject: Re: [MOBY-dev] [moby] Re: Collections vs. Simples in registry service searches, a bug? Sorry, last message got cut off for some reason (mailing list filter?). Again, change MOBY/Adaptor/moby/queryapi/mysql.pm line 1212 from select service_instance_id, namespace_type_uris from simple_$inout where object_type_uri in ($ancestor_string) and service_instance_id IS NOT NULL to select service_instance_id, namespace_type_uris from simple_$inout where object_type_uri in ($ancestor_string) and collection_input_id IS NULL _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Dec 19 08:14:32 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 19 Dec 2006 09:14:32 +0100 Subject: [MOBY-dev] Test Central Down Message-ID: <200612190914.33434.d.haase@gsf.de> Eddie, or whoever feels responsible, the test registry seems to be down since yesterday. Whenever I try to connect I get an internal server error. Is this something serious or did just nobody notice yet? Best, dirk From edward.kawas at gmail.com Tue Dec 19 14:47:44 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 19 Dec 2006 06:47:44 -0800 Subject: [MOBY-dev] Test Central Down In-Reply-To: <200612190914.33434.d.haase@gsf.de> Message-ID: <002701c7237c$a585e180$6900a8c0@notebook> Hi Dirk, I fixed it (and committed code to the repository). Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, December 19, 2006 12:15 AM > To: Core developer announcements > Subject: [MOBY-dev] Test Central Down > > Eddie, > > or whoever feels responsible, the test registry seems to be > down since yesterday. Whenever I try to connect I get an > internal server error. Is this something serious or did just > nobody notice yet? > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From nassar at renci.org Wed Dec 20 21:43:05 2006 From: nassar at renci.org (Nassib Nassar) Date: Wed, 20 Dec 2006 16:43:05 -0500 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <457F21DD.7030904@ucalgary.ca> References: <20061212203611.GA9247@renci.org> <457F21DD.7030904@ucalgary.ca> Message-ID: <20061220214305.GA4523@renci.org> Hi Paul, Sorry for the slow reply.... What you suggest was our original intention, but we found it too complicated to explain the difference at the taverna level between passing data into the namespace/id vs. value fields. More importantly, I think, it's convenient for the workflow developers to be able to pass sequences either by reference or by value along a single pathway, anywhere in a workflow where sequences are being processed. The register and lookup services are used like filters to abbreviate and expand sequences, but all of our services will accept either the standard or abbreviated forms. This is rather experimental, but so far it seems to be working very well. Nassib On Tue, Dec 12, 2006 at 02:40:45PM -0700, Paul Gordon wrote: > Hi Nassib, > > I looked at the presentation, and I'm not sure why you can't just use a > VirtualSequence instead. You can then have all of the combinations you > want, as long as you register the namespaces: > > > 1500 > > > > 1500 > > > > 1500 > > > > 1500 > ATG... > > > etc., etc. > > Hi, > > > > I'd like to start explaining a little bit about our use of biomoby and > > also request feedback... > > > > We're using biomoby mainly with taverna workflows, and gradually > > migrating current web services over to become biomoby services (under > > biomoby.renci.org). The workflows we develop are talking to services > > that for the most part are based here within our servers. As a result > > we end up passing a very large amount of duplicated sequence data over > > the network between taverna and services, often more data than taverna > > is happy about. To get around this we have started passing sequences > > by reference using a FASTA-like format that is non-standard but fits > > well into our system and the taverna UI. I'm calling this the "RENCI > > sequence" format, and it's basically similar to GenBank, while > > allowing an "abbreviated" (truncated) form that consists of only a > > partial header line with at least one namespace/id. (The architecture > > is described in http://www.renci.org/~nassar/sequence_registry.ppt ) > > > > We've added some new datatypes under "RenciSequence" for this purpose, > > analogous to the existing "GenericSequence". In general we are using > > the existing biomoby datatypes, but for sequences our format seems > > unusual enough that we thought it needed its own datatype to avoid > > confusion. > > > > Nassib > > _______________________________________________ > > 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 ots at ac.uma.es Thu Dec 21 07:52:28 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 21 Dec 2006 08:52:28 +0100 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <20061220214305.GA4523@renci.org> References: <20061212203611.GA9247@renci.org> <457F21DD.7030904@ucalgary.ca> <20061220214305.GA4523@renci.org> Message-ID: <458A3D3C.2000303@ac.uma.es> Hi, We are aware about the problem of network overload produced by large data transmission, even when services are located in local networks or even in the same server (i.e. most of our services are located in two servers, so in general, partial data transmission is unnecessary). In this line we are analysing two alternatives: a) sub-workflows (or jobs) to submit a set of tasks to be executed in the same server (a scheduler module, as is the case of MOWServ could identify the set of related tasks). We need to review the documentation to ensure that only the last service returns the output (intermediate results could be requested using the asynch protocol). b) a more general (ergo, more interesting) alternative goes in the way to define a pointer/reference to a local object (an object currently stored in the local file system). Of course we should avoid defining a new object (the corresponding couple-object) for each object (sequences, gene-expression data, structures, etc etc and subtypes). So we could agree in a label/tag or whatever other alternative in the appropriated position of the xml to recognise this type of specification. of course these are only initial ideas regarding a real problem that should be discussed (and solved) best regards, O. GNV5-INB Nassib Nassar escribi?: > Hi Paul, > > Sorry for the slow reply.... What you suggest was our original > intention, but we found it too complicated to explain the difference > at the taverna level between passing data into the namespace/id > vs. value fields. More importantly, I think, it's convenient for the > workflow developers to be able to pass sequences either by reference > or by value along a single pathway, anywhere in a workflow where > sequences are being processed. The register and lookup services are > used like filters to abbreviate and expand sequences, but all of our > services will accept either the standard or abbreviated forms. This > is rather experimental, but so far it seems to be working very well. > > Nassib > > > On Tue, Dec 12, 2006 at 02:40:45PM -0700, Paul Gordon wrote: > >> Hi Nassib, >> >> I looked at the presentation, and I'm not sure why you can't just use a >> VirtualSequence instead. You can then have all of the combinations you >> want, as long as you register the namespaces: >> >> >> 1500 >> >> >> >> 1500 >> >> >> >> 1500 >> >> >> >> 1500 >> ATG... >> >> >> etc., etc. >> >>> Hi, >>> >>> I'd like to start explaining a little bit about our use of biomoby and >>> also request feedback... >>> >>> We're using biomoby mainly with taverna workflows, and gradually >>> migrating current web services over to become biomoby services (under >>> biomoby.renci.org). The workflows we develop are talking to services >>> that for the most part are based here within our servers. As a result >>> we end up passing a very large amount of duplicated sequence data over >>> the network between taverna and services, often more data than taverna >>> is happy about. To get around this we have started passing sequences >>> by reference using a FASTA-like format that is non-standard but fits >>> well into our system and the taverna UI. I'm calling this the "RENCI >>> sequence" format, and it's basically similar to GenBank, while >>> allowing an "abbreviated" (truncated) form that consists of only a >>> partial header line with at least one namespace/id. (The architecture >>> is described in http://www.renci.org/~nassar/sequence_registry.ppt ) >>> >>> We've added some new datatypes under "RenciSequence" for this purpose, >>> analogous to the existing "GenericSequence". In general we are using >>> the existing biomoby datatypes, but for sequences our format seems >>> unusual enough that we thought it needed its own datatype to avoid >>> confusion. >>> >>> Nassib >>> _______________________________________________ >>> 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 Dec 29 15:33:13 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 29 Dec 2006 07:33:13 -0800 Subject: [MOBY-dev] sequence datatypes In-Reply-To: <458A3D3C.2000303@ac.uma.es> References: <20061212203611.GA9247@renci.org> <457F21DD.7030904@ucalgary.ca> <20061220214305.GA4523@renci.org> <458A3D3C.2000303@ac.uma.es> Message-ID: Hi all, just a quick question v.v. this thread: The work that Heiko and I did together a couple of weeks ago while I was in Germany allows the provision of services using HTTP POST. The idea being that you pass a (rather than ) message into a service by POST and it returns a message in response. It seems to me (though we haven't tried it, nor written any code for it yet) that it would be possible to set up: a) a service that "streams" its output continuously, rather than waiting for the service to finish entirely, and b) A client-side SAX parser to deal with the "streaming" output. The SAX parser will be quite tricky to build given that a MOBY service is allowed to output any object that is a child of whatever object it registered (so the trigger would have to respond to every case), but still... it seems that this architecture would solve the problem we are discussing here in a quite simplistic way... it might also overcome *some* of the timeout issues, since the service could output the header information in order to keep the connection alive (and perhaps even output some header "commentary" on a regular basis to keep the connection alive). v.v. legacy: existing clients would not discover these services, because they are registered as Category="moby-post", so there's no problem with breaking anyone. Does this help at all?? M On Wed, 20 Dec 2006 23:52:28 -0800, Oswaldo Trelles wrote: > Hi, > > We are aware about the problem of network overload produced by large > data transmission, even when services are located in local networks or > even in the same server (i.e. most of our services are located in two > servers, so in general, partial data transmission is unnecessary). > > In this line we are analysing two alternatives: > a) sub-workflows (or jobs) to submit a set of tasks to be executed in > the same server (a scheduler module, as is the case of MOWServ could > identify the set of related tasks). We need to review the documentation > to ensure that only the last service returns the output (intermediate > results could be requested using the asynch protocol). > b) a more general (ergo, more interesting) alternative goes in the way > to define a pointer/reference to a local object (an object currently > stored in the local file system). Of course we should avoid defining a > new object (the corresponding couple-object) for each object (sequences, > gene-expression data, structures, etc etc and subtypes). So we could > agree in a label/tag or whatever other alternative in the appropriated > position of the xml to recognise this type of specification. > > of course these are only initial ideas regarding a real problem that > should be discussed (and solved) > > best regards, O. > > GNV5-INB > > > > > Nassib Nassar escribi?: >> Hi Paul, >> >> Sorry for the slow reply.... What you suggest was our original >> intention, but we found it too complicated to explain the difference >> at the taverna level between passing data into the namespace/id >> vs. value fields. More importantly, I think, it's convenient for the >> workflow developers to be able to pass sequences either by reference >> or by value along a single pathway, anywhere in a workflow where >> sequences are being processed. The register and lookup services are >> used like filters to abbreviate and expand sequences, but all of our >> services will accept either the standard or abbreviated forms. This >> is rather experimental, but so far it seems to be working very well. >> >> Nassib >> >> >> On Tue, Dec 12, 2006 at 02:40:45PM -0700, Paul Gordon wrote: >> >>> Hi Nassib, >>> >>> I looked at the presentation, and I'm not sure why you can't just use a >>> VirtualSequence instead. You can then have all of the combinations you >>> want, as long as you register the namespaces: >>> >>> >>> 1500 >>> >>> >>> >>> 1500 >>> >>> >>> >>> 1500 >>> >>> >>> >>> 1500 >>> ATG... >>> >>> >>> etc., etc. >>> >>>> Hi, >>>> >>>> I'd like to start explaining a little bit about our use of biomoby and >>>> also request feedback... >>>> >>>> We're using biomoby mainly with taverna workflows, and gradually >>>> migrating current web services over to become biomoby services (under >>>> biomoby.renci.org). The workflows we develop are talking to services >>>> that for the most part are based here within our servers. As a result >>>> we end up passing a very large amount of duplicated sequence data over >>>> the network between taverna and services, often more data than taverna >>>> is happy about. To get around this we have started passing sequences >>>> by reference using a FASTA-like format that is non-standard but fits >>>> well into our system and the taverna UI. I'm calling this the "RENCI >>>> sequence" format, and it's basically similar to GenBank, while >>>> allowing an "abbreviated" (truncated) form that consists of only a >>>> partial header line with at least one namespace/id. (The architecture >>>> is described in http://www.renci.org/~nassar/sequence_registry.ppt ) >>>> >>>> We've added some new datatypes under "RenciSequence" for this purpose, >>>> analogous to the existing "GenericSequence". In general we are using >>>> the existing biomoby datatypes, but for sequences our format seems >>>> unusual enough that we thought it needed its own datatype to avoid >>>> confusion. >>>> >>>> Nassib >>>> _______________________________________________ >>>> 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 -- -- 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.