From senger at ebi.ac.uk Wed Feb 1 03:05:50 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 1 Feb 2006 08:05:50 +0000 (GMT) Subject: [MOBY-dev] fixes in Moses Message-ID: Hi, Few new fixes/features in jMoby: 1) I have added a new method setValueXML() that allows you to create a Moby XML input as CDATA (if you wish so, but it is not that important I guess). 2) Much more important: I have fixed a nasty bug in Moses objects that prevented (in some cases) to recognize that a more specialized data type has arrived to a moby service (thanks to Eddie for finding the problem). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Feb 1 03:25:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 00:25:35 -0800 Subject: [MOBY-dev] fixes in Moses In-Reply-To: References: Message-ID: On Wed, 01 Feb 2006 00:05:50 -0800, Martin Senger wrote: > 2) Much more important: I have fixed a nasty bug in Moses objects that > prevented (in some cases) to recognize that a more specialized data type > has arrived to a moby service (thanks to Eddie for finding the problem). excellent! This is one of the aspects of MOBY that we haven't fully taken advantage of in the past. gbrowse_moby handles it, but I'm not sure if Taverna does (?? does it ??) I am *so* looking forward to 'Moby II' where we model things in RDF rather than XML, since that will allow us to make the "has" and "hasa" subcomponents of an object also be more complex than they are defined in the ontology. In the current MOBY XML data messages this isn't allowed because we have little choice but to use XPath queries to get at the subcomponents of a data-object, and that would break if the subcomponents were not predictable (by their primary tags)... Nevertheless, allowing the outermost object to be more complex still gives us a lot of freedom! Thanks Martin! M From senger at ebi.ac.uk Wed Feb 1 05:29:38 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 1 Feb 2006 10:29:38 +0000 (GMT) Subject: [MOBY-dev] MOBY II (Was: fixes in Moses) In-Reply-To: Message-ID: > I am *so* looking forward to 'Moby II' where we model things in RDF rather > than XML > To be honest I am rather affraid of that. We all invested time and efforts into making biomoby working. If we are going to change all API and the way how it works we will need to invest gain. Change is not bad, but must be discussed and must have a merit, not just that RDF is more fancy. I hope that we are still on the same board... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Feb 1 10:31:43 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 07:31:43 -0800 Subject: [MOBY-dev] MOBY II (Was: fixes in Moses) In-Reply-To: References: Message-ID: Absolutely - it isn't going to change in a hurry, and it isn't going to change without good reason! There are still many things that can be done with MOBY to use/improve it under the current architecture; however, the "research" potential of the MOBY architecture is largely spent - it's now more a (well funded!) technical excercise of tweaking and adding improvements here and there. There is research potential in the automated selection of services, and the automated integration of the resulting data, and I have grant applications in within those domains, but MOBY *architecture* per se is no longer a "research theme" of my group; Since I am obligated to a research programme out of my lab, we're starting to "play" with RDF representations of MOBY data here just to see how much (if any) advantage it gives us, and whether OWL versions of the MOBY ontologies help in the service discovery/data integration problem. So... don't worry, I'm not suggesting that we break anything! :-) M On Wed, 01 Feb 2006 02:29:38 -0800, Martin Senger wrote: >> I am *so* looking forward to 'Moby II' where we model things in RDF >> rather >> than XML >> > To be honest I am rather affraid of that. We all invested time and > efforts into making biomoby working. If we are going to change all API > and > the way how it works we will need to invest gain. Change is not bad, but > must be discussed and must have a merit, not just that RDF is more > fancy. I hope that we are still on the same board... > > Martin > From johan at ac.uma.es Wed Feb 1 11:17:56 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Wed, 01 Feb 2006 17:17:56 +0100 Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43E0DF34.7070300@ac.uma.es> Hi Martin! Well, the proposal itself should not take very long time to read (but naturally people have other things to do as well). To me, it does not sound unreasonable to expect comments within the next two weeks (we could set the date 15th of February). Comments and suggestions from the BioMOBY community are most welcome but the idea of a time schedule is a good one. This issue has been debated for quite some time without any final result. We need a good and well-documented solution but we need it very soon. Waiting for your comments! Kind regards, Johan Karlsson ------------------------- Johan Karlsson Department of Computer Architecture University of M?laga M?laga, Spain johan at ac.uma.es Martin Senger wrote: >> Attached to this email you can find the INB proposal (RFC) on >> asynchronous service calls. >> >> > Thank you for putting together the proposal. I am going to read it > thoroughly. But it would help me/us if you give us a planned time schedule > when you expect our comments to be back. Could you suggest a sort of > deadline please? > > Regards, > Martin > > From francis_gibbons at hms.harvard.edu Wed Feb 1 12:51:26 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Feb 2006 12:51:26 -0500 Subject: [MOBY-dev] Here's a question.... Message-ID: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> In the Perl MOBY codebase, there is a very confusing parallelism: there's the MOBY directory, and then there's the lib/MOBY directory. There's a line in the Makefile that copies from MOBY to lib/MOBY. Why is this necessary? Perhaps it's related to the following questions. "make install" appears only to work on changes made in "lib/MOBY". I guess this is normal for Perl, except that the "real" version of the source is kept in MOBY. "cvs" appears to deal only with changes made in "MOBY". That's fine too, except that Perl expects to find it in lib/MOBY. Every time I go away from MOBY for a while and come back, this bites me in the ass: I find myself editing in the wrong place, and just getting *really* confused. If I need to edit, where should I do it: MOBY or lib/MOBY? If I need to install my changes, is it simply "make install" or is there something else I should be doing? For example, should I "make clean" each time I want to install? I presume this parallelism is a way to hang onto the CVS comments, while adopting the more usual Perl installation tree. FYI, I have perl 5.8.6 (just upgraded last week), running on SuSE Linux. Can someone out there set me straight? I'd really appreciate it - my ass is starting to hurt ;-) -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Wed Feb 1 13:45:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 10:45:02 -0800 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> References: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> Message-ID: <1138819502.4897.22.camel@bioinfo.icapture.ubc.ca> The /lib/ folder is created during the "make" process. It isn't in the CVS... You should be editing the code in the moby-live/Perl/MOBY* folder, and then running: perl Makefile.pl make make install each time to install it. This isn't a MOBY problem :-) M On Wed, 2006-02-01 at 12:51 -0500, Frank Gibbons wrote: > In the Perl MOBY codebase, there is a very confusing parallelism: there's > the MOBY directory, and then there's the lib/MOBY directory. > > There's a line in the Makefile that copies from MOBY to lib/MOBY. Why is > this necessary? Perhaps it's related to the following questions. > > "make install" appears only to work on changes made in "lib/MOBY". I guess > this is normal for Perl, except that the "real" version of the source is > kept in MOBY. > > "cvs" appears to deal only with changes made in "MOBY". That's fine too, > except that Perl expects to find it in lib/MOBY. > > Every time I go away from MOBY for a while and come back, this bites me in > the ass: I find myself editing in the wrong place, and just getting > *really* confused. > > If I need to edit, where should I do it: MOBY or lib/MOBY? If I need to > install my changes, is it simply "make install" or is there something else > I should be doing? For example, should I "make clean" each time I want to > install? I presume this parallelism is a way to hang onto the CVS comments, > while adopting the more usual Perl installation tree. > > FYI, I have perl 5.8.6 (just upgraded last week), running on SuSE Linux. > > Can someone out there set me straight? I'd really appreciate it - my ass is > starting to hurt ;-) > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Wed Feb 1 13:56:09 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Feb 2006 13:56:09 -0500 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <1138819502.4897.22.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> At 01:45 PM 2/1/2006, you wrote: >You should be editing the code in the moby-live/Perl/MOBY* folder, and >then running: > >perl Makefile.pl >make >make install > >each time to install it. Thanks, Mark. So each time I make a change to a source file, I re-do the entire build process? That's what I had decided needed to happen, as illogical as it sounds to me, since the usual "make" wasn't working properly. Why do we have the duality between MOBY and lib/MOBY? (There's also the version in blib/lib/MOBY, but we know that's created by Perl automatically, so let's not even go there.) Wouldn't it be easier to have a single copy? Is there a good reason to have two copies (I alluded to some in my previous emails). -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From adf at ncgr.org Wed Feb 1 14:17:37 2006 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 1 Feb 2006 12:17:37 -0700 (MST) Subject: [MOBY-dev] [HCLSIG] homologs for yeast proteins? In-Reply-To: Message-ID: replying to the following (and apologies for some cross-posting): > Basically that's why I'm in this group. A challenging question for any > existing Bio* package is whether it can meet the _next_ set of challenges, > like integrating the data. Without attempting to answer that question I'll > say it's easy to imagine that "BioRDF", or the equivalent, would make an > excellent alternative. > > one-stop web portal that can answer this query right now. But it it > > doesn't really help with the generalised case of ontology-aware queries > > of disparate data sources. BioMoby may be able to do something like > > this. Any BioMoby folks on the list? Hi all- I've been somewhat involved in the various BioMOBY projects (though by no means an official spokeperson- hopefully others from that community will chime in), but I picked up on Chris' reference. These things are certainly very much the space at which the BioMOBY efforts are aimed and the use of semantic web technologies, though still a bit nascent, is beginning to take off in some of the MOBY-related development efforts. As one example, you might care to look at a prototypical system based on an early version of the "semantic MOBY" branch of the project at: http://lin.ncgr.org There are a few sets of slides off the help link that give a bit more details than I will here. It uses OWL-based service descriptions for "data-driven" service discovery and RDF graphs for transmission of data in service invocation and response graphs, which enables some interesting aggregative behavior, hooks nicely into some "rich clients" for visulization and interaction with the data, and at least sets the stage for us to engage in some of the nifty promises offered by the higher levels of the semantic web stack. Coincidentally, the central "use case" we chose to highlight the prototype was in fact right along the lines of the question that started this thread, namely exploring homology/orthology/paralogy relationships among functionally annotated sequences (though our focus is on legume data, in which these issues are even more interesting than yeast, IMHO! note, too, that plant biology is also very important to the issues of human health that appear to be the main focus of the "life sci" half of this interest group...) It is very much a prototype at this point (in terms of functionality, documentation, and "production-readiness", i.e. please don't retrieve a set of 10000 sequences and send it to the BLAST service!), but early indications from the plant biologists to whom we have demoed to indicate that we have gone a fair way to helping our user community begin to understand the "semantic value proposition". We hope to evolve it to tap into even more of the potential of the semantic web technologies, we have a lot of ideas about next steps and welcome any help in this direction from interested parties. I guess that is probably enough for the purposes of this list, if anyone is interested in further conversations in this direction, they can get in touch with either our small project (lin at ncgr.org) or the larger MOBY development community (subscribe to lists at biomoby.org). Thanks for listening... Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From adf at ncgr.org Wed Feb 1 14:10:02 2006 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 1 Feb 2006 12:10:02 -0700 (MST) Subject: [MOBY-dev] MOBY II (Was: fixes in Moses) In-Reply-To: Message-ID: Hey all- > > I am *so* looking forward to 'Moby II' where we model things in RDF rather > > than XML > > > To be honest I am rather affraid of that. We all invested time and > efforts into making biomoby working. If we are going to change all API and > the way how it works we will need to invest gain. Change is not bad, but > must be discussed and must have a merit, not just that RDF is more > fancy. I hope that we are still on the same board... > I am glad to hear Mark's enthusiasm for the future use of RDF in MOBY, as well as sympathetic to Martin's concerns (which perhaps Mark's subsequent message has helped to allay). Along those lines, as some of you already know, a few of us at NCGR and a collaborating group (CCGB) from the University of Minnesota recently released the first prototype of a RDF-based service discovery/invocation system, using the basic semantic MOBY approach. You can check it out at: http://lin.ncgr.org Do be aware that it is definitely a prototype and it is far too easy at the moment to invoke services with unreasonable amounts of data; also, it is a bit underdocumented at the moment, though we have put a few sets of slides off the Help link that may help explain; anyway it is pretty intuitive and should not be a quantum leap for the MOBY crowd ;) It also makes some rough inroads in realizing my old dream of getting ISYS back into the picture... We'll be evolving it (we've only scratched the surface!) as funding and involvement in the VPIN project permit, but we have a few lessons learned at this point some of which are a bit relevant to this discussion (which I hope is an omen of blessed days when the two MOBYs are as one ;) ) One of these brings me back from "publicity mode" to Martin's concerns: >From what I understand of MOBY services, it seems that it ought to be entirely possible to use RDF as the data modelling and ontology development substrate without much impacting the messaging aspect of MOBY services and hence presumably allowing the S-MOBY "API" to remain relatively intact (at least, those parts that don't have to do with the interpretation of the "payload" data, although I am sure those are the most important parts!); this step would seem to be a logical one to allow the two branches of MOBY to converge on ideas for shared representation of data even if we cannot come to agreement about the right formalisms for messaging. I am personally not at all convinced that RDF is the right approach for the messaging layer, but certainly trying to be open-minded about it and other ideas. In any case, I am a bit ignorant as to whether any real discussions have been taking place as to the path to "MOBY II", but remain hopeful that they will take place "real soon now". Regards to all, (and apologies for long-windedness and for the somewhat duplicative post you'll receive off the semantic web life sciences mailing list thread that has just mentioned BioMOBY- get your 2c in now!) -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From markw at illuminae.com Wed Feb 1 14:03:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 11:03:29 -0800 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> References: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> Message-ID: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-02-01 at 13:56 -0500, Frank Gibbons wrote: > Thanks, Mark. So each time I make a change to a source file, I re-do the > entire build process? That's what I had decided needed to happen, as > illogical as it sounds to me, since the usual "make" wasn't working properly. Yeah, I believe you do need to re-do the entire process (though I think you could also do a "make clean" rather than re-running the Makefile... I think...) > Why do we have the duality between MOBY and lib/MOBY? (There's also the > version in blib/lib/MOBY, but we know that's created by Perl automatically, > so let's not even go there.) Wouldn't it be easier to have a single copy? > Is there a good reason to have two copies (I alluded to some in my previous > emails). To be honest, I haven't thought about it in years. It's one of those things that "just works", and I can't remember the details of why. The lib and the blib folders are created through the "make" process, and I simply never look at them, since there's no point in editing anything in there anyway... M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Wed Feb 1 14:32:04 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 11:32:04 -0800 Subject: [MOBY-dev] [moby] Re: [HCLSIG] homologs for yeast proteins? In-Reply-To: References: Message-ID: <1138822324.4897.41.camel@bioinfo.icapture.ubc.ca> The web-service branch of BioMOBY is up and running happily (and is being well-used!) but is somewhat locked-in to a legacy XML format that was designed a couple of years before RDF became "the norm". This is unfortunate, since the MOBY XML format was designed to do a very similar job - that is, serialize an ontology. Nevertheless, we are muddling through, and though the messages that are being passed between service and client are in this MOBYesque XML format, we do use ontological queries to achieve the "semantic mapping" between a client with a piece of data, and the various services that could operate on that data. The guts of MOBY are very rapidly being migrated to use OWL/RDF to enhance and simplify this semantic mapping using a reasoner, but the messaging format will remain a legacy problem for quite a while since we have so many services that use it now... It seems, however, that we can inter-convert our XML with RDF fairly easily and reliably, so this may not be as big a problem as we had initially thought. Eric Miller (on this list) has seen my presentation of MOBY and talked to me briefly about it, so he may have some comments on how close/far we are from a "true" semantic-web-service vision... given that we built this in 2001, I think we got it ALMOST right! ...personal bias, of course ;-) Mark On Wed, 2006-02-01 at 12:17 -0700, Andrew D. Farmer wrote: > replying to the following (and apologies for some cross-posting): > > > > Basically that's why I'm in this group. A challenging question for any > > existing Bio* package is whether it can meet the _next_ set of challenges, > > like integrating the data. Without attempting to answer that question I'll > > say it's easy to imagine that "BioRDF", or the equivalent, would make an > > excellent alternative. > > > > > one-stop web portal that can answer this query right now. But it it > > > doesn't really help with the generalised case of ontology-aware queries > > > of disparate data sources. BioMoby may be able to do something like > > > this. Any BioMoby folks on the list? > > > Hi all- > > I've been somewhat involved in the various BioMOBY projects (though by > no means an official spokeperson- hopefully others from that community will > chime in), but I picked up on Chris' reference. These things are certainly > very much the space at which the BioMOBY efforts are aimed and the use of > semantic web technologies, though still a bit nascent, is beginning to take off > in some of the MOBY-related development efforts. > > As one example, you might care to look at a prototypical system based on > an early version of the "semantic MOBY" branch of the project at: > http://lin.ncgr.org > > There are a few sets of slides off the help link that give a bit more details > than I will here. > > It uses OWL-based service descriptions for "data-driven" service discovery and > RDF graphs for transmission of data in service invocation and response graphs, > which enables some interesting aggregative behavior, hooks nicely into some > "rich clients" for visulization and interaction with the data, and at least > sets the stage for us to engage in some of the nifty promises offered by the > higher levels of the semantic web stack. Coincidentally, the central "use > case" we chose to highlight the prototype was in fact right along the lines > of the question that started this thread, namely exploring > homology/orthology/paralogy relationships among functionally annotated > sequences (though our focus is on legume data, in which these issues are > even more interesting than yeast, IMHO! note, too, that plant biology is > also very important to the issues of human health that appear to be the > main focus of the "life sci" half of this interest group...) > > It is very much a prototype at this point (in terms of functionality, > documentation, and "production-readiness", i.e. please don't retrieve > a set of 10000 sequences and send it to the BLAST service!), > but early indications from the plant biologists to whom we have demoed to > indicate that we have gone a fair way to helping our user community begin to > understand the "semantic value proposition". We hope to evolve it to tap > into even more of the potential of the semantic web technologies, we have a > lot of ideas about next steps and welcome any help in this direction from > interested parties. > > I guess that is probably enough for the purposes of this list, if anyone > is interested in further conversations in this direction, they can get in > touch with either our small project (lin at ncgr.org) or the larger > MOBY development community (subscribe to lists at biomoby.org). > > > Thanks for listening... > > Andrew Farmer > adf at ncgr.org > (505) 995-4464 > Database Administrator/Software Developer > National Center for Genome Resources > > --- > "To live in the presence of great truths and eternal laws, > to be led by permanent ideals- > that is what keeps a man patient when the world ignores him, > and calm and unspoiled when the world praises him." > -Balzac > --- > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Wed Feb 1 14:47:38 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 11:47:38 -0800 Subject: [MOBY-dev] [moby] Re: Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> Message-ID: <1138823258.4897.54.camel@bioinfo.icapture.ubc.ca> On Mon, 2006-01-30 at 17:53 +0100, Pieter Neerincx wrote: > No I think you got it right. S::L shouldn't mess it up, but I can > predict that fixing it by changing the prefix in BioMOBY is much > faster than trying to get a fix into the next "stable" release of > S::L. Please go ahead with this change. The other problems are a bit more frustrating, and harder to deal with! It isn't just a question of being S::L compatible, it's also a question of doing the right thing, since we have to be compatible with the Java/Python libraries as well. If S::L is wrong, then we need to push them to change; if *we* are wrong, then we need to recognize that and fix the message structure. I need to do some more reading to figure out which is the case. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Wed Feb 1 15:21:39 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Feb 2006 15:21:39 -0500 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060201151421.028f31f0@email.med.harvard.edu> At 02:03 PM 2/1/2006, you wrote: >To be honest, I haven't thought about it in years. It's one of those >things that "just works", and I can't remember the details of why. The >lib and the blib folders are created through the "make" process, and I >simply never look at them, since there's no point in editing anything in >there anyway... Mark, I know that the "blib" folder "just works". But without a rule in the Makefile expressing the dependency between the files we edit (in MOBY) and the files that Perl uses to build the module (lib/MOBY), we effectively break the build process invisibly. Changes made in "MOBY" do not "just work" unless the developer does the entire "perl Makefile.PL; make; make install". It's the explicit system call in Makefile.PL that updates lib/MOBY from MOBY, and which should be done by make, not perl Makefile.PL. Along comes a developer used to the usual way (change the source? rebuild with "make"! You normally only do "perl Makefile.PL" upon downloading a new module, since it configures the whole system), and the dependencies are broken. I say "invisibly" above, because Perl doesn't complain, it simply ignores what you did in MOBY, since all it cares about are what's in lib/MOBY. Your changes never get propagated, and you can't figure out why your old broken code seems to be unstoppable - you rebuild, it's still there! Anyway, I'm glad to know that it's not just me ;-). I'm going to try to configure Makefile.PL to properly handle dependencies, so that it works like it's supposed to. I think there's some kind of variable to tell it where to find the real code - we should point it at MOBY (not lib/MOBY, the default) -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From ddg at ncgr.org Wed Feb 1 15:08:51 2006 From: ddg at ncgr.org (Damian Gessler) Date: Wed, 1 Feb 2006 13:08:51 -0700 Subject: [MOBY-dev] MOBY II (Was: fixes in Moses) References: Message-ID: <012a01c6276b$51dc64e0$674413ac@ncgr.org> Re: >> > I am *so* looking forward to 'Moby II' where we model things in RDF >> > rather >> > than XML >> > >> To be honest I am rather affraid of that. We all invested time and >> efforts into making biomoby working. If we are going to change all API >> and >> the way how it works we will need to invest gain. Change is not bad, but >> must be discussed and must have a merit, not just that RDF is more >> fancy. I hope that we are still on the same board... >> I caught just a glimpse of this, and understand that the first part of the quoted text is from Mark, and the second from Martin. I can assure you, that from our discussions at BioMOBY meetings--with Mark, Martin, and others present--to our application to NSF for the VPIN, to our current work plans, we have always seen the aim of bridging Semantic MOBY and MOBY Services as one of *joining* mature and value-laden technologies. I continue to believe that some things are just "done better" with a services approach, and some are "done better" with a semantic approach, and our goal in bridging the MOBY's is to develop a potent Semantic Web Services (SWS) platform that works and solves real world problems. Far from seeing MOBY Services or Semantic MOBY code be abandoned or not used, I am eager to see both technologies mature to deliver their respective underlying support for a SWS. Best to y'all; you're doing good work, Damian. From francis_gibbons at hms.harvard.edu Wed Feb 1 15:39:29 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Feb 2006 15:39:29 -0500 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <5.2.1.1.2.20060201151421.028f31f0@email.med.harvard.edu> References: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> At 03:21 PM 2/1/2006, you wrote: >Anyway, I'm glad to know that it's not just me ;-). I'm going to try to >configure Makefile.PL to properly handle dependencies, so that it works >like it's supposed to. I think there's some kind of variable to tell it >where to find the real code - we should point it at MOBY (not lib/MOBY, the >default) Anyone know of a good reason to explicitly copy the code from MOBY to lib/MOBY? ExtUtils::MakeMaker has a variable (called 'PMLIBDIRS') that allows you to tell perl where the source code lives, so there's no need to copy it from one place to another, just point it to the right place, and you're all set. It defaults to ["lib", "MOBY"], and perhaps that's why the copying statement was added. But really it's unnecessary (as I see it), and confusing. I intend to check in a new Makefile.PL that uses PMLIBDIRS and does away with the copying. Let me know if there's a good reason for NOT changing things (maybe it won't work on Mac OS 9? maybe it only works in Perl 5.6.x or better?). I'll check in within 24 hours, otherwise. The reason FOR this change is to follow the implicit rules of building a perl module (or any software using 'make'). Rebuilding should be accomplishable by typing "make", nothing more. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Wed Feb 1 15:39:27 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 12:39:27 -0800 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> References: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> Message-ID: <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> I have no problem with this. whatever makes it more correct and easier to use is a good thing! M On Wed, 2006-02-01 at 15:39 -0500, Frank Gibbons wrote: > At 03:21 PM 2/1/2006, you wrote: > >Anyway, I'm glad to know that it's not just me ;-). I'm going to try to > >configure Makefile.PL to properly handle dependencies, so that it works > >like it's supposed to. I think there's some kind of variable to tell it > >where to find the real code - we should point it at MOBY (not lib/MOBY, the > >default) > > Anyone know of a good reason to explicitly copy the code from MOBY to lib/MOBY? > > ExtUtils::MakeMaker has a variable (called 'PMLIBDIRS') that allows you to > tell perl where the source code lives, so there's no need to copy it from > one place to another, just point it to the right place, and you're all set. > It defaults to ["lib", "MOBY"], and perhaps that's why the copying > statement was added. But really it's unnecessary (as I see it), and > confusing. I intend to check in a new Makefile.PL that uses PMLIBDIRS and > does away with the copying. > > Let me know if there's a good reason for NOT changing things (maybe it > won't work on Mac OS 9? maybe it only works in Perl 5.6.x or better?). I'll > check in within 24 hours, otherwise. > > The reason FOR this change is to follow the implicit rules of building a > perl module (or any software using 'make'). Rebuilding should be > accomplishable by typing "make", nothing more. > > -Frank > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Wed Feb 1 18:12:24 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 2 Feb 2006 00:12:24 +0100 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> References: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Frank, On 01Feb2006, at 21:39, Mark Wilkinson wrote: > I have no problem with this. whatever makes it more correct and > easier > to use is a good thing! I second that. The way it used to work so far surprised me a bit as well, but after I figured it out I was already glad it just worked :). If you are creating a better Makefile.PL would it be also possible to add the pod2html documentation file building somewhere in the process? Currently it's not, so the [module].html file with documentation might be out of sync with [module].pm :(. Cheers, Pi > > M > > > On Wed, 2006-02-01 at 15:39 -0500, Frank Gibbons wrote: >> At 03:21 PM 2/1/2006, you wrote: >>> Anyway, I'm glad to know that it's not just me ;-). I'm going to >>> try to >>> configure Makefile.PL to properly handle dependencies, so that it >>> works >>> like it's supposed to. I think there's some kind of variable to >>> tell it >>> where to find the real code - we should point it at MOBY (not lib/ >>> MOBY, the >>> default) >> >> Anyone know of a good reason to explicitly copy the code from MOBY >> to lib/MOBY? >> >> ExtUtils::MakeMaker has a variable (called 'PMLIBDIRS') that >> allows you to >> tell perl where the source code lives, so there's no need to copy >> it from >> one place to another, just point it to the right place, and you're >> all set. >> It defaults to ["lib", "MOBY"], and perhaps that's why the copying >> statement was added. But really it's unnecessary (as I see it), and >> confusing. I intend to check in a new Makefile.PL that uses >> PMLIBDIRS and >> does away with the copying. >> >> Let me know if there's a good reason for NOT changing things >> (maybe it >> won't work on Mac OS 9? maybe it only works in Perl 5.6.x or >> better?). I'll >> check in within 24 hours, otherwise. >> >> The reason FOR this change is to follow the implicit rules of >> building a >> perl module (or any software using 'make'). Rebuilding should be >> accomplishable by typing "make", nothing more. >> >> -Frank >> >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: >> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 francis_gibbons at hms.harvard.edu Thu Feb 2 09:29:53 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 02 Feb 2006 09:29:53 -0500 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: References: <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> Message-ID: <5.2.1.1.2.20060202092920.028bd2d0@email.med.harvard.edu> At 06:12 PM 2/1/2006, you wrote: >I second that. The way it used to work so far surprised me a bit as >well, but after I figured it out I was already glad it just >worked :). Yeah, I know. "make" and "MakeMaker" tend to have that effect on people! >If you are creating a better Makefile.PL would it be also >possible to add the pod2html documentation file building somewhere in >the process? Currently it's not, so the [module].html file with >documentation might be out of sync with [module].pm :(. Good idea, I'll see what I can do. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Thu Feb 2 12:12:23 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 2 Feb 2006 18:12:23 +0100 Subject: [MOBY-dev] [moby] Re: Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: <1138823258.4897.54.camel@bioinfo.icapture.ubc.ca> References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> <1138823258.4897.54.camel@bioinfo.icapture.ubc.ca> Message-ID: <6E1B1412-95CC-425E-B46A-F27858BC612C@wur.nl> On 1-Feb-2006, at 8:47 PM, Mark Wilkinson wrote: > On Mon, 2006-01-30 at 17:53 +0100, Pieter Neerincx wrote: > >> No I think you got it right. S::L shouldn't mess it up, but I can >> predict that fixing it by changing the prefix in BioMOBY is much >> faster than trying to get a fix into the next "stable" release of >> S::L. > > Please go ahead with this change. Ok I'll change the prefix for that namespace from soap to wsoap then. > > The other problems are a bit more frustrating, and harder to deal > with! > It isn't just a question of being S::L compatible, it's also a > question > of doing the right thing, since we have to be compatible with the > Java/Python libraries as well. If S::L is wrong, then we need to push > them to change; if *we* are wrong, then we need to recognize that and > fix the message structure. > > I need to do some more reading to figure out which is the case. Ok, please let me know what you think. As far as I understand it, the problem with that 'anyURI' thing is a S::L bug, but for the one with the double encoding I'm not sure. It doesn't really matter who encodes the string as long as not both the BioMOBY Perl modules and S::L try to do it... Pi > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From francis_gibbons at hms.harvard.edu Thu Feb 2 13:12:17 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 02 Feb 2006 13:12:17 -0500 Subject: [MOBY-dev] new Makefile.PL for Perl source Message-ID: <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> Just checked in a new Makefile.PL. You'll see what's in it from the "commit" email. I tried to write it as platform-independently as I could. I'm wary of making changes to this file, since if it's broken, you can do nothing at all with the Perl MOBY. Please inform me of problems, if any, and I'll fix them as soon as I possibly can. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Feb 2 13:09:49 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 02 Feb 2006 10:09:49 -0800 Subject: [MOBY-dev] [moby] [MOBY-guts] biomoby commit In-Reply-To: <200602021812.k12ICViR002268@pub.open-bio.org> References: <200602021812.k12ICViR002268@pub.open-bio.org> Message-ID: <1138903789.7790.61.camel@bioinfo.icapture.ubc.ca> Thanks Frank!!! I take it I can now remove the HTML documentation from the CVS tree as well? Halleluja!! M On Thu, 2006-02-02 at 13:12 -0500, Frank Gibbons wrote: > fgibbons > Thu Feb 2 13:12:31 EST 2006 > Update of /home/repository/moby/moby-live/Perl > In directory pub.open-bio.org:/tmp/cvs-serv2194 > > Modified Files: > Makefile.PL > Log Message: > - New & improved! > - Added extra rules to generate HTML from Perl modules. > * Docs now live in separate tree from source, defaulting to "docs/html" > * The doc-tree is built automatically, and echoes the source tree. > * HTML is generated from the default rule (just type 'make'). > * HTML can also be generated specifically by typing 'make html'. > * New rules incorporate dependencies between each module and its HTML. > * New HTML is generated only if the perl module has been changed. > - Your source tree lives under "MOBY". The "lib/MOBY" duplicate tree, > which was formerly required, and auto-generated by the Makefile, > is no longer used. To avoid confusion you should delete it. > > moby-live/Perl Makefile.PL,1.10,1.11 > =================================================================== > RCS file: /home/repository/moby/moby-live/Perl/Makefile.PL,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -u -r1.10 -r1.11 > --- /home/repository/moby/moby-live/Perl/Makefile.PL 2005/12/22 00:08:44 1.10 > +++ /home/repository/moby/moby-live/Perl/Makefile.PL 2006/02/02 18:12:31 1.11 > @@ -1,11 +1,15 @@ > use ExtUtils::MakeMaker; > use FindBin '$Bin'; > > -my $VERSION = '0.1'; > +my $VERSION = '0.87'; > > -system "mkdir lib" unless (-e 'lib' && -d 'lib'); # put the files into the lib directory so that they will be properly installed > -system "cp -rf MOBY lib"; > -system q{xcopy /E MOBY .\lib\MOBY\ }; > +# Anyone know why it was ever necessary to copy everything in "lib"? > +#system "mkdir lib" unless (-e 'lib' && -d 'lib'); # put the files into the lib directory so that they will be properly installed > +#my $os = $^O; > +#if ($os =~ /(linux|unix)/) { system "cp -rf MOBY lib"; } > +#elsif ($os =~ /ms.*win/i) { # windows only, usually $^O="mswin32", is this true on all Windows? > +# system q{xcopy /E MOBY .\lib\MOBY\ }; > +#} > > #my $WWW_ROOT_PATH = "/usr/local/apache" ; > #my $CGI_BIN = "cgi-bin" ; > @@ -71,21 +75,91 @@ > # See lib/ExtUtils/MakeMaker.pm for details of how to influence > # the contents of the Makefile that is written. > > +sub MY::postamble { > + use Pod::Find qw(pod_find simplify_name); > + use Cwd; > + my $cur_dir = getcwd(); > + # Find the files that contain POD, starting from the top-level build directory, and do it silently. > + my %pods = pod_find({ -verbose => 0}, > + File::Spec->catfile($cur_dir, "MOBY") ); > + my @PM = sort keys %pods; > + # Make home for all docs > + my $HTML_ROOT = File::Spec->catfile($cur_dir, qw(docs html)); > + mkdir File::Spec->catfile($cur_dir, "docs") > + unless -e File::Spec->catfile($cur_dir, "docs"); > + mkdir $HTML_ROOT unless -e $HTML_ROOT; > + # Create a new directory tree for the documentation, that mirrors the source tree. > + use File::Find; > + sub wanted { # Define nested subroutine, to inherit variable scope > + my $src_dir = $File::Find::dir; > + (my $doc_dir = $src_dir) =~ s/$cur_dir/$HTML_ROOT/; > + if (!(-e $doc_dir) && !($doc_dir =~ /CVS$/)) { > + my $made_dir = mkdir $doc_dir; > + if (!$made_dir) { print STDERR "Couldn't create directory '$doc_dir' because '$OS_ERROR'"; } > + } > + } > + find(\&wanted, File::Spec->catfile($cur_dir, "MOBY")); > + # Finally, start writing the rules. > + # Let's make a big rule to build all the docs at once, call it 'html' > + # Then other little rules to keep each PM-file's docs up to date, without having to build everything. > + my @HTML = map { # Edit beginning and end of PM files, to make HTML filenames > + my $x = $_; # Don't want to change the original... > + $x =~ s/\.p[lm]$/\.html/; > + $x =~ s/^$cur_dir/$HTML_ROOT/; > + $x} @PM; > + my $postamble = "# Rules to keep developer docs up-to-date.\n"; > + $postamble .= "POD_TO_HTML = " . join("\\\n", @HTML) > + . "\n\nhtml: \$(POD_TO_HTML)\n\n"; > + > + # Now, finally, we build rules for the makefile. > + # The TAB ('\t') characters are essential, otherwise 'make' will silently ignore the rules. > + # Don't be tempted to remove them. > + for (my $i = 0; $i < @PM; $i++) { > + $postamble .= < +$HTML[$i]:$PM[$i] > + \$(NOECHO) pod2html --outfile=$HTML[$i] $PM[$i] > + \$(NOECHO) \$(ECHO) Generating HTML for $PM[$i] > + > +RULE > + } > + return $postamble; > +} > + > +# Override built-in target, by adding the 'html' dependency > +# Now HTML gets updated every time you type "make" > +sub MY::top_targets { > + my $self = shift; > + my $string = $self->MM::top_targets; > + my $add = 'html'; > + $string =~ s/(pure_all\s+)(.*)/$1 $add $2/; > + return $string; > +} > + > +#sub MY::install { > +# my $self = shift; > +# my $string = $self->MM::install; > +# my $add = 'html'; > +# $string =~ s/(pure_install\s+)(.*)/$1 $add $2/; > +# print "INSTALL: $string\n"; > +# return $string; > +#} > + > WriteMakefile( > - 'NAME' => 'MOBY-S', > - 'VERSION' => $VERSION, > - 'PREREQ_PM' => { > - 'SOAP::Lite' => 0.55, > - 'XML::LibXML' => 1.58, > - 'Text::Shellwords' => 1.00, > - 'SOAP::MIME' => 0.55, > - 'XML::XPath' => 1.12, > - # 'LS::ID' => 1.1.1, > + NAME => 'MOBY-S', > + VERSION => $VERSION, > + PMLIBDIRS => ['MOBY'], #Get code from "MOBY", not "lib/MOBY" > + PREREQ_PM => { > + SOAP::Lite => 0.55, > + SOAP::MIME => 0.55, > + XML::LibXML => 1.58, > + XML::XPath => 1.12, > + Text::Shellwords => 1.00, > + # LS::ID => 1.1.1, > }, # e.g., Module::Name => 1.1 > - #'PM_FILTER' => "", > + #PM_FILTER => "", > ($] >= 5.005 ? ## Add these new keywords supported since 5.005 > - (ABSTRACT => 'Perl module binding for MOBY-S', > - AUTHOR => 'Mark Wilkinson [markw at illuminae.com]') : ()), > + (ABSTRACT => 'Perl binding for MOBY-S, a web-services toolkit for exchanging bioinformatic data', > + AUTHOR => 'Mark Wilkinson [markw at illuminae.com] and the BioMOBY Core Developers') : ()), > ); > > # > > _______________________________________________ > MOBY-guts mailing list > MOBY-guts at biomoby.org > http://biomoby.org/mailman/listinfo/moby-guts -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Feb 2 14:01:46 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 02 Feb 2006 11:01:46 -0800 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E0DF34.7070300@ac.uma.es> References: <43E0DF34.7070300@ac.uma.es> Message-ID: <1138906906.7790.95.camel@bioinfo.icapture.ubc.ca> Hi Johan, Thanks for providing such a clearly written proposal! I've added it to Bugzilla in order to get a tracking number (#1941), and have attached your PDF file to the enhancement request. Overall, it sounds like a great solution! I have read it a few times, and have just one or two questions/comments: 1) Page 3 - "illegitimate". I have modified the MessageStructure.html document so that it no longer says "illegitimate". Perhaps you can update that part of the document. 2) In section 3.1 you indicate that you would like the asynchronous information to be added to the data we capture in the registry; however later in that same section, you say "the proper way to do this" is through LSID resolution to metadata. Which is your preference? The former choice requires a change in the registry API, while the latter does not. I guess the choice comes down to a question of whether or not a client will ever want to search specifically for asynchronous services... if the answer to that is "yes" then it should be in the registry. What was your intention? 3) Let's define the new predicate as follows v.v. the RDF for Service Instances: mobyPred:isAsynchronous Domain: mygrid:operation Range: xsd:boolean Definition: a boolean indication of the service providers ability to provide the associated operation in asynchronous, as well as synchronous, mode, according to the specification for asynchronous Moby service calls in the Moby API. 4) I infer from your description that it should be possible to retrieve the results of some queryID's (the ones that have completed) while others are still running. Is that correct? If so, you should perhaps say so explicitly in this document. 5) You might want to create a new section of the document that describes the mobyStatus element so that it is explicitly clear that this is a new addition to the MOBY XML. 6) Section 3.3.2 final paragraph - could you add an explicit example of the proposed use of refQueryID in the mobyException block (if only because the mobyException block is quite a new addition to the API itself...) 7) Section 3.3.5 - what is the response if I request servicename_result on a queryID that has not completed? This is a great proposal!! You probably already have MOBY code that does it, since INB is already doing this (right?). Will you be committing that code for us when the RFC is adopted? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Feb 2 14:35:55 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 02 Feb 2006 11:35:55 -0800 Subject: [MOBY-dev] [moby] new Makefile.PL for Perl source In-Reply-To: <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> References: <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> Message-ID: <1138908955.7790.103.camel@bioinfo.icapture.ubc.ca> On a windows machine, using nmake, I get the following error right at the end of the make process: cp MOBY/Client/ServiceInstance.pm blib\lib\MOBY\Client \ServiceInstance.pm cp MOBY/MOBYXSLT.pm blib\lib\MOBY\MOBYXSLT.pm html @ rem 'html' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1' Stop. On Thu, 2006-02-02 at 13:12 -0500, Frank Gibbons wrote: > Just checked in a new Makefile.PL. You'll see what's in it from the > "commit" email. I tried to write it as platform-independently as I could. > I'm wary of making changes to this file, since if it's broken, you can do > nothing at all with the Perl MOBY. Please inform me of problems, if any, > and I'll fix them as soon as I possibly can. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Thu Feb 2 15:15:13 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 02 Feb 2006 15:15:13 -0500 Subject: [MOBY-dev] [moby] new Makefile.PL for Perl source In-Reply-To: <1138908955.7790.103.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060202151307.02912108@email.med.harvard.edu> Mark, can you send me the Makefile that gets generated on Windows. I added 'html' as a target, to aid in generating the HTML, but I don't understand what follows it: "@ rem". Thanks, -Frank At 02:35 PM 2/2/2006, you wrote: >On a windows machine, using nmake, I get the following error right at >the end of the make process: > >cp MOBY/Client/ServiceInstance.pm blib\lib\MOBY\Client >\ServiceInstance.pm >cp MOBY/MOBYXSLT.pm blib\lib\MOBY\MOBYXSLT.pm > html @ rem >'html' is not recognized as an internal or external command, >operable program or batch file. >NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code >'0x1' >Stop. > > > > > >On Thu, 2006-02-02 at 13:12 -0500, Frank Gibbons wrote: > > Just checked in a new Makefile.PL. You'll see what's in it from the > > "commit" email. I tried to write it as platform-independently as I could. > > I'm wary of making changes to this file, since if it's broken, you can do > > nothing at all with the Perl MOBY. Please inform me of problems, if any, > > and I'll fix them as soon as I possibly can. > > > > -Frank > > > > PhD, Computational Biologist, > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > > Tel: 617-432-3555 Fax: > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev >-- >-- >...his last words were 'Hey guys! Watch this!' >-- >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Fri Feb 3 12:41:58 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 03 Feb 2006 12:41:58 -0500 Subject: [MOBY-dev] Try to create service from serialized WSDL, get strange SOAP::Lite error Message-ID: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> Hi, It takes MOBY about half a second to retrieve WSDL from Central, to build a service. In an effort to improve performance in an application that may need to build many (maybe ten) services at a time, I'm trying to cache WSDL locally, and build services from that, as needed. I'm using Storable for serialization in Perl, which has worked well for me in the past. To paraphrase Yogi Berra: "Half a second here, half a second there, pretty soon you're talking about real time." I'm encountering a strange error in this, which appears to be emanating ultimately from SOAP::Lite (see below) In essence it says: Service description 'data:, can't be loaded: 501 Protocol scheme '' is not supported The WSDL is URI_encoded by MOBY, not by me - I just supply an XML-text description to MOBY::Client::Service->new(), pretty much exactly as provided from MCentral. I DO NOT see this problem when using the WSDL supplied by MOBY Central directly however, so there's clearly some kind of problem with serialization. I'm wondering if any of you have seen a similar behaviour in the past, and how you got around it. The WSDL I retrieve from the cache looks fine when I print it out, but I'm wondering if there might be some other funkiness to it that gets messed up with I store it. Thanks in advance. -Frank ============================== MOBY::Client::Service message below ========================= Service description 'data:,%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Cwsdl%3Adefinitions%20name% 3D%22MOBY_Central_Generated_WSDL%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%2 0%20%20%20targetNamespace%3D%22http%3A%2F%2Fbiomoby.org%2FCentral.wsdl%22%0A %20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Atns%3D%22http%3A%2F% 2Fbiomoby.org%2FCentral.wsdl%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20 %20%20xmlns%3Axsd1%3D%22http%3A%2F%2Fbiomoby.org%2FCentralXSDs.xsd%22%20%0A% 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Asoap%3D%22http%3A%2F% 2Fschemas.xmlsoap.org%2Fwsdl%2Fsoap%2F%22%0A%20%20%20%20%20%20%20%20%20%20%2 0%20%20%20%20%20xmlns%3Axsd%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2FXMLSchema% 22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3D%22http%3A%2F%2 Fschemas.xmlsoap.org%2Fwsdl%2F%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20% 20%20%20xmlns%3Awsdl%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fwsdl%2F%22%3E%0 A%0A%20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceInput%22%3E%0 A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22data%22%20type%3D% 22xsd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20%20%20%20 %20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceOutput%22%3E%0A%2 0%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22body%22%20type%3D%22x sd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20%20%20%20%20 %20%20%20%0A%20%20%3Cwsdl%3AportType%20name%3D%22ASimpleServicePortType%22%3 E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D%22ASimpleSer vice%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Ain put%20message%3D%22tns%3AASimpleServiceInput%22%2F%3E%0A%20%20%20%20%20%20%2 0%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%20message%3D%22tns%3AASimple ServiceOutput%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperatio n%3E%0A%20%20%3C%2Fwsdl%3AportType%3E%0A%20%0A%20%20%3Cwsdl%3Abinding%20name %3D%22ASimpleServiceBinding%22%20type%3D%22tns%3AASimpleServicePortType%22%3 E%0A%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abinding%20style%3D%22rpc%22%20tr ansport%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fhttp%22%2F%3E%0A%20%2 0%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D%22ASimpleService%22%3 E%3C!--%20in%20essense%2C%20this%20is%20the%20name%20of%20the%20subroutine%2 0that%20is%20called%20--%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% 20%20%3Csoap%3Aoperation%20soapAction%3D'http%3A%2F%2Fbiomoby.org%2F%23ASimp leService'%20style%3D'rpc'%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%2 0%20%20%20%3Cwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20 %20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encoded%22%20namespa ce%3D%22http%3A%2F%2Fbiomoby.org%2F%22%20encodingStyle%3D%22http%3A%2F%2Fsch emas.xmlsoap.org%2Fsoap%2Fencoding%2F%22%2F%3E%0A%20%20%20%20%20%20%20%20%20 %20%20%20%20%20%20%20%20%3C%2Fwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20% 20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20% 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encode d%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3 Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperation%3E%0A%20%2 0%3C%2Fwsdl%3Abinding%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% 0A%20%20%3Cwsdl%3Aservice%20name%3D%22ASimpleServiceService%22%3E%0A%20%20%2 0%20%20%20%20%20%20%20%3Cwsdl%3Adocumentation%3EAuthority%3A%20llama.med.har vard.edu%20%20-%20%20A%20simple%20service%20for%20testing%20purposes.%0AEnte r%20or%20edit%20the%20description%20of%20service%20ASimpleService.%0A%0A%3C% 2Fwsdl%3Adocumentation%3E%20%20%3C!--%20service%20description%20goes%20here% 20--%3E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aport%20name%3D%22ASimpleSe rvicePort%22%20binding%3D%22tns%3AASimpleServiceBinding%22%3E%0A%20%20%20%20 %20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Aaddress%20location%3D%22htt p%3A%2F%2Fllama.med.harvard.edu%2F~fgibbons%2Fcgi%2FBGN%2Fdispatcher.pl%22%2 F%3E%20%20%20%20%3C!--%20URL%20to%20service%20scriptname%20--%3E%0A%20%20%20 %20%20%20%20%20%20%20%3C%2Fwsdl%3Aport%3E%0A%20%20%3C%2Fwsdl%3Aservice%3E%0A %0A%3C%2Fwsdl%3Adefinitions%3E%0A%0A%0A' can't be loaded: 501 Protocol scheme '' is not supported PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 [1]http://llama.med.harvard.edu/~fgibbons References 1. http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Mon Feb 6 02:19:07 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 6 Feb 2006 07:19:07 +0000 (GMT) Subject: [MOBY-dev] jMoby update - creating Biomoby input dta Message-ID: Hi everybody, While finishing the last panel for Dashboard (allowing to call actually services) I created - as a side-product - a new simple graphical client that allows to create any complex Biomoby data types. The documentation (with some screenshots) is here: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/CreateInputClient.html. Any comments welcome. Also, I wonder if such component (with some additions that are not yet available but will be soon in the new Dashboard panel - such as collection and secondary parameters) can make it into Taverna as an alternative plug-in for calling Biomoby services. What do you think, Eddie? Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Feb 6 03:59:00 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 6 Feb 2006 08:59:00 +0000 (GMT) Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal In-Reply-To: <43E0DF34.7070300@ac.uma.es> Message-ID: RFC #1941 Asynchronous Service Call Proposal ============================================ I agree with Mark that it is a good proposal - we desperately need it. I just hope that more people will join this discussion (please, do so!). I suggest that we postpone the voting for about two more weeks. Mainly because some of my comments (see below) would require more details to be put in the document. And also to allow other people to jump the board (please, do so!). Before I start, let me express my main principle: we are going to change the Biomoby API because of a need for async services. But we are (sooner or later) going to add other new things to the API (especially we need to address in the future the 'iterator' pattern - sending data by chunks) - all these changes have the same common root - they require some session management. So we should add them in a way that is the least disruptive to the existing software, and in a similar way. That's one of my reasons for my 'major' comments. I have few smaller comments - but let me start with the significant ones: * Data returned by xxx_async and xxx_poll ----------------------------------------- Why does the proposal treat them differently (comparing to normal Biomoby data)? Why to introduced a new XML element 'mobyStatus' when we can easily - and keeping many software untouched - send these data in usual 'mobyData' element? The Biomoby data types (objects) have two functions: they are used to carry data and they are used in service discovery. Obviously the second function is no use here but the first function still can be used. And we do not need any new XML element (now it is 'mobyStatus', later we will need perhaps 'mobySession' or moreand more new tags). What I am suggesting is this: * To create several regular Biomoby data types (objects), such as: - PollingRequest - Event (with hierarchy and attributes taken from LSAE) (the contents would be the same as 'mobyStatus' proposed) I am prepared to be more specific how these objects should look like, and write it into a document (or even register them in Biomoby registry) - but before doing it I need some confirmation from you that it is the way to go. These objects will probably never be used in the service registration (but they can - see below). They should be treated in the similar way as the primitive data types - so in any newly created biomoby registry they should be registered by the installation script (or whatever is done for primitive types now). As a side effect, these data types *can* be used for normal services - if a service have use for them. Having these data types as regular biomoby objects also allows easier to create WSDL for all these new methods (Mark, these new methods should be generated in the WSDL by registry, for asynchronous services; more about it later.) * Dependency on LSID service metadata ------------------------------------- I do not like it (the RDF predicate indicating that a service can be asynchronous). Here is why: For me, the divider between service data and service metadata was always that metadata are good but are not crucial for a service execution. But the flag "this service can be called asynchronously" is very fundamental flag for a service, and it changes its behaviour and the behaviour of its clients. Also, it must be known to a registry - because registry is supposed to generate WSDL with xxx_async and xxx-poll method included. So register should have it, anyway! But in the same time, I agree with Mark that we should add changes to the current API prudently. But still, this request qualifies for a change of the Biomoby API (I think). But perhaps the change does not need to be big: What about to use the existing field 'category'. Because we are, in fact, talking about a new type of service category. Why not to allow a new category, for example, 'moby-async'? * Do not allow the 'mixed' mode ------------------------------- ...where some mobyData can be returned before other mobyData (from the same invocation). This would much complicate implementation - and for what? I was told that the main reason for having more mobyData in an invocation is mainly because some hardware can treat them more efficiently. I wonder if such hardware would give you back partial result, anyway. So please consider the implementation, and make it easier for us, developers. So my suggestion would be: one request == one xxx_result. * And here are my other, but smaller, comments ---------------------------------------------- a) Please whenever you talk about 'job', talk rather about 'session' because in jMoby we use the term 'job' for individual 'mobyData' - so the term would be too overloaded. b) "Id unique to each... in a message". No, the Id must be unique to the whole service provider (at least to the invoked service). If the unique-ness is just in a message there would be problems when I invoke the same service several times before the first one finished. c) How many times am I allowed to call xxx_result? I suggest just once - and any next invocation fails with an exception. This means that this call also serve as a cleaning call - the service implementation can clean the session. c) More must be written about exception states: What (if any) exception to raise when a given session handler is invalid/expired. There may be other states to document by an exception code. I think that this is enough for now. Again, I thank very much INB for the proposal, and please give us slightly more time to discuss and make changes. Then we need a new document, and few days to read it again. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Mon Feb 6 07:09:11 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 6 Feb 2006 13:09:11 +0100 Subject: [MOBY-dev] Try to create service from serialized WSDL, get strange SOAP::Lite error In-Reply-To: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> References: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> Message-ID: Hi Frank, Serialisation and SOP::Lite: ough! It wouldn't surprise me if it's some wierd S::L logic causing this error. First of all which version of S::L are you on? According to the docs, you should pass an URL to the S::L sub that parses the WSDL. Some people use an URL to a file with file:///some/path/to/file.xml, but as far as I can Google it the BioMOBY is the only piece of code that passes a string using 'data:, $wsdl'. So we are using more or less a hack and (de)serialising strings in S::L is not always transparent. It might be an encoding problem. Currently I have a problem with a service that takes the stored output from another one as input. Used to work and the XML still looks the same and valid, but for some reason libxml2 chokes on it. I suspect some encoding problem that occurs after several sessions of serialising and deserialising, but I haven't got a fix yet... Cheers, Pi On 3-Feb-2006, at 6:41 PM, Frank Gibbons wrote: > > Hi, > It takes MOBY about half a second to retrieve WSDL from Central, > to build a > service. In an effort to improve performance in an application > that may need > to build many (maybe ten) services at a time, I'm trying to > cache WSDL > locally, and build services from that, as needed. I'm using > Storable for > serialization in Perl, which has worked well for me in the > past. To > paraphrase Yogi Berra: "Half a second here, half a second there, > pretty soon > you're talking about real time." > I'm encountering a strange error in this, which appears to be > emanating > ultimately from SOAP::Lite (see below) In essence it says: > Service description 'data:, can't be loaded: > 501 Protocol > scheme '' is not supported > The WSDL is URI_encoded by MOBY, not by me - I just supply an > XML-text > description to MOBY::Client::Service->new(), pretty much exactly > as provided > from MCentral. I DO NOT see this problem when using the WSDL > supplied by > MOBY Central directly however, so there's clearly some kind of > problem with > serialization. I'm wondering if any of you have seen a similar > behaviour in > the past, and how you got around it. The WSDL I retrieve from > the cache > looks fine when I print it out, but I'm wondering if there might > be some > other funkiness to it that gets messed up with I store it. > Thanks in advance. > -Frank > ============================== MOBY::Client::Service message > below > ========================= > Service description > 'data:,%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Cwsdl% > 3Adefinitions%20name% > 3D%22MOBY_Central_Generated_WSDL%22%0A%20%20%20%20%20%20%20%20% > 20%20%20%20%2 > 0%20%20%20targetNamespace%3D%22http%3A%2F%2Fbiomoby.org% > 2FCentral.wsdl%22%0A > %20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Atns%3D% > 22http%3A%2F% > 2Fbiomoby.org%2FCentral.wsdl%22%0A%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20 > %20%20xmlns%3Axsd1%3D%22http%3A%2F%2Fbiomoby.org% > 2FCentralXSDs.xsd%22%20%0A% > 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Asoap%3D% > 22http%3A%2F% > 2Fschemas.xmlsoap.org%2Fwsdl%2Fsoap%2F%22%0A%20%20%20%20%20%20% > 20%20%20%20%2 > 0%20%20%20%20%20xmlns%3Axsd%3D%22http%3A%2F%2Fwww.w3.org%2F1999% > 2FXMLSchema% > 22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3D% > 22http%3A%2F%2 > Fschemas.xmlsoap.org%2Fwsdl%2F%22%0A%20%20%20%20%20%20%20%20%20% > 20%20%20%20% > 20%20%20xmlns%3Awsdl%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fwsdl > %2F%22%3E%0 > A%0A%20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D% > 22ASimpleServiceInput%22%3E%0 > A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22data% > 22%20type%3D% > 22xsd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20% > 20%20%20%20 > %20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceOutput > %22%3E%0A%2 > 0%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22body%22% > 20type%3D%22x > sd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20% > 20%20%20%20 > %20%20%20%0A%20%20%3Cwsdl%3AportType%20name%3D% > 22ASimpleServicePortType%22%3 > E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D% > 22ASimpleSer > vice%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% > 3Cwsdl%3Ain > put%20message%3D%22tns%3AASimpleServiceInput%22%2F%3E%0A%20%20% > 20%20%20%20%2 > 0%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%20message%3D% > 22tns%3AASimple > ServiceOutput%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl > %3Aoperatio > n%3E%0A%20%20%3C%2Fwsdl%3AportType%3E%0A%20%0A%20%20%3Cwsdl% > 3Abinding%20name > %3D%22ASimpleServiceBinding%22%20type%3D%22tns% > 3AASimpleServicePortType%22%3 > E%0A%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abinding%20style%3D% > 22rpc%22%20tr > ansport%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fhttp%22%2F > %3E%0A%20%2 > 0%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D% > 22ASimpleService%22%3 > E%3C!--%20in%20essense%2C%20this%20is%20the%20name%20of%20the% > 20subroutine%2 > 0that%20is%20called%20--%3E%0A%20%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20% > 20%20%3Csoap%3Aoperation%20soapAction%3D'http%3A%2F%2Fbiomoby.org > %2F%23ASimp > leService'%20style%3D'rpc'%2F%3E%0A%20%20%20%20%20%20%20%20%20% > 20%20%20%20%2 > 0%20%20%20%3Cwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20 > %20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encoded% > 22%20namespa > ce%3D%22http%3A%2F%2Fbiomoby.org%2F%22%20encodingStyle%3D%22http% > 3A%2F%2Fsch > emas.xmlsoap.org%2Fsoap%2Fencoding%2F%22%2F%3E%0A%20%20%20%20%20% > 20%20%20%20 > %20%20%20%20%20%20%20%20%3C%2Fwsdl%3Ainput%3E%0A%20%20%20%20%20% > 20%20%20%20% > 20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%3E%0A%20%20%20%20%20%20% > 20%20%20%20% > 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use% > 3D%22encode > d%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% > 3C%2Fwsdl%3 > Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperation > %3E%0A%20%2 > 0%3C%2Fwsdl%3Abinding%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20% > 0A%20%20%3Cwsdl%3Aservice%20name%3D%22ASimpleServiceService%22%3E > %0A%20%20%2 > 0%20%20%20%20%20%20%20%3Cwsdl%3Adocumentation%3EAuthority%3A% > 20llama.med.har > vard.edu%20%20-%20%20A%20simple%20service%20for%20testing% > 20purposes.%0AEnte > r%20or%20edit%20the%20description%20of%20service% > 20ASimpleService.%0A%0A%3C% > 2Fwsdl%3Adocumentation%3E%20%20%3C!--%20service%20description% > 20goes%20here% > 20--%3E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aport%20name%3D% > 22ASimpleSe > rvicePort%22%20binding%3D%22tns%3AASimpleServiceBinding%22%3E%0A% > 20%20%20%20 > %20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Aaddress% > 20location%3D%22htt > p%3A%2F%2Fllama.med.harvard.edu%2F~fgibbons%2Fcgi%2FBGN% > 2Fdispatcher.pl%22%2 > F%3E%20%20%20%20%3C!--%20URL%20to%20service%20scriptname%20--%3E% > 0A%20%20%20 > %20%20%20%20%20%20%20%3C%2Fwsdl%3Aport%3E%0A%20%20%3C%2Fwsdl% > 3Aservice%3E%0A > %0A%3C%2Fwsdl%3Adefinitions%3E%0A%0A%0A' can't be loaded: 501 > Protocol > scheme '' is not supported > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 [1]http://llama.med.harvard.edu/~fgibbons > > References > > 1. http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From rmb32 at cornell.edu Mon Feb 6 14:32:44 2006 From: rmb32 at cornell.edu (Robert Buels) Date: Mon, 06 Feb 2006 14:32:44 -0500 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43D92134.2060708@ac.uma.es> References: <43D92134.2060708@ac.uma.es> Message-ID: <43E7A45C.1060509@cornell.edu> Hi all, I've been lurking on this list for a while, but I haven't said anything. However, right now I'm looking at ways to implement a new BLAST service for SGN, where I work, so I'm watching this async thing developing with great interest, and I've got a few comments. About Martin's main comments: 1. I agree with Martin that it's probably not necessary to introduce a new mobyStatus tag for asynchronous services. I also think that new data types would serve just fine. 2. As for Martin's concern with the dependency on LSID service metadata, this is mitigated by the paragraph near the bottom of page 5 of Johan's proposal, which specifies that asynchronous services must also be able to be called synchronously. So clients can always just plod ahead and call the service synchronously, but if they're smart and can check the metadata, they could discover that they can call asynchronously also. I don't really understand the service categories he's talking about though, so I can't speak to that. 3. I kind of think the 'mixed' mode should be allowed. (Mark also referred to this in his comment number 4). The way I see it, implementation of the service is going to have to be keeping separate state for each job (regardless of how they're divided among invocations), so I don't think it would make implementation easier to impose that the grouping of jobs into invocations always has to remain the same. About Martin's smaller comments: a.) isn't Johan also using the term 'job' to refer to a particular block of mobyData input and the results that arise therefrom? Maybe I'm missing something, but I don't understand Martin's distinction here. b.) I agree, the wording should be changed there. Making the identifier unique to the service provider is also critical for supporting mixed mode. c.) "....can clean the session....": This seems a little dangerous. What if there's some kind of interruption of network connectivity and the client fails to get the whole result, but the server thinks the whole result was sent? That scenario could lead to total loss of the results if _result is a cleaning call. I think a better way would be to say that results are valid for X number of hours after the _async call, and have a cron job or equivalent go through cleaning them up periodically on the server. Until the job state is deleted, the client should be able to call _result as many times as it wants. d.) I agree we should more rigorously define in the RFC the exception codes to be used with async services. Now for some of my own comments: A. I think it would be a bit cleaner, rather than defining 3 separate services with patterns to their names, to define asynchronicity in terms of a single service that accepts the type of request you're making as part of its input XML. Building on Martin's idea, perhaps we could have a set of datatypes just for asynchronous services called, for example, AsyncJobID (ISA String), AsyncNewRequest, AsyncPollRequest (HASA AsyncJobID), and AsyncResultRequest (HASA AsyncJobID). Upon invocation, if no AsyncXXXRequest is present as a Primary article (inside a Simple) in the inputs, then the request is treated as synchronous. This scheme would preserve backward compatibility for calling things in a synchronous style, while also doing away with the complexity of having 4 service names (1 for synchronous, 3 for asynchronous) for what is really a single service. OK, end avalanche. I'm really glad this asynchronous discussion is happening, because I was about to implement my own hacked-together asynchronous protocol. Much better to have a real interoperable consensus. :-) What do you all think about my suggestion to choose synchronicity based on what data is in the input? Rob -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32 at cornell.edu http://www.sgn.cornell.edu From senger at ebi.ac.uk Mon Feb 6 23:18:08 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 04:18:08 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E7A45C.1060509@cornell.edu> Message-ID: Nice to have your answer. Thanks for helping this RFC! > 1. I agree with Martin that it's probably not necessary to introduce a > new mobyStatus tag for asynchronous services. I also think that new > data types would serve just fine. > That's good. Johan and Mark, would you in principle agree, so that I can suggest the datatypes I was talking about (based on LSAE) and send it here? > 2. As for Martin's concern with the dependency on LSID service metadata, > this is mitigated by the paragraph near the bottom of page 5 of Johan's > proposal, which specifies that asynchronous services must also be able > to be called synchronously. So clients can always just plod ahead and > call the service synchronously, but if they're smart and can check the > metadata > Yes, that's correct. I have been thinking in the same line. But this "go ahead and try" approach would work only for clients, not for registry when a registry needs to create a WSDL with all methods, sometimes including xxx_async, somethimes not. For that, you cannot expect that a registry will go and check LSID metadata. So I guess that using LSID metadata for that is simply not possible (unless registry caches them but then why not to keep them in a regular way as any other other registered attributes; or unless gnerated WSDL is crippled even more than it is now). > 3. I kind of think the 'mixed' mode should be allowed. > I am afraid that I have not stressed enough how important is *not* to use the mixed mode. Because if we do so, we cannot use xxx_result as a cleaning method (see more about cleaning below), we would need to have another method, such as xxx_clean. Also, why to make things complicated when they do not need to be? Simply speaking, if a client is willing to get results one by one, it can also call the service one by one (and not as a several jobs in one request). Summary why I do not support mixed mode: Just making it simple as much as possible, and not to need a special cleaning method. > a.) isn't Johan also using the term 'job' to refer to a particular block > of mobyData input and the results that arise therefrom? > No. Johan is using 'job' for one request (which can have more mobyData parts). Once you call xxx_async, the whole such request is identified by a 'job identifier'. I would call it rather 'session' and 'session identifier'. The reason I gave (that jMoby uses term 'job' for individual 'mobyData' parts) is minor. But if we accept to have normal moby data type returning from xxx_async (and others used in xxx_poll) we will re-use these data types also for other things (I mentioned iterator pattern for sending/getting data in chunks) where is much better to talk about sessions than job I think. > c.) "....can clean the session....": This seems a little dangerous. > I slightly disagree. Any good API/interface to a session management (which in our case is represented by the async API we are trying to establish) should have a way how to clean up, how to say "close the session". Of course, an implementation cannot rely that clients will always behave well and clean up - but the API should have this option (for example for cases when client want to ask for the same service thousand times in a short time). If the call to xxx_result fails, it fails, and you have nothing, and you have to start again. This is the sa,e as now with sync services. If you want to allow to get results several times, then we need to add xxx_clean method. But allowing to get results several times adds new features, beyond the simply async call. I thought that we wanted to kep it simple, so why to introduce new features when nobody asks for them explicitly? (Not that I do not see also advantages of allowing to call xxx_result more than once: you can use it - for example and if the service supports it - for getting partial result and display them to clients.... But so far nobody asked for such feature. Do we want it?) > A. I think it would be a bit cleaner, rather than defining 3 separate > services with patterns to their names, to define asynchronicity in terms > of a single service that accepts the type of request you're making as > part of its input XML. > But that's exactly what the proposal is saying. It will be oly one service, but it will have more than one method (and a 'method' in web services speak is a 'type of request'). > perhaps we could have a set of datatypes just for asynchronous > services called, for example, AsyncJobID (ISA String), > AsyncNewRequest, AsyncPollRequest (HASA AsyncJobID), and > AsyncResultRequest (HASA AsyncJobID). > These are fine, except AsyncResultRequest... > Upon invocation, if no AsyncXXXRequest is present as a Primary article > (inside a Simple) in the inputs, then the request is treated as > synchronous. > ...this would mean that a service behaviour is totally different depending on input data. Also, how would you send the real input data? To be honest, I do not understand fully what you meant here... But I think that INB suggestion that the initial input and the resulting output are exactly the same bothy for sync and async is very good and valuable, and guarantees backaward compatibility. So I do not see here any need to suggest anything else :-) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From rmb32 at cornell.edu Tue Feb 7 01:01:17 2006 From: rmb32 at cornell.edu (Robert Buels) Date: Tue, 07 Feb 2006 01:01:17 -0500 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43E837AD.1000708@cornell.edu> >use the mixed mode. Because if we do so, we cannot use xxx_result as a >cleaning method (see more about cleaning below), we would need to have >another method, such as xxx_clean. > > No. Johan is using 'job' for one request (which can have more mobyData >parts). Once you call xxx_async, the whole such request is identified by a >'job identifier'. > > It looks to me like our different interpretations here might be because of a lack of clarity in number 2 on page 8 of the RFC. It doesn't really specify whether one mobyStatus block is returned with an asyncID referring to all the submitted jobs/mobyData blocks, or whether one mobyStatus is returned for each mobyData in the input, with a separate ID for each. I assumed the latter, and I think Martin assumed the former. Whichever way it was intented, I definitely think we should get one unique asyncID per mobyData in the input. So if that's the case, then there would be no difficulties in making the xxx_result call be also the cleanup call. When a xxx_result call is issued for a job with asyncID X, you can clean up just the state related to asyncID X and leave the others alone. > If the call to xxx_result fails, it fails, and you have nothing, and >you have to start again. This is the sa,e as now with sync services. > Well, it would be kind of nice to have a little insurance. What if the job took a week of compute time? It would be nice to have a reliable way to do jobs like that. Maybe specifying a xxx_clean method is actually the way to go here, in order to have a more robust system. Or maybe one could only have to call the xxx_clean if one specified in the xxx_result input that it should NOT clean up? > But that's exactly what the proposal is saying. It will be oly one >service, but it will have more than one method (and a 'method' in web >services speak is a 'type of request'). > > > Yeah, you're right, it is just one service, but just with some kind of async flag in its spec. I was sort of thinking of simplicity on the implementation side, but on second thought implementing 4 methods versus implementing 1 method that's called 4 ways is about the same amount of labor. Nevermind. > But I think that INB suggestion that the initial input and the >resulting output are exactly the same bothy for sync and async is very >good and valuable, and guarantees backaward compatibility. So I do not see >here any need to suggest anything else :-) > > > Yep, you're right, it's good to have input and output the same for sync and async. Nevermind. :-) Rob -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32 at cornell.edu http://www.sgn.cornell.edu From senger at ebi.ac.uk Tue Feb 7 01:45:48 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 06:45:48 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E837AD.1000708@cornell.edu> Message-ID: For those who are not patient to read our long emails, these are the options for the 'mixed' mode, summarized so far (as I understand them). All these discussion is mainly relevant for cases when more 'mobyData' parts is sent in one request (but things about cleaning up are general): A) The method xxx_async would return so many 'job' IDs as the number of 'mobyData' parts. A client can use them to ask invividually for status of each 'mobyData' (using xxx_poll) and to get separately result for each 'mobyData' part (using xxx_result). If this option is agreed on, I strongly suggest to have also a 'job' ID (that I would call either 'request id' or 'sesson id') that is also returned by method xxx_async, and that can be used to ask for the status and result of all 'mobyData' parts in one go (this is because of compatibility with the current sync services). B) Or, there will not be individual IDs for each 'mobyData' part, but only a global (session, request) one. So the B option is actually the second paragraph in the A option. As I see it, we definitely needs B, but we may have also functionality described in the first paragraph of A - but that is an additional feature that I do not feel that important. Make things simple unless we need them! Finally, cleanning can be done by xxx_result (in both A and B), but Robert is right that some additional insurance for long-running jobs is welcome. It can be achieved by an additional method xxx_clean. Cheers, Martin PS. Where is Mark, Eddie, Paul, Frank, Rebecca with there comments!? M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From dgpisano at cnb.uam.es Tue Feb 7 06:05:32 2006 From: dgpisano at cnb.uam.es (David Gonzalez Pisano) Date: Tue, 07 Feb 2006 12:05:32 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E837AD.1000708@cornell.edu> References: <43E837AD.1000708@cornell.edu> Message-ID: <43E87EFC.7070400@cnb.uam.es> Robert Buels escribi?: >> use the mixed mode. Because if we do so, we cannot use xxx_result as a >> cleaning method (see more about cleaning below), we would need to have >> another method, such as xxx_clean. >> >> No. Johan is using 'job' for one request (which can have more mobyData >> parts). Once you call xxx_async, the whole such request is identified by a >> 'job identifier'. >> >> >> > It looks to me like our different interpretations here might be because > of a lack of clarity in number 2 on page 8 of the RFC. It doesn't > really specify whether one mobyStatus block is returned with an asyncID > referring to all the submitted jobs/mobyData blocks, or whether one > mobyStatus is returned for each mobyData in the input, with a separate > ID for each. I assumed the latter, and I think Martin assumed the > former. Whichever way it was intented, I definitely think we should get > one unique asyncID per mobyData in the input. > > Maybe the wording has to be change to make it clearer, but the idea is exactly like Robert interprets it: having a single and unique mobyStatus (ie, asyncID) for each one of the mobyData (ie, queryIDs) sent in the original execution request. David From Pieter.Neerincx at wur.nl Tue Feb 7 08:25:02 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 7 Feb 2006 14:25:02 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E7A45C.1060509@cornell.edu> References: <43D92134.2060708@ac.uma.es> <43E7A45C.1060509@cornell.edu> Message-ID: Hi all, On 6-Feb-2006, at 8:32 PM, Robert Buels wrote: > About Martin's main comments: > > 1. I agree with Martin that it's probably not necessary to introduce a > new mobyStatus tag for asynchronous services. I also think that new > data types would serve just fine. I agree too. But there is a catch. If we use "normal" BioMOBY objects to signal the status of a async queryID, it is more likely that people will start to invent other, new, maybe derived objects for similar things. Since anyone can register new objects, this makes the asynchronous service behaviour evolve faster, but it might also mean a less stable interface. Putting the additional info for asynchronous behaviour outside the mobyData blocks (hence in the proposed mobyStatus block) makes sure that it requires a well written RFC (many thanks for that to the INB people). Getting an RFC accepted takes much more time compared to registering a new object, but it also makes the interface more stable. > 3. I kind of think the 'mixed' mode should be allowed. (Mark also > referred to this in his comment number 4). The way I see it, > implementation of the service is going to have to be keeping separate > state for each job (regardless of how they're divided among > invocations), so I don't think it would make implementation easier to > impose that the grouping of jobs into invocations always has to remain > the same. I agree again. > > About Martin's smaller comments: > a.) isn't Johan also using the term 'job' to refer to a particular > block > of mobyData input and the results that arise therefrom? Maybe I'm > missing something, but I don't understand Martin's distinction here. > b.) I agree, the wording should be changed there. Making the > identifier > unique to the service provider is also critical for supporting > mixed mode. Agree for both a and b. > c.) "....can clean the session....": This seems a little dangerous. > What if there's some kind of interruption of network connectivity and > the client fails to get the whole result, but the server thinks the > whole result was sent? That scenario could lead to total loss of the > results if _result is a cleaning call. I think a better way would > be to > say that results are valid for X number of hours after the _async > call, > and have a cron job or equivalent go through cleaning them up > periodically on the server. Until the job state is deleted, the > client > should be able to call _result as many times as it wants. I agree with Rob here. I think it is much better to have an additional xxx_clean or something similar. If a client wants to make sure his data is no longer on the server they can always call xxx_result and immediately after that a xxx_clean. It's just one additional line of code client-side. Server-side it is also not that much work to implement. Just move the cleaning code to an additional sub that translates into an additional SOAP method > d.) I agree we should more rigorously define in the RFC the exception > codes to be used with async services. I agree. > Now for some of my own comments: > > A. I think it would be a bit cleaner, rather than defining 3 separate > services with patterns to their names, to define asynchronicity in > terms > of a single service that accepts the type of request you're making as > part of its input XML. Building on Martin's idea, perhaps we could > have > a set of datatypes just for asynchronous services called, for example, > AsyncJobID (ISA String), AsyncNewRequest, AsyncPollRequest (HASA > AsyncJobID), and AsyncResultRequest (HASA AsyncJobID). Upon > invocation, > if no AsyncXXXRequest is present as a Primary article (inside a > Simple) > in the inputs, then the request is treated as synchronous. This > scheme > would preserve backward compatibility for calling things in a > synchronous style, while also doing away with the complexity of > having 4 > service names (1 for synchronous, 3 for asynchronous) for what is > really > a single service. Currently the object ontology lists only what goes into a service and what comes out of it. Details about where the service resides and how to access it currently go into the service ontology. Therefore it makes more sense to me to put the info about (a)synchronous behaviour in the service ontology. > > OK, end avalanche. I'm really glad this asynchronous discussion is > happening, because I was about to implement my own hacked-together > asynchronous protocol. Much better to have a real interoperable > consensus. :-) I second that! Pi > What do you all think about my suggestion to choose synchronicity > based > on what data is in the input? > > Rob > > -- > Robert Buels > SGN Bioinformatics Analyst > 252A Emerson Hall, Cornell University > Ithaca, NY 14853 > Tel: 607-255-2360 > rmb32 at cornell.edu > http://www.sgn.cornell.edu > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Tue Feb 7 08:27:33 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 7 Feb 2006 14:27:33 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E87EFC.7070400@cnb.uam.es> References: <43E837AD.1000708@cornell.edu> <43E87EFC.7070400@cnb.uam.es> Message-ID: <609EC6A1-82E9-49C2-88EF-DE82607620D1@wur.nl> On 7-Feb-2006, at 12:05 PM, David Gonzalez Pisano wrote: > Robert Buels escribi?: >>> use the mixed mode. Because if we do so, we cannot use xxx_result >>> as a >>> cleaning method (see more about cleaning below), we would need to >>> have >>> another method, such as xxx_clean. >>> >>> No. Johan is using 'job' for one request (which can have more >>> mobyData >>> parts). Once you call xxx_async, the whole such request is >>> identified by a >>> 'job identifier'. >>> >>> >>> >> It looks to me like our different interpretations here might be >> because >> of a lack of clarity in number 2 on page 8 of the RFC. It doesn't >> really specify whether one mobyStatus block is returned with an >> asyncID >> referring to all the submitted jobs/mobyData blocks, or whether one >> mobyStatus is returned for each mobyData in the input, with a >> separate >> ID for each. I assumed the latter, and I think Martin assumed the >> former. Whichever way it was intented, I definitely think we >> should get >> one unique asyncID per mobyData in the input. >> >> > Maybe the wording has to be change to make it clearer, but the idea is > exactly like Robert interprets it: having a single and unique > mobyStatus > (ie, asyncID) for each one of the mobyData (ie, queryIDs) sent in the > original execution request. Well in that case, the queryID and asyncID are redundant aren't they? They are both just unique pointers to identify a certain mobyData block. It would be good though to have an additional ID / ticket to represent a session (that might be based on user's credentials etc.). I think we definitely need one mobyStatus per mobyData block. So I disagree with Martin there. If Martin wants to keep things simple he can always summarise all the mobyStatus elements for one session and tell a user whether the whole batch has finished or not. Pi > > David > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Tue Feb 7 08:44:12 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 13:44:12 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <609EC6A1-82E9-49C2-88EF-DE82607620D1@wur.nl> Message-ID: > Well in that case, the queryID and asyncID are redundant aren't they? > They are both just unique pointers to identify a certain mobyData > block. > They are not the same, at all: First, queryID is defined by a client, not a service provider - and two clients cannot guarantee that they assign different IDs. Second, asyncID must be unique even for more requests (of the same service, at least), but queryID does not need to be. For example, as a client I can send two requests, both with the same queryID, but I expect that the service provider distinguis them when I am polling for their status. > It would be good though to have an additional ID / ticket to > represent a session (that might be based on user's credentials etc.). > Agree. That's what I suggested. > I think we definitely need one mobyStatus per mobyData block. So I > disagree with Martin there. If Martin wants to keep things simple he > can always summarise all the mobyStatus elements for one session and > tell a user whether the whole batch has finished or not. > I already said that I do not mind to have states of individual mobyData blocks (named jobs, as we all in the meantime agreed). Fine with me. But I keep telling that I *mind* to use mobyStatus tag (but that beongs somewhere else). Good to have you on the discussion, Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 7 08:51:54 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 13:51:54 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: Message-ID: > > 1. I agree with Martin that it's probably not necessary to introduce a > > new mobyStatus tag for asynchronous services. I also think that new > > data types would serve just fine. > > I agree too. > Welcome on the board :-) > But there is a catch. If we use "normal" BioMOBY objects > to signal the status of a async queryID, it is more likely that > people will start to invent other, new, maybe derived objects for > similar things. > Not sure why this is a catch. This is an advantage: I can return much more detailed status if I want, and if I use a more specialized event object. But regarding the new API (if approved), all such event objects must inherit from the one defined in the API. As usual... > > 3. I kind of think the 'mixed' mode should be allowed. (Mark also > I agree again. > I think that the existence of a mixed mode is already agreed on (at least by those who expressed their views). Johan, you as the prime author should start to summarize what is agreed on and what needs to be discussed further. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 7 09:18:53 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 14:18:53 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E8A936.9040204@ebi.ac.uk> Message-ID: > Isn't there a risk that you're getting properties of the service > mechanism confused with those of the underlying service function? > I do not see it as a risk. > When you describe a service as 'asynchronous' you really mean that a > service invocation has persistent state on the server to which the > client must reconnect, making more than one call at the low level to > invoke the high level service, right? > Yes. > Every time a 'magic' moby object type is used the client tooling becomes > more complicated. > Precisely, that's why I do not want mobyStatus tag - that is a magic tag. If I use a normal moby object, I do not need to change anything in the client tooling as long as my client do not want to call a service asynchonosly. In that moment, the client obviously becomes more complicated. But if we use for status normal objects, the complication is smaller. > Just my two cents, I'd suggest a look at frameworks such as WSRF which > handle state explicitly (WSRF being derived from the state model in > Globus 2, loosely, but applied to web services), and at the least I'd > like to see a document explaining why these relatively standard > technologies aren't being applied here. > This is a very valid point (you see that I sometimes even agree with Tom?). I was myself trying to find how axis2 can help us with the asynchonicity without changing bimoby api (or changing it not much), and so far I failed to get it. Probably similar it is with other technologies. We do not have time to study in details such big products/specs as WSRF is, unless we have to. But we are usually open if somebody tells us: this and this you can use and it will solve your problem better. So far, we do not have such person for WSRF... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From tmo at ebi.ac.uk Tue Feb 7 09:05:42 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Tue, 07 Feb 2006 14:05:42 +0000 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43E8A936.9040204@ebi.ac.uk> Martin Senger wrote: >>> 1. I agree with Martin that it's probably not necessary to introduce a >>> new mobyStatus tag for asynchronous services. I also think that new >>> data types would serve just fine. >> I agree too. >> > Welcome on the board :-) > >> But there is a catch. If we use "normal" BioMOBY objects >> to signal the status of a async queryID, it is more likely that >> people will start to invent other, new, maybe derived objects for >> similar things. >> > Not sure why this is a catch. This is an advantage: I can return much > more detailed status if I want, and if I use a more specialized event > object. But regarding the new API (if approved), all such event objects > must inherit from the one defined in the API. As usual... This sounds messy to me - I know I haven't been involved up to now and to be honest don't have time to now (I'm only sending this because I'm on holiday!). Isn't there a risk that you're getting properties of the service mechanism confused with those of the underlying service function? When you describe a service as 'asynchronous' you really mean that a service invocation has persistent state on the server to which the client must reconnect, making more than one call at the low level to invoke the high level service, right? Every time a 'magic' moby object type is used the client tooling becomes more complicated. Any invocation framework is going to have to have special catch clauses to handle this magic type, even if the client is otherwise entirely agnostic to the data returned from the service. This is a bad thing. I don't think this message belongs in the standard moby object space, it is a property of the service invocation semantics in the same way as the inherent moby wrapper is at one level and that the low level SOAP wrapper is at another, I would avoid mingling it with the data layer. Just my two cents, I'd suggest a look at frameworks such as WSRF which handle state explicitly (WSRF being derived from the state model in Globus 2, loosely, but applied to web services), and at the least I'd like to see a document explaining why these relatively standard technologies aren't being applied here. If I were a reviewer on one of Mark's grants (hypothetically, they asked me but I had to reject on conflict of interest grounds) I'd want to see this comparison. Cheers, Tom From Pieter.Neerincx at wur.nl Tue Feb 7 11:46:42 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 7 Feb 2006 17:46:42 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E87EFC.7070400@cnb.uam.es> References: <43E837AD.1000708@cornell.edu> <43E87EFC.7070400@cnb.uam.es> Message-ID: <2A9C678A-F1E4-40A1-8A09-E2627ACBF327@wur.nl> Hi all, Ok, this is just a minor comment. It's about the names for the different SOAP methods. Currently proposed: [servicename]_async [servicename]_poll [servicename]_result It looks to me like they are a bit random. Off course they could be just _a, _b and _c as well. For the way it will work it won't matter, but since we will have these names for quite some time, I would suggest something more logical. Async is the the service type, you poll (=verb) for the status (=noun) and you retrieve (=verb) the result (=noun). To me it makes more sense if the methods are named after a verb that describes the action that the SOAP method performs. So that would mean something like this: [servicename]_submit [servicename]_poll [servicename]_retrieve and maybe also: [servicename]_clean or [servicename]_remove Just my 2c, Pi From edward.kawas at gmail.com Tue Feb 7 12:25:25 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 7 Feb 2006 09:25:25 -0800 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <2A9C678A-F1E4-40A1-8A09-E2627ACBF327@wur.nl> Message-ID: <000001c62c0b$7c42c1d0$7766a8c0@notebook> I haven't said much ... I like the idea of having verbs that describe actions. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Pieter Neerincx > Sent: Tuesday, February 07, 2006 8:47 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal > > Hi all, > > Ok, this is just a minor comment. It's about the names for > the different SOAP methods. Currently proposed: > > [servicename]_async > [servicename]_poll > [servicename]_result > > It looks to me like they are a bit random. Off course they > could be just _a, _b and _c as well. For the way it will work > it won't matter, but since we will have these names for quite > some time, I would suggest something more logical. > Async is the the service type, you poll (=verb) for the status > (=noun) and you retrieve (=verb) the result (=noun). To me it > makes more sense if the methods are named after a verb that > describes the action that the SOAP method performs. So that > would mean something like this: > > [servicename]_submit > [servicename]_poll > [servicename]_retrieve > and maybe also: > [servicename]_clean or [servicename]_remove > > Just my 2c, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Feb 7 14:43:21 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 07 Feb 2006 11:43:21 -0800 Subject: [MOBY-dev] [moby] Try to create service from serialized WSDL, get strange SOAP::Lite error In-Reply-To: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> References: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> Message-ID: <1139341401.25375.16.camel@bioinfo.icapture.ubc.ca> Hi Frank, I've read over your bug report below a few times and I can't quite extract from it what the bug actually is... Can you paraphrase? thanks, M On Fri, 2006-02-03 at 12:41 -0500, Frank Gibbons wrote: > Hi, > It takes MOBY about half a second to retrieve WSDL from Central, to build a > service. In an effort to improve performance in an application that may need > to build many (maybe ten) services at a time, I'm trying to cache WSDL > locally, and build services from that, as needed. I'm using Storable for > serialization in Perl, which has worked well for me in the past. To > paraphrase Yogi Berra: "Half a second here, half a second there, pretty soon > you're talking about real time." > I'm encountering a strange error in this, which appears to be emanating > ultimately from SOAP::Lite (see below) In essence it says: > Service description 'data:, can't be loaded: 501 Protocol > scheme '' is not supported > The WSDL is URI_encoded by MOBY, not by me - I just supply an XML-text > description to MOBY::Client::Service->new(), pretty much exactly as provided > from MCentral. I DO NOT see this problem when using the WSDL supplied by > MOBY Central directly however, so there's clearly some kind of problem with > serialization. I'm wondering if any of you have seen a similar behaviour in > the past, and how you got around it. The WSDL I retrieve from the cache > looks fine when I print it out, but I'm wondering if there might be some > other funkiness to it that gets messed up with I store it. > Thanks in advance. > -Frank > ============================== MOBY::Client::Service message below > ========================= > Service description > 'data:,%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Cwsdl%3Adefinitions%20name% > 3D%22MOBY_Central_Generated_WSDL%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%2 > 0%20%20%20targetNamespace%3D%22http%3A%2F%2Fbiomoby.org%2FCentral.wsdl%22%0A > %20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Atns%3D%22http%3A%2F% > 2Fbiomoby.org%2FCentral.wsdl%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20 > %20%20xmlns%3Axsd1%3D%22http%3A%2F%2Fbiomoby.org%2FCentralXSDs.xsd%22%20%0A% > 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Asoap%3D%22http%3A%2F% > 2Fschemas.xmlsoap.org%2Fwsdl%2Fsoap%2F%22%0A%20%20%20%20%20%20%20%20%20%20%2 > 0%20%20%20%20%20xmlns%3Axsd%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2FXMLSchema% > 22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3D%22http%3A%2F%2 > Fschemas.xmlsoap.org%2Fwsdl%2F%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20% > 20%20%20xmlns%3Awsdl%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fwsdl%2F%22%3E%0 > A%0A%20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceInput%22%3E%0 > A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22data%22%20type%3D% > 22xsd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20%20%20%20 > %20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceOutput%22%3E%0A%2 > 0%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22body%22%20type%3D%22x > sd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20%20%20%20%20 > %20%20%20%0A%20%20%3Cwsdl%3AportType%20name%3D%22ASimpleServicePortType%22%3 > E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D%22ASimpleSer > vice%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Ain > put%20message%3D%22tns%3AASimpleServiceInput%22%2F%3E%0A%20%20%20%20%20%20%2 > 0%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%20message%3D%22tns%3AASimple > ServiceOutput%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperatio > n%3E%0A%20%20%3C%2Fwsdl%3AportType%3E%0A%20%0A%20%20%3Cwsdl%3Abinding%20name > %3D%22ASimpleServiceBinding%22%20type%3D%22tns%3AASimpleServicePortType%22%3 > E%0A%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abinding%20style%3D%22rpc%22%20tr > ansport%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fhttp%22%2F%3E%0A%20%2 > 0%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D%22ASimpleService%22%3 > E%3C!--%20in%20essense%2C%20this%20is%20the%20name%20of%20the%20subroutine%2 > 0that%20is%20called%20--%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% > 20%20%3Csoap%3Aoperation%20soapAction%3D'http%3A%2F%2Fbiomoby.org%2F%23ASimp > leService'%20style%3D'rpc'%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%2 > 0%20%20%20%3Cwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20 > %20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encoded%22%20namespa > ce%3D%22http%3A%2F%2Fbiomoby.org%2F%22%20encodingStyle%3D%22http%3A%2F%2Fsch > emas.xmlsoap.org%2Fsoap%2Fencoding%2F%22%2F%3E%0A%20%20%20%20%20%20%20%20%20 > %20%20%20%20%20%20%20%20%3C%2Fwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20% > 20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encode > d%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3 > Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperation%3E%0A%20%2 > 0%3C%2Fwsdl%3Abinding%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% > 0A%20%20%3Cwsdl%3Aservice%20name%3D%22ASimpleServiceService%22%3E%0A%20%20%2 > 0%20%20%20%20%20%20%20%3Cwsdl%3Adocumentation%3EAuthority%3A%20llama.med.har > vard.edu%20%20-%20%20A%20simple%20service%20for%20testing%20purposes.%0AEnte > r%20or%20edit%20the%20description%20of%20service%20ASimpleService.%0A%0A%3C% > 2Fwsdl%3Adocumentation%3E%20%20%3C!--%20service%20description%20goes%20here% > 20--%3E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aport%20name%3D%22ASimpleSe > rvicePort%22%20binding%3D%22tns%3AASimpleServiceBinding%22%3E%0A%20%20%20%20 > %20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Aaddress%20location%3D%22htt > p%3A%2F%2Fllama.med.harvard.edu%2F~fgibbons%2Fcgi%2FBGN%2Fdispatcher.pl%22%2 > F%3E%20%20%20%20%3C!--%20URL%20to%20service%20scriptname%20--%3E%0A%20%20%20 > %20%20%20%20%20%20%20%3C%2Fwsdl%3Aport%3E%0A%20%20%3C%2Fwsdl%3Aservice%3E%0A > %0A%3C%2Fwsdl%3Adefinitions%3E%0A%0A%0A' can't be loaded: 501 Protocol > scheme '' is not supported > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 [1]http://llama.med.harvard.edu/~fgibbons > > References > > 1. http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Tue Feb 7 16:02:27 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 07 Feb 2006 16:02:27 -0500 Subject: [MOBY-dev] [moby] Try to create service from serialized WSDL, get strange SOAP::Lite error In-Reply-To: <1139341401.25375.16.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060207145434.023890c0@email.med.harvard.edu> Hi Mark, At 02:43 PM 2/7/2006, you wrote: >Hi Frank, > >I've read over your bug report below a few times and I can't quite >extract from it what the bug actually is... Can you paraphrase? Yeah, I don't really blame you - I've had a really hard time figuring out where the bug is myself! I've been working on this the past few days, and am happy to announce that I now have a deeper understanding of my confusion, though still no solution. [This posting turned out to be quite long.] First of all, it turns out that the specific problem I see below occurs only when I run my code under the Perl debugger, through emacs. So that may be a complete red herring, perhaps symptomatic of something else. I'm using Perl 5.8.6 from the SuSE distribution on dual-CPU i686-architecture hardware, but compiled for i586 architecture (sysadmin thought that shouldn't be a problem), with thread-support enabled (ditto). However, the problematic behaviour still exists. My code seg-faults 100% of the time. I can nail down the specifics a bit more precisely now. My goal is simple: cache WSDL locally, to avoid hitting MOBY Central too often, and to improve local performance in querying services: "discover once, use often" you might say. I can't keep service objects around, since I'm interested in using this in a web application, so services have to be constructed frequently. But they only need to be discovered sporadically (once an hour, once a day?). Simple enough. I have tried serializing with Storable and Data::Dumper, and find the same fundamental problem with both, which leads me to believe that the problem doesn't lie with serialization as a concept, or as an implementation. This is a relief, since all I want to serialize is the WSDL for each service, which is a string. If I can't serialize a string, I'm in deeper trouble than I thought! ;-D Using the serialized WSDL, I can thaw out ('deserialize'), successfully construct, and even execute services, so there is no inherent problem with the WSDL upon thawing. The MOBY::Client::Service objects returned are normal in every way. My problem comes when I try to return from the subroutine that does all this serializing, thawing, and reconstruction. The program crashes _always _and _only_ upon the return statement, and only when a MOBY::Client::Service has been created. If I simply serialize and thaw the WSDL, I get no problems upon returning. Under certain circumstances, the seg fault is accompanied by a message that "REFCNT decremented below 0!". Looks like a garbage-collection problem, where the GC tries to free something that's already been freed! A further clue is provided by Pieter Neerincx (private communication), who mentioned that he had a very similar problem which he traced back to XML::LibXML. The page http://cpan.uwinnipeg.ca/htdocs/XML-LibXML/Changes.html lists several recent bug fixes for threads from version 1.5.1 onwards (I'm using the latest, 1.5.8), including the specific one that Pieter encountered (the one using documentFragment()), which was supposedly fixed for 1.5.8. In fairness, I don't think the problem lies with MOBY itself, since it mostly just uses XML::LibXML in a fairly generic way (calls parse() a lot, but that's about it). However, the bug is serious enough to prevent caching of MOBY services, and presumably other potential uses which attempt to hide MOBY's interface in modules. So it affects MOBY in that sense, albeit indirectly. Briefly: use serialized WSDL, AND create MOBY::Client::Service, AND then return from subroutine ==> seg fault (always) use "fresh" WSDL, rest unchanged (can't cache services) ==> no seg fault don't return from subroutine, rest unchanged (can't encapsulate in other module) ==> no seg fault omit MOBY::Client::Service creation, rest unchanged (can't do anything useful at all) ==> no seg fault otherwise ==> no seg fault (ever) If you'd like to play around with it, go here: http://llama.med.harvard.edu/~fgibbons/tmp/api_moby.pl to get the self-contained stub I'm using to investigate this. Use the $config hashref to turn on caching (CACHE_SERVICE_INFO => 1), and watch it fault. (You'll have to run it twice: once to build the cache, then again to use it). Then turn off caching, and watch it return normally. I have NO IDEA where to go from here. I'd really rather not ask my sysadmin to build and reinstall Perl _without_ threads unless I'm positive that will cure my problems. If anyone has ANY ideas on where to go from here, I would be really, truly grateful. TIA, -Frank >On Fri, 2006-02-03 at 12:41 -0500, Frank Gibbons wrote: > > Hi, > > It takes MOBY about half a second to retrieve WSDL from Central, to > build a > > service. In an effort to improve performance in an application that > may need > > to build many (maybe ten) services at a time, I'm trying to cache WSDL > > locally, and build services from that, as needed. I'm using Storable for > > serialization in Perl, which has worked well for me in the past. To > > paraphrase Yogi Berra: "Half a second here, half a second there, > pretty soon > > you're talking about real time." > > I'm encountering a strange error in this, which appears to be emanating > > ultimately from SOAP::Lite (see below) In essence it says: > > Service description 'data:, can't be loaded: 501 > Protocol > > scheme '' is not supported > > The WSDL is URI_encoded by MOBY, not by me - I just supply an XML-text > > description to MOBY::Client::Service->new(), pretty much exactly as > provided > > from MCentral. I DO NOT see this problem when using the WSDL supplied by > > MOBY Central directly however, so there's clearly some kind of > problem with > > serialization. I'm wondering if any of you have seen a similar > behaviour in > > the past, and how you got around it. The WSDL I retrieve from the cache > > looks fine when I print it out, but I'm wondering if there might be some > > other funkiness to it that gets messed up with I store it. > > Thanks in advance. > > -Frank > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev >-- PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From rmb32 at cornell.edu Tue Feb 7 16:00:30 2006 From: rmb32 at cornell.edu (Robert Buels) Date: Tue, 07 Feb 2006 16:00:30 -0500 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <2A9C678A-F1E4-40A1-8A09-E2627ACBF327@wur.nl> References: <43E837AD.1000708@cornell.edu> <43E87EFC.7070400@cnb.uam.es> <2A9C678A-F1E4-40A1-8A09-E2627ACBF327@wur.nl> Message-ID: <43E90A6E.70009@cornell.edu> >[servicename]_submit >[servicename]_poll >[servicename]_retrieve >and maybe also: >[servicename]_clean or [servicename]_remove > > Those are nice names, I like them. Anybody else? Rob -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32 at cornell.edu http://www.sgn.cornell.edu From francis_gibbons at hms.harvard.edu Tue Feb 7 17:40:42 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 07 Feb 2006 17:40:42 -0500 Subject: [MOBY-dev] addendum to service creation from serialized WSDL Message-ID: <5.2.1.1.2.20060207173502.01215db0@email.med.harvard.edu> I've learned one or two more things: 1. The whole "return from a subroutine" is a red herring. Even if you create the services in main(), not in a subroutine, you still 'seg fault' at the end. 2. Serialization is too high-brow a term - even if you just save the WSDL in a file, using plain old "open my $WSDL, $wdfl_file; print $WSDL $my_wsdl" and read it back in later, the effect is the same. So it's really and truly got _nothing_ to do with serialization. 3. I've tried altering MOBY::Client::Service to use the other syntax for SOAP::Lite->service(), in which rather than a URI, you give it the name of a file on the local filesystem. Nothing changes. I haven't come across anything like what MOBY _actually_ uses, passing in the WSDL as a string - I guess we should just be thankful that it works. I hate to bring this up, but are there other alternatives to XML::LibXML....? I know we went to it for its support of namespaces, but that was a year ago, and perhaps there's something else that provides that support now, without the threading problems? I'm not advocating it, just wondering out loud. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Feb 7 18:35:23 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 07 Feb 2006 15:35:23 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E8A936.9040204@ebi.ac.uk> References: <43E8A936.9040204@ebi.ac.uk> Message-ID: <1139355323.1479.25.camel@bioinfo.icapture.ubc.ca> I just had a look at the WSRF proposal - it's a very young "standard" (or as Tom puts it, a very young "relatively standard technology"), but it's interesting and looks like it does a lot of what we need. It's surprisingly lightweight. It uses the SOAP Header to pass the state information, and thus would not require any changes to the MOBY Messaging structure (which is nice!). What is going to be slightly tricky for us, however, is that the Schema for the service-specific state information is contained in the WSDL file, and that file is created by MOBY Central. We would either have to extend MOBY Central to capture this information at registration, or we would have to agree on a standard set of XML tags that all stateful MOBY services would agree to use that we could then add into the default WSDL document template. I suspect that the latter would be the way we want to go, since we are already talking about creating standard objects. WSRF also has explicit support for things like "clean" that we have been talking about in this thread to destroy the server-side resources. It also has some standardized fault codes that are (apparently?) extensible such that we could report things like progress or Estimated-time-to-completion. I agree with Tom - much of what we are discussing here is dealt with by the WSRF spec. (thanks for the heads-up Tom!). I wonder if the authors of RFC1941 could browse the WSRF spec and see if they agree that it is useful, and if so, revise the proposal accordingly? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Tue Feb 7 19:36:24 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 8 Feb 2006 00:36:24 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E90A6E.70009@cornell.edu> Message-ID: > >[servicename]_submit > >[servicename]_poll > >[servicename]_retrieve > >and maybe also: > >[servicename]_clean or [servicename]_remove > Those are nice names, I like them. Anybody else? > I don't care (but 'submit' is confusing because even just a sync invocation is a submit...) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From gordonp at ucalgary.ca Wed Feb 8 13:31:42 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 08 Feb 2006 11:31:42 -0700 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43EA390E.6090305@ucalgary.ca> I am pretty much in agreement with all of Martin's points, especially using the existing mobyData tag and formulating job-ticket-like objects. As a client interface builder, this is MUCH more convenient for me... >>Well in that case, the queryID and asyncID are redundant aren't they? >>They are both just unique pointers to identify a certain mobyData >>block. >> >> >> > They are not the same, at all: First, queryID is defined by a client, >not a service provider - and two clients cannot guarantee that they assign >different IDs. Second, asyncID must be unique even for more requests (of >the same service, at least), but queryID does not need to be. For example, >as a client I can send two requests, both with the same queryID, but I >expect that the service provider distinguis them when I am polling for >their status. > > > >>It would be good though to have an additional ID / ticket to >>represent a session (that might be based on user's credentials etc.). >> >> >> > Agree. That's what I suggested. > > > >>I think we definitely need one mobyStatus per mobyData block. So I >>disagree with Martin there. If Martin wants to keep things simple he >>can always summarise all the mobyStatus elements for one session and >>tell a user whether the whole batch has finished or not. >> >> >> > I already said that I do not mind to have states of individual mobyData >blocks (named jobs, as we all in the meantime agreed). Fine with me. But I >keep telling that I *mind* to use mobyStatus tag (but that beongs >somewhere else). > > Good to have you on the discussion, > Cheers, > Martin > > > From francis_gibbons at hms.harvard.edu Wed Feb 8 14:35:57 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 08 Feb 2006 14:35:57 -0500 Subject: [MOBY-dev] MOBY Central OK? Message-ID: <5.2.1.1.2.20060208143403.02362410@email.med.harvard.edu> Just wondering: is MOBY Central OK. I'm still working out my own issues (aren't we all, you say ;-), but now find I'm unable to connect to MOBY Central: I get the dreaded "ERROR ERROR ERROR". I'm wondering if it's just me, or whether others are also encountering this problem. It's been (apparently) down for a few hours now. Thanks -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From edward.kawas at gmail.com Wed Feb 8 14:32:38 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 8 Feb 2006 11:32:38 -0800 Subject: [MOBY-dev] MOBY Central OK? In-Reply-To: <5.2.1.1.2.20060208143403.02362410@email.med.harvard.edu> Message-ID: <002801c62ce6$6c79f530$6700a8c0@notebook> I have been using it all morning, so it should be up. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Frank Gibbons > Sent: Wednesday, February 08, 2006 11:36 AM > To: MOBY-dev at biomoby.org > Subject: [MOBY-dev] MOBY Central OK? > > Just wondering: is MOBY Central OK. I'm still working out my > own issues (aren't we all, you say ;-), but now find I'm > unable to connect to MOBY > Central: I get the dreaded "ERROR ERROR ERROR". I'm wondering > if it's just me, or whether others are also encountering this > problem. It's been > (apparently) down for a few hours now. > > Thanks > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston > MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Wed Feb 8 15:17:33 2006 From: markw at illuminae.com (mark wilkinson) Date: Wed, 8 Feb 2006 20:17:33 +0000 GMT Subject: [MOBY-dev] MOBY Central OK? Message-ID: <655160667-1139429953-cardhu_blackberry.rim.net-28443-@engine08-cell01> The dreaded Error cubed, eh? I dunno... I have also been using it this morning, and haven't touched anything today except the gbrowse rendering modules, so...?? Can you ping or traceroute to the machine? M -----Original Message----- From: Frank Gibbons Date: Wed, 08 Feb 2006 14:35:57 To:MOBY-dev at biomoby.org Subject: [MOBY-dev] MOBY Central OK? Just wondering: is MOBY Central OK. I'm still working out my own issues (aren't we all, you say ;-), but now find I'm unable to connect to MOBY Central: I get the dreaded "ERROR ERROR ERROR". I'm wondering if it's just me, or whether others are also encountering this problem. It's been (apparently) down for a few hours now. Thanks -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From francis_gibbons at hms.harvard.edu Wed Feb 8 16:49:59 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 08 Feb 2006 16:49:59 -0500 Subject: [MOBY-dev] MOBY Central OK? In-Reply-To: <655160667-1139429953-cardhu_blackberry.rim.net-28443-@engi ne08-cell01> Message-ID: <5.2.1.1.2.20060208160929.02368428@email.med.harvard.edu> At 03:17 PM 2/8/2006, you wrote: >The dreaded Error cubed, eh? > >I dunno... I have also been using it this morning, and haven't touched >anything today except the gbrowse rendering modules, so...?? > >Can you ping or traceroute to the machine? Actually, I've now diagnosed that it's _not_ a connectivity problem: for example, MOBY::Client::Central->findServices() works fine. But when I try to retrieve an individual service, I end up with: Empty String at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2457 ERROR ERROR ERROR At first, I thought this was truly bizarre for a number of reasons, not least of which is the fact that there is NO Perl 5.8.5 installed on my machine, and even the perl executable I'm using (which is 5.8.6) is running from my home directory, and therefore should have nothing at all to do with /usr/lib. ....but then I realized that it's coming from the remote MOBY::Central, not from my local MOBY::Client::Central. When I go to that line in MOBY::Central.pm, I notice that it's in _retrieveService(), and the die() propagates up from XML::LibXML being passed in an empty $payload. At least I think that's what's going on. What do you think? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Wed Feb 8 16:55:25 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 08 Feb 2006 13:55:25 -0800 Subject: [MOBY-dev] MOBY Central OK? In-Reply-To: <5.2.1.1.2.20060208160929.02368428@email.med.harvard.edu> References: <5.2.1.1.2.20060208160929.02368428@email.med.harvard.edu> Message-ID: Can you send me the exact code fragment that is causing the problem (or even the search parameters for the findServices call). I'll do a local call directly against the MOBY/Central.pm in debug mode and see if I can track down the problem. M On Wed, 08 Feb 2006 13:49:59 -0800, Frank Gibbons wrote: > At 03:17 PM 2/8/2006, you wrote: >> The dreaded Error cubed, eh? >> >> I dunno... I have also been using it this morning, and haven't touched >> anything today except the gbrowse rendering modules, so...?? >> >> Can you ping or traceroute to the machine? > > Actually, I've now diagnosed that it's _not_ a connectivity problem: for > example, MOBY::Client::Central->findServices() works fine. But when I > try to retrieve an individual service, I end up with: > > Empty String at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2457 > > ERROR ERROR ERROR > > At first, I thought this was truly bizarre for a number of reasons, not > least of which is the fact that there is NO Perl 5.8.5 installed on my > machine, and even the perl executable I'm using (which is 5.8.6) is > running from my home directory, and therefore should have nothing at all > to do with /usr/lib. > > ....but then I realized that it's coming from the remote MOBY::Central, > not from my local MOBY::Client::Central. When I go to that line in > MOBY::Central.pm, I notice that it's in _retrieveService(), and the > die() propagates up from XML::LibXML being passed in an empty $payload. > > At least I think that's what's going on. What do you think? > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From johan at ac.uma.es Thu Feb 9 04:16:30 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 09 Feb 2006 10:16:30 +0100 Subject: [MOBY-dev] RFC #1941: INB Asynchronous Service Call Proposal - discussion summary (so far) Message-ID: <43EB086E.2050108@ac.uma.es> Hello everyone, It is very encouraging to get such a reaction to a RFC. It clearly demonstrates that the proposal is needed. The result of all these discussion and comments will be a much-needed mechanism to call long-running services (something we are eager to implement in our system). However, let me first point out that the RFC is a collaborative result from the entire INB. Martin suggested me to summarize what has been discussed so far and this is what I have come up with (really, it is not an easy task...). Please, if I misinterpret "agreement", I apologize and ask that you let me know. The motivation for the summary is to see if we are reaching some form of consensus. It does not mean that discussion on the "agreed" points is over, anyone with comments are very welcome. "agreed?": ======== * Three additional methods to represent starting an asynchronous session, polling for status and getting the result. * It should be allowed to retrieve results or status for specific mobyData inputs ("jobs"), although all clients must not support this (if they do not want) * XML from LSAE should be used to carry status information (somehow) * More specifics needed about which mobyExceptions for async-related fails/warnings * Information about if a service can be run asynchronously should be stored in the registry. Still debated or unresolved: ========= * Using mobyStatus vs. using status objects in the ontology (actually this is the most debated question). (Martin) * How clients determine if a service can be called asynchronously (Martin) * Names of the methods, use instead verbs to better describe the methods. (Pieter Neerincx) * Alternate solution, WSRF (this one really would mean a completely new RFC) (Tom Oinn) * _result cleans the result vs a specific _clean (Martin) * session_id (Martin) Also, there has been several (justified) requests for rewrites (unclear sentences, better documented predicate etc) to clarify what is meant. We are working on this. Additional comments coming in answers to your specific emails. So far, many and valuable comments from the community but we want to hear from more people what they think. Kind regards, Johan From Pieter.Neerincx at wur.nl Thu Feb 9 10:28:35 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 9 Feb 2006 16:28:35 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <8FF00FBE-FDB8-4C0E-8333-0A22A1F4D750@wur.nl> On 8-Feb-2006, at 1:36 AM, Martin Senger wrote: >>> [servicename]_submit >>> [servicename]_poll >>> [servicename]_retrieve >>> and maybe also: >>> [servicename]_clean or [servicename]_remove >> Those are nice names, I like them. Anybody else? >> > I don't care (but 'submit' is confusing because even just a sync > invocation is a submit...) I disagree. If you do a sync call you do a _submit and _retrieve in one go. If you specify individual parts of the job execution process, than that is exactly what you get. If you don't specify individual parts you get a "all-in-one" sync call. What do the others think? Pi > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Thu Feb 9 12:00:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 9 Feb 2006 18:00:37 +0100 Subject: [MOBY-dev] RFC #1941: INB Asynchronous Service Call Proposal - sync mode required or not? In-Reply-To: <43EB086E.2050108@ac.uma.es> References: <43EB086E.2050108@ac.uma.es> Message-ID: <338278A6-F198-4953-B40F-EF43B538EC5D@wur.nl> Hi Johan et al., Thanks for the summary. There is one more point I'd like to discuss with you all. The proposal lists that a service provider should always support sync mode. So it's either sync only or sync and async. I have a service for which supporting sync doesn't make any sense. The jobs take way to long for sync mode. I'd rather not waste resources on all the clients that try sync mode first and run into webserver time-outs after a minute or 5. So my question is do we really have to support sync for all services? If the answer to that question is yes, I hereby request an additional error code for the recently adopted error handling RFC to signal that a service can only be invoked in async mode. So if I have to implement sync, I will do it but throw an error by default :). Cheers, Pi From markw at illuminae.com Thu Feb 9 13:13:05 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 09 Feb 2006 10:13:05 -0800 Subject: [MOBY-dev] [moby] RFC #1941: INB Asynchronous Service Call Proposal - sync mode required or not? In-Reply-To: <338278A6-F198-4953-B40F-EF43B538EC5D@wur.nl> References: <43EB086E.2050108@ac.uma.es> <338278A6-F198-4953-B40F-EF43B538EC5D@wur.nl> Message-ID: <1139508785.6165.51.camel@bioinfo.icapture.ubc.ca> I guess this speaks to the issue of whether synch/asynch/both need to be flags registered in the registry, or not. If they were, then clients that didn't report themselves as asynch-enabled could be excluded from discovering services that were asynch only... I'm not advocating one position or another, just suggesting that it could be handled that way. I'm looking forward to seeing the next draft of the RFC proposal where these ideas are more formally synthesized!! M On Thu, 2006-02-09 at 18:00 +0100, Pieter Neerincx wrote: > Hi Johan et al., > > Thanks for the summary. There is one more point I'd like to discuss > with you all. The proposal lists that a service provider should > always support sync mode. So it's either sync only or sync and async. > I have a service for which supporting sync doesn't make any sense. > The jobs take way to long for sync mode. I'd rather not waste > resources on all the clients that try sync mode first and run into > webserver time-outs after a minute or 5. So my question is do we > really have to support sync for all services? If the answer to that > question is yes, I hereby request an additional error code for the > recently adopted error handling RFC to signal that a service can only > be invoked in async mode. So if I have to implement sync, I will do > it but throw an error by default :). > > Cheers, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From johan at ac.uma.es Thu Feb 9 15:10:41 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 09 Feb 2006 21:10:41 +0100 Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43EBA1C1.6000504@ac.uma.es> (Martins first email with comments is a good starting point, I know that there has been discussions after he sent the email and some things have changed, but it is an excellent overview of the "hottest" points.) Martin Senger wrote: > I agree with Mark that it is a good proposal - we desperately need > it. I just hope that more people will join this discussion (please, do > so!). I suggest that we postpone the voting for about two more > weeks. Mainly because some of my comments (see below) would require > more details to be put in the document. And also to allow other people > to jump the board (please, do so!). Yes, this is reasonable. We still have some very fundamental discussions open and we should give time for more people to give comments. > * Data returned by xxx_async and xxx_poll > ----------------------------------------- > > Why does the proposal treat them differently (comparing to normal > Biomoby data)? Why to introduced a new XML element 'mobyStatus' when > we can easily - and keeping many software untouched - send these data > in usual 'mobyData' element? The answers to both your questions are really implied by your first question: The proposal treats them differently because they are very different (not normal Biomoby data). Status information is not Moby data (clearly not biological data or results) and not related to service discovery. It is data about a service execution. But more about "Data returned by xxx_async and xxx_poll" in a separate email (this email is already long enough...). > * Dependency on LSID service metadata > ------------------------------------- > > I do not like it (the RDF predicate indicating that a service can be > asynchronous). Here is why: > > For me, the divider between service data and service metadata was > always that metadata are good but are not crucial for a service > execution. But the flag "this service can be called asynchronously" is > very fundamental flag for a service, and it changes its behaviour and > the behaviour of its clients. Also, it must be known to a registry - > because registry is supposed to generate WSDL with xxx_async and > xxx-poll method included. So register should have it, anyway! > This is an interesting discussion (also referring to later emails about this subject). Three (?) sub-topics: 1) Should the information be in the RDF? The RDF predicate "isAsynchronous" is information about how a service can be used, in the same way as information about a service instance?s input/output parameters, object types etc (just some of the information available as RDF for service instances) . They are all necessary clues of how to call a service (not just good to have but actually needed, although they are _also_ provided in another way as WSDL). Same thing goes for information if a service can be called asynchronously, it is needed and should be in the RDF. We could offer this information both as WSDL and as RDF? 2) Should this information be stored in the registry? Information if a service is asynchronous must be stored by the registry, this we agree on (it was in the proposal). An excellent reason to keep the information in the database of the registry was given by Martin in later emails; basically that the registry can't be expected to check a RDF file (LSID metadata) every time WSDL is generated (even if this information is cached). This information must be in the database, yes, but what is said in the proposal about LSID resolution is not how the registry finds out if a service is asynchronous, it says one way how a client can find out. Also, regarding what Mark asked in his first comments. There is no real value added by doing a search for asynchronous services if that is the only search term (other than for statistical reasons maybe). Simply the fact that the service is asynchronous does not (or at least should not) motivate clients to call it. But the information still belongs in the registry. 3) How does a client tell if a service is async? We agree that the information should be in the information from the Moby Central (retrieveService), but as said above, it should also be possible to get as RDF. So, maybe it is better not to specify how the client tells if the service is async? We need to define places where to put the information but we do not have any control over if a client finds out that a service is asynchronous by reading the WSDL (or the RDF) or by just simply calling xxx_async, hoping that it will work (not saying that this is a good option, but it would be one possible way to do it). We have to consider how to do it, but maybe not specify in the RFC how to do it? Regarding "category": One possible place to put this information would be, as Martin suggested, in the "category"-field. If everyone agrees, then we will add this to the proposal. Right now, the allowed values are "moby", "wsdl" and "cgi"? Does "moby-async" makes it clear that "yes, it is a moby-type service, but it should be called asynchronously"? We need some form of flag, either way. What do others think? > b) "Id unique to each... in a message". No, the Id must be unique to > the whole service provider (at least to the invoked service). If > the unique-ness is just in a message there would be problems when I > invoke the same service several times before the first one > finished. You are completely right, this will be corrected in the RFC document. > c) How many times am I allowed to call xxx_result? I suggest just once > - and any next invocation fails with an exception. This means that > this call also serve as a cleaning call - the service > implementation can clean the session. > This has also been further discussed and the agreement was to allow several calls to _result? As was pointed out also by Robert Buels, results could take a long time to produce and transfer (and it would probably be very annoying for a client to loose the result he/she has been waiting for if the connection is broken during a call to _result because of network errors or whatever). It should be (in principle) possible to call _result as many times as the client wants, but the service providers must be allowed to clean old results after a (service provider-specific) time period. After that time period, calls to _result with the asyncID should return an empty mobyData with a mobyException (saying "result not found"?). However, as Martin pointed out, this probably does not belong in the RFC, it is more an implementation detail (a service provider with large resources might choose to never clean the results, unless specifically asked to do so). Of course, it would also be good to add an explicit xxx_clean method to allow clients that want to say "ok, I will not need this result ever again, you may remove it". Naturally messages to and the behavior of _clean must be documented if there is a consensus that it should be added to the RFC. This possibility has been discussed earlier in INB but we decided not to include it in the RFC to keep the proposal as simple as possible, but there seems to be a need for a clean-method, even if the service provider automatically cleans services (after some time). Actually, we have been thinking about how to provide ways to stop, pause and restart service executions (in similar ways to _async, _poll, etc) but, again, we did not want to complicate discussions. However, while this discussion is important, it would be better if we agreed on the current proposal first. > c) More must be written about exception states: What (if any) > exception to raise when a given session handler is > invalid/expired. There may be other states to document by an > exception code. > Yes, we are adding some example(s) to the proposal, mainly to show how it can be done. It is, however, difficult to list all possible exceptions, anyone with suggestions is welcome to let us know. > I think that this is enough for now. Again, I thank very much INB > for the proposal, and please give us slightly more time to discuss and > make changes. Then we need a new document, and few days to read it > again. Thank you for your comments and suggestions. We are working on a new version, so please stay tuned! Kind regards, Johan From johan at ac.uma.es Thu Feb 9 15:20:46 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 09 Feb 2006 21:20:46 +0100 Subject: [MOBY-dev] RFC #1941: Data returned by xxx_async and xxx_poll Message-ID: <43EBA41E.5010409@ac.uma.es> This is really one of the hot-points. Should we wrap this data in mobyStatus or in mobyData? It really comes down to a question of viewpoints (both ways would be possible to implement). (btw, sorry if we mix the terms "event" and "status" but we are talking about, in this context, the same information (mobyStatus vs Event-base class) Just to summarize what (we think) Martin is suggesting: ===== He suggests that we do not need mobyStatus and instead the status information should be put in normal Moby objects, all registered in the shared Moby object ontology. The methods _async and _poll would return mobyObjects instead of mobyStatus. These mobyObjects would have the same information as is in mobyStatus (asyncID, LSAE status XML etc). The mobyObjects for this would also be ordered in the moby object ontology (placed in a hierarchy, separate subtree). Some comments from Martin: (1) We should change the API/protocol as little as possible (more of a general comment). (2) There could be services that would like to register with such mobyObjects. (3) Service providers could easily register new such mobyObjects and inherit (extend) existing status mobyObjects (all new status objects must inherit the base-object Event). ===== Martin, please correct us if we misunderstood something. Now, let us try to explain our position (which is to keep mobyStatus): We do not want to put such information in mobyObjects because it would mean that we put what is really status (event) information about jobs in the Moby object ontology. It is difficult enough to maintain a good ontology but, at least, let us keep the biomoby ontology for objects related to biological information (results belonging in the domain). This is a very important principle. (1) Martin is correct that our mobyStatus alters the protocol more (the new async clients would need to handle the tag) than putting the information as mobyObjects. However, the only clients and services that would be affected by the alteration (mobyStatus) would be asynchronous clients and services ("new" services/clients, or at least new "interfaces"). Old clients would never receive or send mobyStatus content, so they would not be affected by it. In our opinion, it is better to create new placeholders (mobyStatus) for such new and different information than to put it where it does not belong (the ontology). The protocol would only be altered for this new type of communication, not for the "standard" communication (which would still be available). (2) We have a hard time imagining such services. Martin, could you give some examples? (3) By using "standard" LSAE in our approach (mobyStatus), new events can be extended from existing events (but as we will explain, this should, if possible, be avoided), so the possibility to extend events is not an argument in itself to put this information in the moby object ontology. If the events are placed as mobyObjects in the ontology, new events would be instantly shared by all clients (but of course, the clients would not understand the new, added, attributes unless there are changes in their implementation). Same thing is possible with mobyStatus and LSAE, but the changes would not be "shared", at least not directly. The five basic event types (Heartbeat_event, Percent_progress_event, State_changed_event, Step_progress_event and Time_progress_event) in LSAE covers most (if not all) situations. We are proposing that the only status messages all async clients _must_ understand are the ones specified already in LSAE. If a service provider needs to define new status messages by extending already existing, they run the risk of clients not understanding their new status messages (at all). In the LSAE specification, it even says that clients should simply ignore new status/events that they do not understand. Only specialized clients would in this scenario be able to understand the new status/events (that would come from a very specialized service). If, in the future, there is a need for new "standard" event types, this could be carefully considered (in this mailing list for example) and added to the official documentation/API. While this is a simpler and slower mechanism than what Martin suggests, it is also a more _stable_ mechanism than ordering the events in a dynamic, uncontrolled and shared hierarchy. MobyStatus and LSAE events still do what we need, but in a more stable and controlled way. While mobyStatus would need to be handled by new async clients, it does not complicate future client tooling to have a stable interface, does it? Kind regards, Johan From markw at illuminae.com Thu Feb 9 16:33:19 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 09 Feb 2006 13:33:19 -0800 Subject: [MOBY-dev] [moby] RFC #1941: Data returned by xxx_async and xxx_poll In-Reply-To: <43EBA41E.5010409@ac.uma.es> References: <43EBA41E.5010409@ac.uma.es> Message-ID: <1139520799.8542.18.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-02-09 at 21:20 +0100, Johan Karlsson wrote: > This is really one of the hot-points. Should we wrap this data in > mobyStatus or in mobyData? It really comes down to a question of > viewpoints (both ways would be possible to implement). > > Now, let us try to explain our position (which is to keep mobyStatus): > > We do not want to put such information in mobyObjects because it would > mean that we put what is really status (event) information about jobs in > the Moby object ontology. I would argue that you have simply moved the problem to another level of the system - you are now passing event information in the data payload :-) This is what I liked about Tom's suggestion - after reading about WSRF it seemed to me that the SOAP header would be the appropriate place to pass status information, and that the behaviour of MOBY services from the client perspective would therefore be identical to what it is now. You call XXX_result and you get an empty response; however in the SOAP header, for those clients that can read it, there is a variety of status information. No need for new non-biological object types, no need for new payload tags. I disagree with an earlier comment that this would require a new RFC - I think it is a simplification and improvement on the current RFC, and in fact, it requires less of a change in the existing behaviour than any other suggestion so far (at least as I understand them...) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Thu Feb 9 18:26:59 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 09 Feb 2006 18:26:59 -0500 Subject: [MOBY-dev] problems with retrieveService() in Perl API Message-ID: <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> Hi, Just wondering if anyone has had problems with the Perl API. As you know, I've been having difficulties the last few days. My current roadblock is that, while I can discover services from MOBY Central, I am unable to retrieve the service description (WSDL). I have tried Mark's at iCapture, as well as the one at MIPS, and the symptoms are identical at both. Retrieval fails because the MOBY Central thinks it got an empty message from me, and XML parser *hates* being asked to parse empty messages. Yet, if I insert code immediately preceding the line in which I call the remote MOBY Central, I can verify that I'm *not* sending an empty message. So now I'm wondering whether there could some problem with the transport layer, or possibly with some kind of dependency on a module that no-one is aware of. Has anyone run into this kind of issue before? I don't understand what's going on: I installed a new perl interpreter to deal with some issues I was having parsing XML, and now I can't even get the XML I was having difficulty with! Any ideas would be most welcome. Thanks. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From rmb32 at cornell.edu Thu Feb 9 09:02:49 2006 From: rmb32 at cornell.edu (Robert Buels) Date: Thu, 09 Feb 2006 09:02:49 -0500 Subject: [MOBY-dev] RFC #1941: INB Asynchronous Service Call Proposal - discussion summary (so far) In-Reply-To: <43EB086E.2050108@ac.uma.es> References: <43EB086E.2050108@ac.uma.es> Message-ID: <43EB4B89.8030400@cornell.edu> I agree with Tom Oinn's comment that we should thoroughly consider the way WSRF does things. I don't know anything about it. Johan, what do you and your team think about WSRF? Rob -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32 at cornell.edu http://www.sgn.cornell.edu From senger at ebi.ac.uk Thu Feb 9 19:46:08 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 00:46:08 +0000 (GMT) Subject: [MOBY-dev] [moby] RFC #1941: Data returned by xxx_async and xxx_poll In-Reply-To: <1139520799.8542.18.camel@bioinfo.icapture.ubc.ca> Message-ID: > I disagree with an earlier comment that this would require a new RFC - I > think it is a simplification and improvement on the current RFC, and in > fact, it requires less of a change in the existing behaviour than any > other suggestion so far (at least as I understand them...) > It does not matter how you call it, new RFC or comments to the old one, but you need to tell us what you are suggesting - preferrably in the same level of details as INB did. Otherwise, I am not able to follow your points. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Feb 9 19:51:29 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 00:51:29 +0000 (GMT) Subject: [MOBY-dev] [moby] RFC #1941: INB Asynchronous Service Call Proposal - sync mode required or not? In-Reply-To: <1139508785.6165.51.camel@bioinfo.icapture.ubc.ca> Message-ID: > I guess this speaks to the issue of whether synch/asynch/both need to be > flags registered in the registry, or not. If they were, then clients > that didn't report themselves as asynch-enabled could be excluded from > discovering services that were asynch only... > I thought that "whether synch/asynch/both need to be flags registered in the registry" was sort of already agreed on (actually without having it in registry I would not know how the registry can generate rich enough WSDL). The rest of your message is unclear to me. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 10 01:06:59 2006 From: markw at illuminae.com (mark wilkinson) Date: Fri, 10 Feb 2006 06:06:59 +0000 GMT Subject: [MOBY-dev] Frank's problems Message-ID: <1379816415-1139551722-cardhu_blackberry.rim.net-20105-@engine02-cell01> Hi Frank, Let's maybe try to get in touch by phone tomorrow. I'll put some debugging and soap trace statements into the code on my mobycentral instance on bioinfo.icapture.ubc.ca (same os and codebase as the public registry) and we can play around for a while - maybe we'll be able to figure out what is going wrong... I want to see what is being received at this end to see if I am receiving the same message that you are sending! Hopefully the problem will be obvious... Have you done a trace on your soap messages (add "use SOAP::Lite +trace;" somewhere in your code) to see exactly what is going out on the wire as it leaves your client? I have never seen anything like the bug that you are reporting, so it might help if we are on the phone and I can watch the server error logs etc while you make a call... Bioinfo is quiet - only you and I and one of our special projects students will be using it tomorrow so it will be easier to monitor than the public registry. Let me know what time is good for you, and a number I can call to find you, M -- Mark Wilkinson ...on the road! From markw at illuminae.com Fri Feb 10 01:18:39 2006 From: markw at illuminae.com (mark wilkinson) Date: Fri, 10 Feb 2006 06:18:39 +0000 GMT Subject: [MOBY-dev] Moby dashboard Message-ID: <2126268158-1139552423-cardhu_blackberry.rim.net-27277-@engine12-cell01> Hey Martin! I used Dashboard today for the first time "in anger" (as Michael Ashburner would say). It is absolutely amazing! I registered a couple of namespaces, registered a new service, and edited an existing one - it all worked exactly as advertised :-). There are a few things in the interface that confused me, though - Eddie was hovering over me watching so he knows what bits were not intuitive - would you mind if he went in and modified them himself, or would you prefer that we send you comments that you can use or discard as you see fit? (One example was the label "Set" instead of "Collection" when registering a service that operates on or returns Collection's... I interpreted the label as a verb, rather than an adjective, and found myself saying "Set what... To what?") We won't touch it without your OK :-) M -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Fri Feb 10 01:40:04 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 06:40:04 +0000 (GMT) Subject: [MOBY-dev] Moby dashboard In-Reply-To: <2126268158-1139552423-cardhu_blackberry.rim.net-27277-@engine12-cell01> Message-ID: > There are a few things in the interface that confused me, though - > Eddie was hovering over me watching so he knows what bits were not > intuitive - would you mind if he went in and modified them himself, or > would you prefer that we send you comments that you can use or discard > as you see fit? > I am now intensively working on Dashboard - so it will be a pleasure to implement your suggestions. Very welcome them, indeed. (Which does not mean that I am refusing other people to add/change there things. Vice-versa, I welcome that, too.) > (One example was the label "Set" instead of "Collection" when > registering a service > Done. (Not yet committed, will be later today, when I clean my other code I am working on just now...) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Fri Feb 10 05:57:55 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 10 Feb 2006 11:57:55 +0100 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> References: <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> Message-ID: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> Hi Frank, On 10-Feb-2006, at 12:26 AM, Frank Gibbons wrote: > Hi, > > Just wondering if anyone has had problems with the Perl API. You know I've had one. I kind off found a workaround for the time being, but I do know it's XML parsing related and really hope I won't run into more problems. I'm still suspecting a minor security update for messing up either libxml2, libxslt or something related and as a result XML::LibXML not playing nice anymore. The createDocumentFragment() method used to work for me for over 1.5 years, so something must have changed. I'm on SuSE by the way as well. SLES 9 (i386) with service pack 3 to be precise. XML::LibXML is 1.58. I tried the latest libxml2 2.6.23 and recompiled XML::LibXML for that one, but that gave me the same results. I currently running on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 today... If you reinstalled Perl, did you also reinstall SOAP::Lite? If yes which version? In case it's 0.60+ you might have an "anyURI" problem. I you have a snipped of code that produces the problem, I could run it in my setup to see if I can reproduce the problem. Pi > As you know, > I've been having difficulties the last few days. My current > roadblock is > that, while I can discover services from MOBY Central, I am unable to > retrieve the service description (WSDL). I have tried Mark's at > iCapture, > as well as the one at MIPS, and the symptoms are identical at both. > > Retrieval fails because the MOBY Central thinks it got an empty > message > from me, and XML parser *hates* being asked to parse empty > messages. Yet, > if I insert code immediately preceding the line in which I call the > remote > MOBY Central, I can verify that I'm *not* sending an empty message. > > So now I'm wondering whether there could some problem with the > transport > layer, or possibly with some kind of dependency on a module that no- > one is > aware of. Has anyone run into this kind of issue before? I don't > understand > what's going on: I installed a new perl interpreter to deal with some > issues I was having parsing XML, and now I can't even get the XML I > was > having difficulty with! Any ideas would be most welcome. > > Thanks. > > -Frank > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From francis_gibbons at hms.harvard.edu Fri Feb 10 09:29:33 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 09:29:33 -0500 Subject: [MOBY-dev] Frank's problems In-Reply-To: <1379816415-1139551722-cardhu_blackberry.rim.net-20105-@eng ine02-cell01> Message-ID: <5.2.1.1.2.20060210092639.022efe20@email.med.harvard.edu> Hey Mark, I was just thinking about turning on the SOAP::Lite trace facility. I have a meeting at 4pm eastern time, but am otherwise free, so if it's all the same to you, maybe we could talk around 2pm - hopefully that'll give us time to track things down. If that time doesn't work for you, suggest another - I'm free most of the day. My number is 617-432-3555. It's a shared line, so ask for me, if I don't pick up. Thanks, -Frank At 01:06 AM 2/10/2006, you wrote: >Hi Frank, > >Let's maybe try to get in touch by phone tomorrow. I'll put some >debugging and soap trace statements into the code on my mobycentral >instance on bioinfo.icapture.ubc.ca (same os and codebase as the public >registry) and we can play around for a while - maybe we'll be able to >figure out what is going wrong... I want to see what is being received at >this end to see if I am receiving the same message that you are >sending! Hopefully the problem will be obvious... > >Have you done a trace on your soap messages (add "use SOAP::Lite +trace;" >somewhere in your code) to see exactly what is going out on the wire as it >leaves your client? I have never seen anything like the bug that you are >reporting, so it might help if we are on the phone and I can watch the >server error logs etc while you make a call... Bioinfo is quiet - only you >and I and one of our special projects students will be using it tomorrow >so it will be easier to monitor than the public registry. > >Let me know what time is good for you, and a number I can call to find you, > >M > > >-- >Mark Wilkinson >...on the road! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From gordonp at ucalgary.ca Fri Feb 10 09:54:08 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 10 Feb 2006 07:54:08 -0700 Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: <43E0DF34.7070300@ac.uma.es> References: <43E0DF34.7070300@ac.uma.es> Message-ID: <43ECA910.30304@ucalgary.ca> From francis_gibbons at hms.harvard.edu Fri Feb 10 09:56:06 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 09:56:06 -0500 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> References: <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060210095209.0110b210@email.med.harvard.edu> At 05:57 AM 2/10/2006, you wrote: >for that one, but that gave me the same results. I currently running >on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 >today... If you reinstalled Perl, did you also reinstall SOAP::Lite? >If yes which version? In case it's 0.60+ you might have an "anyURI" >problem. Yes, when I re-installed the interpreter (built from source 5.8.6), I reinstalled all of the modules too, from CPAN. I have SOAP::Lite version 0.67 installed. What is the "anyURI" problem you mention? Thanks for the response, Pieter. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Fri Feb 10 10:34:19 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 15:34:19 +0000 (GMT) Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: <43ECA910.30304@ucalgary.ca> Message-ID: If this error would be the only missing link/feature in the Biomoby doc, I would shut up... But I must admit that Mark's previous documentation (API in one long page) was not that great but much better. Proof? If I need to look at it I am still using my local copy of his page because the new pages simply are not linked together. BTW, the checkbot on the page ttp://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/index_API.html reports 26 missing links (from 58; ratio 44%). Could somebody remind me who has access to the pages - is it possible to correct it in a CVS? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Fri Feb 10 10:36:38 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 10:36:38 -0500 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: <5.2.1.1.2.20060210095209.0110b210@email.med.harvard.edu> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> OK, so there is a problem with SOAP::Lite 0.67. I downgraded my installation to 0.60 (which by the way, is reported here (http://soaplite.com/download.html) as being the recommended stable release, and now at least I can retrieveService details sufficiently to build a service instance. If upgraded back to 0.67, and the problem re-appears, so I'm downgrading to 0.60, where I will stay. However, as I discovered, when a user simply installs SOAP::Lite from CPAN, they may get quite a different version than 0.60 (I got 0.67), in which case, the message gets sent out correctly on the wire, but is perceived as empty by MOBY Central. I don't know much about the details of packaging SOAP requests, and you can read the gory details below for yourselves, but it appears that SOAP::Lite 0.60 and SOAP::Lite 0.67 do not understand each other. The clue was given by the User-Agent and SOAPServer lines, showing that my request was sent using SOAP::Lite/Perl/0.67, and the error message sent in response was generated by SOAP::Lite/Perl/0.60 So, mystery solved. I'll put a check for SOAP::Lite's version, and a warning for this into the Makefile, until we can figure out what the real solution to this problem is. Thanks to Mark & Pieter for their help and suggestions. -Frank ================================== SOAP::Lite +trace output ============================ SOAP::Transport::HTTP::Client::send_receive: POST http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl HTTP/1.1 Accept: text/xml Accept: multipart/* Accept: application/soap User-Agent: SOAP::Lite/Perl/0.67 Content-Length: 1539 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://mips.gsf.de/MOBY/Central#retrieveService" Retrieval 1 moby paulien.adamse at wur.nl http://www.watdb.nl/moby-live/cgi-bin/MOBY/Services/Watdb_mobyservices.py Object PO_acc Object WAtDB_id SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x8906a8c) SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error Connection: close Date: Fri, 10 Feb 2006 15:31:05 GMT Server: Apache Content-Length: 559 Content-Type: text/xml; charset=utf-8 Client-Date: Fri, 10 Feb 2006 15:29:58 GMT Client-Peer: 146.107.217.142:80 Client-Response-Num: 1 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:ServerEmpty String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 SOAP::Deserializer::deserialize: () SOAP::Parser::decode: () SOAP::SOM::new: () SOAP::SOM::DESTROY: () Connection to MOBY Central at URI 'http://mips.gsf.de/MOBY/Central' died because: SOAP-ENV:Server : Empty String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 ERROR ERROR ERROR At 09:56 AM 2/10/2006, you wrote: >At 05:57 AM 2/10/2006, you wrote: > >for that one, but that gave me the same results. I currently running > >on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 > >today... If you reinstalled Perl, did you also reinstall SOAP::Lite? > >If yes which version? In case it's 0.60+ you might have an "anyURI" > >problem. > >Yes, when I re-installed the interpreter (built from source 5.8.6), I >reinstalled all of the modules too, from CPAN. I have SOAP::Lite version >0.67 installed. What is the "anyURI" problem you mention? > >Thanks for the response, Pieter. > >-Frank > > >PhD, Computational Biologist, >Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. >Tel: 617-432-3555 Fax: >617-432-3557 http://llama.med.harvard.edu/~fgibbons > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Fri Feb 10 10:57:38 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 10:57:38 -0500 Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: References: <43ECA910.30304@ucalgary.ca> Message-ID: <5.2.1.1.2.20060210104000.011f12d8@email.med.harvard.edu> Martin, At 10:34 AM 2/10/2006, you wrote: >If this error would be the only missing link/feature in the Biomoby doc, I >would shut up... But I must admit that Mark's previous documentation (API >in one long page) was not that great but much better. Proof? If I need to >look at it I am still using my local copy of his page because the new >pages simply are not linked together. I'm not sure what you mean - the pages of the API are linked, at least to the extent that the older single-page document was linked. In addition, there's a table of contents on the right-hand side of each page, so you don't have to back-track to find what you need. I think this version makes it easier to see what is known, but I'm open to the idea that it might not work for everyone. Certainly, if you're looking for something to print out, then having one long page is better. >BTW, the checkbot on the page >ttp://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/index_API.html >reports 26 missing links (from 58; ratio 44%). I wasn't familiar with checkbot, but found its homepage from google. Unfortunately, checkbot's homepage is down (the irony is killing me ;-D. Could you send a list of the broken links, Martin? I'll be happy to fix them. >Could somebody remind me who has access to the pages - is it possible to >correct it in a CVS? As far as possible, it is all under CVS. Only the front page, and the pages linked to from the bar at the top, are not under CVS. I think the entire website's contents should be under CVS, so that any one of us could set up a complete mirror site. Basically, whatever is shown on the website as having an URL containing CVS_CONTENT is accessible in CVS. The website is updated from CVS every few hours. I encourage every developer to get in there, and add links to things as they see fit. The docs you check out under CVS also link to the biomoby.org website, where possible, so you can start at your local docs, but surf to biomoby.org seamlessly. As for the search function, I pointed out that it was broken about a month ago. Does anyone know if it ever worked? In other words, is it simply a case of some pointers being broken, and if we reset them, everything will work again? Or, if it never worked in the first place, is it more of a black-box, where we don't know what's wrong, or how long it might take to fix? Just as much as the code, perhaps even more so since much of it is language-independent, the documentation should be the work of all developers. I know that few people particularly enjoy writing docs, and certainly there are no kudos for doing it, compared to writing code. To my mind, having a single long page of almost plain text is not a particularly easy way for a newbie to get to learn how MOBY works. That's more who I felt we should be aiming for - put it all out there, make it as easy to find as possible. But you know, perhaps we need both, I'm open to that. We could have a rule in the makefile/build.xml to paste all the pages together into a single document for people who prefer to navigate MOBY like that. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Fri Feb 10 11:04:43 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 16:04:43 +0000 (GMT) Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: <5.2.1.1.2.20060210104000.011f12d8@email.med.harvard.edu> Message-ID: > I'm not sure what you mean - > For example, try to click on 'Primary articles' link in page http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/SecondaryArticle.html and you will get: The requested URL /CVS_CONTENT/moby-live/Docs/MOBY-S_API/PrimaryMessage.html was not found on this server. > Certainly, if you're looking for something to print out, then having > one long page is better. > I like the new design. I simply only complain that there are many broken links. > I wasn't familiar with checkbot, but found its homepage from google. > Unfortunately, checkbot's homepage is down > I took from here: http://public.planetmirror.com/pub/checkbot/checkbot-1.77.tar.gz > Could you send a list of the broken links, Martin? > See below. Thanks for fixin it. Cheers, Martin 404 Not Found http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/CentralRegistry.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ConstructYourService.html http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/DataClassOntology.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/ObjectValue http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/InputMessage.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Secondarymessage.html http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ConstructingYourService.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/Articles.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/CentralRegistry.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/DataClassOntology.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/Examples.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ExceptionCodes.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ExceptionReporting.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/InformationBlocks.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/InputMessage.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/InstallingLocalMOBYCentral.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/MessageStructure.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/MobyCentralObjects.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ObjectStructure.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ObsoleteExceptionMechanism.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/OntologyExamples.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/OutputMessage.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/PrimaryArticle.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/RFC.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/SecondaryArticle.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/XMLPayloads.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/index_API.html http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/DesignAnObject.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/MobyNamespace * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ObjectOntology http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/SecondaryArticle.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/PrimaryMessage.html -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 10 11:29:24 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 08:29:24 -0800 Subject: [MOBY-dev] [personal] Re: [moby] RFC #1941: INB Asynchronous Service Call Proposal - sync mode required or not? In-Reply-To: References: Message-ID: <1139588964.12961.10.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 00:51 +0000, Martin Senger wrote: > I thought that "whether synch/asynch/both need to be flags registered > in the registry" was sort of already agreed on (actually without having it > in registry I would not know how the registry can generate rich enough > WSDL). I agree entirely. The alternative would be for the registry to resolve the LSID and figure it out that way; however I think it should be in the registry. I just don't want to presume to tell the authors of the RFC what they are proposing, before they have had a chance to tell us what they are proposing, in their next draft. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Fri Feb 10 11:33:34 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 08:33:34 -0800 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: <1139589214.12961.13.camel@bioinfo.icapture.ubc.ca> Does that mean we don't need a phone call today? M On Fri, 2006-02-10 at 10:36 -0500, Frank Gibbons wrote: > OK, so there is a problem with SOAP::Lite 0.67. I downgraded my > installation to 0.60 (which by the way, is reported here > (http://soaplite.com/download.html) as being the recommended stable > release, and now at least I can retrieveService details sufficiently to > build a service instance. If upgraded back to 0.67, and the problem > re-appears, so I'm downgrading to 0.60, where I will stay. > > However, as I discovered, when a user simply installs SOAP::Lite from CPAN, > they may get quite a different version than 0.60 (I got 0.67), in which > case, the message gets sent out correctly on the wire, but is perceived as > empty by MOBY Central. I don't know much about the details of packaging > SOAP requests, and you can read the gory details below for yourselves, but > it appears that SOAP::Lite 0.60 and SOAP::Lite 0.67 do not understand each > other. The clue was given by the User-Agent and SOAPServer lines, showing > that my request was sent using SOAP::Lite/Perl/0.67, and the error message > sent in response was generated by SOAP::Lite/Perl/0.60 > > So, mystery solved. I'll put a check for SOAP::Lite's version, and a > warning for this into the Makefile, until we can figure out what the real > solution to this problem is. > > Thanks to Mark & Pieter for their help and suggestions. > > -Frank > ================================== SOAP::Lite +trace output > ============================ > > SOAP::Transport::HTTP::Client::send_receive: POST > http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl HTTP/1.1 > Accept: text/xml > Accept: multipart/* > Accept: application/soap > User-Agent: SOAP::Lite/Perl/0.67 > Content-Length: 1539 > Content-Type: text/xml; charset=utf-8 > SOAPAction: "http://mips.gsf.de/MOBY/Central#retrieveService" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> xmlns="http://mips.gsf.de/MOBY/Central"> > > lsid="urn:lsid:biomoby.org:serviceinstance:www.watdb.nl,getWAtDBIdByPOAcc"> > Retrieval > 1 > moby > a certain PO accession number]]> > paulien.adamse at wur.nl > > http://www.watdb.nl/moby-live/cgi-bin/MOBY/Services/Watdb_mobyservices.py > > > lsid="urn:lsid:biomoby.org:objectclass:Object">Object > lsid="urn:lsid:biomoby.org:namespacetype:PO_acc">PO_acc > > > > > lsid="urn:lsid:biomoby.org:objectclass:Object">Object > lsid="urn:lsid:biomoby.org:namespacetype:WAtDB_id">WAtDB_id > > > > > > > SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x8906a8c) > SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error > Connection: close > Date: Fri, 10 Feb 2006 15:31:05 GMT > Server: Apache > Content-Length: 559 > Content-Type: text/xml; charset=utf-8 > Client-Date: Fri, 10 Feb 2006 15:29:58 GMT > Client-Peer: 146.107.217.142:80 > Client-Response-Num: 1 > SOAPServer: SOAP::Lite/Perl/0.60 > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">SOAP-ENV:ServerEmpty > String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 > > SOAP::Deserializer::deserialize: () > SOAP::Parser::decode: () > SOAP::SOM::new: () > SOAP::SOM::DESTROY: () > > Connection to MOBY Central at URI 'http://mips.gsf.de/MOBY/Central' died > because: > SOAP-ENV:Server : Empty String at > /home/users/plant/lib/perl/MOBY/Central.pm line 2457 > > ERROR ERROR ERROR > > > > At 09:56 AM 2/10/2006, you wrote: > >At 05:57 AM 2/10/2006, you wrote: > > >for that one, but that gave me the same results. I currently running > > >on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 > > >today... If you reinstalled Perl, did you also reinstall SOAP::Lite? > > >If yes which version? In case it's 0.60+ you might have an "anyURI" > > >problem. > > > >Yes, when I re-installed the interpreter (built from source 5.8.6), I > >reinstalled all of the modules too, from CPAN. I have SOAP::Lite version > >0.67 installed. What is the "anyURI" problem you mention? > > > >Thanks for the response, Pieter. > > > >-Frank > > > > > >PhD, Computational Biologist, > >Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > >Tel: 617-432-3555 Fax: > >617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Fri Feb 10 11:35:39 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 08:35:39 -0800 Subject: [MOBY-dev] [moby] Re: FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: <5.2.1.1.2.20060210104000.011f12d8@email.med.harvard.edu> References: <43ECA910.30304@ucalgary.ca> <5.2.1.1.2.20060210104000.011f12d8@email.med.harvard.edu> Message-ID: <1139589339.12961.16.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 10:57 -0500, Frank Gibbons wrote: > As for the search function, I pointed out that it was broken about a month > ago. Does anyone know if it ever worked? In other words, is it simply a > case of some pointers being broken, and if we reset them, everything will > work again? Or, if it never worked in the first place, is it more of a > black-box, where we don't know what's wrong, or how long it might take to fix? AFAIK it never worked. It's a bit of PHP script that I looked at for a while, couldn't make immediate sense of, and left on my "future TODO list" for a day when I didn't have a dozen other things to do. -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From dgpisano at cnb.uam.es Fri Feb 10 12:01:41 2006 From: dgpisano at cnb.uam.es (David Gonzalez Pisano) Date: Fri, 10 Feb 2006 18:01:41 +0100 Subject: [MOBY-dev] [personal] Re: [moby] RFC #1941: INBAsynchronous Service Call Proposal - sync mode required or not? In-Reply-To: <1139588964.12961.10.camel@bioinfo.icapture.ubc.ca> References: <1139588964.12961.10.camel@bioinfo.icapture.ubc.ca> Message-ID: <43ECC6F5.6000006@cnb.uam.es> Mark Wilkinson escribi?: > On Fri, 2006-02-10 at 00:51 +0000, Martin Senger wrote: > > >> I thought that "whether synch/asynch/both need to be flags registered >> in the registry" was sort of already agreed on (actually without having it >> in registry I would not know how the registry can generate rich enough >> WSDL). >> > > I agree entirely. The alternative would be for the registry to resolve > the LSID and figure it out that way; however I think it should be in the > registry. I just don't want to presume to tell the authors of the RFC > what they are proposing, before they have had a chance to tell us what > they are proposing, in their next draft. > > M > > > > Well, in fact something could be missed in the proposal we sent, but the philosophy we had in mind was always to extend the registerService API call to include the "sync" flag and store it in registry. Between other benefits, that would allow the client to know whether the service can run in asynchrous mode, at service discovery time. We'll write it more clearly in the next iteration of the proposal. David From Pieter.Neerincx at wur.nl Fri Feb 10 12:03:10 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 10 Feb 2006 18:03:10 +0100 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: On 10-Feb-2006, at 4:36 PM, Frank Gibbons wrote: > OK, so there is a problem with SOAP::Lite 0.67. I downgraded my > installation to 0.60 (which by the way, is reported here > (http://soaplite.com/download.html) as being the recommended stable > release, and now at least I can retrieveService details > sufficiently to > build a service instance. If upgraded back to 0.67, and the problem > re-appears, so I'm downgrading to 0.60, where I will stay. > However, as I discovered, when a user simply installs SOAP::Lite > from CPAN, > they may get quite a different version than 0.60 (I got 0.67), in > which > case, the message gets sent out correctly on the wire, but is > perceived as > empty by MOBY Central. Ok, still have to test 0.67, but 0.66 definitely had some problems. However we can not cling onto 0.60 forever. especially now that 0.67 is up at CPAN and that is what new Perlisch Mobifiers will get when they try MOBY out. So either we have to adapt or S::L has to be patched or both. I posted the "anyURI" problem at the S::L list and so far haven't had any feedback :(. I'll test 0.67 this weekend and repost. If S::L is not fixed fast enough I'll make a list of the small patches you'll need to make BioMOBY work with the latest "stable" S::L. Is your XML parsing problem now fixed by the installation of the new Perl interpreter or is that one still pending a fix? > I don't know much about the details of packaging > SOAP requests, and you can read the gory details below for > yourselves, but > it appears that SOAP::Lite 0.60 and SOAP::Lite 0.67 do not > understand each > other. The clue was given by the User-Agent and SOAPServer lines, > showing > that my request was sent using SOAP::Lite/Perl/0.67, and the error > message > sent in response was generated by SOAP::Lite/Perl/0.60 > > So, mystery solved. I'll put a check for SOAP::Lite's version, and a > warning for this into the Makefile, until we can figure out what > the real > solution to this problem is. > > Thanks to Mark & Pieter for their help and suggestions. > > -Frank > ================================== SOAP::Lite +trace output > ============================ > > SOAP::Transport::HTTP::Client::send_receive: POST > http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl HTTP/1.1 > Accept: text/xml > Accept: multipart/* > Accept: application/soap > User-Agent: SOAP::Lite/Perl/0.67 > Content-Length: 1539 > Content-Type: text/xml; charset=utf-8 > SOAPAction: "http://mips.gsf.de/MOBY/Central#retrieveService" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:soap="http://schemas.xmlsoap.org/soap/ > envelope/"> xmlns="http://mips.gsf.de/MOBY/Central"> xsi:type="xsd:anyURI"> > > serviceName="getWAtDBIdByPOAcc" > lsid="urn:lsid:biomoby.org:serviceinstance:www.watdb.nl,getWAtDBIdByPO > Acc"> > Retrieval > 1 > moby > ids with > a certain PO accession number]]> > paulien.adamse at wur.nl > > http://www.watdb.nl/moby-live/cgi-bin/MOBY/Services/ > Watdb_mobyservices.py > > > lsid="urn:lsid:biomoby.org:objectclass:Object">Object > lsid="urn:lsid:biomoby.org:namespacetype:PO_acc">PO_acc > > > > > lsid="urn:lsid:biomoby.org:objectclass:Object">Object > lsid="urn:lsid:biomoby.org:namespacetype:WAtDB_id">WAtDB_id Namespace> > > > > > > soap:Body> > SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH > (0x8906a8c) > SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal > Server Error > Connection: close > Date: Fri, 10 Feb 2006 15:31:05 GMT > Server: Apache > Content-Length: 559 > Content-Type: text/xml; charset=utf-8 > Client-Date: Fri, 10 Feb 2006 15:29:58 GMT > Client-Peer: 146.107.217.142:80 > Client-Response-Num: 1 > SOAPServer: SOAP::Lite/Perl/0.60 > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/ > encoding/">SOAP- > ENV:ServerEmpty > String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 > > SOAP::Deserializer::deserialize: () > SOAP::Parser::decode: () > SOAP::SOM::new: () > SOAP::SOM::DESTROY: () > > Connection to MOBY Central at URI 'http://mips.gsf.de/MOBY/Central' > died > because: > SOAP-ENV:Server : Empty String at > /home/users/plant/lib/perl/MOBY/Central.pm line 2457 > > ERROR ERROR ERROR > > > > At 09:56 AM 2/10/2006, you wrote: >> At 05:57 AM 2/10/2006, you wrote: >>> for that one, but that gave me the same results. I currently running >>> on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 >>> today... If you reinstalled Perl, did you also reinstall SOAP::Lite? >>> If yes which version? In case it's 0.60+ you might have an "anyURI" >>> problem. >> >> Yes, when I re-installed the interpreter (built from source 5.8.6), I >> reinstalled all of the modules too, from CPAN. I have SOAP::Lite >> version >> 0.67 installed. What is the "anyURI" problem you mention? >> >> Thanks for the response, Pieter. >> >> -Frank >> >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: >> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Feb 10 12:07:49 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 09:07:49 -0800 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: <1139591269.12961.32.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > I'll test 0.67 this weekend and > repost. If S::L is not fixed fast enough I'll make a list of the > small patches you'll need to make BioMOBY work with the latest > "stable" S::L. Do you know if the MOBY patches are backwards-compatible with S::L .60? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Fri Feb 10 12:11:26 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 09:11:26 -0800 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: <1139591486.12961.36.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > I posted the "anyURI" problem at the S::L list and > so far haven't had any feedback :( That problem surely must be a bug in S::L - just because the content *contains* a URI, doesn't mean that it *is* a URI! What confuses me is why S::L is making this choice given that we are now explicitly telling it in the WSDL that the body is *not* a URI but rather a block of XML...?? Maybe S::L doesn't really read the WSDL properly at all?? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Fri Feb 10 12:19:57 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 12:19:57 -0500 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: <1139591486.12961.36.camel@bioinfo.icapture.ubc.ca> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060210121638.011e0fa0@email.med.harvard.edu> At 12:11 PM 2/10/2006, you wrote: >On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > > > I posted the "anyURI" problem at the S::L list and > > so far haven't had any feedback :( > >That problem surely must be a bug in S::L - just because the content >*contains* a URI, doesn't mean that it *is* a URI! > >What confuses me is why S::L is making this choice given that we are now >explicitly telling it in the WSDL that the body is *not* a URI but >rather a block of XML...?? Maybe S::L doesn't really read the WSDL >properly at all?? Well, if you take a look at the structure of the SOAP messages, you can see that 0.67 is using a 2001 schema, while 0.60 is still using a 1999 schema. This means that almost all tags in the SOAP message are completely difference, even the most basic ones. Of course, there are additional ones too, but to me it seems most likely that the older SOAP is looking for high-level tags, which are no longer provided by S::L 0.67, and therefore it thinks that the entire message is empty. I could be wrong (it's happened once or twice before ;-), but my sense is that my problem at least (and that of any new MOBY users who happen along) is not necessarily at the level of "anyURL", WSDL, or some other feature. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Fri Feb 10 12:25:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 10 Feb 2006 18:25:37 +0100 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: <1139591269.12961.32.camel@bioinfo.icapture.ubc.ca> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> <1139591269.12961.32.camel@bioinfo.icapture.ubc.ca> Message-ID: On 10-Feb-2006, at 6:07 PM, Mark Wilkinson wrote: > On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > >> I'll test 0.67 this weekend and >> repost. If S::L is not fixed fast enough I'll make a list of the >> small patches you'll need to make BioMOBY work with the latest >> "stable" S::L. > > Do you know if the MOBY patches are backwards-compatible with S::L . > 60? So far I have only tested client S::L version X with local BioMOBY Central same version X, but before suggesting patches on the BioMOBY side I'll test mixed version as well. What I can not test is the Java and Python stuff. But if a patched client S::L 0.67 with patched client ~Perl/MOBY works fine with the official Central we can leave that one for some more time to come on S::L 0.60... I'll report back on monday... Pi > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Feb 10 12:32:38 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 09:32:38 -0800 Subject: [MOBY-dev] the Search function on biomoby.org Message-ID: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> I take that back - it does work! However, it only searches through what has been "blogged", not through the full content of the site (i.e. it excludes what is in the CVS_CONTENT folder) I don't know how easy it would be to modify this behaviour, as the search utility is part of Wordpress... M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Fri Feb 10 12:31:47 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 10 Feb 2006 18:31:47 +0100 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: <1139591486.12961.36.camel@bioinfo.icapture.ubc.ca> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> <1139591486.12961.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <95689DA5-537A-4FA5-9D10-DC39854FB4EF@wur.nl> On 10-Feb-2006, at 6:11 PM, Mark Wilkinson wrote: > On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > >> I posted the "anyURI" problem at the S::L list and >> so far haven't had any feedback :( > > That problem surely must be a bug in S::L - just because the content > *contains* a URI, doesn't mean that it *is* a URI! I know, I'll check if it's still there in 0.67 or whether Franks' second problem was yet another new bug. > What confuses me is why S::L is making this choice given that we > are now > explicitly telling it in the WSDL that the body is *not* a URI but > rather a block of XML...?? Maybe S::L doesn't really read the WSDL > properly at all?? In 0.66 it simply does a regexp on the entire message and if it finds 'http://' *anywhere* in the XML it puts that *&#!@ anyURI label on the payload, which is not serialised client-side. Have a nice weekend, Pi > > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Feb 10 12:56:50 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 09:56:50 -0800 Subject: [MOBY-dev] [moby] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <1138906906.7790.95.camel@bioinfo.icapture.ubc.ca> References: <43E0DF34.7070300@ac.uma.es> <1138906906.7790.95.camel@bioinfo.icapture.ubc.ca> Message-ID: <1139594210.12961.64.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-02-02 at 11:01 -0800, Mark Wilkinson wrote: > 3) Let's define the new predicate as follows v.v. the RDF for Service > Instances: > mobyPred:isAsynchronous > Domain: mygrid:operation > Range: xsd:boolean > Definition: a boolean indication of the service providers ability to > provide the associated operation in asynchronous, as well as > synchronous, mode, according to the specification for asynchronous Moby > service calls in the Moby API. I'd like to modify my suggestion above. I think we may want to have one more "layer" between the operation metadata and the synchronous/asyncronous tag, in the form of a "hasCallingDetail" parameter, where one of the properties of a callingDetail includes whether it is synchronous, asynchronous, or both. This also changes it from having a range of xsd:boolean to being a controlled vocabulary (I propose "synchronous", "asynchronous", "sych_asych") An example as N3: a :operation; :hasCallingDetail [ a :callingDetail; :hasSynchType moby:asynchronous ]; an example as RDF: This is somewhat tangential to the discussion, but since your RFC talked about adding this information into the Service Instance metadata, it is ~relevant to the discussion. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From edward.kawas at gmail.com Fri Feb 10 13:05:10 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 10 Feb 2006 10:05:10 -0800 Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: Message-ID: <000701c62e6c$8935fc00$6500a8c0@notebook> > Could somebody remind me who has access to the pages - is it > possible to correct it in a CVS? You can get/modify the documentation from the cvs, under moby-live/Docs Eddie From senger at ebi.ac.uk Fri Feb 10 13:10:19 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 18:10:19 +0000 (GMT) Subject: [MOBY-dev] [moby] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <1139594210.12961.64.camel@bioinfo.icapture.ubc.ca> Message-ID: > I'd like to modify my suggestion above.... > I am confused. Why are you talking now about RDF predicates when in your last email you said that you probably would agree to have this flag in registry? Or does your last sentence (below) answer my question above? > This is somewhat tangential to the discussion, but since your RFC talked > about adding this information into the Service Instance metadata, it is > ~relevant to the discussion. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 10 13:16:00 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 10:16:00 -0800 Subject: [MOBY-dev] [personal] Re: [moby] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <1139595360.12961.67.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 18:10 +0000, Martin Senger wrote: > I am confused. Why are you talking now about RDF predicates when in > your last email you said that you probably would agree to have this flag > in registry? > Or does your last sentence (below) answer my question above? It clearly needs to be in both places. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Feb 10 13:17:36 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 18:17:36 +0000 (GMT) Subject: [MOBY-dev] [personal] Re: [moby] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <1139595360.12961.67.camel@bioinfo.icapture.ubc.ca> Message-ID: > It clearly needs to be in both places. > Good. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 10 13:44:05 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 10:44:05 -0800 Subject: [MOBY-dev] [moby] Re: the Search function on biomoby.org In-Reply-To: References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <1139597045.12961.73.camel@bioinfo.icapture.ubc.ca> Excellent! Thanks Simon M On Fri, 2006-02-10 at 12:43 -0600, Twigger Simon wrote: > Hi Mark, > > I might have missed the first part of this but it should be possible > to add in functionality to search static pages too - I did this via a > plug-in for one of my own wordpress installations. Im not sure where > the CVS_CONTENT folder is in relation to the wordpress file hierarchy > but I'll log in and see if I installed the plugin on the MOBY site > and if not, I'll add it in and we'll see what happens... > > Simon. > > > -- > > Simon N. Twigger, Ph.D. > Assistant Professor, Department of Physiology > Medical College of Wisconsin > 8701 Watertown Plank Road, > Milwaukee, WI, USA > tel: 414-456-8802 > fax: 414-456-6595 > AIM/iChat: simontatmcw > > > On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: > > > I take that back - it does work! However, it only searches through > > what > > has been "blogged", not through the full content of the site (i.e. it > > excludes what is in the CVS_CONTENT folder) > > > > I don't know how easy it would be to modify this behaviour, as the > > search utility is part of Wordpress... > > > > M > > > > > > -- > > -- > > ...his last words were 'Hey guys! Watch this!' > > -- > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > "For most of this century we have viewed communications as a conduit, > > a pipe between physical locations on the planet. > > What's happened now is that the conduit has become so big and > > interesting > > that communication has become more than a conduit, > > it has become a destination in its own right..." > > > > Paul Saffo - Director, Institute for the Future > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From simont at hmgc.mcw.edu Fri Feb 10 13:43:05 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Fri, 10 Feb 2006 12:43:05 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, I might have missed the first part of this but it should be possible to add in functionality to search static pages too - I did this via a plug-in for one of my own wordpress installations. Im not sure where the CVS_CONTENT folder is in relation to the wordpress file hierarchy but I'll log in and see if I installed the plugin on the MOBY site and if not, I'll add it in and we'll see what happens... Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: > I take that back - it does work! However, it only searches through > what > has been "blogged", not through the full content of the site (i.e. it > excludes what is in the CVS_CONTENT folder) > > I don't know how easy it would be to modify this behaviour, as the > search utility is part of Wordpress... > > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From francis_gibbons at hms.harvard.edu Fri Feb 10 14:30:57 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 14:30:57 -0500 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> Simon, That's a big improvement on what we had before. Can we tweak the style a little though? If I search for "constructing", I get a single result, which looks like plain text. It's not until I mouse over the heading "BioMoby Perl Service Providers Tutorial" that I realise it's a link. That's becuase it's just big bold black text. Is there some way to format the results, so that the heading comes out as something that's more obviously a link? (Color being the usual indicator for a link, my vote would be that it follow the style of the other links on the page.) Great work, -Frank At 01:43 PM 2/10/2006, you wrote: >Hi Mark, > >I might have missed the first part of this but it should be possible >to add in functionality to search static pages too - I did this via a >plug-in for one of my own wordpress installations. Im not sure where >the CVS_CONTENT folder is in relation to the wordpress file hierarchy >but I'll log in and see if I installed the plugin on the MOBY site >and if not, I'll add it in and we'll see what happens... > >Simon. > > >-- > >Simon N. Twigger, Ph.D. >Assistant Professor, Department of Physiology >Medical College of Wisconsin >8701 Watertown Plank Road, >Milwaukee, WI, USA >tel: 414-456-8802 >fax: 414-456-6595 >AIM/iChat: simontatmcw > > >On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: > > > I take that back - it does work! However, it only searches through > > what > > has been "blogged", not through the full content of the site (i.e. it > > excludes what is in the CVS_CONTENT folder) > > > > I don't know how easy it would be to modify this behaviour, as the > > search utility is part of Wordpress... > > > > M > > > > > > -- > > -- > > ...his last words were 'Hey guys! Watch this!' > > -- > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > "For most of this century we have viewed communications as a conduit, > > a pipe between physical locations on the planet. > > What's happened now is that the conduit has become so big and > > interesting > > that communication has become more than a conduit, > > it has become a destination in its own right..." > > > > Paul Saffo - Director, Institute for the Future > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Fri Feb 10 14:32:51 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 14:32:51 -0500 Subject: [MOBY-dev] [moby] Re: the Search function on biomoby.org In-Reply-To: <1139597045.12961.73.camel@bioinfo.icapture.ubc.ca> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <5.2.1.1.2.20060210143122.0121e180@email.med.harvard.edu> Mark, Search for "installation", and you come up with both old and new instructions. It's not clear that the old ones are, in fact, OLD. Since the old installation instructions are not under CVS, would you mind editing them to say that, and putting a link in to the newer instructions. Thanks, -Frank At 01:44 PM 2/10/2006, you wrote: >Excellent! Thanks Simon > >M > >On Fri, 2006-02-10 at 12:43 -0600, Twigger Simon wrote: > > Hi Mark, > > > > I might have missed the first part of this but it should be possible > > to add in functionality to search static pages too - I did this via a > > plug-in for one of my own wordpress installations. Im not sure where > > the CVS_CONTENT folder is in relation to the wordpress file hierarchy > > but I'll log in and see if I installed the plugin on the MOBY site > > and if not, I'll add it in and we'll see what happens... > > > > Simon. > > > > > > -- > > > > Simon N. Twigger, Ph.D. > > Assistant Professor, Department of Physiology > > Medical College of Wisconsin > > 8701 Watertown Plank Road, > > Milwaukee, WI, USA > > tel: 414-456-8802 > > fax: 414-456-6595 > > AIM/iChat: simontatmcw > > > > > > On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: > > > > > I take that back - it does work! However, it only searches through > > > what > > > has been "blogged", not through the full content of the site (i.e. it > > > excludes what is in the CVS_CONTENT folder) > > > > > > I don't know how easy it would be to modify this behaviour, as the > > > search utility is part of Wordpress... > > > > > > M > > > > > > > > > -- > > > -- > > > ...his last words were 'Hey guys! Watch this!' > > > -- > > > Mark Wilkinson > > > Asst. Professor > > > Dept. of Medical Genetics > > > University of British Columbia > > > PI in Bioinformatics > > > iCAPTURE Centre > > > St. Paul's Hospital > > > Rm. 166, 1081 Burrard St. > > > Vancouver, BC, V6Z 1Y6 > > > tel: 604 682 2344 x62129 > > > fax: 604 806 9274 > > > > > > "For most of this century we have viewed communications as a conduit, > > > a pipe between physical locations on the planet. > > > What's happened now is that the conduit has become so big and > > > interesting > > > that communication has become more than a conduit, > > > it has become a destination in its own right..." > > > > > > Paul Saffo - Director, Institute for the Future > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://biomoby.org/mailman/listinfo/moby-dev > > >-- >-- >...his last words were 'Hey guys! Watch this!' >-- >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From jmfernandez at cnb.uam.es Fri Feb 10 16:03:37 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri, 10 Feb 2006 22:03:37 +0100 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl><5.2.1.1.2.20060209 182213.02318500@email.med.harvard.edu><5.2.1.1.2.20060209182213.02318500@em ail.med.harvard.edu><5.2.1.1.2.20060210102435.011ee750@email.med.harvard.ed u> Message-ID: <43ECFFA9.6040705@cnb.uam.es> Hi everybody, I have been reading perldoc documentation associated to SOAP::Lite 0.67 (aka Captain Ahab ;-)). Have you played with the new methods soapversion, ns and default_ns? Perhaps they can help. I'm including the fragments of the related documentation: * soapversion(optional value) $client->soapversion('1.2'); If no parameter is given, returns the current version of SOAP that is being used by the client object to encode requests. If a parameter is given, the method attempts to set that as the version of SOAP being used. The value should be either 1.1 or 1.2. * default_ns($uri) Sets the default namespace for the request to the specified uri. This overrides any previous namespace declaration that may have been set using a previous call to "ns()" or "default_ns()". Setting the default namespace causes elements to be serialized without a namespace prefix, like so: * ns($uri,$prefix=undef) Sets the namespace uri and optionally the namespace prefix for the request to the specified values. This overrides any previous namespace declaration that may have been set using a previous call to "ns()" or "default_ns()". If a prefix is not specified, one will be generated for you automatically. Setting the namespace causes elements to be serialized with a declared namespace prefix, like so: Pieter Neerincx wrote: > On 10-Feb-2006, at 4:36 PM, Frank Gibbons wrote: > >> OK, so there is a problem with SOAP::Lite 0.67. I downgraded my >> installation to 0.60 (which by the way, is reported here >> (http://soaplite.com/download.html) as being the recommended stable >> release, and now at least I can retrieveService details >> sufficiently to >> build a service instance. If upgraded back to 0.67, and the problem >> re-appears, so I'm downgrading to 0.60, where I will stay. > >> However, as I discovered, when a user simply installs SOAP::Lite >> from CPAN, >> they may get quite a different version than 0.60 (I got 0.67), in >> which >> case, the message gets sent out correctly on the wire, but is >> perceived as >> empty by MOBY Central. > > Ok, still have to test 0.67, but 0.66 definitely had some problems. > However we can not cling onto 0.60 forever. especially now that 0.67 > is up at CPAN and that is what new Perlisch Mobifiers will get when > they try MOBY out. So either we have to adapt or S::L has to be > patched or both. I posted the "anyURI" problem at the S::L list and > so far haven't had any feedback :(. I'll test 0.67 this weekend and > repost. If S::L is not fixed fast enough I'll make a list of the > small patches you'll need to make BioMOBY work with the latest > "stable" S::L. > > Is your XML parsing problem now fixed by the installation of the new > Perl interpreter or is that one still pending a fix? > >> I don't know much about the details of packaging >> SOAP requests, and you can read the gory details below for >> yourselves, but >> it appears that SOAP::Lite 0.60 and SOAP::Lite 0.67 do not >> understand each >> other. The clue was given by the User-Agent and SOAPServer lines, >> showing >> that my request was sent using SOAP::Lite/Perl/0.67, and the error >> message >> sent in response was generated by SOAP::Lite/Perl/0.60 >> >> So, mystery solved. I'll put a check for SOAP::Lite's version, and a >> warning for this into the Makefile, until we can figure out what >> the real >> solution to this problem is. >> >> Thanks to Mark & Pieter for their help and suggestions. >> >> -Frank >> ================================== SOAP::Lite +trace output >> ============================ >> >> SOAP::Transport::HTTP::Client::send_receive: POST >> http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl HTTP/1.1 >> Accept: text/xml >> Accept: multipart/* >> Accept: application/soap >> User-Agent: SOAP::Lite/Perl/0.67 >> Content-Length: 1539 >> Content-Type: text/xml; charset=utf-8 >> SOAPAction: "http://mips.gsf.de/MOBY/Central#retrieveService" >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" >> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" >> xmlns:soap="http://schemas.xmlsoap.org/soap/ >> envelope/">> xmlns="http://mips.gsf.de/MOBY/Central">> xsi:type="xsd:anyURI"> >> >> > serviceName="getWAtDBIdByPOAcc" >> lsid="urn:lsid:biomoby.org:serviceinstance:www.watdb.nl,getWAtDBIdByPO >> Acc"> >> Retrieval >> 1 >> moby >> > ids with >> a certain PO accession number]]> >> paulien.adamse at wur.nl >> >> http://www.watdb.nl/moby-live/cgi-bin/MOBY/Services/ >> Watdb_mobyservices.py >> >> >> > lsid="urn:lsid:biomoby.org:objectclass:Object">Object >> > lsid="urn:lsid:biomoby.org:namespacetype:PO_acc">PO_acc >> >> >> >> >> > lsid="urn:lsid:biomoby.org:objectclass:Object">Object >> > lsid="urn:lsid:biomoby.org:namespacetype:WAtDB_id">WAtDB_id> Namespace> >> >> >> >> >> >> > soap:Body> >> SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH >> (0x8906a8c) >> SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal >> Server Error >> Connection: close >> Date: Fri, 10 Feb 2006 15:31:05 GMT >> Server: Apache >> Content-Length: 559 >> Content-Type: text/xml; charset=utf-8 >> Client-Date: Fri, 10 Feb 2006 15:29:58 GMT >> Client-Peer: 146.107.217.142:80 >> Client-Response-Num: 1 >> SOAPServer: SOAP::Lite/Perl/0.60 >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" >> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/ >> encoding/">SOAP- >> ENV:ServerEmpty >> String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 >> >> SOAP::Deserializer::deserialize: () >> SOAP::Parser::decode: () >> SOAP::SOM::new: () >> SOAP::SOM::DESTROY: () >> >> Connection to MOBY Central at URI 'http://mips.gsf.de/MOBY/Central' >> died >> because: >> SOAP-ENV:Server : Empty String at >> /home/users/plant/lib/perl/MOBY/Central.pm line 2457 >> >> ERROR ERROR ERROR >> >> >> >> At 09:56 AM 2/10/2006, you wrote: >>> At 05:57 AM 2/10/2006, you wrote: >>>> for that one, but that gave me the same results. I currently running >>>> on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 >>>> today... If you reinstalled Perl, did you also reinstall SOAP::Lite? >>>> If yes which version? In case it's 0.60+ you might have an "anyURI" >>>> problem. >>> Yes, when I re-installed the interpreter (built from source 5.8.6), I >>> reinstalled all of the modules too, from CPAN. I have SOAP::Lite >>> version >>> 0.67 installed. What is the "anyURI" problem you mention? >>> >>> Thanks for the response, Pieter. >>> >>> -Frank >>> >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: >>> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: >> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From simont at hmgc.mcw.edu Fri Feb 10 18:00:51 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Fri, 10 Feb 2006 17:00:51 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> Message-ID: <5EAB1B87-47EF-4861-A519-4CD958B3178E@hmgc.mcw.edu> Just to note that I havent done anything yet - so any improvements you may have noted are not due to anything I did! =) I checked and we do have the plugin installed and activated to search both posts and pages. The pages are going to be things inside wordpress though and it stores them in the db I believe so Im not sure that merely being in the filesystem somewhere is going to count. I'll go on a hunt for something that might address this, I also saw that wordpress 2 has come out, I'll see what new features that brings too. I see what you mean about the style problem for the search results, I'll have a stab at improving that. S. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 10, 2006, at 1:30 PM, Frank Gibbons wrote: > Simon, > > That's a big improvement on what we had before. Can we tweak the > style a > little though? If I search for "constructing", I get a single > result, which > looks like plain text. It's not until I mouse over the heading > "BioMoby > Perl Service Providers Tutorial" that I realise it's a link. That's > becuase > it's just big bold black text. Is there some way to format the > results, so > that the heading comes out as something that's more obviously a link? > (Color being the usual indicator for a link, my vote would be that it > follow the style of the other links on the page.) > > Great work, > > -Frank > > > At 01:43 PM 2/10/2006, you wrote: >> Hi Mark, >> >> I might have missed the first part of this but it should be possible >> to add in functionality to search static pages too - I did this via a >> plug-in for one of my own wordpress installations. Im not sure where >> the CVS_CONTENT folder is in relation to the wordpress file hierarchy >> but I'll log in and see if I installed the plugin on the MOBY site >> and if not, I'll add it in and we'll see what happens... >> >> Simon. >> >> >> -- >> >> Simon N. Twigger, Ph.D. >> Assistant Professor, Department of Physiology >> Medical College of Wisconsin >> 8701 Watertown Plank Road, >> Milwaukee, WI, USA >> tel: 414-456-8802 >> fax: 414-456-6595 >> AIM/iChat: simontatmcw >> >> >> On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: >> >>> I take that back - it does work! However, it only searches through >>> what >>> has been "blogged", not through the full content of the site >>> (i.e. it >>> excludes what is in the CVS_CONTENT folder) >>> >>> I don't know how easy it would be to modify this behaviour, as the >>> search utility is part of Wordpress... >>> >>> M >>> >>> >>> -- >>> -- >>> ...his last words were 'Hey guys! Watch this!' >>> -- >>> Mark Wilkinson >>> Asst. Professor >>> Dept. of Medical Genetics >>> University of British Columbia >>> PI in Bioinformatics >>> iCAPTURE Centre >>> St. Paul's Hospital >>> Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "For most of this century we have viewed communications as a >>> conduit, >>> a pipe between physical locations on the planet. >>> What's happened now is that the conduit has become so big and >>> interesting >>> that communication has become more than a conduit, >>> it has become a destination in its own right..." >>> >>> Paul Saffo - Director, Institute for the Future >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri Feb 10 18:27:37 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 15:27:37 -0800 Subject: [MOBY-dev] WSRF solution to the asynchronous services problem Message-ID: Hi all, Well, I seem to have mis-understood and mis-represented WSRF in my previous messages. It isn't the utopea that I thought it was the first time I read the spec, but that was my mistake - I was reading it with the assumption that it would be clever and elegant. There are two near-identical specifications in OASIS for dealing with stateful services: WSRF and ASAP. Neither of them have yet been accepted as "standards", so they are still prone to change. Here's a brief overview of the two spec's: WSRF: Web Services Resource Framework - WS Resources are uniquely identifiable entities - One WS Resource is created per Web Service invocation (**NB**) - WS Resources have Property Documents (defined by an XML schema) - Property Documents contain Properties (duh!) describing the state of that WS Resource - Using WSRF-defined, predictable API calls it is possible to obtain the full Property Document or named parts of the Property Document, and/or set the property values - the Web Service must implement these API call(s) as method on the service - a variety of Faults are defined to deal with cases e.g. where the WS Resource or property named in the request is unknown - [[speculation]] cleanup could be achieved by having one of the properties, e.g. "discard", be settable by the client through the appropriate API call ASAP: Asynchronous Service Access Protocol - Specifically for Asynchronous services - Server must implement a "Factory" interface - "Factory" generates "Instances" of a service upon Service invocation - Instances have a variety of API calls to manipulate their parameters and check their status, including their current state, the input data, and the output data. - Instances generate event notifications to the client (**NB**) to tell it that it is finished (active notification, NOT passive notification!!), as well as when its state has changed, etc. - clean-up happens through a server-side, timed event, where one of the properties of an Instance is the duration for which it will be held, after which it is no longer accessible. - it isn't clear from the spec which parts are required and which are optional... unfortunately, there are a LOT of API methods described in the spec, so this is a bit worrisome as they would have to be implemented for every asynch service. My instincts tell me that ASAP is too complex for our needs, and it would be better to work with the more generic of the two specifications anyway just in case we need to use it for something other than asynchronicity (e.g. message chunking!) The problems I see with WSRF are the following: a) It doesn't (natively) handle batching the way we do in MOBY Collections, so anything we come up with is going to be a bit of a hack in that regard. b) It requires that service providers implement one or more of the defined WSRF API methods, and this means that there will be messages passed between MOBY Client and MOBY Service that are not MOBY messages. I'm going to try to put together a strawman proposal for how we might implement MOBY Services asynchronously using WSRF, but it will take me a little while because it isn't entirely trivial nor intuitive to do so... We can then compare it to whatever the RFC proposal is and decide if we gain any significant advantage from following an existing "standard", or if our own proposal is sufficient. M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From markw at illuminae.com Sat Feb 11 01:04:51 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 22:04:51 -0800 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <5EAB1B87-47EF-4861-A519-4CD958B3178E@hmgc.mcw.edu> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> <5EAB1B87-47EF-4861-A519-4CD958B3178E@hmgc.mcw.edu> Message-ID: If we put a symlink in the wordpress folder will it traverse? On Fri, 10 Feb 2006 15:00:51 -0800, Twigger Simon wrote: > Just to note that I havent done anything yet - so any improvements > you may have noted are not due to anything I did! =) > > I checked and we do have the plugin installed and activated to search > both posts and pages. The pages are going to be things inside > wordpress though and it stores them in the db I believe so Im not > sure that merely being in the filesystem somewhere is going to count. > I'll go on a hunt for something that might address this, I also saw > that wordpress 2 has come out, I'll see what new features that brings > too. > > I see what you mean about the style problem for the search results, > I'll have a stab at improving that. > > S. > > -- > > Simon N. Twigger, Ph.D. > Assistant Professor, Department of Physiology > Medical College of Wisconsin > 8701 Watertown Plank Road, > Milwaukee, WI, USA > tel: 414-456-8802 > fax: 414-456-6595 > AIM/iChat: simontatmcw > > > On Feb 10, 2006, at 1:30 PM, Frank Gibbons wrote: > >> Simon, >> >> That's a big improvement on what we had before. Can we tweak the >> style a >> little though? If I search for "constructing", I get a single >> result, which >> looks like plain text. It's not until I mouse over the heading >> "BioMoby >> Perl Service Providers Tutorial" that I realise it's a link. That's >> becuase >> it's just big bold black text. Is there some way to format the >> results, so >> that the heading comes out as something that's more obviously a link? >> (Color being the usual indicator for a link, my vote would be that it >> follow the style of the other links on the page.) >> >> Great work, >> >> -Frank >> >> >> At 01:43 PM 2/10/2006, you wrote: >>> Hi Mark, >>> >>> I might have missed the first part of this but it should be possible >>> to add in functionality to search static pages too - I did this via a >>> plug-in for one of my own wordpress installations. Im not sure where >>> the CVS_CONTENT folder is in relation to the wordpress file hierarchy >>> but I'll log in and see if I installed the plugin on the MOBY site >>> and if not, I'll add it in and we'll see what happens... >>> >>> Simon. >>> >>> >>> -- >>> >>> Simon N. Twigger, Ph.D. >>> Assistant Professor, Department of Physiology >>> Medical College of Wisconsin >>> 8701 Watertown Plank Road, >>> Milwaukee, WI, USA >>> tel: 414-456-8802 >>> fax: 414-456-6595 >>> AIM/iChat: simontatmcw >>> >>> >>> On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: >>> >>>> I take that back - it does work! However, it only searches through >>>> what >>>> has been "blogged", not through the full content of the site >>>> (i.e. it >>>> excludes what is in the CVS_CONTENT folder) >>>> >>>> I don't know how easy it would be to modify this behaviour, as the >>>> search utility is part of Wordpress... >>>> >>>> M >>>> >>>> >>>> -- >>>> -- >>>> ...his last words were 'Hey guys! Watch this!' >>>> -- >>>> Mark Wilkinson >>>> Asst. Professor >>>> Dept. of Medical Genetics >>>> University of British Columbia >>>> PI in Bioinformatics >>>> iCAPTURE Centre >>>> St. Paul's Hospital >>>> Rm. 166, 1081 Burrard St. >>>> Vancouver, BC, V6Z 1Y6 >>>> tel: 604 682 2344 x62129 >>>> fax: 604 806 9274 >>>> >>>> "For most of this century we have viewed communications as a >>>> conduit, >>>> a pipe between physical locations on the planet. >>>> What's happened now is that the conduit has become so big and >>>> interesting >>>> that communication has become more than a conduit, >>>> it has become a destination in its own right..." >>>> >>>> Paul Saffo - Director, Institute for the Future >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://biomoby.org/mailman/listinfo/moby-dev >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: >> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From simont at hmgc.mcw.edu Mon Feb 13 12:44:40 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Mon, 13 Feb 2006 11:44:40 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> <5EAB1B87-47EF-4861-A519-4CD958B3178E@hmgc.mcw.edu> Message-ID: Hi Mark, I think the content would need to be actually loaded into the wordpress database as that is where it stores the text rather than in flat files. From looking at a local install of the db we'd need to load the HTML into the *_posts table with appropriate meta data to keep the page hierarchy straight and we'd have to deal with redirecting/rewriting hyperlinks from their flat file form to a wordpress URL form. This seems a little messy so I'll keep looking on the wp site to see if anything easier crops up. S. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 11, 2006, at 12:04 AM, Mark Wilkinson wrote: > If we put a symlink in the wordpress folder will it traverse? > > > On Fri, 10 Feb 2006 15:00:51 -0800, Twigger Simon > > wrote: > >> Just to note that I havent done anything yet - so any improvements >> you may have noted are not due to anything I did! =) >> >> I checked and we do have the plugin installed and activated to search >> both posts and pages. The pages are going to be things inside >> wordpress though and it stores them in the db I believe so Im not >> sure that merely being in the filesystem somewhere is going to count. >> I'll go on a hunt for something that might address this, I also saw >> that wordpress 2 has come out, I'll see what new features that brings >> too. >> >> I see what you mean about the style problem for the search results, >> I'll have a stab at improving that. >> >> S. >> >> -- >> >> Simon N. Twigger, Ph.D. >> Assistant Professor, Department of Physiology >> Medical College of Wisconsin >> 8701 Watertown Plank Road, >> Milwaukee, WI, USA >> tel: 414-456-8802 >> fax: 414-456-6595 >> AIM/iChat: simontatmcw >> >> >> On Feb 10, 2006, at 1:30 PM, Frank Gibbons wrote: >> >>> Simon, >>> >>> That's a big improvement on what we had before. Can we tweak the >>> style a >>> little though? If I search for "constructing", I get a single >>> result, which >>> looks like plain text. It's not until I mouse over the heading >>> "BioMoby >>> Perl Service Providers Tutorial" that I realise it's a link. That's >>> becuase >>> it's just big bold black text. Is there some way to format the >>> results, so >>> that the heading comes out as something that's more obviously a >>> link? >>> (Color being the usual indicator for a link, my vote would be >>> that it >>> follow the style of the other links on the page.) >>> >>> Great work, >>> >>> -Frank >>> >>> >>> At 01:43 PM 2/10/2006, you wrote: >>>> Hi Mark, >>>> >>>> I might have missed the first part of this but it should be >>>> possible >>>> to add in functionality to search static pages too - I did this >>>> via a >>>> plug-in for one of my own wordpress installations. Im not sure >>>> where >>>> the CVS_CONTENT folder is in relation to the wordpress file >>>> hierarchy >>>> but I'll log in and see if I installed the plugin on the MOBY site >>>> and if not, I'll add it in and we'll see what happens... >>>> >>>> Simon. >>>> >>>> >>>> -- >>>> >>>> Simon N. Twigger, Ph.D. >>>> Assistant Professor, Department of Physiology >>>> Medical College of Wisconsin >>>> 8701 Watertown Plank Road, >>>> Milwaukee, WI, USA >>>> tel: 414-456-8802 >>>> fax: 414-456-6595 >>>> AIM/iChat: simontatmcw >>>> >>>> >>>> On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: >>>> >>>>> I take that back - it does work! However, it only searches >>>>> through >>>>> what >>>>> has been "blogged", not through the full content of the site >>>>> (i.e. it >>>>> excludes what is in the CVS_CONTENT folder) >>>>> >>>>> I don't know how easy it would be to modify this behaviour, as the >>>>> search utility is part of Wordpress... >>>>> >>>>> M >>>>> >>>>> >>>>> -- >>>>> -- >>>>> ...his last words were 'Hey guys! Watch this!' >>>>> -- >>>>> Mark Wilkinson >>>>> Asst. Professor >>>>> Dept. of Medical Genetics >>>>> University of British Columbia >>>>> PI in Bioinformatics >>>>> iCAPTURE Centre >>>>> St. Paul's Hospital >>>>> Rm. 166, 1081 Burrard St. >>>>> Vancouver, BC, V6Z 1Y6 >>>>> tel: 604 682 2344 x62129 >>>>> fax: 604 806 9274 >>>>> >>>>> "For most of this century we have viewed communications as a >>>>> conduit, >>>>> a pipe between physical locations on the planet. >>>>> What's happened now is that the conduit has become so big and >>>>> interesting >>>>> that communication has become more than a conduit, >>>>> it has become a destination in its own right..." >>>>> >>>>> Paul Saffo - Director, Institute for the Future >>>>> >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev at biomoby.org >>>>> http://biomoby.org/mailman/listinfo/moby-dev >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://biomoby.org/mailman/listinfo/moby-dev >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: >>> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Tue Feb 14 10:57:07 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 14 Feb 2006 15:57:07 +0000 (GMT) Subject: [MOBY-dev] non-compliant services Message-ID: I wonder (I forgot it) what was the decision, after the big change regarding not inheriting from primitive types, what to do and when with services that do not comply with the new specification. I think that the discussion was about what to do with old data types, there was even a script to rectify them semi-automatically, but I do not recall what we said about the services. An example is a service getFASTAFromUniprot - a nice, fast, possibly reliable and important service, but it returns something like this: which is, according my limited knowledge wrong (the FASTA should have a String with the value there). Are we going to remove one day such services from a registry? Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Tue Feb 14 12:00:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 14 Feb 2006 09:00:20 -0800 Subject: [MOBY-dev] [moby] non-compliant services In-Reply-To: References: Message-ID: <1139936420.21275.31.camel@bioinfo.icapture.ubc.ca> I see this as the second question of a two-question set, where the first question is "how do we FIND these non-compliant services in the first place?" You and I run across them somewhat randomly, but only because we happen to know what the correct input data would be to get some output from the service in question. (this speaks to the discussion we had at the last meeting about adding sample input/output to the service metadata, but that's beside the point for this discusson). I am entirely in favour of removing these services from the registry, since they only serve to confuse people. I suspect, however, that these services will naturally disappear when we switch on the RDF agent (the delay now is in creating the MOBY Administrative interface that know you and he have been discussing. It's almost done - I wrote it for him yesterday :-) ). Anyone who has not downloaded their RDF is also unlikely to have fixed their services, so they will get culled from the registry. Regardless, we are still left with the question of what to do when you receive an illegally structured object. I think the client should raise a warning, including the service providers email address, but do its best to render the data that it receives. However, I don't think the client should attempt to pass this invalid data on to another service. A clever client might be able to re-format the data to make it right, but that obviously shouldn't be a requirement. It would be great if we could do a registry "purge" at some point in the near future to get rid of the clutter... Certainly, I think we MUST do a purge of "test" services/objects before we publish our respective articles on gbrowse_moby and dashboard, or we will frustrate and confuse the reviewers! M On Tue, 2006-02-14 at 15:57 +0000, Martin Senger wrote: > I wonder (I forgot it) what was the decision, after the big change > regarding not inheriting from primitive types, what to do and when with > services that do not comply with the new specification. I think that the > discussion was about what to do with old data types, there was even a > script to rectify them semi-automatically, but I do not recall what we > said about the services. > An example is a service getFASTAFromUniprot - a nice, fast, possibly > reliable and important service, but it returns something like this: > > xmlns:moby='http://www.biomoby.org/moby' > xmlns='http://www.biomoby.org/moby'> moby:authority='mmb.pcb.ub.es'> > > id='Q7T7Q6'> AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI > SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV > DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF > CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS > NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF > TITFPTGGDGTA > ]]> > > > > which is, according my limited knowledge wrong (the FASTA should have a > String with the value there). > > Are we going to remove one day such services from a registry? > > Cheers, > Martin > -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From akerhornou at imim.es Tue Feb 14 12:28:08 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Tue, 14 Feb 2006 18:28:08 +0100 Subject: [MOBY-dev] non-compliant services In-Reply-To: References: Message-ID: <43F21328.6080701@imim.es> Hi everyone, On this note, I have a service that generates GFF objects, e.g. Is this object correct. If so would taverna (v1.3.1) be affected by the new object specifications ? I have a workflow that connects the output port of a service returning a collection of GFF objects, and feeds a parse_moby_data local processor with this list of simples and when i have GFF objects as above, i get a list of empty objects. Thanks Arnaud Martin Senger wrote: >I wonder (I forgot it) what was the decision, after the big change >regarding not inheriting from primitive types, what to do and when with >services that do not comply with the new specification. I think that the >discussion was about what to do with old data types, there was even a >script to rectify them semi-automatically, but I do not recall what we >said about the services. > An example is a service getFASTAFromUniprot - a nice, fast, possibly >reliable and important service, but it returns something like this: > >xmlns:moby='http://www.biomoby.org/moby' >xmlns='http://www.biomoby.org/moby'>moby:authority='mmb.pcb.ub.es'> > > id='Q7T7Q6'>AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI >SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV >DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF >CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS >NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF >TITFPTGGDGTA >]]> > > > >which is, according my limited knowledge wrong (the FASTA should have a >String with the value there). > > Are we going to remove one day such services from a registry? > > Cheers, > Martin > > > From edward.kawas at gmail.com Tue Feb 14 11:09:13 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 14 Feb 2006 08:09:13 -0800 Subject: [MOBY-dev] non-compliant services In-Reply-To: Message-ID: <000c01c63181$0671eeb0$6500a8c0@notebook> Hi Martin, I don't think that it is possible to weed those services out, because moby just keeps track of service signatures (inputs/outputs, service details, etc). It is up to the provider to structure the service and its logic according to the api. The best that we can do is email the service provider and request that they fix the service. If they don't, the service will ultimately 'remove' itself, since other moby services will not be able to interact with it. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Martin Senger > Sent: Tuesday, February 14, 2006 7:57 AM > To: Moby Developers > Subject: [MOBY-dev] non-compliant services > > I wonder (I forgot it) what was the decision, after the big > change regarding not inheriting from primitive types, what > to do and when with services that do not comply with the new > specification. I think that the discussion was about what to > do with old data types, there was even a script to rectify > them semi-automatically, but I do not recall what we said > about the services. > An example is a service getFASTAFromUniprot - a nice, > fast, possibly reliable and important service, but it returns > something like this: > > xmlns:moby='http://www.biomoby.org/moby' > xmlns='http://www.biomoby.org/moby'> moby:authority='mmb.pcb.ub.es'> > > id='Q7T7Q6'> (Fragment) > AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI > SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV > DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF > CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS > NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF > TITFPTGGDGTA > ]]> > > > > which is, according my limited knowledge wrong (the FASTA > should have a String with the value there). > > Are we going to remove one day such services from a registry? > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From officeparis at yahoo.co.jp Tue Feb 14 12:55:50 2006 From: officeparis at yahoo.co.jp (Kazuo Ishii) Date: Wed, 15 Feb 2006 02:55:50 +0900 (JST) Subject: [MOBY-dev] (no subject) Message-ID: <20060214175550.39642.qmail@web2812.mail.bbt.yahoo.co.jp> -------------------------------------- GANBARE! NIPPON! Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE PARTNER http://pr.mail.yahoo.co.jp/ganbare-nippon/ From edward.kawas at gmail.com Tue Feb 14 12:44:10 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 14 Feb 2006 09:44:10 -0800 Subject: [MOBY-dev] non-compliant services In-Reply-To: <43F21328.6080701@imim.es> Message-ID: <000d01c6318e$48b709b0$6500a8c0@notebook> Hi, Can you send me the workflow and example inputs? BTW, the xml looks fine to me. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Arnaud Kerhornou > Sent: Tuesday, February 14, 2006 9:28 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] non-compliant services > > Hi everyone, > > On this note, I have a service that generates GFF objects, e.g. > > > ENSBTAG00000014911 MatScan I$HSF_01 490 494 > 4.99 > - . # AGAAG > ENSBTAG00000014911 MatScan I$HSF_01 487 491 > 5.48 > - . # AGAAA > ]]> > > > > Is this object correct. If so would taverna (v1.3.1) be > affected by the new object specifications ? > > I have a workflow that connects the output port of a service > returning a collection of GFF objects, and feeds a > parse_moby_data local processor with this list of simples and > when i have GFF objects as above, i get a list of empty objects. > > Thanks > Arnaud > > Martin Senger wrote: > > >I wonder (I forgot it) what was the decision, after the big change > >regarding not inheriting from primitive types, what to do and when > >with services that do not comply with the new specification. I think > >that the discussion was about what to do with old data > types, there was > >even a script to rectify them semi-automatically, but I do > not recall > >what we said about the services. > > An example is a service getFASTAFromUniprot - a nice, > fast, possibly > >reliable and important service, but it returns something like this: > > > > >xmlns:moby='http://www.biomoby.org/moby' > >xmlns='http://www.biomoby.org/moby'> >moby:authority='mmb.pcb.ub.es'> > > > > >id='Q7T7Q6'> >AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI > >SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV > >DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF > >CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS > >NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF > >TITFPTGGDGTA > >]]> > > > > > > > >which is, according my limited knowledge wrong (the FASTA > should have a > >String with the value there). > > > > Are we going to remove one day such services from a registry? > > > > Cheers, > > Martin > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From akerhornou at imim.es Tue Feb 14 13:39:25 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Tue, 14 Feb 2006 19:39:25 +0100 Subject: [MOBY-dev] non-compliant services In-Reply-To: <000d01c6318e$48b709b0$6500a8c0@notebook> References: <000d01c6318e$48b709b0$6500a8c0@notebook> Message-ID: <43F223DD.5070708@imim.es> Hi Eddie, See files attached, Thanks for looking at it, Arnaud Edward Kawas wrote: >Hi, > >Can you send me the workflow and example inputs? > >BTW, the xml looks fine to me. > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces at biomoby.org >>[mailto:moby-dev-bounces at biomoby.org] On Behalf Of Arnaud Kerhornou >>Sent: Tuesday, February 14, 2006 9:28 AM >>To: Core developer announcements >>Subject: Re: [MOBY-dev] non-compliant services >> >>Hi everyone, >> >>On this note, I have a service that generates GFF objects, e.g. >> >> >> > ENSBTAG00000014911 MatScan I$HSF_01 490 494 >> 4.99 >>- . # AGAAG >> ENSBTAG00000014911 MatScan I$HSF_01 487 491 >> 5.48 >>- . # AGAAA >> ]]> >> >> >> >>Is this object correct. If so would taverna (v1.3.1) be >>affected by the new object specifications ? >> >>I have a workflow that connects the output port of a service >>returning a collection of GFF objects, and feeds a >>parse_moby_data local processor with this list of simples and >>when i have GFF objects as above, i get a list of empty objects. >> >>Thanks >>Arnaud >> >>Martin Senger wrote: >> >> >> >>>I wonder (I forgot it) what was the decision, after the big change >>>regarding not inheriting from primitive types, what to do and when >>>with services that do not comply with the new specification. I think >>>that the discussion was about what to do with old data >>> >>> >>types, there was >> >> >>>even a script to rectify them semi-automatically, but I do >>> >>> >>not recall >> >> >>>what we said about the services. >>> An example is a service getFASTAFromUniprot - a nice, >>> >>> >>fast, possibly >> >> >>>reliable and important service, but it returns something like this: >>> >>>>>xmlns:moby='http://www.biomoby.org/moby' >>>xmlns='http://www.biomoby.org/moby'>>>moby:authority='mmb.pcb.ub.es'> >>> >>> >>id='Q7T7Q6'>>>AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI >>>SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV >>>DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF >>>CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS >>>NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF >>>TITFPTGGDGTA >>>]]> >>> >>> >>> >>>which is, according my limited knowledge wrong (the FASTA >>> >>> >>should have a >> >> >>>String with the value there). >>> >>> Are we going to remove one day such services from a registry? >>> >>> Cheers, >>> Martin >>> >>> >>> >>> >>> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PromoterAnalysisWorkflow_coexpressedGenesMode_MEME_Mode_Fasta_Version.xml Type: text/xml Size: 15899 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20060214/975b10dc/attachment-0002.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: ENSG00000174697.orthologs.500.fa.xml Type: text/xml Size: 6955 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20060214/975b10dc/attachment-0003.xml From senger at ebi.ac.uk Wed Feb 15 06:00:52 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 15 Feb 2006 11:00:52 +0000 (GMT) Subject: [MOBY-dev] [moby] non-compliant services In-Reply-To: <1139936420.21275.31.camel@bioinfo.icapture.ubc.ca> Message-ID: > I see this as the second question of a two-question set, where the first > question is "how do we FIND these non-compliant services in the first > place?" > Correct. > You and I run across them somewhat randomly > Yes - but if it happens, what is the policy? Should I informe Eddie, or you to inform the contact, or should I send her/him myself an email? Both is fine with me. But what happen when there is no reaction? Are you willing to remove such service (after some waiting period)? > I am entirely in favour of removing these services from the registry, > since they only serve to confuse people. > Good, my question answered. And I second it. > Anyone who has not downloaded their RDF is also unlikely to have fixed > their services, so they will get culled from the registry. > That I would not be so sure. I surely will suggest GCP service providers to wait quite long before starting to register their services with the RDF URL. We need to trust first that an agent can come at once (within seconds, I mean) when we call it - otherwise will will rather take a risk to be unregistered by a malicious person. For that reasons, we already started to put scripts that can help with fast re-registration if a need comes. > Regardless, we are still left with the question of what to do when you > receive an illegally structured object. I think the client should raise > a warning > Well, that's an additional effort in client development. I understand your point, and I will try to help to make such clever clients, but I do not feel that is my priority. I would just stick with the policy tht I asked for/about above... > It would be great if we could do a registry "purge" at some point in the > near future to get rid of the clutter... > ...and the wrong CSHL objects :-) > Certainly, I think we MUST do a purge of "test" services/objects > before we publish our respective articles on gbrowse_moby and > dashboard, or we will frustrate and confuse the reviewers! > Agree! BTW, let me know when the time is coming and you need something from me for hese articles... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Wed Feb 15 15:37:04 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 15 Feb 2006 15:37:04 -0500 Subject: [MOBY-dev] Fwd: Re: [MOBY-l] error when do make test Message-ID: <5.2.1.1.2.20060215153638.021bad50@email.med.harvard.edu> Mark, it looks like DBD::mysql is now required (see Nicholas's email below), because of MOBY::OntologyServer.pm, is that right? I see that the constructor new() tries to instantiate a connection to a remote DB. If it's a requirement, then I'll put it into the Makefile.PL, otherwise perhaps there's a way we could find a work-around for users who don't have it installed. -Frank At 02:13 PM 2/15/2006, you wrote: >Hello, > >I just downloaded the biomoby tarball from the CVS reprository >(http://cvs.open-bio.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=biomoby), and >tried to install it here to my system. > >So I went to moby/moby-live/Perl folder, and do "perl Makefile.PL >PREFIX=/MyInstallationFolder". >Then, I do make. > >But it seems that it's failing when i did the make test. >I copied and pasted the error message in the bottom of this email. > >Do you guys can give me any clue why this happen? Maybe I miss something? > >I did the same thing with the latest code release version (09/16/2004).., >but it >seems I can install it without this problem. > > >Thanks a lot, >Nicholas. > > >alhagib 86 % make test >PERL_DL_NONLAZY=1 /p/perl/bin/perl "-MExtUtils::Command::MM" "-e" >"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t >t/Central...................................# Failed test (t/Central.t at >line 26) ># Tried to use 'MOBY::Central'. >t/Central...................................NOK 1# Error: Can't locate >DBD/mysql.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >line 70. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >line 70. PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Wed Feb 15 17:34:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 15 Feb 2006 14:34:53 -0800 Subject: [MOBY-dev] Fwd: Re: [MOBY-l] error when do make test In-Reply-To: <5.2.1.1.2.20060215153638.021bad50@email.med.harvard.edu> References: <5.2.1.1.2.20060215153638.021bad50@email.med.harvard.edu> Message-ID: Hmmmm.... that's a tricky one. DBD::mysql should not be required if the person is running MOBY as a client only, but it is required when running it as a Registry. I don't think that MOBY::OntologyServer is used client-side either. AFAIK MOBY::Client::OntologyServer is used by the client software. The upshot is that people not running a registry do not need to successfully load the MOBY::Central module, or the MOBY::OntologyServer module, so the first test (Central.t) should not be run for these cases. Thus, DBD::mysql is also not a requirement in these cases. M On Wed, 15 Feb 2006 12:37:04 -0800, Frank Gibbons wrote: > Mark, > > it looks like DBD::mysql is now required (see Nicholas's email below), > because of MOBY::OntologyServer.pm, is that right? I see that the > constructor new() tries to instantiate a connection to a remote DB. If > it's a requirement, then I'll put it into the Makefile.PL, otherwise > perhaps there's a way we could find a work-around for users who don't > have it installed. > > -Frank > > At 02:13 PM 2/15/2006, you wrote: >> Hello, >> >> I just downloaded the biomoby tarball from the CVS reprository >> (http://cvs.open-bio.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=biomoby), >> and >> tried to install it here to my system. >> >> So I went to moby/moby-live/Perl folder, and do "perl Makefile.PL >> PREFIX=/MyInstallationFolder". >> Then, I do make. >> >> But it seems that it's failing when i did the make test. >> I copied and pasted the error message in the bottom of this email. >> >> Do you guys can give me any clue why this happen? Maybe I miss >> something? >> >> I did the same thing with the latest code release version >> (09/16/2004).., but it >> seems I can install it without this problem. >> >> >> Thanks a lot, >> Nicholas. >> >> >> alhagib 86 % make test >> PERL_DL_NONLAZY=1 /p/perl/bin/perl "-MExtUtils::Command::MM" "-e" >> "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t >> t/Central...................................# Failed test >> (t/Central.t at >> line 26) >> # Tried to use 'MOBY::Central'. >> t/Central...................................NOK 1# Error: Can't >> locate >> DBD/mysql.pm in @INC (@INC contains: >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >> /p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/5.8.4 >> /p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/site_perl/5.8.4 >> /p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >> /p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/5.8.4 >> /p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >> line 70. >> # BEGIN failed--compilation aborted at >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >> line 70. > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From senger at ebi.ac.uk Wed Feb 15 22:05:43 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 16 Feb 2006 03:05:43 +0000 (GMT) Subject: [MOBY-dev] Fwd: Re: [MOBY-l] error when do make test In-Reply-To: Message-ID: > person is running MOBY as a client only, but it is required when running > it as a Registry > This reminds me: the main biomoby page should either not to have "get code" at all (because it is confusing what code is meant), or should have (preferrably) sublist of code for registry, perl user. java users etc. I can provide the link for 'gettting Java code' (it would be: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/Download.html). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Thu Feb 16 10:22:30 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 16 Feb 2006 10:22:30 -0500 Subject: [MOBY-dev] [MOBY-l] error when do make test In-Reply-To: <1140030803.43f37d537d852@webmail.purdue.edu> References: <000f01c63253$26985670$6500a8c0@notebook> <000f01c63253$26985670$6500a8c0@notebook> Message-ID: <5.2.1.1.2.20060216102036.01226e38@email.med.harvard.edu> Nicholas, I've edited the Makefile.PL to tell you if you're missing certain modules. I've also modified the tests, so that if you are simply missing the database-connection modules, it explains the situation better. You might want to do 'cvs update' in moby-live/Perl to get these changes, then do 'perl Makefile.PL PREFIX=....' and 'make test'. Hope that helps, -F At 02:13 PM 2/15/2006, you wrote: >Hello, > >I just downloaded the biomoby tarball from the CVS reprository >(http://cvs.open-bio.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=biomoby), and >tried to install it here to my system. > >So I went to moby/moby-live/Perl folder, and do "perl Makefile.PL >PREFIX=/MyInstallationFolder". >Then, I do make. > >But it seems that it's failing when i did the make test. >I copied and pasted the error message in the bottom of this email. > >Do you guys can give me any clue why this happen? Maybe I miss something? > >I did the same thing with the latest code release version (09/16/2004).., >but it >seems I can install it without this problem. > > >Thanks a lot, >Nicholas. > > >alhagib 86 % make test >PERL_DL_NONLAZY=1 /p/perl/bin/perl "-MExtUtils::Command::MM" "-e" >"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t >t/Central...................................# Failed test (t/Central.t at >line 26) ># Tried to use 'MOBY::Central'. >t/Central...................................NOK 1# Error: Can't locate >DBD/mysql.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >line 70. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >line 70. ># Compilation failed in require at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/Central.pm >line 14. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/Central.pm >line 14. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/Central.t at line 57) >t/Central...................................NOK 2# >MOBY::Central->can('Registration') failed ># MOBY::Central->can('registerObjectClass') failed ># MOBY::Central->can('_registerObjectPayload') failed ># MOBY::Central->can('deregisterObjectClass') failed ># MOBY::Central->can('_deregisterObjectPayload') failed ># MOBY::Central->can('_testObjectTypeAgainstPrimitives') failed ># MOBY::Central->can('registerServiceType') failed ># MOBY::Central->can('_registerServiceTypePayload') failed ># MOBY::Central->can('deregisterServiceType') failed ># MOBY::Central->can('_deregisterServiceTypePayload') failed ># MOBY::Central->can('retrieveNamespaces') failed ># MOBY::Central->can('_registerNamespacePayload') failed ># MOBY::Central->can('deregisterNamespace') failed ># MOBY::Central->can('_deregisterNamespacePayload') failed ># MOBY::Central->can('registerService') failed ># MOBY::Central->can('_registerServicePayload') failed ># MOBY::Central->can('_getServiceInstanceRDF') failed ># MOBY::Central->can('_registerArticles') failed ># MOBY::Central->can('deregisterService') failed ># MOBY::Central->can('_deregisterServicePayload') failed ># MOBY::Central->can('findService') failed ># MOBY::Central->can('_findServicePayload') failed ># MOBY::Central->can('_extractObjectTypes') failed ># MOBY::Central->can('registerServiceWSDL') failed ># MOBY::Central->can('_extract_ids') failed ># MOBY::Central->can('_searchForServicesWithArticle') failed ># MOBY::Central->can('_searchForSimple') failed ># MOBY::Central->can('_searchForCollection') failed ># MOBY::Central->can('_extractObjectTypesAndNamespaces') failed ># MOBY::Central->can('retrieveService') failed ># MOBY::Central->can('_retrieveServicePayload') failed ># MOBY::Central->can('retrieveResourceURLs') failed ># MOBY::Central->can('retrieveServiceProviders') failed ># MOBY::Central->can('retrieveServiceNames') failed ># MOBY::Central->can('retrieveServiceTypes') failed ># MOBY::Central->can('retrieveRelationshipTypes') failed ># MOBY::Central->can('retrieveObjectNames') failed ># MOBY::Central->can('retrieveObjectDefinition') failed ># MOBY::Central->can('retrieveNamespaces') failed ># MOBY::Central->can('retrieveObject') failed ># MOBY::Central->can('_retrieveObjectPayload') failed ># MOBY::Central->can('Relationships') failed ># MOBY::Central->can('DUMP_MySQL') failed ># MOBY::Central->can('_ISAPayload') failed ># MOBY::Central failed to implement full API ># Looks like you failed 2 tests of 2. >t/Central...................................dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/Client-Central............................ok >t/Client-CollectionArticle..................ok >t/Client-OntologyServer.....................ok >t/Client-Registration.......................ok >t/Client-SecondaryArticle...................ok >t/Client-Service............................ok >t/Client-ServiceInstance....................ok >t/Client-SimpleArticle......................ok >t/CommonSubs................................ok >t/Config....................................skipped > all skipped: Required only for local MOBY Central >t/CrossReference............................ok >t/dbConnect.................................# Failed test >(t/dbConnect.t at >line 18) ># Tried to use 'MOBY::lsid::authority::dbConnect'. >t/dbConnect.................................NOK 1# Error: Can't locate >DBD/mysql.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/dbConnect.pm >line 17. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/dbConnect.pm >line 17. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/dbConnect.t at line 25) ># MOBY::lsid::authority::dbConnect->can('dbConnect') failed ># API not correctly implemented >t/dbConnect.................................NOK 2# Looks like you failed 2 >tests >of 2. >t/dbConnect.................................dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/lsid-authority-ClassResolver..............# Failed test >(t/lsid-authority-ClassResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::ClassResolver'. >t/lsid-authority-ClassResolver..............NOK 1# Error: Can't locate >XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/ClassResolver.pm >line 5. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/ClassResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/lsid-authority-ClassResolver.t at line 25) ># MOBY::lsid::authority::ClassResolver->can('resolve_classtype') failed ># Didn't implement full API >t/lsid-authority-ClassResolver..............NOK 2# Looks like you failed 2 >tests >of 2. >t/lsid-authority-ClassResolver..............dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/lsid-authority-dbConnect..................# Failed test >(t/lsid-authority-dbConnect.t at line 18) >t/lsid-authority-dbConnect..................NOK 1# Tried to use >'MOBY::lsid::authority::dbConnect'. ># Error: Can't locate DBD/mysql.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/dbConnect.pm >line 17. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/dbConnect.pm >line 17. ># Compilation failed in require at (eval 1) line 2. ># Looks like you failed 1 tests of 1. >t/lsid-authority-dbConnect..................dubious > Test returned status 1 (wstat 256, 0x100) >DIED. FAILED test 1 > Failed 1/1 tests, 0.00% okay >t/lsid-authority-Error......................ok >t/lsid-authority-NamespaceResolver..........# Failed test >(t/lsid-authority-NamespaceResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::NamespaceResolver'. ># Error: Can't locate XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/NamespaceResolver.pm >line 5. >t/lsid-authority-NamespaceResolver..........NOK 1# BEGIN failed--compilation >aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/NamespaceResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/lsid-authority-NamespaceResolver.t at line 25) ># >MOBY::lsid::authority::NamespaceResolver->can('resolve_namespacetype') failed ># NamespaceResolver didn't implement API correctly ># Looks like you failed 2 tests of 2. >t/lsid-authority-NamespaceResolver..........dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/lsid-authority-PredicateResolver..........# Failed test >(t/lsid-authority-PredicateResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::PredicateResolver'. ># Error: Can't locate XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/PredicateResolver.pm >line 5. >t/lsid-authority-PredicateResolver..........NOK 1# BEGIN failed--compilation >aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/PredicateResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Looks like you failed 1 tests of 1. >t/lsid-authority-PredicateResolver..........dubious > Test returned status 1 (wstat 256, 0x100) >DIED. FAILED test 1 > Failed 1/1 tests, 0.00% okay >t/lsid-authority-RDFConfigure...............ok >t/lsid-authority-RelationshipResolver.......# Failed test >(t/lsid-authority-RelationshipResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::RelationshipResolver'. >t/lsid-authority-RelationshipResolver.......NOK 1# Error: Can't locate >XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/RelationshipResolver.pm >line 5. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/RelationshipResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/lsid-authority-RelationshipResolver.t at line 25) ># >MOBY::lsid::authority::RelationshipResolver->can('resolve_relationshiptype') >failed ># RelationshipResolver didn't implement full API >t/lsid-authority-RelationshipResolver.......NOK 2# Looks like you failed 2 >tests >of 2. >t/lsid-authority-RelationshipResolver.......dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/lsid-authority-ServiceInstanceResolver....skipped > all skipped: Skip until apparent namespace pollution fixed in >ServiceInstanceResolver >t/lsid-authority-ServiceResolver............# Failed test >(t/lsid-authority-ServiceResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::ServiceResolver'. >t/lsid-authority-ServiceResolver............NOK 1# Error: Can't locate >XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/ServiceResolver.pm >line 5. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/ServiceResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Looks like you failed 1 tests of 1. >t/lsid-authority-ServiceResolver............dubious > Test returned status 1 (wstat 256, 0x100) >DIED. FAILED test 1 > Failed 1/1 tests, 0.00% okay >t/Template..................................skipped > all skipped: This is just a template >Failed Test Stat Wstat Total Fail Failed List of >Failed >------------------------------------------------------------------------------- >t/Central.t 2 512 2 2 100.00% 1-2 >t/dbConnect.t 2 512 2 2 100.00% 1-2 >t/lsid-authority-ClassResolver.t 2 512 2 2 100.00% 1-2 >t/lsid-authority-NamespaceResolve 2 512 2 2 100.00% 1-2 >t/lsid-authority-PredicateResolve 1 256 1 1 100.00% 1 >t/lsid-authority-RelationshipReso 2 512 2 2 100.00% 1-2 >t/lsid-authority-ServiceResolver. 1 256 1 1 100.00% 1 >t/lsid-authority-dbConnect.t 1 256 1 1 100.00% 1 >3 tests skipped. >Failed 8/23 test scripts, 65.22% okay. 13/380 subtests failed, 96.58% okay. >*** Error code 29 >make: Fatal error: Command failed for target `test_dynamic' > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Feb 16 12:58:23 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 09:58:23 -0800 Subject: [MOBY-dev] Cleaning out the registry Message-ID: <1140112703.28350.46.camel@bioinfo.icapture.ubc.ca> Hi All, As you have read, Martin and I are discussing the problem of cleaning up the registry. Though MOBY was not intended to be curated per se, it isThere are four kinds of "bad" services in the registry right now: 1) Services that are registered using some form of the word "test" in their service name, service type, object name, and or namespace. 2) Services that do not work at all - 404 errors, or other clear indications that the service is simply dead. 3) Services that return invalid data-types (according to the recent revision of the Object ontology). 4) Services that may function perfectly well, but have been registered entirely incorrectly (e.g. require plain-text input, but have been registered as accepting base Object a input). There are a HUGE number of these in there, and they are quite annoying... Regarding (1) and (2): The main public registry is not intended to be a laboratory, nor a lavatory! I intend to remove these nuisance services without any warning unless someone strongly objects and has a good reason for objecting... even so, as the host of my instance of the registry, I feel it is within my jurisdiction to do my best to keep it clean and make it useful, so the objection will have to be VERY good... Regarding (3): Martin and I discussed this on-list the other day, and I think it is appropriate that we contact the service provider as we discover these errors, and if the service provider doesn't fix the error in a reasonable time, then we delete the service. At some point this will become automated, when we begin adding sample input and output data to the Service Instance RDF (an RFC will be sent to the list in a few weeks relating to this) Regarding (4): I am loathe to fix the registration parameters of other people's service, even in cases where the correct registration parameters are obvious, because I don't want to become a full-time curator of the Registry. It is also important to not change them because I don't know what tools that service provider may have that are relying on that service signature (even if it is wrong). Moreover, it is important that service providers see their errors, and understand why they are errors, such that their future registrations are correct. Of course, tools like Dashboard are going to make this all a piece of cake, but in the meantime, I will be contacting service providers about services that are obviously registered incorrectly, and I encourage others to do the same :-) However, I will not touch these services. Please send comments ASAP, since I am about to submit a manuscript where the reviewers will be using the registry, and I want to get it cleaned- up as quickly as possible! Best wishes all! Mark -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Feb 16 13:06:22 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 10:06:22 -0800 Subject: [MOBY-dev] [moby] Cleaning out the registry In-Reply-To: <1140112703.28350.46.camel@bioinfo.icapture.ubc.ca> References: <1140112703.28350.46.camel@bioinfo.icapture.ubc.ca> Message-ID: <1140113182.28350.50.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-02-16 at 09:58 -0800, Mark Wilkinson wrote: > As you have read, Martin and I are discussing the problem of cleaning up > the registry. Though MOBY was not intended to be curated per se, it > isThere are four kinds of "bad" services in the registry right now: I didn't finish my sentence there - I mean to say "it is becoming so cluttered as to be almost unusable for some tasks." M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Feb 16 13:28:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 10:28:20 -0800 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object Message-ID: <1140114500.28350.70.camel@bioinfo.icapture.ubc.ca> Hi again, On a related note: There are obviously other "rubbish" entities in the Object ontology, and I will not feel guilty for removing those either. However, just as in the service instance registry, there are some Objects in the ontology that are not "rubbish", but do not reflect best-practices (yes, I know... this has to be defined somewhere in writing, and it is not at the moment...). Martin, Richard and I had a (heated :-) ) discussion about one of these "best practices" over Christmas, and I don't think we came to a resolution, so I don't want to take any preemptive action. I'd prefer to have the discussion in the open community such that (a) we all learn a little bit about the various ways that MOBY can be used/mis-used, and (b) so that we can, as a community, decide what the definition of "mis- used" is going be. Here is my position statement - please feel free to attack it or support it: Statement: Any Object that is registered as deriving from base Object, without any HAS or HASA relationships, should be considered invalid. Rationale: Base "Object" is used exclusively for passing identifiers. Extending base Object, without making it more complex, can only (IMO) indicate that you are attempting to create a specific type of identifier container. This is the role of the Namespace (the Namespace ontology being a list of types of identifiers, and their meanings). It is incorrect use of the Object (syntax) ontology to imply that a given Syntax is specific to a particular type of identifier. The Object and Namespace ontologies are mutually exclusive. My proposal: The Registry should trap attempts to register Objects that derive from base Object without any additional syntactic complexity, and refuse to register them. Thoughts? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Thu Feb 16 19:19:08 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 00:19:08 +0000 (GMT) Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <1140114500.28350.70.camel@bioinfo.icapture.ubc.ca> Message-ID: > Here is my position statement - please feel free to attack it or support > it: > I am not going to attack it, and I am far away from supporting it. > Statement: Any Object that is registered as deriving from base Object, > without any HAS or HASA relationships, should be considered invalid. > My position is clear here, and without any heat in my heart (my heart has already burned in the pre-xmas discussion you mentioned) I just state that this is unacceptable for me. > My proposal: The Registry should trap attempts to register Objects that > derive from base Object without any additional syntactic complexity, and > refuse to register them. > Which would mean (IMO), at least, to loose quite a chunk of Biomoby users and developers. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Feb 16 19:34:01 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 16:34:01 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: <1140136441.28350.139.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-17 at 00:19 +0000, Martin Senger wrote: > My position is clear here, and without any heat in my heart (my heart > has already burned in the pre-xmas discussion you mentioned) I just state > that this is unacceptable for me. I made the argument from my perspective, but I'd like your counter- argument to be known and clearly understood by the community. The two approaches to the use of the MOBY Object ontology are not entirely interoperable with each other, so it is important for everyone two know why they might want to chose one philosophy or the other before making a decision on how to construct their services. but you will feel no heat from me either :-) Only respectful discussion and (perhaps) disagreement. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Thu Feb 16 21:53:04 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 02:53:04 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <1140136441.28350.139.camel@bioinfo.icapture.ubc.ca> Message-ID: > I made the argument from my perspective, but I'd like your counter- > argument to be known and clearly understood by the community. > Okay, here we go: * I prefer to have semantics (if I accept that they can be any semantics in computers) in the object names because they have mechanism of inheritance and containment - while namespaces do not. * I made my decision also because of the lack of description how to use namespaces at all (it was never documented). > The two approaches to the use of the MOBY Object ontology are not > entirely interoperable with each other > I think they are, I do not see any harm to have both concepts sitting in the same registry. My bottom line is: This is not a question that we need to agree on (like asynchonous API or error handling - which *must* be accepted by any service). I would rather advocate the principle "live and let live". But you are right that we should to explain about the concepts we decided to take - especially for newcomers. We have it available in the GCP CropWiki (and if it is not yet fully up-to-date it will be in the due time). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Feb 16 22:02:37 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 03:02:37 +0000 (GMT) Subject: [MOBY-dev] Cleaning out the registry In-Reply-To: <1140112703.28350.46.camel@bioinfo.icapture.ubc.ca> Message-ID: > Please send comments ASAP, since I am about to submit a manuscript where > I agree with the approach you suggested. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Feb 16 22:56:09 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 19:56:09 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: On Thu, 16 Feb 2006 18:53:04 -0800, Martin Senger wrote: > * I prefer to have semantics (if I accept that they can be any > semantics in computers) in the object names because they have mechanism > of inheritance and containment - while namespaces do not. Could we find common ground if we made an API change that resulted in the Namespace ontology being hierarchical rather than flat? If I understand the problem you are trying to solve, this would make a significant difference - but would it make *enough* difference that you wouldn't have to create more specific types of simple Objects? You have thought through your solution from beginning to end, and I haven't, so I don't want to presume. Though I agree that the "live and let live" solution doesn't do anyone any harm, it would enhance interoperability if we were all using the same philosophy to build the objects that we are supposed to be sharing... M From Pieter.Neerincx at wur.nl Fri Feb 17 05:32:36 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 17 Feb 2006 11:32:36 +0100 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> Hi all, I'm with Martin here. I have quite a few Objects that inherit from the base Object without having any HAS or HASA relationships. Most of them are very generic things like for example "Program", "DataBase" and "User". They can have different IDs and have different namespaces depending on the service they are used for. And the namespace alone is not enough. Within the same namespace I can have multiple things which are only an ID, but one pointing to a user and another pointing to a program and I think it's to be able to see the difference directly from the name of the element instead of adding all kind of child elements that only cause more overhead in XML parsing. Just my ? 2c, Pi On 17-Feb-2006, at 1:19 AM, Martin Senger wrote: >> Here is my position statement - please feel free to attack it or >> support >> it: >> > I am not going to attack it, and I am far away from supporting it. > >> Statement: Any Object that is registered as deriving from base >> Object, >> without any HAS or HASA relationships, should be considered invalid. >> > My position is clear here, and without any heat in my heart (my > heart > has already burned in the pre-xmas discussion you mentioned) I just > state > that this is unacceptable for me. > >> My proposal: The Registry should trap attempts to register >> Objects that >> derive from base Object without any additional syntactic >> complexity, and >> refuse to register them. >> > Which would mean (IMO), at least, to loose quite a chunk of Biomoby > users and developers. > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Feb 17 09:12:35 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 17 Feb 2006 15:12:35 +0100 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> Message-ID: <68287F71-664B-405C-B27D-0EA9104BA744@wur.nl> On 17-Feb-2006, at 11:32 AM, Pieter Neerincx wrote: Oops missed an essential word there: > Within the same namespace I can have multiple things > which are only an ID, but one pointing to a user and another pointing > to a program and I think it's *GOOD* to be able to see the difference > directly from the name of the element instead of adding all kind of > child elements that only cause more overhead in XML parsing. > From francis_gibbons at hms.harvard.edu Fri Feb 17 09:19:35 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 17 Feb 2006 09:19:35 -0500 Subject: [MOBY-dev] Fwd: Re: Fwd: Re: [MOBY-l] error when do make test Message-ID: <5.2.1.1.2.20060217091459.011b2de0@email.med.harvard.edu> > > > > Sorry, I should have checked before asking... I did not know that > it is > > >about CVS, I thought that it is for Mark's Perl magics. > > > > OK - well, I was going to offer to make some links on this page, but it's > > not under CVS, so Mark or Simon will have to do it. > > > I have checked again - and I see that actually I was right! The link to >"Latest Code Release" is only to the package with Perl, there is no Java >at all. So it is very confusing... I think we should separate it to to >links (the java would be the one I gave you: >http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/CVS.html). Martin, You're quite right - I had confused the "Getting the code" in the main field on that page, with "Latest code release", in tiny text in the sidebar on the right-hand side of the page. Yes, it points only to Perl releases. I'd like to help, but don't have access to that page - it's one of the few top-level pages that are not under CVS control. As Documentation Guy I guess it would fall to me to fix this, but I don't have access to that particular page. Mark - what's the best solution here, I see three possibilities: 1. You make the changes, as Martin requests. 2. I gain access to the webserver, and make the changes 3. (my favourite) the entire website goes into CVS, and changes can be made by any developer. If you're worried about security, only developers will be able to check in changes, and we can always roll things back if undesirable changes get made. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Fri Feb 17 09:28:40 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 14:28:40 +0000 (GMT) Subject: [MOBY-dev] Fwd: Re: Fwd: Re: [MOBY-l] error when do make test In-Reply-To: <5.2.1.1.2.20060217091459.011b2de0@email.med.harvard.edu> Message-ID: Frank, Many thanks for help and involvement. It is good that you are managing docs. It is not an easy task... > 3. (my favourite) the entire website goes into CVS, and changes can be made > by any developer > I strongly second this option. "Open-source" and "Open-content" are similar in a sense that both concepts should be supported by us... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From simont at hmgc.mcw.edu Fri Feb 17 11:10:49 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Fri, 17 Feb 2006 10:10:49 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> Message-ID: Hi Frank, I tweaked the style sheet for the search results so now the headers are in the same blue as the other links and if you mouse over they go a little darker and have an underline - same as the other links on the page. Hopefully this should make things a little easier to follow, let me know what you think. Cheers, Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 10, 2006, at 1:30 PM, Frank Gibbons wrote: > Simon, > > That's a big improvement on what we had before. Can we tweak the > style a > little though? If I search for "constructing", I get a single > result, which > looks like plain text. It's not until I mouse over the heading > "BioMoby > Perl Service Providers Tutorial" that I realise it's a link. That's > becuase > it's just big bold black text. Is there some way to format the > results, so > that the heading comes out as something that's more obviously a link? > (Color being the usual indicator for a link, my vote would be that it > follow the style of the other links on the page.) > > Great work, > > -Frank > > > At 01:43 PM 2/10/2006, you wrote: >> Hi Mark, >> >> I might have missed the first part of this but it should be possible >> to add in functionality to search static pages too - I did this via a >> plug-in for one of my own wordpress installations. Im not sure where >> the CVS_CONTENT folder is in relation to the wordpress file hierarchy >> but I'll log in and see if I installed the plugin on the MOBY site >> and if not, I'll add it in and we'll see what happens... >> >> Simon. >> >> >> -- >> >> Simon N. Twigger, Ph.D. >> Assistant Professor, Department of Physiology >> Medical College of Wisconsin >> 8701 Watertown Plank Road, >> Milwaukee, WI, USA >> tel: 414-456-8802 >> fax: 414-456-6595 >> AIM/iChat: simontatmcw >> >> >> On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: >> >>> I take that back - it does work! However, it only searches through >>> what >>> has been "blogged", not through the full content of the site >>> (i.e. it >>> excludes what is in the CVS_CONTENT folder) >>> >>> I don't know how easy it would be to modify this behaviour, as the >>> search utility is part of Wordpress... >>> >>> M >>> >>> >>> -- >>> -- >>> ...his last words were 'Hey guys! Watch this!' >>> -- >>> Mark Wilkinson >>> Asst. Professor >>> Dept. of Medical Genetics >>> University of British Columbia >>> PI in Bioinformatics >>> iCAPTURE Centre >>> St. Paul's Hospital >>> Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "For most of this century we have viewed communications as a >>> conduit, >>> a pipe between physical locations on the planet. >>> What's happened now is that the conduit has become so big and >>> interesting >>> that communication has become more than a conduit, >>> it has become a destination in its own right..." >>> >>> Paul Saffo - Director, Institute for the Future >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Fri Feb 17 11:28:14 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 17 Feb 2006 09:28:14 -0700 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> Message-ID: <43F5F99E.8090609@ucalgary.ca> I support Martin's position, but would add a caveat: since we are all sharing the same ontology, it would be nice if no one hogged the generic words like "Person" and "DataBase" if they are specific to their services instead of generic objects representing any Person or DataBase. Perhaps DutchPerson or DutchDatabase in your app Pieter? Well maybe not, but you get the idea... :-) 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. I think proper namespace restriction in service registration is a bigger issue than people creating new name-only ontology objects... My CAN $0.02. >Hi all, > >I'm with Martin here. I have quite a few Objects that inherit from >the base Object without having any HAS or HASA relationships. Most of >them are very generic things like for example "Program", "DataBase" >and "User". They can have different IDs and have different namespaces >depending on the service they are used for. And the namespace alone >is not enough. Within the same namespace I can have multiple things >which are only an ID, but one pointing to a user and another pointing >to a program and I think it's to be able to see the difference >directly from the name of the element instead of adding all kind of >child elements that only cause more overhead in XML parsing. > >Just my ? 2c, > >Pi > >On 17-Feb-2006, at 1:19 AM, Martin Senger wrote: > > > >>>Here is my position statement - please feel free to attack it or >>>support >>>it: >>> >>> >>> >> I am not going to attack it, and I am far away from supporting it. >> >> >> >>>Statement: Any Object that is registered as deriving from base >>>Object, >>>without any HAS or HASA relationships, should be considered invalid. >>> >>> >>> >> My position is clear here, and without any heat in my heart (my >>heart >>has already burned in the pre-xmas discussion you mentioned) I just >>state >>that this is unacceptable for me. >> >> >> >>>My proposal: The Registry should trap attempts to register >>>Objects that >>>derive from base Object without any additional syntactic >>>complexity, and >>>refuse to register them. >>> >>> >>> >> Which would mean (IMO), at least, to loose quite a chunk of Biomoby >>users and developers. >> >> Martin >> >>-- >>Martin Senger >> email: martin.senger at gmail.com >> skype: martinsenger >>consulting for: >> International Rice Research Institute >> Biometrics and Bioinformatics Unit >> DAPO BOX 7777, Metro Manila >> Philippines, phone: +63-2-580-5600 (ext.2324) >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev >> >> > > >Wageningen University and Research centre (WUR) >Laboratory of Bioinformatics >Transitorium (building 312) room 1034 >Dreijenlaan 3 >6703 HA Wageningen >The Netherlands >phone: 0317-483 060 >fax: 0317-483 584 >mobile: 06-143 66 783 >pieter.neerincx at wur.nl > > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev > > From simont at hmgc.mcw.edu Fri Feb 17 12:01:56 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Fri, 17 Feb 2006 11:01:56 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <5.2.1.1.2.20060217115136.022246f8@email.med.harvard.edu> References: <5.2.1.1.2.20060217113413.0219f938@email.med.harvard.edu> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> <5.2.1.1.2.20060217113413.0219f938@email.med.harvard.edu> <5.2.1.1.2.20060217115136.022246f8@email.med.harvard.edu> Message-ID: The 404 search problem should be fixed now too. I hard coded the search URL to point to the top level page so now it works everywhere rather than having the subdirectory path added in. Im not sure that I'm not messing up some functionality - maybe it was meant to search only within a particular set of pages... Anyway, it wasn't working before and now at least it will search as expected. I have the same problem on all my other wordpress sites now I look at them. Perhaps upgrading to v2 will fix some of these things. Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 17, 2006, at 10:51 AM, Frank Gibbons wrote: > Yeah, reloading did the trick - nice! > > -Frank > > At 11:47 AM 2/17/2006, you wrote: >> Try reloading the page and the style sheet changes should kick in. I >> had the same observation when I made the changes initially. >> >> I see what you mean about the search problem - the URL for the search >> script is incorrect on these other pages, I'll see what I can do to >> fix that. >> >> S. >> >> -- >> >> Simon N. Twigger, Ph.D. >> Assistant Professor, Department of Physiology >> Medical College of Wisconsin >> 8701 Watertown Plank Road, >> Milwaukee, WI, USA >> tel: 414-456-8802 >> fax: 414-456-6595 >> AIM/iChat: simontatmcw >> >> > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 http:// > llama.med.harvard.edu/~fgibbons From markw at illuminae.com Fri Feb 17 12:07:36 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 17 Feb 2006 09:07:36 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <43F5F99E.8090609@ucalgary.ca> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> <43F5F99E.8090609@ucalgary.ca> Message-ID: <1140196056.32702.29.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-17 at 09:28 -0700, Paul Gordon wrote: > object without dying a horrible death. I think proper namespace > restriction in service registration is a bigger issue than people > creating new name-only ontology objects... I agree, and I believe that much of this confusion is happening because: 1) My fault - insufficient documentation of what the namespace *means* in MOBY. It's discussed in publications and such, but not discussed clearly in the tutorials. 2) My fault - the Namespaces have been modelled incorrectly (IMO) right from the start as a flat list, because of our need (or at least desire) to be compatible with the GO community. I think this has to change - we either have to break away from them again, or better, bring them with us. Either way, we need to allow for hierarchical namespaces such that people do not need to mix the semantics of what an object represents (the Namespace) with the syntax of how it is represented (the Object) The short-term gain that people are observing by creating domain- specific Objects is just that - short term gain. It is not an extensible solution, since it leads to a combinatorial explosion of data-types: Object DatabaseObject GenbankObject GenbankSequence GenbankDNASequence GenbankAASequence EMBLObject EMBLSequence EMBLDNASequence EMBLAASequence PDBObject PDBSequence etc. etc. From the Rectorian ontology-philosophy, this is a perfect example of the "exploding bicycle", and the end result is well documented and disasterous! Even in that example, there would be no way to discover a Blast service that operated on GenericSequence objects if you had a GenbankDNASequence object in-hand. I **desperately** want to solve this problem. The discussion over the past couple of days has revealed that there is a serious need for a rapid solution since several of our key users are already starting down this path. I maintain that the solution is NOT to generate domain-specific objects, but rather to model the orthogonal Namespace ontology properly, and facilitate hierarchical searching over Namespaces in the registry, such that creating these mixed objects is no longer necessary. If I am understanding correctly the reason why people are creating these objects, then this srikes me as being the Right Thing to do. Am I mis-interpreting the problem? If so, please explain it to me. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From rebecca.ernst at gsf.de Fri Feb 17 11:42:55 2006 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Fri, 17 Feb 2006 17:42:55 +0100 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> Message-ID: <43F5FD0F.9000903@gsf.de> Hi all! I go with Mark in this discussion. If, like Pieter explained here, one ID is pointing to a user and another to a program this should be specified in the namespace. Like namespace_user and namespace_program. I usually compare the namespace/id principle with phonenumbers. If someone tells you his phonenumber '77345' this is not sufficient but together with a namespace 'area-code' this is a valid pair of information. If I get it right Pieter and Martin want is a namespace 'City' which can then be used for objects 'phonenumber', 'citycode', 'adress', etc. I believe that this is not what namespaces (and objects) are meant to be. Cheers, Rebecca Pieter Neerincx wrote: >Hi all, > >I'm with Martin here. I have quite a few Objects that inherit from >the base Object without having any HAS or HASA relationships. Most of >them are very generic things like for example "Program", "DataBase" >and "User". They can have different IDs and have different namespaces >depending on the service they are used for. And the namespace alone >is not enough. Within the same namespace I can have multiple things >which are only an ID, but one pointing to a user and another pointing >to a program and I think it's to be able to see the difference >directly from the name of the element instead of adding all kind of >child elements that only cause more overhead in XML parsing. > >Just my ? 2c, > >Pi > >On 17-Feb-2006, at 1:19 AM, Martin Senger wrote: > > > >>>Here is my position statement - please feel free to attack it or >>>support >>>it: >>> >>> >>> >> I am not going to attack it, and I am far away from supporting it. >> >> >> >>>Statement: Any Object that is registered as deriving from base >>>Object, >>>without any HAS or HASA relationships, should be considered invalid. >>> >>> >>> >> My position is clear here, and without any heat in my heart (my >>heart >>has already burned in the pre-xmas discussion you mentioned) I just >>state >>that this is unacceptable for me. >> >> >> >>>My proposal: The Registry should trap attempts to register >>>Objects that >>>derive from base Object without any additional syntactic >>>complexity, and >>>refuse to register them. >>> >>> >>> >> Which would mean (IMO), at least, to loose quite a chunk of Biomoby >>users and developers. >> >> Martin >> >>-- >>Martin Senger >> email: martin.senger at gmail.com >> skype: martinsenger >>consulting for: >> International Rice Research Institute >> Biometrics and Bioinformatics Unit >> DAPO BOX 7777, Metro Manila >> Philippines, phone: +63-2-580-5600 (ext.2324) >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev >> >> > > >Wageningen University and Research centre (WUR) >Laboratory of Bioinformatics >Transitorium (building 312) room 1034 >Dreijenlaan 3 >6703 HA Wageningen >The Netherlands >phone: 0317-483 060 >fax: 0317-483 584 >mobile: 06-143 66 783 >pieter.neerincx at wur.nl > > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From senger at ebi.ac.uk Fri Feb 17 12:21:31 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 17:21:31 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <1140196056.32702.29.camel@bioinfo.icapture.ubc.ca> Message-ID: > Am I mis-interpreting the problem? If so, please explain it to me. > Yes, you are. The problem is that you want to remove things from registry if you do not like how they are created. If our objects will not be easy discoverable, fine, our decision. And you can make your objects as good as you wish. You are mixing subjects: "what to allow" and "what to recommend". Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 17 12:46:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 17 Feb 2006 09:46:53 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: <1140198413.32702.65.camel@bioinfo.icapture.ubc.ca> I don't want to remove things from the registry! I want to find a solution to the problem you are experiencing that also enhances the interoperability between your services and the services of others - this is clearly of mutual benefit. For your objects to not be easily discovered is, of course, entirely your business... but wouldn't it be better if they were? M On Fri, 2006-02-17 at 17:21 +0000, Martin Senger wrote: > > Am I mis-interpreting the problem? If so, please explain it to me. > > > Yes, you are. The problem is that you want to remove things from > registry if you do not like how they are created. If our objects will not > be easy discoverable, fine, our decision. And you can make your objects as > good as you wish. You are mixing subjects: "what to allow" and "what to > recommend". > > Martin > -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Feb 17 12:52:31 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 17:52:31 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <1140198413.32702.65.camel@bioinfo.icapture.ubc.ca> Message-ID: > I don't want to remove things from the registry! > Good. So my problem is solved :-) > others - this is clearly of mutual benefit. For your objects to not be > easily discovered is, of course, entirely your business... but wouldn't > it be better if they were? > Of course. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 17 14:25:26 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 17 Feb 2006 11:25:26 -0800 Subject: [MOBY-dev] New website parts of the CVS Message-ID: <1140204326.754.19.camel@bioinfo.icapture.ubc.ca> Hi all, Responding to the discussion of a misleading link to "code releases" there are now three links in the right panel of the homepage: 1) Code releases -> moby-live/Docs/ProjectDocs/Releases 2) General Docs -> moby-live/Docs/ProjectDocs 3) CVS Repository -> view.cgi CVS viewer v.v. editing the website in general: The website is not run as a dictatorship - anyone who wants to be able to edit the Wordpress pages is welcome to ask Simon for a password - however to put the entire website into the CVS is just begging to return to the state we were in before where the pages are hard to maintain and generally unstyled and "ugly". We get a LOT of benefit from having the core pages under Wordpress, and Simon put a lot of effort into setting this up. I don't see the need to throw the baby out with the bathwater for the sake of giving an appearance of openness that, in fact, already exists. I would prefer that we thank Simon for his efforts and work within the framework that he has set up for us, rather than against it. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Sat Feb 18 09:50:04 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 18 Feb 2006 14:50:04 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: Message-ID: Mark, Do I understand correctly that you have started to remove some services from the registry? (I may be wrong - perhaps my services diaappeared from a different reasons.) If it is true, you probably also removed services that had URL pointing to the localhost. This may seem correct, but it is not. It is true that such services cannot be used by other users, but they had been there as part of tutorial - for service developers that *have* these sample services on their local machines. Could you clarify what steps (if any) have you taken? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Sun Feb 19 12:47:32 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sun, 19 Feb 2006 18:47:32 +0100 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <43F5F99E.8090609@ucalgary.ca> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> <43F5F99E.8090609@ucalgary.ca> Message-ID: On 17Feb2006, at 17:28, Paul Gordon wrote: > I support Martin's position, but would add a caveat: since we are all > sharing the same ontology, it would be nice if no one hogged the > generic > words like "Person" and "DataBase" if they are specific to their > services instead of generic objects representing any Person or > DataBase. Perhaps DutchPerson or DutchDatabase in your app Pieter? > Well maybe not, but you get the idea... :-) Don't worry, I realize that the power of the ontology is the level of recycle-ability of objects. If everybody designs yet another object specific to their services, building workflows will be just as difficult with as without ontology. Therefore a "DataBase" or "User" object should be generic. If I need some kind of specialized "DutchBase" object specific for a certain service I'll create a new one that inherits from the "base" DataBase object and/or I'll restrict the namespaces. > > 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. I think proper namespace > restriction in service registration is a bigger issue than people > creating new name-only ontology objects... You are absolutely right! Add to that dead services and improper registered services and it can be pretty difficult for BioMOBY newbies to find some working workflow examples. > > My CAN $0.02. Looks like we could use a BioMOBY currency converter service :) Pi > >> Hi all, >> >> I'm with Martin here. I have quite a few Objects that inherit from >> the base Object without having any HAS or HASA relationships. Most of >> them are very generic things like for example "Program", "DataBase" >> and "User". They can have different IDs and have different namespaces >> depending on the service they are used for. And the namespace alone >> is not enough. Within the same namespace I can have multiple things >> which are only an ID, but one pointing to a user and another pointing >> to a program and I think it's to be able to see the difference >> directly from the name of the element instead of adding all kind of >> child elements that only cause more overhead in XML parsing. >> >> Just my ? 2c, >> >> Pi >> >> On 17-Feb-2006, at 1:19 AM, Martin Senger wrote: >> >> >> >>>> Here is my position statement - please feel free to attack it or >>>> support >>>> it: >>>> >>>> >>>> >>> I am not going to attack it, and I am far away from supporting it. >>> >>> >>> >>>> Statement: Any Object that is registered as deriving from base >>>> Object, >>>> without any HAS or HASA relationships, should be considered >>>> invalid. >>>> >>>> >>>> >>> My position is clear here, and without any heat in my heart (my >>> heart >>> has already burned in the pre-xmas discussion you mentioned) I just >>> state >>> that this is unacceptable for me. >>> >>> >>> >>>> My proposal: The Registry should trap attempts to register >>>> Objects that >>>> derive from base Object without any additional syntactic >>>> complexity, and >>>> refuse to register them. >>>> >>>> >>>> >>> Which would mean (IMO), at least, to loose quite a chunk of >>> Biomoby >>> users and developers. >>> >>> Martin >>> >>> -- >>> Martin Senger >>> email: martin.senger at gmail.com >>> skype: martinsenger >>> consulting for: >>> International Rice Research Institute >>> Biometrics and Bioinformatics Unit >>> DAPO BOX 7777, Metro Manila >>> Philippines, phone: +63-2-580-5600 (ext.2324) >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Sun Feb 19 14:09:57 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 19 Feb 2006 19:09:57 +0000 (GMT) Subject: [MOBY-dev] New website parts of the CVS In-Reply-To: Message-ID: > > 2) General Docs -> moby-live/Docs/ProjectDocs > > > Actually, I do not know how to put things there. I have 'cvs update', then edited moby-live/Docs/ProjectDocs/index.html, committed, then run my cronjob on biomoby.org in order to update docs, but nothing changed on the page http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/ProjectDocs/ (where the link you created points to). Where is the problem? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Feb 20 01:03:59 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 20 Feb 2006 06:03:59 +0000 (GMT) Subject: [MOBY-dev] biomoby.org down? Message-ID: Is this just my local problem? My browser connects, but then is "waiting for biomoby.org" indefinitely... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Feb 20 09:36:47 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 20 Feb 2006 06:36:47 -0800 Subject: [MOBY-dev] biomoby.org down? In-Reply-To: References: Message-ID: Looks like it is failing DNS lookup. I'll tell Chris. M On Sun, 19 Feb 2006 22:03:59 -0800, Martin Senger wrote: > Is this just my local problem? My browser connects, but then is "waiting > for biomoby.org" indefinitely... > > Martin > From edward.kawas at gmail.com Mon Feb 20 10:28:18 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 20 Feb 2006 07:28:18 -0800 Subject: [MOBY-dev] biomoby.org down? In-Reply-To: Message-ID: <000701c63632$47424d30$6b00a8c0@notebook> I think it's a local problem, I can browse biomoby.org without a cache. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Martin Senger > Sent: Sunday, February 19, 2006 10:04 PM > To: Mark Wilkinson > Cc: Moby Developers > Subject: [MOBY-dev] biomoby.org down? > > Is this just my local problem? My browser connects, but then > is "waiting for biomoby.org" indefinitely... > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Feb 20 11:16:45 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 20 Feb 2006 08:16:45 -0800 Subject: [MOBY-dev] [moby] Re: New website parts of the CVS In-Reply-To: References: Message-ID: <1140452205.19091.7.camel@bioinfo.icapture.ubc.ca> It seems you have solved this problem - the page loads as edited. Correct? M On Sun, 2006-02-19 at 19:09 +0000, Martin Senger wrote: > > > 2) General Docs -> moby-live/Docs/ProjectDocs > > > > > > Actually, I do not know how to put things there. I have 'cvs update', > then edited moby-live/Docs/ProjectDocs/index.html, committed, then run my > cronjob on biomoby.org in order to update docs, but nothing changed on the > page http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/ProjectDocs/ > (where the link you created points to). > Where is the problem? > > Martin > -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Mon Feb 20 11:18:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 20 Feb 2006 08:18:10 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> <43F5F99E.8090609@ucalgary.ca> Message-ID: <1140452290.19091.9.camel@bioinfo.icapture.ubc.ca> On Sun, 2006-02-19 at 18:47 +0100, Pieter Neerincx wrote: > > My CAN $0.02. > > Looks like we could use a BioMOBY currency converter service :) Yes... if we all want to go bankrupt! ;-) M From edward.kawas at gmail.com Mon Feb 20 15:42:38 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 20 Feb 2006 12:42:38 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks Message-ID: <000301c6365e$30fe3670$9d66a8c0@notebook> Hi, The RDF agent that we have heard so much about will begin 'crawling' in 2 weeks starting Monday March 6, 2006. As a service provider, your only task will be to generate one or more RDF documents describing your service(s) and to place that document somewhere reachable from the outside world. If you no longer wish to host that service, then removing its description from the document will effectively deregister the service. The place to obtain your service RDF is from the following url: http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm This page will update your service signature URL location. In 2 weeks, the agent will start removing services that do not have a signature url specified for it. The agent is also configured to remove any service that fails to uphold to the latest API, as specified on biomoby.org. Specifically, the agent is looking for un-named inputs or outputs (i.e. simples or collections without article names). However, if a service was modified, then the agent will use the API to re-register it and if the service was invalid for other reasons, the registry will reject that particular service. In 2 weeks, the agent will attempt to read from the signature url that you provided. If the agent cannot read from the url on 3 (maybe more or less - details will be revealed later) different consecutive occasions, then the agent will remove all services described by that url. The agent will then, depending on configuration, email the service provider and detail what happened to cause their service deregistration. If the deregistration was in error, service providers will be able to reregister their services very easily. Contained in the email message to the provider is RDF-XML that describes the last known footprint of their service. Using this RDF-XML, and a tool to be released soon, you can re-register your service in any registry. As a service provider, you are free to add any valid RDF statements to your document. At the very least, the document must contain statements with predicates found at http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/moby_me tadata. All other statements are ignored by the agent. If you end up modifying the RDF-XML, and you want to verify that the XML is valid, you could always use the following tool to validate and visualize your RDF document: http://www.w3.org/RDF/Validator/. If you are new to RDF and you do make changes to the document, it's highly recommended to check your document with this tool. A common error is placing multiple tags within a single file. This is not allowed and will result in parsing errors. This error is usually achieved by downloading multiple RDF documents and then placing the contents of each document into one document. Those of you that wish to consolidate RDF documents should consolidate the contents between the tags. All questions and concerns regarding this agent should be posted to the list so that they can be discussed amongst us all. Thanks, Eddie From senger at ebi.ac.uk Mon Feb 20 19:52:34 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 00:52:34 +0000 (GMT) Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000301c6365e$30fe3670$9d66a8c0@notebook> Message-ID: Eddie, I have not seen an answer to the most pertinent question that we always had about the RDF agent: How can we ask it to come? And how often does it come if we do not ask? And please do not tell me that I cannot ask - if that would be the case, please do not start it yet. > In 2 weeks, the agent will start removing services that do not have a > signature url specified for it. > I strongy oppose this - and I said it several times. Please do not do that. It was never said that services must have the signature URL - it was always said that services without such signature are vulnerable to be remove by some malicious guys. But a mandatory existence of such signature URL has never been in the Biomoby API, and if you do what you are saying, it is breaking API without consulting us/users. It is related to the question above: if I have a way to ask an agent to come at once (by at once I mean in seconds) I am not afraid to put signature url in the service. If not, I cannot edit my service anymore and I am not willing to put there the signature. > In 2 weeks, the agent will attempt to read from the signature url that you > provided. If the agent cannot read from the url on 3 (maybe more or less - > details will be revealed later) different consecutive occasions, then the > agent will remove all services described by that url. > Again, this should not be done so rigidly. I simply need, for example, few services, that are registered to the localhost (so they will never be used by reasonably clever clients) but they are used in tutorials, and they can be used when a service is being developed (so it can be called via registry by its author, because she has the service on her local machine). There will never be many of such services, but they should stay. I also do not like your wording "details will be revealed later". This sounds like a typical dictatorship. > If the deregistration was in error, service providers will be able to > reregister their services very easily. Contained in the email message to the > provider is RDF-XML that describes the last known footprint of their > service. Using this RDF-XML, and a tool to be released soon, you can > re-register your service in any registry. > This is a home-made addition to the Biomoby API - we have never discussed it. We need a way that can be automatized - so if I need to react to the email message, I need to know first exact format of such email etc. This is doable but needs to be discussed. > All questions and concerns regarding this agent should be posted to the list > so that they can be discussed amongst us all. > Thanks, that's encouraging. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Feb 20 19:53:46 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 00:53:46 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: New website parts of the CVS In-Reply-To: <1140452205.19091.7.camel@bioinfo.icapture.ubc.ca> Message-ID: > It seems you have solved this problem - the page loads as edited. > Correct? > Yes, problem solved - but I do not know how. Well, it is there now... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 21 03:33:50 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 08:33:50 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: Message-ID: > Could we find common ground if we made an API change that resulted in the > Namespace ontology being hierarchical rather than flat? If I understand > the problem you are trying to solve, this would make a significant > difference - but would it make *enough* difference that you wouldn't have > to create more specific types of simple Objects? > Honestly, I do not know. I even do not fully understand your "combinatorial explosion", and - mainly - why it would not happen with a hierarchy and inheritance within namespaces? That would also mean that we would have two trees, one (roughly speaking) describing syntax (data type tree) and one describing semantics (namapsce tree). That would not be easy to explain, maintain and use... I am tempted to say that I wuold still use data types to express how a reality is related, and I would use namespaces as an additional information - where I would welcome less flat alternative. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Tue Feb 21 09:31:20 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 21 Feb 2006 09:31:20 -0500 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: References: <000301c6365e$30fe3670$9d66a8c0@notebook> Message-ID: <5.2.1.1.2.20060221091746.0110f008@email.med.harvard.edu> Eddie, Mark, Martin, & others, I have to second Martin's comments below. We tried this RDF agent once before, and some of us dutifully followed the link provided to create the RDF, and we placed it in the appropriate spot. Then we found that the agent never came, and we could no longer remove our services at all! I propose that you start the agent before we convert our services - I'd like to see the agent come and visit a few times before I hand over control of my services to it. So I think we need to know the two very specific things that Martin mentions: how often will it come, and how do we ask it to come? The policies don't have to be set in stone, but we need to know what is proposed, and to agree upon it. In particular, for people who are developing services, there has to be a way to cause a service to be registered within a short time (I would propose less than 60 seconds). I'd like to have a dry run, in which I ask the agent to come, and then - hey presto! - there it is, within the required interval. It wouldn't have to do anything, just come over and say 'hi'. As to his second point (that use of RDF-document is now mandatory for services to be considered registered), I also agree: there should at least be some kind of grandfather-clause. People who want the extra security of being able to guarantee that their service will remain registered until they take down the RDF document, should be able to do that; but others, who simply wish to register by function-call should also be able to use that. Is there a reason that both systems cannot coexist? I understand the necessity of cleaning up the registry, and wonder if that is driving this decision on mandatory-RDF, since it would automatically clear out the abandoned services. At the very least (and I contradict myself here), there could be a phase-out/in period, during which services registered under the old system can remain, but all new services must be created using RDF. Then after three (?) months, such old services might be retired - or perhaps kept on indefinitely. They would be the _only_ services which would continue to be deregistered using the function-call syntax - all new registrations would have to use RDF. -F At 07:52 PM 2/20/2006, you wrote: > I have not seen an answer to the most pertinent question that we always >had about the RDF agent: How can we ask it to come? And how often does it >come if we do not ask? > And please do not tell me that I cannot ask - if that would be the >case, please do not start it yet. > > > In 2 weeks, the agent will start removing services that do not have a > > signature url specified for it. > > > I strongy oppose this - and I said it several times. Please do not >do that. It was never said that services must have the signature URL - it >was always said that services without such signature are vulnerable to be >remove by some malicious guys. But a mandatory existence of such signature >URL has never been in the Biomoby API, and if you do what you are saying, >it is breaking API without consulting us/users. PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Tue Feb 21 10:01:13 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 15:01:13 +0000 (GMT) Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000601c636f5$74fea250$6500a8c0@notebook> Message-ID: > I am going to create a test registry soon and you (and everyone else) > can use this registry for these types of services. > I think that a selected authority (in my case net.jmoby.samples) is good enough not to confuse people - and I prefer to use a real registry when I am teching how to use it. Why the address 'localhost' would cause any problems? Every client, including your code in taverna, can easily ignore these services and not to show them... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 21 10:21:10 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 15:21:10 +0000 (GMT) Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000701c636f9$32d2a4e0$6500a8c0@notebook> Message-ID: Thanks for your answer. I am a bit reluctant to contiue with this argument because this is relatively mior issue, comparing to other points I made. Just one more perhaps: > people what moby is, or how to use it when 90% of the services don?t > really 'work'. > If the localhost services will be there and everything else will work, the percentage will be close to 1%. See it in perspective :-) > Sure I can write a client that ignores certain authorities, > but I am not worried about me. > I am - because most people see moby through client you or Mark wrote - so if you two ignore these services, everybody wins. But this is insignificant comparing to the dungeon you two are preparing for us with secret agents :-) [This was a joke, really.] Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Tue Feb 21 10:12:13 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 21 Feb 2006 07:12:13 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: Message-ID: <000701c636f9$32d2a4e0$6500a8c0@notebook> > > > I am going to create a test registry soon and you (and > everyone else) > > can use this registry for these types of services. > > > I think that a selected authority (in my case > net.jmoby.samples) is good enough not to confuse people - and > I prefer to use a real registry when I am teching how to use > it. Why the address 'localhost' would cause any problems? > Every client, including your code in taverna, can easily > ignore these services and not to show them... Using localhost doesn?t cause any problems, and you are right about clients being able to ignore them. My *personal* opinion is that if some na?ve user comes and wants to try out moby and they encounter services that they would like to use, but they are all localhost or point to some unreachable domain, they would probably become frustrated and leave moby alone. The main registry should contain real services. It is very frustrating trying to show people what moby is, or how to use it when 90% of the services don?t really 'work'. Sure I can write a client that ignores certain authorities, but I am not worried about me. Anyways, this is just my opinion. I thought that I would create a test registry so that others could benefit from it without feeling like the main registry was the only place they had to register their test services. Ed > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > From edward.kawas at gmail.com Tue Feb 21 09:45:26 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 21 Feb 2006 06:45:26 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: Message-ID: <000601c636f5$74fea250$6500a8c0@notebook> Hi Martin, > Eddie, > I have not seen an answer to the most pertinent question > that we always had about the RDF agent: How can we ask it to > come? And how often does it come if we do not ask? > And please do not tell me that I cannot ask - if that > would be the case, please do not start it yet. You can indeed call the agent over to visit your signature url. Performing a register service call and only providing the url will cause the agent to visit you right away. > > In 2 weeks, the agent will attempt to read from the > signature url that > > you provided. If the agent cannot read from the url on 3 > (maybe more > > or less - details will be revealed later) different consecutive > > occasions, then the agent will remove all services > described by that url. > > > Again, this should not be done so rigidly. I simply need, > for example, few services, that are registered to the > localhost (so they will never be used by reasonably clever > clients) but they are used in tutorials, and they can be used > when a service is being developed (so it can be called via > registry by its author, because she has the service on her > local machine). There will never be many of such services, > but they should stay. > I also do not like your wording "details will be revealed > later". This sounds like a typical dictatorship. I am going to create a test registry soon and you (and everyone else) can use this registry for these types of services. I personally think that the main registry should not be used for testing, but until we have a real test registry running production code I understand that there may be no other choice. So details to be revealed later meant that I would consult for an appropriate number of times that the agent should have to visit someone before declaring the url invalid. > > If the deregistration was in error, service providers will > be able to > > reregister their services very easily. Contained in the > email message > > to the provider is RDF-XML that describes the last known > footprint of > > their service. Using this RDF-XML, and a tool to be > released soon, you > > can re-register your service in any registry. > > > This is a home-made addition to the Biomoby API - we have > never discussed it. We need a way that can be automatized - > so if I need to react to the email message, I need to know > first exact format of such email etc. This is doable but > needs to be discussed. > You are right, this can be automated. I have created classes that parse RDF into MobyService objects and then using the api, you can register them very easily. As for the message, the rdf is appended to the body of the message. Feel free to ask me more. > > All questions and concerns regarding this agent should be posted to > > the list so that they can be discussed amongst us all. > > > Thanks, that's encouraging. > Martin > Eddie > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > From edward.kawas at gmail.com Tue Feb 21 11:34:58 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 21 Feb 2006 08:34:58 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <5.2.1.1.2.20060221091746.0110f008@email.med.harvard.edu> Message-ID: <000c01c63704$c78c5ee0$6500a8c0@notebook> Hi Frank, > I have to second Martin's comments below. We tried this RDF > agent once before, and some of us dutifully followed the link > provided to create the RDF, and we placed it in the > appropriate spot. Then we found that the agent never came, > and we could no longer remove our services at all! I propose > that you start the agent before we convert our services - I'd > like to see the agent come and visit a few times before I > hand over control of my services to it. This is kind of a chicken and the egg problem. The agent can't visit unless it knows who to visit. It can't know who to visit unless providers convert their services... :-) > So I think we need to know the two very specific things that Martin > mentions: how often will it come, and how do we ask it to > come? The policies don't have to be set in stone, but we need > to know what is proposed, and to agree upon it. In > particular, for people who are developing services, there has > to be a way to cause a service to be registered within a > short time (I would propose less than 60 seconds). I'd like > to have a dry run, in which I ask the agent to come, and then > - hey presto! - there it is, within the required interval. It > wouldn't have to do anything, just come over and say 'hi'. So currently, it is up to the administrator of a registry to set how often the agent would run, if at all, (easily be placed on a cron job). As for manually calling it, right now it can be called by performing a registerService call and only providing the signatureURL. Manually calling it should cause the agent to come instantly. Eddie From francis_gibbons at hms.harvard.edu Tue Feb 21 12:08:41 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 21 Feb 2006 12:08:41 -0500 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000c01c63704$c78c5ee0$6500a8c0@notebook> References: <5.2.1.1.2.20060221091746.0110f008@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> Hi Eddie, At 11:34 AM 2/21/2006, you wrote: >This is kind of a chicken and the egg problem. The agent can't >visit unless it knows who to visit. It can't know who to visit >unless providers convert their services... :-) OK, I understand that it can't make a _routine_ visit unless it knows who to visit. But it should still be possible to call it, even if I haven't registered at all. Perhaps you could set up a form where I could put in my URL, click 'submit' , and then watch my web-logs to see if it comes. Perhaps better yet would be if you could provide some generic RDF, with no service-specific information, which would simply allow the agent to visit, and verify that it can read the RDF. It could then email me that it was able to read this "test RDF" on my site. Who knows, there might be problems not with the agent, but with my local configuration, and it would be nice to be able to verify that the whole infrastructure was working correctly, without complicating it with details of my services. I'm just worried about going through a bunch of trouble to get ready for the agent, and then some unforeseen problem crops up (at either end), and the agent's deployment is delayed by 6 weeks, and in the meantime, I'm unable to change my services. I'm not denigrating the agent, I just have recent personal (painful!) experience of how difficult it can be to debug things "over the wire". -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From edward.kawas at gmail.com Tue Feb 21 12:16:34 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 21 Feb 2006 09:16:34 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> Message-ID: <000d01c6370a$9236bfa0$6500a8c0@notebook> > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Frank Gibbons > Sent: Tuesday, February 21, 2006 9:09 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Notice that the ever elusive agent > will start curating in 2 weeks > > Hi Eddie, > > At 11:34 AM 2/21/2006, you wrote: > >This is kind of a chicken and the egg problem. The agent can't visit > >unless it knows who to visit. It can't know who to visit unless > >providers convert their services... :-) > > OK, I understand that it can't make a _routine_ visit unless > it knows who to visit. But it should still be possible to > call it, even if I haven't registered at all. Perhaps you > could set up a form where I could put in my URL, click > 'submit' , and then watch my web-logs to see if it comes. > Perhaps better yet would be if you could provide some generic > RDF, with no service-specific information, which would simply > allow the agent to visit, and verify that it can read the > RDF. It could then email me that it was able to read this > "test RDF" on my site. Who knows, there might be problems not > with the agent, but with my local configuration, and it would > be nice to be able to verify that the whole infrastructure > was working correctly, without complicating it with details > of my services. This sounds doable. I will create a form that contains a field for a url and an email address. The agent will then parse the rdf located at the url and email the address entered into the form with the details of what it found. Probably, email is not necessary and I could just output to the browser what the agent found. What do you think? > > I'm just worried about going through a bunch of trouble to > get ready for the agent, and then some unforeseen problem > crops up (at either end), and the agent's deployment is > delayed by 6 weeks, and in the meantime, I'm unable to change > my services. I'm not denigrating the agent, I just have > recent personal (painful!) experience of how difficult it can > be to debug things "over the wire". I understand your concerns completely. Eddie > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston > MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From francis_gibbons at hms.harvard.edu Tue Feb 21 12:40:54 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 21 Feb 2006 12:40:54 -0500 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000d01c6370a$9236bfa0$6500a8c0@notebook> References: <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060221123804.0120ea58@email.med.harvard.edu> At 12:16 PM 2/21/2006, you wrote: >This sounds doable. I will create a form that contains a field > for a url and an email address. The agent will then parse the >rdf located at the url and email the address entered into the > form with the details of what it found. Probably, email is not > necessary and I could just output to the browser what the agent >found. What do you think? Hey Eddie, Yeah, you're right email is probably not necessary, but otherwise it sounds good. I guess I was thinking asynchronously, but if the agent can respond quickly, output to the browser would be fine. Since this would just test the functionality, independent of any services, it would be useful if you could provide an RDF stub - correctly formed, but without meaningful content - so a user could verify that all is well. (Mark, did you do something like this last time? I remember the form, just not whether you provided the stub RDF.) Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Feb 21 13:11:42 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 21 Feb 2006 10:11:42 -0800 Subject: [MOBY-dev] [moby] Re: Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> References: <5.2.1.1.2.20060221091746.0110f008@email.med.harvard.edu> <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> Message-ID: <1140545502.30116.36.camel@bioinfo.icapture.ubc.ca> I suppose I should wade in here, though Eddie is doing a great job of making the case :-) Here are my thoughts on the issue, in no particular order: * I would support the proposal to extend the duration over which the agent "visits" but does not de-register. Three months seems reasonable, maybe longer if we discover problems. * The Agent idea has been the most protracted API change we have ever had. The "guts" of the API change were made almost a year ago, the discussions about it have been going on for longer than that, and the registry API has been behaving as if the agent were functional for at least that long (e.g. not being able to deregister services that had a Signature URL). As such, the switch to an agent-based curation system should not come as any surprise, and we should not over-react to it. The changes are not that large given that the API as it exists has already accommodated them, and primarily give us benefit more than they cause barriers. * The move to an RDF signature-based system is an ENORMOUS benefit to us - and we have all agreed on that in previous meetings. It allows us, as service providers, to add additional metadata about our services, and perhaps more importantly, it forms the basis of the LSID resolution for Service Instance LSID's (the service provider themselves becomes the LSID resolution service by putting their signature RDF at the location that they have registered in MOBY Central). * The "immediacy" of calls to MOBY Central should not (if I understand Eddie's changes to the code) be affected. If you want to register a service, you can continue to use the registerService API call. If you want to deregister a service, you simply remove that service RDF signature and it will be deregistered "passively". To "actively" or immediately deregister a service, simply remove the service RDF and call "registerService" passing the SignatureURL. This will invoke the agent to immediately crawl to you, discover that the document is now gone, and deregister your service. This we maintain the immediacy of registration/deregistration but gain the security that only you can deregister your services. * The policy of the curation behaviour of the agent is not hard-coded. Every registry curator can set their own policy in the agent configuration file - individual registry curators may or may not chose to deregister services, or to give more or less warning, or to run the agent more or less often, as they see fit. * The policy of the MOBY Central registry at iCAPTURE is currently being drawn-up. A first draft is available (click on Project Docs on the right side of the moby homepage) for comment. Like any other public resource, the host and curator of that resource must make appropriate decisions that are both sustainable, and provide the maximum benefit to their community given the resources available. As host and curator of the iCAPTURE registry, I will set the policy of this instance of the registry with that goal in mind. Some may consider this being a dictator, some may consider it being responsible. * I do not support "gradfathering", since this will require changes at the code level, and in fact, behavioural changes in the API that would have to be documented. A three-month passive trial period for the Agent sounds like a functionally equivalent but better alternative, particularly since the move to RDF is essential and parallel to our adoption of the LSID resolution system. * I disagree with having to code circumstantial exceptions into the clients (e.g. ignoring localhost). Not only would this exception have to be coded into every client, but in those instances where "localhost" was meaningful and useful (e.g. if you are using Taverna and you are hosting a MOBY Central registry on your own hard drive that Taverna is connecting to) that exception would have to be removed from the client such that you could discover your own services... and moreover, by removing that exception, you then begin to discover services that are "localhost" to someone else's machine... Individual registry hosts can create their own policy on this, but it seems to me that the only feasible way to deal with this problem is for clients to accept localhost whenever they find it, but for registry hosts to determine whether a localhost registration is appropriate in their registry. Those are just the thoughts off the top of my head. I need to drop out of this discussion again for a while as I have a ton of essay marking to do :-) Darn students! They do love to express themselves.... Cheers all! Mark -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From gordonp at ucalgary.ca Wed Feb 22 18:46:28 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 22 Feb 2006 16:46:28 -0700 Subject: [MOBY-dev] Namespace matching Message-ID: <43FCF7D4.9070901@ucalgary.ca> Hi all: Perhaps I am dense, but how can I prevent a findService central API call from finding ALL services that consume a particular object when the object doesn't have a namespace? e.g. Suppose I just built a GenericSequence with some anonymous data I have laying around. I have no namespace or ID for it, it's just a plain old sequence someone typed in: 3 tga When I submit to findService it has the format: GenericSequence But the central server interprets the blank namespace as a wildcard, not a undefined namespace. I want all services that take GenericSequence or VirtualSequence but don't care about the namespace, but I get all services that take VitualSequence including those expecting particular namespaces. Can I get around this without inventing my own useless namespace, or is this the only way to go? I thought you needed a "*" between the Namespace tags in findService for it to act as a wildcard... From gordonp at ucalgary.ca Thu Feb 23 12:56:11 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 23 Feb 2006 10:56:11 -0700 Subject: [MOBY-dev] Suggestion for new tag in Parameter (Secondary Input specification) Message-ID: <43FDF73B.5040105@ucalgary.ca> Can we add an optional description field to the secondary article tag? It might help people fill it out if they have a hint *what* they're filling out besides the articleName. i.e.: This field sets the frameshift penalty in the alignment. The higher it is set, the less likely frameshifts will be detected and corrected. Integer|Float|String|DateTime ... ... ... ... ... Sound reasonable? Does this require a RFC? From senger at ebi.ac.uk Thu Feb 23 13:03:59 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 23 Feb 2006 18:03:59 +0000 (GMT) Subject: [MOBY-dev] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <43FDF73B.5040105@ucalgary.ca> Message-ID: Sounds reasonable to me. I support it. (No problem to add it to the Dashboard when/if it is added.) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Feb 23 13:11:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 23 Feb 2006 10:11:29 -0800 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <43FDF73B.5040105@ucalgary.ca> References: <43FDF73B.5040105@ucalgary.ca> Message-ID: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> Absolutely - I believe the INB had also requested this a while ago, too. Do we need to go through an RFC for this? I hope not... If nobody objects, I'll add it to the API right away. It should only take a couple of minutes to code. M On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: > Can we add an optional description field to the secondary article tag? > It might help people fill it out if they have a hint *what* they're > filling out besides the articleName. i.e.: > > > This field sets the frameshift penalty in the alignment. The higher it is set, the less likely frameshifts will be detected and corrected. > Integer|Float|String|DateTime > ... > ... > ... > ... > ... > > > Sound reasonable? Does this require a RFC? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Thu Feb 23 13:12:38 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 23 Feb 2006 13:12:38 -0500 Subject: [MOBY-dev] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <43FDF73B.5040105@ucalgary.ca> Message-ID: <5.2.1.1.2.20060223131213.01e9ffe0@email.med.harvard.edu> Sounds like a good idea to me too. -Frank At 12:56 PM 2/23/2006, you wrote: >Can we add an optional description field to the secondary article tag? >It might help people fill it out if they have a hint *what* they're >filling out besides the articleName. i.e.: > > > This field sets the frameshift penalty in the > alignment. The higher it is set, the less likely frameshifts will be > detected and corrected. > Integer|Float|String|DateTime > ... > ... > ... > ... > ... > > >Sound reasonable? Does this require a RFC? > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Thu Feb 23 13:17:01 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 23 Feb 2006 18:17:01 +0000 (GMT) Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> Message-ID: > Do we need to go through an RFC for this? I hope not... > No (it does not break anything in the current software). > If nobody objects, I'll add it to the API right away. It should only > take a couple of minutes to code. > No objection in Philippines. Just also please update the docs. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Thu Feb 23 14:12:51 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 23 Feb 2006 14:12:51 -0500 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> At 01:17 PM 2/23/2006, you wrote: > > If nobody objects, I'll add it to the API right away. It should only > > take a couple of minutes to code. > > > No objection in Philippines. Just also please update the docs. Wow, what efficiency, what compatibility, what.... interoperability! I'd just like to make a plug for adding a line to the Perl tests, to verify that this new feature "works". You get to define what "works" means - at the very least, I suggest that if I try to register a service that either specifies or doesn't specify the field, the registration should go through successfully (assuming there's no other reason for it to fail). I encourage all Perl developers to write tight tests, so you may want to take it further than that minimal definition. Just on this topic, what does the java crew use for unit-testing? -F PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Feb 23 14:22:08 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 23 Feb 2006 11:22:08 -0800 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> Message-ID: <1140722528.5536.33.camel@bioinfo.icapture.ubc.ca> Ah! right! That reminds me I need to write a test for the updates to the Relationships API call (and document them properly). M On Thu, 2006-02-23 at 14:12 -0500, Frank Gibbons wrote: > At 01:17 PM 2/23/2006, you wrote: > > > If nobody objects, I'll add it to the API right away. It should only > > > take a couple of minutes to code. > > > > > No objection in Philippines. Just also please update the docs. > > > Wow, what efficiency, what compatibility, what.... interoperability! > > I'd just like to make a plug for adding a line to the Perl tests, to verify > that this new feature "works". You get to define what "works" means - at > the very least, I suggest that if I try to register a service that either > specifies or doesn't specify the field, the registration should go > through successfully (assuming there's no other reason for it to fail). I > encourage all Perl developers to write tight tests, so you may want to take > it further than that minimal definition. > > Just on this topic, what does the java crew use for unit-testing? > > -F > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From gordonp at ucalgary.ca Thu Feb 23 15:12:39 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 23 Feb 2006 13:12:39 -0700 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> Message-ID: <43FE1737.60402@ucalgary.ca> AFAIK, nothing. I have written JUnit tests to check several of the classes I wrote, but they are not part of the repository. We should really get on that :-) >Just on this topic, what does the java crew use for unit-testing? > > From Pieter.Neerincx at wur.nl Thu Feb 23 18:47:58 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 00:47:58 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> Message-ID: <16CA102E-7DD9-439E-A901-808D178A9AE1@wur.nl> On 23Feb2006, at 20:12, Frank Gibbons wrote: > At 01:17 PM 2/23/2006, you wrote: >>> If nobody objects, I'll add it to the API right away. It should >>> only >>> take a couple of minutes to code. >>> >> No objection in Philippines. Just also please update the docs. > > > Wow, what efficiency, what compatibility, what.... interoperability! I would welcome the description for secondaries too. Currently figuring what some secondaries do requires voodoo :(. Cheers, Pi > I'd just like to make a plug for adding a line to the Perl tests, > to verify > that this new feature "works". You get to define what "works" means > - at > the very least, I suggest that if I try to register a service that > either > specifies or doesn't specify the field, the registration > should go > through successfully (assuming there's no other reason for it to > fail). I > encourage all Perl developers to write tight tests, so you may want > to take > it further than that minimal definition. > > Just on this topic, what does the java crew use for unit-testing? > > -F > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Thu Feb 23 19:09:02 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 24 Feb 2006 00:09:02 +0000 (GMT) Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> Message-ID: > Just on this topic, what does the java crew use for unit-testing? > Nothing. We should use jUnit, a standard way in Java, but I have never started with it. As a I said, we should... (I think that Paul has started to use it, at least somebody put junit.jar in jMoby.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Feb 23 21:08:50 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 23 Feb 2006 18:08:50 -0800 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <1140722528.5536.33.camel@bioinfo.icapture.ubc.ca> References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> <1140722528.5536.33.camel@bioinfo.icapture.ubc.ca> Message-ID: <1140746930.14621.1.camel@bioinfo.icapture.ubc.ca> Secondaries should now be able to have descriptions. a XML tag has been added to the API for secondary articles. Seems to pass the tests. Please let me know if it doesn't work for you. M From johan at ac.uma.es Fri Feb 24 06:44:14 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Fri, 24 Feb 2006 12:44:14 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> References: <43FDF73B.5040105@ucalgary.ca> <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <43FEF18E.3040103@ac.uma.es> Hi! As Mark says, description of secondaries is something the INB have been requesting for a while now. Actually, we are already capturing this information together with some additional information during service registration. We store this information in a separate database, apart from the Moby Central database. We have recently started a new registration procedure at the INB where (as part of the procedure) service providers can add the following additional information about their services: ? Name of the author. ? For each input and output (primary/collection parameters), a description of the parameter, and a data type example. ? For each secondary parameter, a description of the parameter and an example value. ? Help file for the service (in XML format) ? Keywords describing the service (we are working on "semantic" searches) Maybe some of this information can be useful to the BioMoby community? Kind regards, Johan Karlsson Mark Wilkinson wrote: > Absolutely - I believe the INB had also requested this a while ago, too. > > Do we need to go through an RFC for this? I hope not... > > If nobody objects, I'll add it to the API right away. It should only > take a couple of minutes to code. > > M > > > > On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: > >> Can we add an optional description field to the secondary article tag? >> It might help people fill it out if they have a hint *what* they're >> filling out besides the articleName. i.e.: >> >> >> This field sets the frameshift penalty in the alignment. The higher it is set, the less likely frameshifts will be detected and corrected. >> Integer|Float|String|DateTime >> ... >> ... >> ... >> ... >> ... >> >> >> Sound reasonable? Does this require a RFC? >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> From Pieter.Neerincx at wur.nl Fri Feb 24 07:00:13 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 13:00:13 +0100 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: <60FEE9FB-F15B-471F-BF7D-452ED27D1CA1@wur.nl> On 21-Feb-2006, at 9:33 AM, Martin Senger wrote: >> Could we find common ground if we made an API change that resulted >> in the >> Namespace ontology being hierarchical rather than flat? If I >> understand >> the problem you are trying to solve, this would make a significant >> difference - but would it make *enough* difference that you >> wouldn't have >> to create more specific types of simple Objects? >> > Honestly, I do not know. I even do not fully understand your > "combinatorial explosion", and - mainly - why it would not happen > with a > hierarchy and inheritance within namespaces? I'm with Martin again here. I do see how what Martin and I want could be done with namespaces instead, but I fail to see how this prevents the problem Mark described here: > Object > DatabaseObject > GenbankObject > GenbankSequence > GenbankDNASequence > GenbankAASequence > EMBLObject > EMBLSequence > EMBLDNASequence > EMBLAASequence > PDBObject > PDBSequence > > etc. etc. From the Rectorian ontology-philosophy, this is a perfect > example of the "exploding bicycle", and the end result is well > documented and disasterous! Even in that example, there would be > no way > to discover a Blast service that operated on GenericSequence > objects if > you had a GenbankDNASequence object in-hand. What are the relationships in the example above? Would it be possible to do the following: Object DatabaseObject ISA Object GenbankObject ISA DatabaseObject HASA GenbankSequence HASA GenbankDNASequence ISA GenericSequence HASA GenbankAASequence ISA GenericSequence EMBLObject EMBLSequence EMBLDNASequence EMBLAASequence PDBObject PDBSequence That would still not be an elegant object structure, but it's difficult to make sure people don't register clumsy object structures or create yet another redundant object for something that's already there. I don't see how using a less flat namespace ontology would prevent that, because in that case I could register: Namespace DatabaseNS GenbankNS GenbankSequenceNS GenbankDNASequenceNS GenbankAASequenceNS EMBL_NS EMBLSequenceNS EMBLDNASequenceNS EMBLAASequenceNS PDB_NS PDBSequenceNS In that case if a service is registered to take a GenericSequence object as input, but it's limited to the GenbankDNASequenceNS namepsace, you still won't be able to use it if GenbankDNASequenceNS wasn't registered to be 'ISA GenericSequenceNS'. I'm a bit confused here.... Pi > That would also mean that we > would have two trees, one (roughly speaking) describing syntax > (data type > tree) and one describing semantics (namapsce tree). That would not > be easy > to explain, maintain and use... > I am tempted to say that I wuold still use data types to express > how a > reality is related, and I would use namespaces as an additional > information - where I would welcome less flat alternative. > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Fri Feb 24 08:05:30 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 24 Feb 2006 13:05:30 +0000 (GMT) Subject: [MOBY-dev] Dashboard update Message-ID: Dear all, I have added few more things to the Dashboard and - mainly! - finalized its documentation and help pages. The main update is a new SimpleClient panel that allows you to call any service, and to display its results using various viewers (applying the same plug-in mechanism as Taverna has, even re-using shamelessly some of the Taverna viewers). This concludes the cycle that a Biomoby service provider needs to go through (register service, implement service, deploy service and test/call service). The documentation was significantly extended especially for developers that wish to add there their own panels and viewers. I am looking forward to seeing some additions (Eddie, what about a browser of the RDF used in Biomoby, or perhaps a browser of the LSID metadata resolution?), and I am here to help as much as I can (my time zone will be GMT from the next week). Please let me know about any problems and suggestions for improvements. The latest Dashboard documentation is available here: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/Dashboard.html With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Fri Feb 24 09:21:18 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 15:21:18 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <43FEF18E.3040103@ac.uma.es> References: <43FDF73B.5040105@ucalgary.ca> <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <43FEF18E.3040103@ac.uma.es> Message-ID: <9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> Hi Johan et al., On 24-Feb-2006, at 12:44 PM, Johan Karlsson wrote: > Hi! > > As Mark says, description of secondaries is something the INB have > been > requesting for a while now. > > Actually, we are already capturing this information together with some > additional information during service registration. We store this > information in a separate database, apart from the Moby Central > database. > > We have recently started a new registration procedure at the INB where > (as part of the procedure) service providers can add the following > additional information about their services: > > ? Name of the author. > ? For each input and output (primary/collection parameters), a > description of the parameter, and a data type example. > ? For each secondary parameter, a description of the parameter > and an > example value. > ? Help file for the service (in XML format) > ? Keywords describing the service (we are working on "semantic" > searches) > > Maybe some of this information can be useful to the BioMoby community? I read the INB paper "Intelligent client for integrating bioinformatics services" published in Bioinformatics. The things mentioned above were described there and it made me wonder... For asynchronous service calls the INB leads an initiative to extend the BioMOBY standard, which is great! This may take a bit longer to get accepted and implemented as compared to hacking together some custom extension, but it makes sure that your BioMOBY services are compatible with the rest of the BioMOBY world. The INB did the same for error handling. But for the things mentioned above the INB people chose to go their own way. The "extended service registration" procedure is INB specific and the additional (help) info is available form a "fourth party" server (not the BioMOBY client, nor the service provider, nor the INB BioMOBY Central). I think this is bad. The INB BioMOBY Central is out of sync with the official BioMOBY Central and no longer compatible, because of the modified registration procedure : (. Personally I think this is even worse... Anyway the things mentioned above would definitely be useful! The secondary parameter description was just added to the service registration call. So that's solved. When I retrieve a service I get the BioMOBY WSDL that contains amongst others all the description fields. If I have a typical BLAST service that supports all 40+ parameters it also means that this WSDL will hold the description for 40+ params. It's getting big...:). So adding additional help in XML format and example input and output there (during registration) would make the WSDL we send around even longer. Not my favourite solution. I would rather like to see a solution where this additional information is provided by the service (provider) and only when the client requests it explicitly. This way it doesn't need to be stored in a BioMOBY Central. This could be done for example using an additional method [ServiceName]_help. If this would be standardised the new RDF agent, might be extended and use this method to get the example input, excute the service with this example input and validate the results. It can than check: * whether the service works * if the input and output are valid as compared to how the service was registered. If these checks fail it might send an automated e-mail to the maintainer of that service and eventually if the issues are not resolved remove the service from BioMOBY Central. In the "cleaning out the registry" thread Mark mentioned that he would contact service providers whose services work perfectly well, but were registered incorrectly. No matter how efficient Mark might work, sooner or later BioMOBY will be so popular and BioMOBY Central so big, that doing this manually won't be feasible anymore. So this needs to be automated sooner or later anyway. Having example input and output might be used for that. So what do the others think... Just my 2c, Pi > > Kind regards, > Johan Karlsson > > Mark Wilkinson wrote: >> Absolutely - I believe the INB had also requested this a while >> ago, too. >> >> Do we need to go through an RFC for this? I hope not... >> >> If nobody objects, I'll add it to the API right away. It should only >> take a couple of minutes to code. >> >> M >> >> >> >> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: >> >>> Can we add an optional description field to the secondary article >>> tag? >>> It might help people fill it out if they have a hint *what* they're >>> filling out besides the articleName. i.e.: >>> >>> >>> This field sets the frameshift penalty in the alignment. >>> The higher it is set, the less likely frameshifts will be >>> detected and corrected. >>> Integer|Float|String|DateTime >>> ... >>> ... >>> ... >>> ... >>> ... >>> >>> >>> Sound reasonable? Does this require a RFC? >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >>> > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Fri Feb 24 09:38:38 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 24 Feb 2006 14:38:38 +0000 (GMT) Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> Message-ID: > I would rather like to see a solution where this additional > information is provided by the service (provider) > This solution already exists. It is called LSID metadata resolution and any service provider can (should) do it. Even the RDF predicates to be used for things like example input and expected output were (I think) defined in an RFC describing the LSID metadata resolution. Regarding INB, it is not that important how they add and how they store the additional information about their services, but how they make access to this information. If they choose to provide them via LSID metadata resolution, it's perfect, standard and everybody can benefit fom it. Martin's 2c's. Cheers, M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 24 11:26:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 24 Feb 2006 08:26:10 -0800 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: References: Message-ID: <1140798370.15348.8.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-24 at 14:38 +0000, Martin Senger wrote: > > I would rather like to see a solution where this additional > > information is provided by the service (provider) > > > This solution already exists. It is called LSID metadata resolution and > any service provider can (should) do it. Absolutely correct! The "core" predicates were defined in the RFC, and are documented here: http://biomoby.open-bio.org/index.php/for- developers/moby_extensions/moby_metadata It's probably a good idea to discuss what the common extension predicates are going to be amongst the community so that we all know what to look for in your RDF (and these may eventually become part of the core API), but that doesn't stop anyone from adding whatever metadata they wish to their own RDF. M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From ots at ac.uma.es Fri Feb 24 13:04:33 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 24 Feb 2006 19:04:33 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter(Secondary Input specification) References: <43FDF73B.5040105@ucalgary.ca><1140718289.5536.1.camel@bioinfo.icapture.ubc.ca><43FEF18E.3040103@ac.uma.es> <9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> Message-ID: <02b201c6396c$c46655d0$346dd696@ac.uma.es> Hi all and Pieter in particular: This is Oswaldo from the gnv5 -University of Malaga- group at the INB. Perhaps Pieter's mail needs some additional information from our group to better understand some aspects of the INB architecture. The INB project was started in March'04, a major decision was make to use BioMOBY as the underlying integration protocol. However, several of the desirable functionalities were not available in the protocol, specially important from the INB perspective were the ability to launch large-CPU tasks using asynchronous messaging; a protocol for error handling (and, in the way, some specific rules for dealing with collections; help information, DB optimization, etc etc. we expect to propose extensions in these fields. soon). However, we design the architecture keeping in mind to maintain full compatibility with moby. A good example is our current async implementation (see the attached document for a longer description). What can we learn from this document? that we extend the protocol -async- even with the double cost of maintain moby compatibility: Even more, our current proposal for async was born during the INB meeting (July'05) and discussed with Martin and Eddie. This proposal is completely new and -if approved- we will need to re-write our async code (well, not at all). Thus, once we are part of the moby group and our ideas can be taken into account, we will move closer in the moby direction to avoid double work from our side (as you can imagine, this is what we want). On the other hand, our registration procedure -in my opinion- does not break our moby compatibility. In fact you can use directly all the services we have developed. If you see the new fields, most of them are used to allow (user-friendly and self explicative) automatic interface building. SO they don't have any influence in the services call protocol. We of course will be happy to propose a documentation system and other extensions, but at this moment there are other priorities. In sumary; in fact we have our own ideas about a full protocol. For strategic reasons we develeop at our own cost, some moby extension (from a practical point of view, we took our own decisions because we needed a fast development -you know that error handling have spent more than 4 months in discussion!!!!). But we dont want to break moby (and we are not going to do that). sorry for this long (and boring) dissertation. Oswaldo PS with repect to the registration procedure, it can be done using moby functionality, but we request additional information to be used by our client (if you want addictional information on our protocol dont hesitate to request) > I read the INB paper "Intelligent client for integrating > bioinformatics services" published in Bioinformatics. The things > mentioned above were described there and it made me wonder... For > asynchronous service calls the INB leads an initiative to extend the > BioMOBY standard, which is great! This may take a bit longer to get > accepted and implemented as compared to hacking together some custom > extension, but it makes sure that your BioMOBY services are > compatible with the rest of the BioMOBY world. The INB did the same > for error handling. But for the things mentioned above the INB people > chose to go their own way. The "extended service registration" > procedure is INB specific and the additional (help) info is available > form a "fourth party" server (not the BioMOBY client, nor the service > provider, nor the INB BioMOBY Central). I think this is bad. The INB > BioMOBY Central is out of sync with the official BioMOBY Central and > no longer compatible, because of the modified registration procedure : > (. Personally I think this is even worse... > > Anyway the things mentioned above would definitely be useful! The > secondary parameter description was just added to the service > registration call. So that's solved. When I retrieve a service I get > the BioMOBY WSDL that contains amongst others all the description > fields. If I have a typical BLAST service that supports all 40+ > parameters it also means that this WSDL will hold the description for > 40+ params. It's getting big...:). So adding additional help in XML > format and example input and output there (during registration) would > make the WSDL we send around even longer. Not my favourite solution. > > I would rather like to see a solution where this additional > information is provided by the service (provider) and only when the > client requests it explicitly. This way it doesn't need to be stored > in a BioMOBY Central. This could be done for example using an > additional method [ServiceName]_help. If this would be standardised > the new RDF agent, might be extended and use this method to get the > example input, excute the service with this example input and > validate the results. It can than check: > * whether the service works > * if the input and output are valid as compared to how the service > was registered. > If these checks fail it might send an automated e-mail to the > maintainer of that service and eventually if the issues are not > resolved remove the service from BioMOBY Central. In the "cleaning > out the registry" thread Mark mentioned that he would contact service > providers whose services work perfectly well, but were registered > incorrectly. No matter how efficient Mark might work, sooner or later > BioMOBY will be so popular and BioMOBY Central so big, that doing > this manually won't be feasible anymore. So this needs to be > automated sooner or later anyway. Having example input and output > might be used for that. So what do the others think... > > Just my 2c, > > Pi > > > > > Kind regards, > > Johan Karlsson > > > > Mark Wilkinson wrote: > >> Absolutely - I believe the INB had also requested this a while > >> ago, too. > >> > >> Do we need to go through an RFC for this? I hope not... > >> > >> If nobody objects, I'll add it to the API right away. It should only > >> take a couple of minutes to code. > >> > >> M > >> > >> > >> > >> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: > >> > >>> Can we add an optional description field to the secondary article > >>> tag? > >>> It might help people fill it out if they have a hint *what* they're > >>> filling out besides the articleName. i.e.: > >>> > >>> > >>> This field sets the frameshift penalty in the alignment. > >>> The higher it is set, the less likely frameshifts will be > >>> detected and corrected. > >>> Integer|Float|String|DateTime > >>> ... > >>> ... > >>> ... > >>> ... > >>> ... > >>> > >>> > >>> Sound reasonable? Does this require a RFC? > >>> > >>> _______________________________________________ > >>> MOBY-dev mailing list > >>> MOBY-dev at biomoby.org > >>> http://biomoby.org/mailman/listinfo/moby-dev > >>> > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Fri Feb 24 14:12:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 20:12:37 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: References: Message-ID: <59188CE8-6F85-4D93-BFC4-F753D4CED8D7@wur.nl> On 24-Feb-2006, at 3:38 PM, Martin Senger wrote: >> I would rather like to see a solution where this additional >> information is provided by the service (provider) >> > This solution already exists. It is called LSID metadata > resolution and > any service provider can (should) do it. > Even the RDF predicates to be > used for things like example input and expected output were (I > think) defined in an RFC describing the LSID metadata resolution. Oops, looks like I missed something :). I'll have a second look at the LSID things. So far I didn't look at it thoroughly, because I never got the Perl LS::ID.pm module to install correctly. Always failed the tests. I simply copied it over and so far it doesn't create problems. > Regarding INB, it is not that important how they add and how > they store > the additional information about their services, but how they make > access > to this information. If they choose to provide them via LSID metadata > resolution, it's perfect, standard and everybody can benefit fom it. If I understood the paper correctly that's not the case, but correct me if I'm wrong. Cheers, Pi > Martin's 2c's. > Cheers, M. > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Feb 24 14:30:44 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 20:30:44 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <1140798370.15348.8.camel@bioinfo.icapture.ubc.ca> References: <1140798370.15348.8.camel@bioinfo.icapture.ubc.ca> Message-ID: <010E264E-92CA-47D1-801A-5CBABE7CB3DF@wur.nl> On 24-Feb-2006, at 5:26 PM, Mark Wilkinson wrote: > > On Fri, 2006-02-24 at 14:38 +0000, Martin Senger wrote: >>> I would rather like to see a solution where this additional >>> information is provided by the service (provider) >>> >> This solution already exists. It is called LSID metadata >> resolution and >> any service provider can (should) do it. > > > Absolutely correct! > > The "core" predicates were defined in the RFC, and are documented > here: > http://biomoby.open-bio.org/index.php/for- > developers/moby_extensions/moby_metadata Check, I took a second look at the site. Looks like LSID resolution could perfectly work for these things as well. Thanks Martin and Mark for clarifying the extensibility of LSID metadata resolution. I previously overlooked that completely. > It's probably a good idea to discuss what the common extension > predicates are going to be amongst the community so that we all know > what to look for in your RDF (and these may eventually become part of > the core API), I would welcome that discussion. I could not find tags for things like example input, example output and extended help yet, but those would be useful for many of us. And it would hamper interoperability if everyone designs their own lollypop for that functionality. > but that doesn't stop anyone from adding whatever > metadata they wish to their own RDF. Which is great as well! I saw the light, Pi > > M > > > > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Feb 24 14:57:03 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 20:57:03 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <02b201c6396c$c46655d0$346dd696@ac.uma.es> References: <43FDF73B.5040105@ucalgary.ca><1140718289.5536.1.camel@bioinfo.icapture.ubc.ca><43FEF18E.3040103@ac.uma.es> <9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> <02b201c6396c$c46655d0$346dd696@ac.uma.es> Message-ID: <2B8E89C5-BA34-4F11-97CB-C210016AF76B@wur.nl> Hi Oswaldo, On 24-Feb-2006, at 7:04 PM, Oswaldo Trelles wrote: > Hi all and Pieter in particular: > > > > This is Oswaldo from the gnv5 -University of Malaga- group at the INB. > Perhaps Pieter's mail needs some additional information from our > group to > better understand some aspects of the INB architecture. > > > > The INB project was started in March'04, a major decision was make > to use > BioMOBY as the underlying integration protocol. However, several of > the > desirable functionalities were not available in the protocol, > specially > important from the INB perspective were the ability to launch large- > CPU > tasks using asynchronous messaging; a protocol for error handling > (and, in > the way, some specific rules for dealing with collections; help > information, > DB optimization, etc etc. we expect to propose extensions in these > fields. > soon). So far those proposals from the INB group have resulted in valuable extensions :), so I'm looking forward to any new proposals. > > > However, we design the architecture keeping in mind to maintain full > compatibility with moby. A good example is our current async > implementation > (see the attached document for a longer description). What can we > learn from > this document? that we extend the protocol -async- even with the > double cost > of maintain moby compatibility: Even more, our current proposal for > async > was born during the INB meeting (July'05) and discussed with Martin > and > Eddie. This proposal is completely new and -if approved- we will > need to > re-write our async code I understand. Same here. I experimented with some async stuff, which is different from what was proposed, so I rewrote them. In fact we have course in two weeks where I want to use one of those services, so you will see some async stuff popup in the BioMOBY Central next week. Those services were rewritten to make them at least partially compatible with the current proposal. Rest assured that I will rewrite them once more once the proposal is finished and accepted. > (well, not at all). Thus, once we are part of the > moby group and our ideas can be taken into account, we will move > closer in > the moby direction to avoid double work from our side (as you can > imagine, > this is what we want). > > > > On the other hand, our registration procedure -in my opinion- does > not break > our moby compatibility. In fact you can use directly all the > services we > have developed. If you see the new fields, most of them are used to > allow > (user-friendly and self explicative) automatic interface building. > SO they > don't have any influence in the services call protocol. Ok, that's good to read. I thought it might have broken interoperability. > We of course will be happy to propose a documentation system and other > extensions, but at this moment there are other priorities. > > In sumary; in fact we have our own ideas about a full protocol. For > strategic reasons we develeop at our own cost, some moby extension > (from a > practical point of view, we took our own decisions because we > needed a fast > development -you know that error handling have spent more than 4 > months in > discussion!!!!) I know it took a while. It was a bit too long I think, but in the end the proposal did improve because of the discussion. Just be glad your into bioinformatics and not politics, because otherwise the proposal would have taken easily 4 years :). Cheers, Pi > . But we dont want to break moby (and we are not going to do > that). > > sorry for this long (and boring) dissertation. > > Oswaldo > > PS with repect to the registration procedure, it can be done using > moby > functionality, but we request additional information to be used by our > client (if you want addictional information on our protocol dont > hesitate to > request) > > > >> I read the INB paper "Intelligent client for integrating >> bioinformatics services" published in Bioinformatics. The things >> mentioned above were described there and it made me wonder... For >> asynchronous service calls the INB leads an initiative to extend the >> BioMOBY standard, which is great! This may take a bit longer to get >> accepted and implemented as compared to hacking together some custom >> extension, but it makes sure that your BioMOBY services are >> compatible with the rest of the BioMOBY world. The INB did the same >> for error handling. But for the things mentioned above the INB people >> chose to go their own way. The "extended service registration" >> procedure is INB specific and the additional (help) info is available >> form a "fourth party" server (not the BioMOBY client, nor the service >> provider, nor the INB BioMOBY Central). I think this is bad. The INB >> BioMOBY Central is out of sync with the official BioMOBY Central and >> no longer compatible, because of the modified registration >> procedure : >> (. Personally I think this is even worse... >> >> Anyway the things mentioned above would definitely be useful! The >> secondary parameter description was just added to the service >> registration call. So that's solved. When I retrieve a service I get >> the BioMOBY WSDL that contains amongst others all the description >> fields. If I have a typical BLAST service that supports all 40+ >> parameters it also means that this WSDL will hold the description for >> 40+ params. It's getting big...:). So adding additional help in XML >> format and example input and output there (during registration) would >> make the WSDL we send around even longer. Not my favourite solution. >> >> I would rather like to see a solution where this additional >> information is provided by the service (provider) and only when the >> client requests it explicitly. This way it doesn't need to be stored >> in a BioMOBY Central. This could be done for example using an >> additional method [ServiceName]_help. If this would be standardised >> the new RDF agent, might be extended and use this method to get the >> example input, excute the service with this example input and >> validate the results. It can than check: >> * whether the service works >> * if the input and output are valid as compared to how the service >> was registered. >> If these checks fail it might send an automated e-mail to the >> maintainer of that service and eventually if the issues are not >> resolved remove the service from BioMOBY Central. In the "cleaning >> out the registry" thread Mark mentioned that he would contact service >> providers whose services work perfectly well, but were registered >> incorrectly. No matter how efficient Mark might work, sooner or later >> BioMOBY will be so popular and BioMOBY Central so big, that doing >> this manually won't be feasible anymore. So this needs to be >> automated sooner or later anyway. Having example input and output >> might be used for that. So what do the others think... >> >> Just my 2c, >> >> Pi >> >>> >>> Kind regards, >>> Johan Karlsson >>> >>> Mark Wilkinson wrote: >>>> Absolutely - I believe the INB had also requested this a while >>>> ago, too. >>>> >>>> Do we need to go through an RFC for this? I hope not... >>>> >>>> If nobody objects, I'll add it to the API right away. It should >>>> only >>>> take a couple of minutes to code. >>>> >>>> M >>>> >>>> >>>> >>>> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: >>>> >>>>> Can we add an optional description field to the secondary article >>>>> tag? >>>>> It might help people fill it out if they have a hint *what* >>>>> they're >>>>> filling out besides the articleName. i.e.: >>>>> >>>>> >>>>> This field sets the frameshift penalty in the alignment. >>>>> The higher it is set, the less likely frameshifts will be >>>>> detected and corrected. >>>>> Integer|Float|String|DateTime >>>>> ... >>>>> ... >>>>> ... >>>>> ... >>>>> ... >>>>> >>>>> >>>>> Sound reasonable? Does this require a RFC? >>>>> >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev at biomoby.org >>>>> http://biomoby.org/mailman/listinfo/moby-dev >>>>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Fri Feb 24 22:21:20 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 03:21:20 +0000 (GMT) Subject: [MOBY-dev] where are all signature URLs? Message-ID: I know that the signatureURLs were not used (waiting for the agent) - but they still have been, at least sometimes, registered. Where are they now? I am getting *all* services from the registry without them now. I wonder if the problem is in jMoby fetching software, or if they are really not there anymore. Please tell me. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Feb 24 22:43:32 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 03:43:32 +0000 (GMT) Subject: [MOBY-dev] where are all signature URLs? In-Reply-To: <35793108-1140838578-cardhu_blackberry.rim.net-302-@engine12-cell01> Message-ID: It happens to all of us... :-) But it reminds me something else: if you do anytime a manual change in the registry, please do not forget always to change also the timestamp field (unless it's done automatically by the RDBS) - otherwise the software relying on the new LSID versioning will not notice the change and cannot update various caches properly. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 24 22:33:57 2006 From: markw at illuminae.com (mark wilkinson) Date: Sat, 25 Feb 2006 03:33:57 +0000 GMT Subject: [MOBY-dev] where are all signature URLs? Message-ID: <35793108-1140838578-cardhu_blackberry.rim.net-302-@engine12-cell01> That was my fault. An accident. We noticed last week that there were entries in the database that were not representing anything (eg things that got it and never got erased during code tests). They were popping out from certain findService requests in fragmented ways and breaking the code because they were incomplete or badly formatted. I was trying to clean them by manual and scripted trash collection but I made an error. I have a backup, and could replace them, it will just take a bit of careful scripting. M -----Original Message----- From: Martin Senger Date: Sat, 25 Feb 2006 03:21:20 To:Edward Kawas Cc:Moby Developers Subject: [MOBY-dev] where are all signature URLs? I know that the signatureURLs were not used (waiting for the agent) - but they still have been, at least sometimes, registered. Where are they now? I am getting *all* services from the registry without them now. I wonder if the problem is in jMoby fetching software, or if they are really not there anymore. Please tell me. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Sat Feb 25 01:06:43 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 06:06:43 +0000 (GMT) Subject: [MOBY-dev] Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <2B8E89C5-BA34-4F11-97CB-C210016AF76B@wur.nl> Message-ID: Dear all, I have updated jMoby in order to handle description in/for the secondary inputs (parameters). Regards, Martin [ Details: * MobySecondaryData includes now set/get method for description. Also its toString(), toXML() and from XML method have been updated. * Dashboard Registration panel now has an additional column in a table creating definitions of the secondary inputs - allowing multi-line descripion to be entered. ] -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Feb 25 01:43:27 2006 From: markw at illuminae.com (mark wilkinson) Date: Sat, 25 Feb 2006 06:43:27 +0000 GMT Subject: [MOBY-dev] where are all signature URLs? Message-ID: <1899503299-1140849949-cardhu_blackberry.rim.net-5259-@engine08-cell01> Thanks for your forgiveness - I was quite embarrassed by it, actually! The reason I didn't fix it right away was that it was the last operation I did that day, so to roll-back would have re-introduced all of the crap that I had just spent the morning removing. I just kicked myself and decided that I would only script the replacement of the sigURL's if someone asked me to... I have night-terrors when I have to edit the main registry database by hand!! Over the past three years it had picked up a lot of junk from various code bugs and such, so the cleaning needed to happen, but I messed it up... And I sincerely apologize for that!!! Vv changing the timestamp: that was an even bigger problem. Last week eddie mentioned to me that, sor some reason that we still don't understand, many of the namespace terms ended up with an underscore appended to them ("EMBL_"). This happened before the LSID timestamp was added, and so our LSID's ended up with this underscore in them as well! This caused a problem (that nobody seemed to notice??) That namespaces registered for a service were no longer valid namespaces (the lsid is used as the primary key, and it no longer matched with the namespace in the namespaces database tables). The only solutiuon was to modify the lsid in the namespace table (remove the underscore) but keep the same timestamp, since that was the timestamp that the service was registered under. Again, I apologize for any frustration that caused, but in this case I couldn't see a good alternative that didn't involve changing the registration of every service (and that terrifies me!)... I wish I knew where those underscores came from in the first place, though...?????? Anyway, that's the full history of the manual registry database edits from last week... M -----Original Message----- From: Martin Senger Date: Sat, 25 Feb 2006 03:43:32 To:mark wilkinson Cc:Core developer announcements Subject: Re: [MOBY-dev] where are all signature URLs? It happens to all of us... :-) But it reminds me something else: if you do anytime a manual change in the registry, please do not forget always to change also the timestamp field (unless it's done automatically by the RDBS) - otherwise the software relying on the new LSID versioning will not notice the change and cannot update various caches properly. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Sat Feb 25 08:57:00 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 13:57:00 +0000 (GMT) Subject: [MOBY-dev] where are all signature URLs? In-Reply-To: <1899503299-1140849949-cardhu_blackberry.rim.net-5259-@engine08-cell01> Message-ID: Thanks for the details, interesting. When reading your comments, I suddenly was not sure if we have the same understanding for LSID versioning. I guess we have but here is what slightly confused me: > was to modify the lsid in the namespace table (remove the underscore) > but keep the same timestamp, since that was the timestamp that the > service was registered under > This seems to me like a service version depends on the version of a namespace used by this service. Is it true? If yes then it differs from my version understanding - I thought that a version of a, for example, service is changed when the same service is registered again. But it does not change if the entities used by this service are changed (which is normally impossible, anyway, because except manual editing you cannot unregister and register again anything that other entities depend on). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Feb 25 08:57:11 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 13:57:11 +0000 (GMT) Subject: [MOBY-dev] jMoby updated - LSIDs used Message-ID: Dear all, Let me inform you that I have updated some classes in jMoby in order to take advantage of the new LSID versioning. The update of the local cache should be now able to pick up also changes inside individual entities. Please cvs update. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Feb 25 11:11:12 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 25 Feb 2006 08:11:12 -0800 Subject: [MOBY-dev] where are all signature URLs? In-Reply-To: References: Message-ID: I think we have the same understanding. I just didn't explain clearly what it is that I had to do. What had happened was (in temporal order, as best I can understand it): 1) Services were registered as consuming a particular namespace - the LSID of that namespace, without timestamp, as the primary key, was entered into that service's registry entry. 2) Then, somehow (?!?!?) a small number of namespace terms in the namespace database were altered by the addition of an underscore. I don't know why or when this happened... this, however, didn't affect the namespace's LSID, which is a different field in the namespace database, nor did it affect the namespace LSID's that were associated with the service instances in the registry. We didn't notice this at the time. 3) a few weeks ago I scripted the addition of a timestamp to every namespace LSID. For the Namespace database, I used the namespace term (some of them how with additional '_') as the template to create the associated namespace LSID. However, in the Service Instance table, I used the namespace LSID itself as the template, and simply appended a timestamp on to each namespace that the service instance was using. This SHOULD have been a safe operation... but because of this peculiar and unexplained addition of an underscore to certain namespaces, it was not. 4) At that point, the namespace LSID's associated with service instances went out of sync with the namespace LSID's that were in the namespace table. The namespace table LSIDs were e.g. urn:lsid:....:EMBL_:timestamp, but the service instance table LSIDs were urn:lsid:...:EMBL:timestamp Since the LSID is the primary key used to validate and retrieve namespace information, this ended up making some service regisrations "invalid" (they could not be retrieved properly anymore). What I was describing below was the operation that I did to fix the problem - I modified the LSIDs in the namespace table by removing the '_', but I didn't modify the timestamp, because if I had, then I would have had to update the namespace LSID in each of the services that used that namespace to keep them in sync (and then I'd have to update that service's service instance LSID as well...) Ugh... I hate working on the database manually! :-) M On Sat, 25 Feb 2006 05:57:00 -0800, Martin Senger wrote: > Thanks for the details, interesting. > When reading your comments, I suddenly was not sure if we have the > same > understanding for LSID versioning. I guess we have but here is what > slightly confused me: > >> was to modify the lsid in the namespace table (remove the underscore) >> but keep the same timestamp, since that was the timestamp that the >> service was registered under >> > This seems to me like a service version depends on the version of a > namespace used by this service. Is it true? If yes then it differs from > my > version understanding - I thought that a version of a, for example, > service is changed when the same service is registered again. But it does > not change if the entities used by this service are changed (which is > normally impossible, anyway, because except manual editing you cannot > unregister and register again anything that other entities depend on). > > Martin > From senger at ebi.ac.uk Sat Feb 25 11:25:07 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 16:25:07 +0000 (GMT) Subject: [MOBY-dev] where are all signature URLs? In-Reply-To: Message-ID: Many thanks, I understand it now clearly. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From jmfernandez at cnb.uam.es Mon Feb 27 09:51:08 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon, 27 Feb 2006 15:51:08 +0100 Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) Message-ID: <440311DC.6040807@cnb.uam.es> Hi everybody, I'm trying to use the getSignatureForm CGI from Eddie, in order to update the RDF URL and description of my services, with no success. I have set up my domain (pdg.cnb.uam.es), no service instance name (I want only an RDF document for all my services) and the signature URL I'm going to use (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). The answer is: Unable to update your information Make sure that you specify a valid signature url! This field looks like the following: http://myAuthority.domain/path/to/rdf/for/service. Also make sure that you have specified the right case-sensitive service name, if applicable. What am I doing wrong? Best Regards, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From edward.kawas at gmail.com Mon Feb 27 10:27:52 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 27 Feb 2006 07:27:52 -0800 Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) In-Reply-To: <440311DC.6040807@cnb.uam.es> Message-ID: <000101c63bb2$60cb1fe0$6500a8c0@notebook> Give it a try now, the regular expression that I had didn?t like the - in the url. Sorry! Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Monday, February 27, 2006 6:51 AM > To: mobydev > Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) > > Hi everybody, > I'm trying to use the getSignatureForm CGI from Eddie, > in order to update the RDF URL and description of my > services, with no success. I have set up my domain > (pdg.cnb.uam.es), no service instance name (I want only an > RDF document for all my services) and the signature URL I'm > going to use > (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). The answer is: > > Unable to update your information > > Make sure that you specify a valid signature url! This > field looks like the following: > http://myAuthority.domain/path/to/rdf/for/service. > Also make sure that you have specified the right > case-sensitive service name, if applicable. > > What am I doing wrong? > > Best Regards, > Jos? Mar?a > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > (Spain) _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Mon Feb 27 12:39:34 2006 From: jmfernandez at cnb.uam.es (=?windows-1252?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon, 27 Feb 2006 18:39:34 +0100 Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) In-Reply-To: <000101c63bb2$60cb1fe0$6500a8c0@notebook> References: <000101c63bb2$60cb1fe0$6500a8c0@notebook> Message-ID: <44033956.9010900@cnb.uam.es> Thanks Eddie! Now it works! Now I have seen a cosmetic bug: the name of the returned file is '-moby-signature-moby.rdf' instead of 'signature-moby.rdf'. In other words, the returned file has in its name the prefix '-moby-'. Best Regards, Jos? Mar?a Edward Kawas wrote: > Give it a try now, the regular expression that I had didn?t like the - in > the url. > > Sorry! > > Eddie > >> -----Original Message----- >> From: moby-dev-bounces at biomoby.org >> [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a >> Fern?ndez Gonz?lez >> Sent: Monday, February 27, 2006 6:51 AM >> To: mobydev >> Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) >> >> Hi everybody, >> I'm trying to use the getSignatureForm CGI from Eddie, >> in order to update the RDF URL and description of my >> services, with no success. I have set up my domain >> (pdg.cnb.uam.es), no service instance name (I want only an >> RDF document for all my services) and the signature URL I'm >> going to use >> (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). The answer is: >> >> Unable to update your information >> >> Make sure that you specify a valid signature url! This >> field looks like the following: >> http://myAuthority.domain/path/to/rdf/for/service. >> Also make sure that you have specified the right >> case-sensitive service name, if applicable. >> >> What am I doing wrong? >> >> Best Regards, >> Jos? Mar?a >> -- >> Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es >> Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 >> Grupo de Dise?o de Proteinas Protein Design Group >> Centro Nacional de Biotecnolog?a National Center of Biotechnology >> C.P.: 28049 Zip Code: 28049 >> C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid >> (Spain) _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From markw at illuminae.com Mon Feb 27 13:03:30 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 27 Feb 2006 10:03:30 -0800 Subject: [MOBY-dev] [moby] Re: Problems with getSignatureForm (RDF related) In-Reply-To: <44033956.9010900@cnb.uam.es> References: <000101c63bb2$60cb1fe0$6500a8c0@notebook> <44033956.9010900@cnb.uam.es> Message-ID: <1141063410.23301.43.camel@bioinfo.icapture.ubc.ca> Also, Eddie, heads-up that you will need to add a predicate and node for the new "name" for secondary parameters. M On Mon, 2006-02-27 at 18:39 +0100, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Thanks Eddie! Now it works! > > Now I have seen a cosmetic bug: the name of the returned file is > '-moby-signature-moby.rdf' instead of 'signature-moby.rdf'. In other > words, the returned file has in its name the prefix '-moby-'. > > Best Regards, > Jos? Mar?a > > Edward Kawas wrote: > > Give it a try now, the regular expression that I had didn?t like the - in > > the url. > > > > Sorry! > > > > Eddie > > > >> -----Original Message----- > >> From: moby-dev-bounces at biomoby.org > >> [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > >> Fern?ndez Gonz?lez > >> Sent: Monday, February 27, 2006 6:51 AM > >> To: mobydev > >> Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) > >> > >> Hi everybody, > >> I'm trying to use the getSignatureForm CGI from Eddie, > >> in order to update the RDF URL and description of my > >> services, with no success. I have set up my domain > >> (pdg.cnb.uam.es), no service instance name (I want only an > >> RDF document for all my services) and the signature URL I'm > >> going to use > >> (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). The answer is: > >> > >> Unable to update your information > >> > >> Make sure that you specify a valid signature url! This > >> field looks like the following: > >> http://myAuthority.domain/path/to/rdf/for/service. > >> Also make sure that you have specified the right > >> case-sensitive service name, if applicable. > >> > >> What am I doing wrong? > >> > >> Best Regards, > >> Jos? Mar?a > >> -- > >> Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > >> Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > >> Grupo de Dise?o de Proteinas Protein Design Group > >> Centro Nacional de Biotecnolog?a National Center of Biotechnology > >> C.P.: 28049 Zip Code: 28049 > >> C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > >> (Spain) _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > > > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From edward.kawas at gmail.com Mon Feb 27 13:23:19 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 27 Feb 2006 10:23:19 -0800 Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) In-Reply-To: <44033956.9010900@cnb.uam.es> Message-ID: <000301c63bca$e4803d80$6500a8c0@notebook> I was aware of that bug. I didn?t want to parse the url myself, so using the tools available to me the file returned is called actually called x-filename where x is the path to the filename obtained from the url, i.e. http://myDomain.com/my/path/to/rdfDescription.rdf, x = -my-path-to- Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Monday, February 27, 2006 9:40 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Problems with getSignatureForm (RDF related) > > Thanks Eddie! Now it works! > > Now I have seen a cosmetic bug: the name of the > returned file is '-moby-signature-moby.rdf' instead of > 'signature-moby.rdf'. In other words, the returned file has > in its name the prefix '-moby-'. > > Best Regards, > Jos? Mar?a > > Edward Kawas wrote: > > Give it a try now, the regular expression that I had didn?t > like the - > > in the url. > > > > Sorry! > > > > Eddie > > > >> -----Original Message----- > >> From: moby-dev-bounces at biomoby.org > >> [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > >> Fern?ndez Gonz?lez > >> Sent: Monday, February 27, 2006 6:51 AM > >> To: mobydev > >> Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) > >> > >> Hi everybody, > >> I'm trying to use the getSignatureForm CGI from Eddie, > in order to > >> update the RDF URL and description of my services, with no > success. I > >> have set up my domain (pdg.cnb.uam.es), no service > instance name (I > >> want only an RDF document for all my services) and the > signature URL > >> I'm going to use > (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). > >> The answer is: > >> > >> Unable to update your information > >> > >> Make sure that you specify a valid signature url! This field > >> looks like the following: > >> http://myAuthority.domain/path/to/rdf/for/service. > >> Also make sure that you have specified the right case-sensitive > >> service name, if applicable. > >> > >> What am I doing wrong? > >> > >> Best Regards, > >> Jos? Mar?a > >> -- > >> Jos? Mar?a Fern?ndez Gonz?lez e-mail: > jmfernandez at cnb.uam.es > >> Tlfn: (+34) 91 585 54 50 Fax: (+34) > 91 585 45 06 > >> Grupo de Dise?o de Proteinas Protein Design Group > >> Centro Nacional de Biotecnolog?a National Center of Biotechnology > >> C.P.: 28049 Zip Code: 28049 > >> C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > >> (Spain) _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > > > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > (Spain) _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Mon Feb 27 16:36:25 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 27 Feb 2006 14:36:25 -0700 Subject: [MOBY-dev] Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: References: Message-ID: <440370D9.3050009@ucalgary.ca> On a related note, can we clarify the documentation for Secondary Input in the MOBY API? Can min and max apply to floating point numbers, as well as to integers (e.g. I'd like to limit a real number between 0 and 1)? Can we set a minimum floating point accuracy or integer size a conforming implementation must acheive? Can we explicitly say in the doc that enumerations are for the String type only? >Dear all, > I have updated jMoby in order to handle description in/for the >secondary inputs (parameters). > > Regards, > Martin > > [ Details: > * MobySecondaryData includes now set/get method for description. Also >its toString(), toXML() and from XML method have been updated. > * Dashboard Registration panel now has an additional column in a table >creating definitions of the secondary inputs - allowing multi-line >descripion to be entered. ] > > > > From Pieter.Neerincx at wur.nl Mon Feb 27 17:44:58 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 27 Feb 2006 23:44:58 +0100 Subject: [MOBY-dev] Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <440370D9.3050009@ucalgary.ca> References: <440370D9.3050009@ucalgary.ca> Message-ID: <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> On 27Feb2006, at 22:36, Paul Gordon wrote: > On a related note, can we clarify the documentation for Secondary > Input > in the MOBY API? That would be a good idea. Currently they are only mentioned very briefly. > Can min and max apply to floating point numbers, as > well as to integers (e.g. I'd like to limit a real number between 0 > and > 1)? Can we set a minimum floating point accuracy or integer size a > conforming implementation must acheive? Can we explicitly say in > the doc > that enumerations are for the String type only? Hmmm I use enum for some integers as well. I think it's perfectly normal to say for example: enum [1,2,4,8]. Cheers, Pi > >> Dear all, >> I have updated jMoby in order to handle description in/for the >> secondary inputs (parameters). >> >> Regards, >> Martin >> >> [ Details: >> * MobySecondaryData includes now set/get method for >> description. Also >> its toString(), toXML() and from XML method have been updated. >> * Dashboard Registration panel now has an additional column in >> a table >> creating definitions of the secondary inputs - allowing multi-line >> descripion to be entered. ] >> >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 markw at illuminae.com Mon Feb 27 17:53:06 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 27 Feb 2006 14:53:06 -0800 Subject: [MOBY-dev] [moby] Re: Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> References: <440370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> Message-ID: <1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: > Hmmm I use enum for some integers as well. I think it's perfectly > normal to say for example: enum [1,2,4,8]. Perhaps Paul can clarify what problem he is trying to solve. My instincts tell me that maybe he is having difficulty with casting un- typed XML blocks as either Integer or String, as appropriate... is that a correct interpretation of the problem Paul? I think the combination of the block and the block should be able to indicate whether the ENUM is of type String or of type Integer (or Float, or whatever). Is that not sufficient? Or am I misunderstanding what the root of the problem is? M From gordonp at ucalgary.ca Mon Feb 27 18:55:12 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 27 Feb 2006 16:55:12 -0700 Subject: [MOBY-dev] [moby] Re: Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> References: <440370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> <1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> Message-ID: <44039160.6090609@ucalgary.ca> The main problem: If somebody specifies a float, can I legally submit a e-value cutoff like "1.0e-180" (i.e. are we going to assume bit capacity, such as 2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary precision)? Underflow and overflow can cause problems on many systems... same thing for integers > 2^32... Actually, do we support scientific notation? That isn't mentioned either. Cheers, Paul P.S. Yes, you are right Pieter. You could enumerate integers, or even floats for that matter: this distinction matters for a server with strong types, but not for the client. I've been too client centric lately :-) >On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: > > > >>Hmmm I use enum for some integers as well. I think it's perfectly >>normal to say for example: enum [1,2,4,8]. >> >> > >Perhaps Paul can clarify what problem he is trying to solve. My >instincts tell me that maybe he is having difficulty with casting un- >typed XML blocks as either Integer or String, as appropriate... is that >a correct interpretation of the problem Paul? > >I think the combination of the block and the block >should be able to indicate whether the ENUM is of type String or of type >Integer (or Float, or whatever). Is that not sufficient? Or am I >misunderstanding what the root of the problem is? > >M > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev > > From gordonp at ucalgary.ca Mon Feb 27 20:35:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 27 Feb 2006 18:35:43 -0700 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" Message-ID: <4403A8EF.5070603@ucalgary.ca> I'm not sure who runs the service "RunNCBIBlastn", but when I get an exception returned, it comes in a ServiceNotes tag, not a serviceNotes tag (note capitalization). Can this be fixed please? Thanks! From jmfernandez at cnb.uam.es Tue Feb 28 07:14:44 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Tue, 28 Feb 2006 13:14:44 +0100 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <44039160.6090609@ucalgary.ca> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl>< 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> Message-ID: <44043EB4.1070108@cnb.uam.es> I think we should choose the corresponding XML Schema types for each primitive object. For instance: moby:String -> xsd:string (it would not allow XML content) or xsd:anyType (any content) moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* integer) moby:Float -> xsd:double (IEEE double-precision 64-bit floating point type), xsd:float (IEEE single-precision 32-bit floating point type) or xsd:decimal (*any* real number with a finite number of decimal digits) moby:DateTime -> xsd:dateTime moby:Boolean -> xsd:boolean or an enumerated xsd:string {'0','1','false','true'} Best Regards, Jos? Mar?a Paul Gordon wrote: > The main problem: > > If somebody specifies a float, can I legally submit a e-value cutoff > like "1.0e-180" (i.e. are we going to assume bit capacity, such as > 2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary > precision)? Underflow and overflow can cause problems on many > systems... same thing for integers > 2^32... > > Actually, do we support scientific notation? That isn't mentioned either. > > Cheers, > Paul > > P.S. Yes, you are right Pieter. You could enumerate integers, or even > floats for that matter: this distinction matters for a server with > strong types, but not for the client. I've been too client centric > lately :-) > >> On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: >> >> >> >>> Hmmm I use enum for some integers as well. I think it's perfectly >>> normal to say for example: enum [1,2,4,8]. >>> >>> >> Perhaps Paul can clarify what problem he is trying to solve. My >> instincts tell me that maybe he is having difficulty with casting un- >> typed XML blocks as either Integer or String, as appropriate... is that >> a correct interpretation of the problem Paul? >> >> I think the combination of the block and the block >> should be able to indicate whether the ENUM is of type String or of type >> Integer (or Float, or whatever). Is that not sufficient? Or am I >> misunderstanding what the root of the problem is? >> >> M >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From senger at ebi.ac.uk Tue Feb 28 08:05:48 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 28 Feb 2006 13:05:48 +0000 (GMT) Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: <4403A8EF.5070603@ucalgary.ca> Message-ID: > I'm not sure who runs the service "RunNCBIBlastn", but when I get an > exception returned, it comes in a ServiceNotes tag, not a serviceNotes > tag (note capitalization). > BTW, both are wrong, of course: it should be in .... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Tue Feb 28 09:37:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 28 Feb 2006 15:37:37 +0100 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: References: Message-ID: On 28-Feb-2006, at 2:05 PM, Martin Senger wrote: >> I'm not sure who runs the service "RunNCBIBlastn", but when I get an >> exception returned, it comes in a ServiceNotes tag, not a >> serviceNotes >> tag (note capitalization). >> > BTW, both are wrong, of course: it should be in > .... Which reminds me: in Perl MOBY/Commonsubs.pm also still generates .... So basically all the services that use the Perl API are incompatible as well :(. Does Anyone have objections if I change that to ...? Cheers, Pi > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Tue Feb 28 09:52:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 28 Feb 2006 06:52:29 -0800 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: References: Message-ID: On Tue, 28 Feb 2006 06:37:37 -0800, Pieter Neerincx wrote: > So basically all the services that > use the Perl API are incompatible as well :(. Does Anyone have > objections if I change that to ... serviceNotes>? Please do! M From gordonp at ucalgary.ca Tue Feb 28 10:09:53 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 28 Feb 2006 08:09:53 -0700 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <44043EB4.1070108@cnb.uam.es> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl>< 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> <44043EB4.1070108@cnb.uam.es> Message-ID: <440467C1.5060801@ucalgary.ca> Given that the size of the human genome exceeds the limits of a xsd:int, and that we often use e-values exceeding the limits of xsd:double, may I suggest that we mandate the equivalents to xsd:integer and xsd:decimal? I have built my jMOBY code using arbitrary precision numbers, but I'm sure we'll need to change other parts of it, and of the Perl libraries... >I think we should choose the corresponding XML Schema types for each >primitive object. For instance: > >moby:String -> xsd:string (it would not allow XML content) or >xsd:anyType (any content) > >moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* >integer) > >moby:Float -> xsd:double (IEEE double-precision 64-bit floating point >type), xsd:float (IEEE single-precision 32-bit floating point type) or >xsd:decimal (*any* real number with a finite number of decimal digits) > >moby:DateTime -> xsd:dateTime > >moby:Boolean -> xsd:boolean or an enumerated xsd:string >{'0','1','false','true'} > > Best Regards, > Jos? Mar?a > >Paul Gordon wrote: > > >>The main problem: >> >>If somebody specifies a float, can I legally submit a e-value cutoff >>like "1.0e-180" (i.e. are we going to assume bit capacity, such as >>2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary >>precision)? Underflow and overflow can cause problems on many >>systems... same thing for integers > 2^32... >> >>Actually, do we support scientific notation? That isn't mentioned either. >> >>Cheers, >>Paul >> >>P.S. Yes, you are right Pieter. You could enumerate integers, or even >>floats for that matter: this distinction matters for a server with >>strong types, but not for the client. I've been too client centric >>lately :-) >> >> >> >>>On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: >>> >>> >>> >>> >>> >>>>Hmmm I use enum for some integers as well. I think it's perfectly >>>>normal to say for example: enum [1,2,4,8]. >>>> >>>> >>>> >>>> >>>Perhaps Paul can clarify what problem he is trying to solve. My >>>instincts tell me that maybe he is having difficulty with casting un- >>>typed XML blocks as either Integer or String, as appropriate... is that >>>a correct interpretation of the problem Paul? >>> >>>I think the combination of the block and the block >>>should be able to indicate whether the ENUM is of type String or of type >>>Integer (or Float, or whatever). Is that not sufficient? Or am I >>>misunderstanding what the root of the problem is? >>> >>>M >>> >>> >>> >>>_______________________________________________ >>>MOBY-dev mailing list >>>MOBY-dev at biomoby.org >>>http://biomoby.org/mailman/listinfo/moby-dev >>> >>> >>> >>> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev >> >> >> >> > > > From ots at ac.uma.es Fri Feb 24 13:24:36 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 24 Feb 2006 19:24:36 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter(SecondaryInput specification) References: <43FDF73B.5040105@ucalgary.ca><1140718289.5536.1.camel@bioinfo.icapture.ubc.ca><43FEF18E.3040103@ac.uma.es><9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> <02b201c6396c$c46655d0$346dd696@ac.uma.es> Message-ID: <02f301c6396f$91123340$346dd696@ac.uma.es> sorry, as usual.. here the attach for the previous email O. ----- Original Message ----- From: "Oswaldo Trelles" To: "Core developer announcements" Cc: Sent: Friday, February 24, 2006 7:04 PM Subject: Re: [MOBY-dev] [moby] Suggestion for new tag in Parameter(SecondaryInput specification) > Hi all and Pieter in particular: > > > > This is Oswaldo from the gnv5 -University of Malaga- group at the INB. > Perhaps Pieter's mail needs some additional information from our group to > better understand some aspects of the INB architecture. > > > > The INB project was started in March'04, a major decision was make to use > BioMOBY as the underlying integration protocol. However, several of the > desirable functionalities were not available in the protocol, specially > important from the INB perspective were the ability to launch large-CPU > tasks using asynchronous messaging; a protocol for error handling (and, in > the way, some specific rules for dealing with collections; help information, > DB optimization, etc etc. we expect to propose extensions in these fields. > soon). > > > > However, we design the architecture keeping in mind to maintain full > compatibility with moby. A good example is our current async implementation > (see the attached document for a longer description). What can we learn from > this document? that we extend the protocol -async- even with the double cost > of maintain moby compatibility: Even more, our current proposal for async > was born during the INB meeting (July'05) and discussed with Martin and > Eddie. This proposal is completely new and -if approved- we will need to > re-write our async code (well, not at all). Thus, once we are part of the > moby group and our ideas can be taken into account, we will move closer in > the moby direction to avoid double work from our side (as you can imagine, > this is what we want). > > > > On the other hand, our registration procedure -in my opinion- does not break > our moby compatibility. In fact you can use directly all the services we > have developed. If you see the new fields, most of them are used to allow > (user-friendly and self explicative) automatic interface building. SO they > don't have any influence in the services call protocol. > > > > We of course will be happy to propose a documentation system and other > extensions, but at this moment there are other priorities. > > In sumary; in fact we have our own ideas about a full protocol. For > strategic reasons we develeop at our own cost, some moby extension (from a > practical point of view, we took our own decisions because we needed a fast > development -you know that error handling have spent more than 4 months in > discussion!!!!). But we dont want to break moby (and we are not going to do > that). > > sorry for this long (and boring) dissertation. > > Oswaldo > > PS with repect to the registration procedure, it can be done using moby > functionality, but we request additional information to be used by our > client (if you want addictional information on our protocol dont hesitate to > request) > > > > > I read the INB paper "Intelligent client for integrating > > bioinformatics services" published in Bioinformatics. The things > > mentioned above were described there and it made me wonder... For > > asynchronous service calls the INB leads an initiative to extend the > > BioMOBY standard, which is great! This may take a bit longer to get > > accepted and implemented as compared to hacking together some custom > > extension, but it makes sure that your BioMOBY services are > > compatible with the rest of the BioMOBY world. The INB did the same > > for error handling. But for the things mentioned above the INB people > > chose to go their own way. The "extended service registration" > > procedure is INB specific and the additional (help) info is available > > form a "fourth party" server (not the BioMOBY client, nor the service > > provider, nor the INB BioMOBY Central). I think this is bad. The INB > > BioMOBY Central is out of sync with the official BioMOBY Central and > > no longer compatible, because of the modified registration procedure : > > (. Personally I think this is even worse... > > > > Anyway the things mentioned above would definitely be useful! The > > secondary parameter description was just added to the service > > registration call. So that's solved. When I retrieve a service I get > > the BioMOBY WSDL that contains amongst others all the description > > fields. If I have a typical BLAST service that supports all 40+ > > parameters it also means that this WSDL will hold the description for > > 40+ params. It's getting big...:). So adding additional help in XML > > format and example input and output there (during registration) would > > make the WSDL we send around even longer. Not my favourite solution. > > > > I would rather like to see a solution where this additional > > information is provided by the service (provider) and only when the > > client requests it explicitly. This way it doesn't need to be stored > > in a BioMOBY Central. This could be done for example using an > > additional method [ServiceName]_help. If this would be standardised > > the new RDF agent, might be extended and use this method to get the > > example input, excute the service with this example input and > > validate the results. It can than check: > > * whether the service works > > * if the input and output are valid as compared to how the service > > was registered. > > If these checks fail it might send an automated e-mail to the > > maintainer of that service and eventually if the issues are not > > resolved remove the service from BioMOBY Central. In the "cleaning > > out the registry" thread Mark mentioned that he would contact service > > providers whose services work perfectly well, but were registered > > incorrectly. No matter how efficient Mark might work, sooner or later > > BioMOBY will be so popular and BioMOBY Central so big, that doing > > this manually won't be feasible anymore. So this needs to be > > automated sooner or later anyway. Having example input and output > > might be used for that. So what do the others think... > > > > Just my 2c, > > > > Pi > > > > > > > > Kind regards, > > > Johan Karlsson > > > > > > Mark Wilkinson wrote: > > >> Absolutely - I believe the INB had also requested this a while > > >> ago, too. > > >> > > >> Do we need to go through an RFC for this? I hope not... > > >> > > >> If nobody objects, I'll add it to the API right away. It should only > > >> take a couple of minutes to code. > > >> > > >> M > > >> > > >> > > >> > > >> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: > > >> > > >>> Can we add an optional description field to the secondary article > > >>> tag? > > >>> It might help people fill it out if they have a hint *what* they're > > >>> filling out besides the articleName. i.e.: > > >>> > > >>> > > >>> This field sets the frameshift penalty in the alignment. > > >>> The higher it is set, the less likely frameshifts will be > > >>> detected and corrected. > > >>> Integer|Float|String|DateTime > > >>> ... > > >>> ... > > >>> ... > > >>> ... > > >>> ... > > >>> > > >>> > > >>> Sound reasonable? Does this require a RFC? > > >>> > > >>> _______________________________________________ > > >>> MOBY-dev mailing list > > >>> MOBY-dev at biomoby.org > > >>> http://biomoby.org/mailman/listinfo/moby-dev > > >>> > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://biomoby.org/mailman/listinfo/moby-dev > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: asynchMOBY.pdf Type: application/pdf Size: 56693 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20060224/adf252cb/attachment-0001.pdf From Sebastien.Carrere at toulouse.inra.fr Tue Feb 28 10:06:19 2006 From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere) Date: Tue, 28 Feb 2006 16:06:19 +0100 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: References: Message-ID: <440466EB.9000205@toulouse.inra.fr> Hello Pieter, I agree with you for making this change in the responseHeader sub. However, shouldn't we rewritte completely this sub to also include Error handling in the block ? Maybe this sub should have a "-exception" parameter . What do you think about this ? Cordialement, Sebastien Pieter Neerincx a ?crit : > On 28-Feb-2006, at 2:05 PM, Martin Senger wrote: > > >>> I'm not sure who runs the service "RunNCBIBlastn", but when I get an >>> exception returned, it comes in a ServiceNotes tag, not a >>> serviceNotes >>> tag (note capitalization). >>> >>> >> BTW, both are wrong, of course: it should be in >> .... >> > > Which reminds me: in Perl MOBY/Commonsubs.pm also still generates > .... So basically all the services that > use the Perl API are incompatible as well :(. Does Anyone have > objections if I change that to ... serviceNotes>? > > Cheers, > > Pi > > >> Martin >> >> -- >> Martin Senger >> email: martin.senger at gmail.com >> skype: martinsenger >> consulting for: >> International Rice Research Institute >> Biometrics and Bioinformatics Unit >> DAPO BOX 7777, Metro Manila >> Philippines, phone: +63-2-580-5600 (ext.2324) >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Tue Feb 28 11:35:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 28 Feb 2006 08:35:29 -0800 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <440467C1.5060801@ucalgary.ca> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> < 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> <44043EB4.1070108@cnb.uam.es> <440467C1.5060801@ucalgary.ca> Message-ID: <1141144529.17722.30.camel@bioinfo.icapture.ubc.ca> Hi Paul, Could you collect together the various ideas that have come up in this thread and present a formal proposal? Cheers! M On Tue, 2006-02-28 at 08:09 -0700, Paul Gordon wrote: > Given that the size of the human genome exceeds the limits of a xsd:int, > and that we often use e-values exceeding the limits of xsd:double, may I > suggest that we mandate the equivalents to xsd:integer and xsd:decimal? > I have built my jMOBY code using arbitrary precision numbers, but I'm > sure we'll need to change other parts of it, and of the Perl libraries... > > >I think we should choose the corresponding XML Schema types for each > >primitive object. For instance: > > > >moby:String -> xsd:string (it would not allow XML content) or > >xsd:anyType (any content) > > > >moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* > >integer) > > > >moby:Float -> xsd:double (IEEE double-precision 64-bit floating point > >type), xsd:float (IEEE single-precision 32-bit floating point type) or > >xsd:decimal (*any* real number with a finite number of decimal digits) > > > >moby:DateTime -> xsd:dateTime > > > >moby:Boolean -> xsd:boolean or an enumerated xsd:string > >{'0','1','false','true'} > > > > Best Regards, > > Jos? Mar?a > > > >Paul Gordon wrote: > > > > > >>The main problem: > >> > >>If somebody specifies a float, can I legally submit a e-value cutoff > >>like "1.0e-180" (i.e. are we going to assume bit capacity, such as > >>2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary > >>precision)? Underflow and overflow can cause problems on many > >>systems... same thing for integers > 2^32... > >> > >>Actually, do we support scientific notation? That isn't mentioned either. > >> > >>Cheers, > >>Paul > >> > >>P.S. Yes, you are right Pieter. You could enumerate integers, or even > >>floats for that matter: this distinction matters for a server with > >>strong types, but not for the client. I've been too client centric > >>lately :-) > >> > >> > >> > >>>On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: > >>> > >>> > >>> > >>> > >>> > >>>>Hmmm I use enum for some integers as well. I think it's perfectly > >>>>normal to say for example: enum [1,2,4,8]. > >>>> > >>>> > >>>> > >>>> > >>>Perhaps Paul can clarify what problem he is trying to solve. My > >>>instincts tell me that maybe he is having difficulty with casting un- > >>>typed XML blocks as either Integer or String, as appropriate... is that > >>>a correct interpretation of the problem Paul? > >>> > >>>I think the combination of the block and the block > >>>should be able to indicate whether the ENUM is of type String or of type > >>>Integer (or Float, or whatever). Is that not sufficient? Or am I > >>>misunderstanding what the root of the problem is? > >>> > >>>M > >>> > >>> > >>> > >>>_______________________________________________ > >>>MOBY-dev mailing list > >>>MOBY-dev at biomoby.org > >>>http://biomoby.org/mailman/listinfo/moby-dev > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev at biomoby.org > >>http://biomoby.org/mailman/listinfo/moby-dev > >> > >> > >> > >> > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From gordonp at ucalgary.ca Tue Feb 28 12:23:28 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 28 Feb 2006 10:23:28 -0700 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <1141144529.17722.30.camel@bioinfo.icapture.ubc.ca> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> < 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> <44043EB4.1070108@cnb.uam.es> <440467C1.5060801@ucalgary.ca> <1141144529.17722.30.camel@bioinfo.icapture.ubc.ca> Message-ID: <44048710.2000903@ucalgary.ca> Sure. >Hi Paul, > >Could you collect together the various ideas that have come up in this >thread and present a formal proposal? > >Cheers! > >M > > > >On Tue, 2006-02-28 at 08:09 -0700, Paul Gordon wrote: > > >>Given that the size of the human genome exceeds the limits of a xsd:int, >>and that we often use e-values exceeding the limits of xsd:double, may I >>suggest that we mandate the equivalents to xsd:integer and xsd:decimal? >>I have built my jMOBY code using arbitrary precision numbers, but I'm >>sure we'll need to change other parts of it, and of the Perl libraries... >> >> >> >>>I think we should choose the corresponding XML Schema types for each >>>primitive object. For instance: >>> >>>moby:String -> xsd:string (it would not allow XML content) or >>>xsd:anyType (any content) >>> >>>moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* >>>integer) >>> >>>moby:Float -> xsd:double (IEEE double-precision 64-bit floating point >>>type), xsd:float (IEEE single-precision 32-bit floating point type) or >>>xsd:decimal (*any* real number with a finite number of decimal digits) >>> >>>moby:DateTime -> xsd:dateTime >>> >>>moby:Boolean -> xsd:boolean or an enumerated xsd:string >>>{'0','1','false','true'} >>> >>> Best Regards, >>> Jos? Mar?a >>> >>>Paul Gordon wrote: >>> >>> >>> >>> >>>>The main problem: >>>> >>>>If somebody specifies a float, can I legally submit a e-value cutoff >>>>like "1.0e-180" (i.e. are we going to assume bit capacity, such as >>>>2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary >>>>precision)? Underflow and overflow can cause problems on many >>>>systems... same thing for integers > 2^32... >>>> >>>>Actually, do we support scientific notation? That isn't mentioned either. >>>> >>>>Cheers, >>>>Paul >>>> >>>>P.S. Yes, you are right Pieter. You could enumerate integers, or even >>>>floats for that matter: this distinction matters for a server with >>>>strong types, but not for the client. I've been too client centric >>>>lately :-) >>>> >>>> >>>> >>>> >>>> >>>>>On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hmmm I use enum for some integers as well. I think it's perfectly >>>>>>normal to say for example: enum [1,2,4,8]. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Perhaps Paul can clarify what problem he is trying to solve. My >>>>>instincts tell me that maybe he is having difficulty with casting un- >>>>>typed XML blocks as either Integer or String, as appropriate... is that >>>>>a correct interpretation of the problem Paul? >>>>> >>>>>I think the combination of the block and the block >>>>>should be able to indicate whether the ENUM is of type String or of type >>>>>Integer (or Float, or whatever). Is that not sufficient? Or am I >>>>>misunderstanding what the root of the problem is? >>>>> >>>>>M >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>MOBY-dev mailing list >>>>>MOBY-dev at biomoby.org >>>>>http://biomoby.org/mailman/listinfo/moby-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>MOBY-dev mailing list >>>>MOBY-dev at biomoby.org >>>>http://biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev >> >> From francis_gibbons at hms.harvard.edu Tue Feb 28 12:58:48 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 28 Feb 2006 12:58:48 -0500 Subject: [MOBY-dev] service registration situation.... Message-ID: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> OK, I got caught up in the service clean-up enthusiasm (roll on spring!), dereg'd all of my services, then rereg'd some of them. All seemed to go smoothly, and I can retrieve service details without difficulty. But now nothing works. As usual, due to the layering inherent in web services (SOAP/HTTP, XML parsing, etc.), I'm having a really hard time figuring out *where* the problem lies. I've tried using scripts/DebugYourService.pl, >DebugYourService.pl -a llama.med.harvard.edu -n Uetz -i simple.xml with this input (simple.xml): > > > > > and got this output: >Using default BioMOBY Central. >--------------- >Using service: > name: Uetz > authority: llama.med.harvard.edu > Description: Protein-protein interactions, by Uetz et al >--------------- >Service execution failed: 500 Can't connect to :80 (Bad hostname '') at >MOBY/Client/Service.pm line 289 The last line is totally weird! The test suite runs without errors, and I'm using the latest moby-live/Perl code under Perl 5.8.6, with SOAP::Lite v0.60. Anybody have any ideas where I should look? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Feb 28 13:40:37 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 28 Feb 2006 10:40:37 -0800 Subject: [MOBY-dev] [moby] service registration situation.... In-Reply-To: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> References: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> Message-ID: <1141152037.18276.9.camel@bioinfo.icapture.ubc.ca> Your service registrations are not correct - this is what is in the WSDL: This is confirmed by looking at the database entry: | moby | Uetz | urn:lsid:biomoby.org:servicetype:Retrieval:2001-09-21T16-00-00Z | 43 | http:///~fgibbons/cgi/BGN/dispatcher.pl | fgibbons at hms.harvard.edu | 0 | Protein-protein interactions, by Uetz et al. | 9727 | NULL | urn:lsid:biomoby.org:serviceinstance:llama.med.harvard.edu,Uetz:2006-02-27T19-03-39Z | Can you check if this is a problem with the registration system that you are using, or is it something mis-configured at your end? Whose bug is it?? M On Tue, 2006-02-28 at 12:58 -0500, Frank Gibbons wrote: > OK, > > I got caught up in the service clean-up enthusiasm (roll on spring!), > dereg'd all of my services, then rereg'd some of them. All seemed to go > smoothly, and I can retrieve service details without difficulty. > > But now nothing works. As usual, due to the layering inherent in web > services (SOAP/HTTP, XML parsing, etc.), I'm having a really hard time > figuring out *where* the problem lies. > > I've tried using scripts/DebugYourService.pl, > > >DebugYourService.pl -a llama.med.harvard.edu -n Uetz -i simple.xml > > with this input (simple.xml): > > > > > > > > > > > > > and got this output: > > >Using default BioMOBY Central. > >--------------- > >Using service: > > name: Uetz > > authority: llama.med.harvard.edu > > Description: Protein-protein interactions, by Uetz et al > >--------------- > >Service execution failed: 500 Can't connect to :80 (Bad hostname '') at > >MOBY/Client/Service.pm line 289 > > The last line is totally weird! The test suite runs without errors, and I'm > using the latest moby-live/Perl code under Perl 5.8.6, with SOAP::Lite v0.60. > > Anybody have any ideas where I should look? > > -Frank > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Tue Feb 28 13:58:12 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 28 Feb 2006 13:58:12 -0500 Subject: [MOBY-dev] [moby] service registration situation.... In-Reply-To: <1141152037.18276.9.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060228135638.01258b30@email.med.harvard.edu> Thanks Mark - looks like I mis-registered the address, likely a mis-configuration of the script I use to register services. Strangely, it used to work, but I haven't used it in a while. I'll fix it and try again - thanks for quick response, sorry for inconvenience. My bug. -Frank At 01:40 PM 2/28/2006, you wrote: >Your service registrations are not correct - this is what is in the >WSDL: > > > >This is confirmed by looking at the database entry: >| moby | Uetz | >urn:lsid:biomoby.org:servicetype:Retrieval:2001-09-21T16-00-00Z | >43 | http:///~fgibbons/cgi/BGN/dispatcher.pl | fgibbons at hms.harvard.edu >| 0 | Protein-protein interactions, by Uetz et al. > | 9727 | NULL | >urn:lsid:biomoby.org:serviceinstance:llama.med.harvard.edu,Uetz:2006-02-27T19-03-39Z >| > > >Can you check if this is a problem with the registration system that you >are using, or is it something mis-configured at your end? > >Whose bug is it?? > >M > > > > > >On Tue, 2006-02-28 at 12:58 -0500, Frank Gibbons wrote: > > OK, > > > > I got caught up in the service clean-up enthusiasm (roll on spring!), > > dereg'd all of my services, then rereg'd some of them. All seemed to go > > smoothly, and I can retrieve service details without difficulty. > > > > But now nothing works. As usual, due to the layering inherent in web > > services (SOAP/HTTP, XML parsing, etc.), I'm having a really hard time > > figuring out *where* the problem lies. > > > > I've tried using scripts/DebugYourService.pl, > > > > >DebugYourService.pl -a llama.med.harvard.edu -n Uetz -i simple.xml > > > > with this input (simple.xml): > > > > > > > > > > > > > > > > > > > > > and got this output: > > > > >Using default BioMOBY Central. > > >--------------- > > >Using service: > > > name: Uetz > > > authority: llama.med.harvard.edu > > > Description: Protein-protein interactions, by Uetz et al > > >--------------- > > >Service execution failed: 500 Can't connect to :80 (Bad hostname '') at > > >MOBY/Client/Service.pm line 289 > > > > The last line is totally weird! The test suite runs without errors, and > I'm > > using the latest moby-live/Perl code under Perl 5.8.6, with SOAP::Lite > v0.60. > > > > Anybody have any ideas where I should look? > > > > -Frank > > > > > > PhD, Computational Biologist, > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > > Tel: 617-432-3555 Fax: > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev >-- > >-- >Mark Wilkinson >Asst. Professor, Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics, iCAPTURE Centre >St. Paul's Hospital, Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Feb 28 14:18:39 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 28 Feb 2006 11:18:39 -0800 Subject: [MOBY-dev] [moby] service registration situation.... In-Reply-To: <5.2.1.1.2.20060228135638.01258b30@email.med.harvard.edu> References: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> <5.2.1.1.2.20060228135638.01258b30@email.med.harvard.edu> Message-ID: <1141154319.18276.35.camel@bioinfo.icapture.ubc.ca> no worries :-) M On Tue, 2006-02-28 at 13:58 -0500, Frank Gibbons wrote: > Thanks Mark - looks like I mis-registered the address, likely a > mis-configuration of the script I use to register services. Strangely, it > used to work, but I haven't used it in a while. I'll fix it and try again - > thanks for quick response, sorry for inconvenience. > > My bug. > > -Frank > > At 01:40 PM 2/28/2006, you wrote: > >Your service registrations are not correct - this is what is in the > >WSDL: > > > > > > > >This is confirmed by looking at the database entry: > >| moby | Uetz | > >urn:lsid:biomoby.org:servicetype:Retrieval:2001-09-21T16-00-00Z | > >43 | http:///~fgibbons/cgi/BGN/dispatcher.pl | fgibbons at hms.harvard.edu > >| 0 | Protein-protein interactions, by Uetz et al. > > | 9727 | NULL | > >urn:lsid:biomoby.org:serviceinstance:llama.med.harvard.edu,Uetz:2006-02-27T19-03-39Z > >| > > > > > >Can you check if this is a problem with the registration system that you > >are using, or is it something mis-configured at your end? > > > >Whose bug is it?? > > > >M > > > > > > > > > > > >On Tue, 2006-02-28 at 12:58 -0500, Frank Gibbons wrote: > > > OK, > > > > > > I got caught up in the service clean-up enthusiasm (roll on spring!), > > > dereg'd all of my services, then rereg'd some of them. All seemed to go > > > smoothly, and I can retrieve service details without difficulty. > > > > > > But now nothing works. As usual, due to the layering inherent in web > > > services (SOAP/HTTP, XML parsing, etc.), I'm having a really hard time > > > figuring out *where* the problem lies. > > > > > > I've tried using scripts/DebugYourService.pl, > > > > > > >DebugYourService.pl -a llama.med.harvard.edu -n Uetz -i simple.xml > > > > > > with this input (simple.xml): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and got this output: > > > > > > >Using default BioMOBY Central. > > > >--------------- > > > >Using service: > > > > name: Uetz > > > > authority: llama.med.harvard.edu > > > > Description: Protein-protein interactions, by Uetz et al > > > >--------------- > > > >Service execution failed: 500 Can't connect to :80 (Bad hostname '') at > > > >MOBY/Client/Service.pm line 289 > > > > > > The last line is totally weird! The test suite runs without errors, and > > I'm > > > using the latest moby-live/Perl code under Perl 5.8.6, with SOAP::Lite > > v0.60. > > > > > > Anybody have any ideas where I should look? > > > > > > -Frank > > > > > > > > > PhD, Computational Biologist, > > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > > USA. > > > Tel: 617-432-3555 Fax: > > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://biomoby.org/mailman/listinfo/moby-dev > >-- > > > >-- > >Mark Wilkinson > >Asst. Professor, Dept. of Medical Genetics > >University of British Columbia > >PI in Bioinformatics, iCAPTURE Centre > >St. Paul's Hospital, Rm. 166, 1081 Burrard St. > >Vancouver, BC, V6Z 1Y6 > >tel: 604 682 2344 x62129 > >fax: 604 806 9274 > > > >"For most of this century we have viewed communications as a conduit, > > a pipe between physical locations on the planet. > >What's happened now is that the conduit has become so big and interesting > > that communication has become more than a conduit, > > it has become a destination in its own right..." > > > > Paul Saffo - Director, Institute for the Future > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Tue Feb 28 14:59:01 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 28 Feb 2006 20:59:01 +0100 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <44043EB4.1070108@cnb.uam.es> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl>< 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> <44043EB4.1070108@cnb.uam.es> Message-ID: <76307C2D-96BF-4AA2-83E1-8E4B66030AD2@wur.nl> Sounds like a good plan to me... Cheers, Pi On 28Feb2006, at 13:14, Jos? Mar?a Fern?ndez Gonz?lez wrote: > I think we should choose the corresponding XML Schema types for each > primitive object. For instance: > > moby:String -> xsd:string (it would not allow XML content) or > xsd:anyType (any content) > > moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* > integer) > > moby:Float -> xsd:double (IEEE double-precision 64-bit floating point > type), xsd:float (IEEE single-precision 32-bit floating point type) or > xsd:decimal (*any* real number with a finite number of decimal digits) > > moby:DateTime -> xsd:dateTime > > moby:Boolean -> xsd:boolean or an enumerated xsd:string > {'0','1','false','true'} > > Best Regards, > Jos? Mar?a > > Paul Gordon wrote: >> The main problem: >> >> If somebody specifies a float, can I legally submit a e-value cutoff >> like "1.0e-180" (i.e. are we going to assume bit capacity, such as >> 2^-149 for 16-byte IEEE floating point, or are we supporting >> arbitrary >> precision)? Underflow and overflow can cause problems on many >> systems... same thing for integers > 2^32... >> >> Actually, do we support scientific notation? That isn't mentioned >> either. >> >> Cheers, >> Paul >> >> P.S. Yes, you are right Pieter. You could enumerate integers, or >> even >> floats for that matter: this distinction matters for a server with >> strong types, but not for the client. I've been too client centric >> lately :-) >> >>> On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: >>> >>> >>> >>>> Hmmm I use enum for some integers as well. I think it's perfectly >>>> normal to say for example: enum [1,2,4,8]. >>>> >>>> >>> Perhaps Paul can clarify what problem he is trying to solve. My >>> instincts tell me that maybe he is having difficulty with casting >>> un- >>> typed XML blocks as either Integer or String, as appropriate... >>> is that >>> a correct interpretation of the problem Paul? >>> >>> I think the combination of the block and the block >>> should be able to indicate whether the ENUM is of type String or >>> of type >>> Integer (or Float, or whatever). Is that not sufficient? Or am I >>> misunderstanding what the root of the problem is? >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> >> > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 Pieter.Neerincx at wur.nl Tue Feb 28 16:52:02 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 28 Feb 2006 22:52:02 +0100 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: <440466EB.9000205@toulouse.inra.fr> References: <440466EB.9000205@toulouse.inra.fr> Message-ID: On 28Feb2006, at 16:06, Sebastien Carrere wrote: > Hello Pieter, > > I agree with you for making this change in the responseHeader sub. Done :). > However, shouldn't we rewritte completely this sub to also include > Error > handling in the block ? > Maybe this sub should have a "-exception" parameter . > > What do you think about this ? Yes we should, but that requires a bit more work and debugging. Moving the human readable stuff to Notes inside serviceNotes was a 5 minute fix. So at least we're compatible with the current specs again although the advanced error handling is not implemented yet. Cheers, Pi > Cordialement, > Sebastien > > > > Pieter Neerincx a ?crit : >> On 28-Feb-2006, at 2:05 PM, Martin Senger wrote: >> >> >>>> I'm not sure who runs the service "RunNCBIBlastn", but when I >>>> get an >>>> exception returned, it comes in a ServiceNotes tag, not a >>>> serviceNotes >>>> tag (note capitalization). >>>> >>>> >>> BTW, both are wrong, of course: it should be in >>> .... >>> >> >> Which reminds me: in Perl MOBY/Commonsubs.pm also still generates >> .... So basically all the services that >> use the Perl API are incompatible as well :(. Does Anyone have >> objections if I change that to ...> serviceNotes>? >> >> Cheers, >> >> Pi >> >> >>> Martin >>> >>> -- >>> Martin Senger >>> email: martin.senger at gmail.com >>> skype: martinsenger >>> consulting for: >>> International Rice Research Institute >>> Biometrics and Bioinformatics Unit >>> DAPO BOX 7777, Metro Manila >>> Philippines, phone: +63-2-580-5600 (ext.2324) >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> >> >> > > -- > __________________________________________________________ > > Sebastien CARRERE LIPM (INRA-CNRS) > B.P.52627 -- 31326 CASTANET TOLOSAN > tel:(33) 5-61-28-53-29 > fax:(33) 5-61-28-50-61 > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Wed Feb 1 01:22:37 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 31 Jan 2006 17:22:37 -0800 Subject: [MOBY-dev] RFC1913 & 1914 passed Message-ID: <1138756957.30488.10.camel@bioinfo.icapture.ubc.ca> Hi all, Just a confirmation that, by my count, 1913 and 1914 have now reached a majority, and so are passed. The initial timestamp (lsid version has been suggested as 2001-09-21T16-00-00Z. That's okay with me unless anyone has objections. I'll do the database update later this week, and will make the update script available in the CVS moby-live/Database folder for others to use. Cheers! Mark -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Wed Feb 1 08:05:50 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 1 Feb 2006 08:05:50 +0000 (GMT) Subject: [MOBY-dev] fixes in Moses Message-ID: Hi, Few new fixes/features in jMoby: 1) I have added a new method setValueXML() that allows you to create a Moby XML input as CDATA (if you wish so, but it is not that important I guess). 2) Much more important: I have fixed a nasty bug in Moses objects that prevented (in some cases) to recognize that a more specialized data type has arrived to a moby service (thanks to Eddie for finding the problem). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Feb 1 08:25:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 00:25:35 -0800 Subject: [MOBY-dev] fixes in Moses In-Reply-To: References: Message-ID: On Wed, 01 Feb 2006 00:05:50 -0800, Martin Senger wrote: > 2) Much more important: I have fixed a nasty bug in Moses objects that > prevented (in some cases) to recognize that a more specialized data type > has arrived to a moby service (thanks to Eddie for finding the problem). excellent! This is one of the aspects of MOBY that we haven't fully taken advantage of in the past. gbrowse_moby handles it, but I'm not sure if Taverna does (?? does it ??) I am *so* looking forward to 'Moby II' where we model things in RDF rather than XML, since that will allow us to make the "has" and "hasa" subcomponents of an object also be more complex than they are defined in the ontology. In the current MOBY XML data messages this isn't allowed because we have little choice but to use XPath queries to get at the subcomponents of a data-object, and that would break if the subcomponents were not predictable (by their primary tags)... Nevertheless, allowing the outermost object to be more complex still gives us a lot of freedom! Thanks Martin! M From senger at ebi.ac.uk Wed Feb 1 10:29:38 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 1 Feb 2006 10:29:38 +0000 (GMT) Subject: [MOBY-dev] MOBY II (Was: fixes in Moses) In-Reply-To: Message-ID: > I am *so* looking forward to 'Moby II' where we model things in RDF rather > than XML > To be honest I am rather affraid of that. We all invested time and efforts into making biomoby working. If we are going to change all API and the way how it works we will need to invest gain. Change is not bad, but must be discussed and must have a merit, not just that RDF is more fancy. I hope that we are still on the same board... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Feb 1 15:31:43 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 07:31:43 -0800 Subject: [MOBY-dev] MOBY II (Was: fixes in Moses) In-Reply-To: References: Message-ID: Absolutely - it isn't going to change in a hurry, and it isn't going to change without good reason! There are still many things that can be done with MOBY to use/improve it under the current architecture; however, the "research" potential of the MOBY architecture is largely spent - it's now more a (well funded!) technical excercise of tweaking and adding improvements here and there. There is research potential in the automated selection of services, and the automated integration of the resulting data, and I have grant applications in within those domains, but MOBY *architecture* per se is no longer a "research theme" of my group; Since I am obligated to a research programme out of my lab, we're starting to "play" with RDF representations of MOBY data here just to see how much (if any) advantage it gives us, and whether OWL versions of the MOBY ontologies help in the service discovery/data integration problem. So... don't worry, I'm not suggesting that we break anything! :-) M On Wed, 01 Feb 2006 02:29:38 -0800, Martin Senger wrote: >> I am *so* looking forward to 'Moby II' where we model things in RDF >> rather >> than XML >> > To be honest I am rather affraid of that. We all invested time and > efforts into making biomoby working. If we are going to change all API > and > the way how it works we will need to invest gain. Change is not bad, but > must be discussed and must have a merit, not just that RDF is more > fancy. I hope that we are still on the same board... > > Martin > From johan at ac.uma.es Wed Feb 1 16:17:56 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Wed, 01 Feb 2006 17:17:56 +0100 Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43E0DF34.7070300@ac.uma.es> Hi Martin! Well, the proposal itself should not take very long time to read (but naturally people have other things to do as well). To me, it does not sound unreasonable to expect comments within the next two weeks (we could set the date 15th of February). Comments and suggestions from the BioMOBY community are most welcome but the idea of a time schedule is a good one. This issue has been debated for quite some time without any final result. We need a good and well-documented solution but we need it very soon. Waiting for your comments! Kind regards, Johan Karlsson ------------------------- Johan Karlsson Department of Computer Architecture University of M?laga M?laga, Spain johan at ac.uma.es Martin Senger wrote: >> Attached to this email you can find the INB proposal (RFC) on >> asynchronous service calls. >> >> > Thank you for putting together the proposal. I am going to read it > thoroughly. But it would help me/us if you give us a planned time schedule > when you expect our comments to be back. Could you suggest a sort of > deadline please? > > Regards, > Martin > > From francis_gibbons at hms.harvard.edu Wed Feb 1 17:51:26 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Feb 2006 12:51:26 -0500 Subject: [MOBY-dev] Here's a question.... Message-ID: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> In the Perl MOBY codebase, there is a very confusing parallelism: there's the MOBY directory, and then there's the lib/MOBY directory. There's a line in the Makefile that copies from MOBY to lib/MOBY. Why is this necessary? Perhaps it's related to the following questions. "make install" appears only to work on changes made in "lib/MOBY". I guess this is normal for Perl, except that the "real" version of the source is kept in MOBY. "cvs" appears to deal only with changes made in "MOBY". That's fine too, except that Perl expects to find it in lib/MOBY. Every time I go away from MOBY for a while and come back, this bites me in the ass: I find myself editing in the wrong place, and just getting *really* confused. If I need to edit, where should I do it: MOBY or lib/MOBY? If I need to install my changes, is it simply "make install" or is there something else I should be doing? For example, should I "make clean" each time I want to install? I presume this parallelism is a way to hang onto the CVS comments, while adopting the more usual Perl installation tree. FYI, I have perl 5.8.6 (just upgraded last week), running on SuSE Linux. Can someone out there set me straight? I'd really appreciate it - my ass is starting to hurt ;-) -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Wed Feb 1 18:45:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 10:45:02 -0800 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> References: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> Message-ID: <1138819502.4897.22.camel@bioinfo.icapture.ubc.ca> The /lib/ folder is created during the "make" process. It isn't in the CVS... You should be editing the code in the moby-live/Perl/MOBY* folder, and then running: perl Makefile.pl make make install each time to install it. This isn't a MOBY problem :-) M On Wed, 2006-02-01 at 12:51 -0500, Frank Gibbons wrote: > In the Perl MOBY codebase, there is a very confusing parallelism: there's > the MOBY directory, and then there's the lib/MOBY directory. > > There's a line in the Makefile that copies from MOBY to lib/MOBY. Why is > this necessary? Perhaps it's related to the following questions. > > "make install" appears only to work on changes made in "lib/MOBY". I guess > this is normal for Perl, except that the "real" version of the source is > kept in MOBY. > > "cvs" appears to deal only with changes made in "MOBY". That's fine too, > except that Perl expects to find it in lib/MOBY. > > Every time I go away from MOBY for a while and come back, this bites me in > the ass: I find myself editing in the wrong place, and just getting > *really* confused. > > If I need to edit, where should I do it: MOBY or lib/MOBY? If I need to > install my changes, is it simply "make install" or is there something else > I should be doing? For example, should I "make clean" each time I want to > install? I presume this parallelism is a way to hang onto the CVS comments, > while adopting the more usual Perl installation tree. > > FYI, I have perl 5.8.6 (just upgraded last week), running on SuSE Linux. > > Can someone out there set me straight? I'd really appreciate it - my ass is > starting to hurt ;-) > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Wed Feb 1 18:56:09 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Feb 2006 13:56:09 -0500 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <1138819502.4897.22.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> At 01:45 PM 2/1/2006, you wrote: >You should be editing the code in the moby-live/Perl/MOBY* folder, and >then running: > >perl Makefile.pl >make >make install > >each time to install it. Thanks, Mark. So each time I make a change to a source file, I re-do the entire build process? That's what I had decided needed to happen, as illogical as it sounds to me, since the usual "make" wasn't working properly. Why do we have the duality between MOBY and lib/MOBY? (There's also the version in blib/lib/MOBY, but we know that's created by Perl automatically, so let's not even go there.) Wouldn't it be easier to have a single copy? Is there a good reason to have two copies (I alluded to some in my previous emails). -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From adf at ncgr.org Wed Feb 1 19:17:37 2006 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 1 Feb 2006 12:17:37 -0700 (MST) Subject: [MOBY-dev] [HCLSIG] homologs for yeast proteins? In-Reply-To: Message-ID: replying to the following (and apologies for some cross-posting): > Basically that's why I'm in this group. A challenging question for any > existing Bio* package is whether it can meet the _next_ set of challenges, > like integrating the data. Without attempting to answer that question I'll > say it's easy to imagine that "BioRDF", or the equivalent, would make an > excellent alternative. > > one-stop web portal that can answer this query right now. But it it > > doesn't really help with the generalised case of ontology-aware queries > > of disparate data sources. BioMoby may be able to do something like > > this. Any BioMoby folks on the list? Hi all- I've been somewhat involved in the various BioMOBY projects (though by no means an official spokeperson- hopefully others from that community will chime in), but I picked up on Chris' reference. These things are certainly very much the space at which the BioMOBY efforts are aimed and the use of semantic web technologies, though still a bit nascent, is beginning to take off in some of the MOBY-related development efforts. As one example, you might care to look at a prototypical system based on an early version of the "semantic MOBY" branch of the project at: http://lin.ncgr.org There are a few sets of slides off the help link that give a bit more details than I will here. It uses OWL-based service descriptions for "data-driven" service discovery and RDF graphs for transmission of data in service invocation and response graphs, which enables some interesting aggregative behavior, hooks nicely into some "rich clients" for visulization and interaction with the data, and at least sets the stage for us to engage in some of the nifty promises offered by the higher levels of the semantic web stack. Coincidentally, the central "use case" we chose to highlight the prototype was in fact right along the lines of the question that started this thread, namely exploring homology/orthology/paralogy relationships among functionally annotated sequences (though our focus is on legume data, in which these issues are even more interesting than yeast, IMHO! note, too, that plant biology is also very important to the issues of human health that appear to be the main focus of the "life sci" half of this interest group...) It is very much a prototype at this point (in terms of functionality, documentation, and "production-readiness", i.e. please don't retrieve a set of 10000 sequences and send it to the BLAST service!), but early indications from the plant biologists to whom we have demoed to indicate that we have gone a fair way to helping our user community begin to understand the "semantic value proposition". We hope to evolve it to tap into even more of the potential of the semantic web technologies, we have a lot of ideas about next steps and welcome any help in this direction from interested parties. I guess that is probably enough for the purposes of this list, if anyone is interested in further conversations in this direction, they can get in touch with either our small project (lin at ncgr.org) or the larger MOBY development community (subscribe to lists at biomoby.org). Thanks for listening... Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From adf at ncgr.org Wed Feb 1 19:10:02 2006 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 1 Feb 2006 12:10:02 -0700 (MST) Subject: [MOBY-dev] MOBY II (Was: fixes in Moses) In-Reply-To: Message-ID: Hey all- > > I am *so* looking forward to 'Moby II' where we model things in RDF rather > > than XML > > > To be honest I am rather affraid of that. We all invested time and > efforts into making biomoby working. If we are going to change all API and > the way how it works we will need to invest gain. Change is not bad, but > must be discussed and must have a merit, not just that RDF is more > fancy. I hope that we are still on the same board... > I am glad to hear Mark's enthusiasm for the future use of RDF in MOBY, as well as sympathetic to Martin's concerns (which perhaps Mark's subsequent message has helped to allay). Along those lines, as some of you already know, a few of us at NCGR and a collaborating group (CCGB) from the University of Minnesota recently released the first prototype of a RDF-based service discovery/invocation system, using the basic semantic MOBY approach. You can check it out at: http://lin.ncgr.org Do be aware that it is definitely a prototype and it is far too easy at the moment to invoke services with unreasonable amounts of data; also, it is a bit underdocumented at the moment, though we have put a few sets of slides off the Help link that may help explain; anyway it is pretty intuitive and should not be a quantum leap for the MOBY crowd ;) It also makes some rough inroads in realizing my old dream of getting ISYS back into the picture... We'll be evolving it (we've only scratched the surface!) as funding and involvement in the VPIN project permit, but we have a few lessons learned at this point some of which are a bit relevant to this discussion (which I hope is an omen of blessed days when the two MOBYs are as one ;) ) One of these brings me back from "publicity mode" to Martin's concerns: >From what I understand of MOBY services, it seems that it ought to be entirely possible to use RDF as the data modelling and ontology development substrate without much impacting the messaging aspect of MOBY services and hence presumably allowing the S-MOBY "API" to remain relatively intact (at least, those parts that don't have to do with the interpretation of the "payload" data, although I am sure those are the most important parts!); this step would seem to be a logical one to allow the two branches of MOBY to converge on ideas for shared representation of data even if we cannot come to agreement about the right formalisms for messaging. I am personally not at all convinced that RDF is the right approach for the messaging layer, but certainly trying to be open-minded about it and other ideas. In any case, I am a bit ignorant as to whether any real discussions have been taking place as to the path to "MOBY II", but remain hopeful that they will take place "real soon now". Regards to all, (and apologies for long-windedness and for the somewhat duplicative post you'll receive off the semantic web life sciences mailing list thread that has just mentioned BioMOBY- get your 2c in now!) -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From markw at illuminae.com Wed Feb 1 19:03:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 11:03:29 -0800 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> References: <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> Message-ID: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-02-01 at 13:56 -0500, Frank Gibbons wrote: > Thanks, Mark. So each time I make a change to a source file, I re-do the > entire build process? That's what I had decided needed to happen, as > illogical as it sounds to me, since the usual "make" wasn't working properly. Yeah, I believe you do need to re-do the entire process (though I think you could also do a "make clean" rather than re-running the Makefile... I think...) > Why do we have the duality between MOBY and lib/MOBY? (There's also the > version in blib/lib/MOBY, but we know that's created by Perl automatically, > so let's not even go there.) Wouldn't it be easier to have a single copy? > Is there a good reason to have two copies (I alluded to some in my previous > emails). To be honest, I haven't thought about it in years. It's one of those things that "just works", and I can't remember the details of why. The lib and the blib folders are created through the "make" process, and I simply never look at them, since there's no point in editing anything in there anyway... M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Wed Feb 1 19:32:04 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 11:32:04 -0800 Subject: [MOBY-dev] [moby] Re: [HCLSIG] homologs for yeast proteins? In-Reply-To: References: Message-ID: <1138822324.4897.41.camel@bioinfo.icapture.ubc.ca> The web-service branch of BioMOBY is up and running happily (and is being well-used!) but is somewhat locked-in to a legacy XML format that was designed a couple of years before RDF became "the norm". This is unfortunate, since the MOBY XML format was designed to do a very similar job - that is, serialize an ontology. Nevertheless, we are muddling through, and though the messages that are being passed between service and client are in this MOBYesque XML format, we do use ontological queries to achieve the "semantic mapping" between a client with a piece of data, and the various services that could operate on that data. The guts of MOBY are very rapidly being migrated to use OWL/RDF to enhance and simplify this semantic mapping using a reasoner, but the messaging format will remain a legacy problem for quite a while since we have so many services that use it now... It seems, however, that we can inter-convert our XML with RDF fairly easily and reliably, so this may not be as big a problem as we had initially thought. Eric Miller (on this list) has seen my presentation of MOBY and talked to me briefly about it, so he may have some comments on how close/far we are from a "true" semantic-web-service vision... given that we built this in 2001, I think we got it ALMOST right! ...personal bias, of course ;-) Mark On Wed, 2006-02-01 at 12:17 -0700, Andrew D. Farmer wrote: > replying to the following (and apologies for some cross-posting): > > > > Basically that's why I'm in this group. A challenging question for any > > existing Bio* package is whether it can meet the _next_ set of challenges, > > like integrating the data. Without attempting to answer that question I'll > > say it's easy to imagine that "BioRDF", or the equivalent, would make an > > excellent alternative. > > > > > one-stop web portal that can answer this query right now. But it it > > > doesn't really help with the generalised case of ontology-aware queries > > > of disparate data sources. BioMoby may be able to do something like > > > this. Any BioMoby folks on the list? > > > Hi all- > > I've been somewhat involved in the various BioMOBY projects (though by > no means an official spokeperson- hopefully others from that community will > chime in), but I picked up on Chris' reference. These things are certainly > very much the space at which the BioMOBY efforts are aimed and the use of > semantic web technologies, though still a bit nascent, is beginning to take off > in some of the MOBY-related development efforts. > > As one example, you might care to look at a prototypical system based on > an early version of the "semantic MOBY" branch of the project at: > http://lin.ncgr.org > > There are a few sets of slides off the help link that give a bit more details > than I will here. > > It uses OWL-based service descriptions for "data-driven" service discovery and > RDF graphs for transmission of data in service invocation and response graphs, > which enables some interesting aggregative behavior, hooks nicely into some > "rich clients" for visulization and interaction with the data, and at least > sets the stage for us to engage in some of the nifty promises offered by the > higher levels of the semantic web stack. Coincidentally, the central "use > case" we chose to highlight the prototype was in fact right along the lines > of the question that started this thread, namely exploring > homology/orthology/paralogy relationships among functionally annotated > sequences (though our focus is on legume data, in which these issues are > even more interesting than yeast, IMHO! note, too, that plant biology is > also very important to the issues of human health that appear to be the > main focus of the "life sci" half of this interest group...) > > It is very much a prototype at this point (in terms of functionality, > documentation, and "production-readiness", i.e. please don't retrieve > a set of 10000 sequences and send it to the BLAST service!), > but early indications from the plant biologists to whom we have demoed to > indicate that we have gone a fair way to helping our user community begin to > understand the "semantic value proposition". We hope to evolve it to tap > into even more of the potential of the semantic web technologies, we have a > lot of ideas about next steps and welcome any help in this direction from > interested parties. > > I guess that is probably enough for the purposes of this list, if anyone > is interested in further conversations in this direction, they can get in > touch with either our small project (lin at ncgr.org) or the larger > MOBY development community (subscribe to lists at biomoby.org). > > > Thanks for listening... > > Andrew Farmer > adf at ncgr.org > (505) 995-4464 > Database Administrator/Software Developer > National Center for Genome Resources > > --- > "To live in the presence of great truths and eternal laws, > to be led by permanent ideals- > that is what keeps a man patient when the world ignores him, > and calm and unspoiled when the world praises him." > -Balzac > --- > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Wed Feb 1 19:47:38 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 11:47:38 -0800 Subject: [MOBY-dev] [moby] Re: Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> Message-ID: <1138823258.4897.54.camel@bioinfo.icapture.ubc.ca> On Mon, 2006-01-30 at 17:53 +0100, Pieter Neerincx wrote: > No I think you got it right. S::L shouldn't mess it up, but I can > predict that fixing it by changing the prefix in BioMOBY is much > faster than trying to get a fix into the next "stable" release of > S::L. Please go ahead with this change. The other problems are a bit more frustrating, and harder to deal with! It isn't just a question of being S::L compatible, it's also a question of doing the right thing, since we have to be compatible with the Java/Python libraries as well. If S::L is wrong, then we need to push them to change; if *we* are wrong, then we need to recognize that and fix the message structure. I need to do some more reading to figure out which is the case. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Wed Feb 1 20:21:39 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Feb 2006 15:21:39 -0500 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060201151421.028f31f0@email.med.harvard.edu> At 02:03 PM 2/1/2006, you wrote: >To be honest, I haven't thought about it in years. It's one of those >things that "just works", and I can't remember the details of why. The >lib and the blib folders are created through the "make" process, and I >simply never look at them, since there's no point in editing anything in >there anyway... Mark, I know that the "blib" folder "just works". But without a rule in the Makefile expressing the dependency between the files we edit (in MOBY) and the files that Perl uses to build the module (lib/MOBY), we effectively break the build process invisibly. Changes made in "MOBY" do not "just work" unless the developer does the entire "perl Makefile.PL; make; make install". It's the explicit system call in Makefile.PL that updates lib/MOBY from MOBY, and which should be done by make, not perl Makefile.PL. Along comes a developer used to the usual way (change the source? rebuild with "make"! You normally only do "perl Makefile.PL" upon downloading a new module, since it configures the whole system), and the dependencies are broken. I say "invisibly" above, because Perl doesn't complain, it simply ignores what you did in MOBY, since all it cares about are what's in lib/MOBY. Your changes never get propagated, and you can't figure out why your old broken code seems to be unstoppable - you rebuild, it's still there! Anyway, I'm glad to know that it's not just me ;-). I'm going to try to configure Makefile.PL to properly handle dependencies, so that it works like it's supposed to. I think there's some kind of variable to tell it where to find the real code - we should point it at MOBY (not lib/MOBY, the default) -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From ddg at ncgr.org Wed Feb 1 20:08:51 2006 From: ddg at ncgr.org (Damian Gessler) Date: Wed, 1 Feb 2006 13:08:51 -0700 Subject: [MOBY-dev] MOBY II (Was: fixes in Moses) References: Message-ID: <012a01c6276b$51dc64e0$674413ac@ncgr.org> Re: >> > I am *so* looking forward to 'Moby II' where we model things in RDF >> > rather >> > than XML >> > >> To be honest I am rather affraid of that. We all invested time and >> efforts into making biomoby working. If we are going to change all API >> and >> the way how it works we will need to invest gain. Change is not bad, but >> must be discussed and must have a merit, not just that RDF is more >> fancy. I hope that we are still on the same board... >> I caught just a glimpse of this, and understand that the first part of the quoted text is from Mark, and the second from Martin. I can assure you, that from our discussions at BioMOBY meetings--with Mark, Martin, and others present--to our application to NSF for the VPIN, to our current work plans, we have always seen the aim of bridging Semantic MOBY and MOBY Services as one of *joining* mature and value-laden technologies. I continue to believe that some things are just "done better" with a services approach, and some are "done better" with a semantic approach, and our goal in bridging the MOBY's is to develop a potent Semantic Web Services (SWS) platform that works and solves real world problems. Far from seeing MOBY Services or Semantic MOBY code be abandoned or not used, I am eager to see both technologies mature to deliver their respective underlying support for a SWS. Best to y'all; you're doing good work, Damian. From francis_gibbons at hms.harvard.edu Wed Feb 1 20:39:29 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Feb 2006 15:39:29 -0500 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <5.2.1.1.2.20060201151421.028f31f0@email.med.harvard.edu> References: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> At 03:21 PM 2/1/2006, you wrote: >Anyway, I'm glad to know that it's not just me ;-). I'm going to try to >configure Makefile.PL to properly handle dependencies, so that it works >like it's supposed to. I think there's some kind of variable to tell it >where to find the real code - we should point it at MOBY (not lib/MOBY, the >default) Anyone know of a good reason to explicitly copy the code from MOBY to lib/MOBY? ExtUtils::MakeMaker has a variable (called 'PMLIBDIRS') that allows you to tell perl where the source code lives, so there's no need to copy it from one place to another, just point it to the right place, and you're all set. It defaults to ["lib", "MOBY"], and perhaps that's why the copying statement was added. But really it's unnecessary (as I see it), and confusing. I intend to check in a new Makefile.PL that uses PMLIBDIRS and does away with the copying. Let me know if there's a good reason for NOT changing things (maybe it won't work on Mac OS 9? maybe it only works in Perl 5.6.x or better?). I'll check in within 24 hours, otherwise. The reason FOR this change is to follow the implicit rules of building a perl module (or any software using 'make'). Rebuilding should be accomplishable by typing "make", nothing more. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Wed Feb 1 20:39:27 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 01 Feb 2006 12:39:27 -0800 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> References: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> Message-ID: <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> I have no problem with this. whatever makes it more correct and easier to use is a good thing! M On Wed, 2006-02-01 at 15:39 -0500, Frank Gibbons wrote: > At 03:21 PM 2/1/2006, you wrote: > >Anyway, I'm glad to know that it's not just me ;-). I'm going to try to > >configure Makefile.PL to properly handle dependencies, so that it works > >like it's supposed to. I think there's some kind of variable to tell it > >where to find the real code - we should point it at MOBY (not lib/MOBY, the > >default) > > Anyone know of a good reason to explicitly copy the code from MOBY to lib/MOBY? > > ExtUtils::MakeMaker has a variable (called 'PMLIBDIRS') that allows you to > tell perl where the source code lives, so there's no need to copy it from > one place to another, just point it to the right place, and you're all set. > It defaults to ["lib", "MOBY"], and perhaps that's why the copying > statement was added. But really it's unnecessary (as I see it), and > confusing. I intend to check in a new Makefile.PL that uses PMLIBDIRS and > does away with the copying. > > Let me know if there's a good reason for NOT changing things (maybe it > won't work on Mac OS 9? maybe it only works in Perl 5.6.x or better?). I'll > check in within 24 hours, otherwise. > > The reason FOR this change is to follow the implicit rules of building a > perl module (or any software using 'make'). Rebuilding should be > accomplishable by typing "make", nothing more. > > -Frank > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Wed Feb 1 23:12:24 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 2 Feb 2006 00:12:24 +0100 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> References: <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Frank, On 01Feb2006, at 21:39, Mark Wilkinson wrote: > I have no problem with this. whatever makes it more correct and > easier > to use is a good thing! I second that. The way it used to work so far surprised me a bit as well, but after I figured it out I was already glad it just worked :). If you are creating a better Makefile.PL would it be also possible to add the pod2html documentation file building somewhere in the process? Currently it's not, so the [module].html file with documentation might be out of sync with [module].pm :(. Cheers, Pi > > M > > > On Wed, 2006-02-01 at 15:39 -0500, Frank Gibbons wrote: >> At 03:21 PM 2/1/2006, you wrote: >>> Anyway, I'm glad to know that it's not just me ;-). I'm going to >>> try to >>> configure Makefile.PL to properly handle dependencies, so that it >>> works >>> like it's supposed to. I think there's some kind of variable to >>> tell it >>> where to find the real code - we should point it at MOBY (not lib/ >>> MOBY, the >>> default) >> >> Anyone know of a good reason to explicitly copy the code from MOBY >> to lib/MOBY? >> >> ExtUtils::MakeMaker has a variable (called 'PMLIBDIRS') that >> allows you to >> tell perl where the source code lives, so there's no need to copy >> it from >> one place to another, just point it to the right place, and you're >> all set. >> It defaults to ["lib", "MOBY"], and perhaps that's why the copying >> statement was added. But really it's unnecessary (as I see it), and >> confusing. I intend to check in a new Makefile.PL that uses >> PMLIBDIRS and >> does away with the copying. >> >> Let me know if there's a good reason for NOT changing things >> (maybe it >> won't work on Mac OS 9? maybe it only works in Perl 5.6.x or >> better?). I'll >> check in within 24 hours, otherwise. >> >> The reason FOR this change is to follow the implicit rules of >> building a >> perl module (or any software using 'make'). Rebuilding should be >> accomplishable by typing "make", nothing more. >> >> -Frank >> >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: >> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 francis_gibbons at hms.harvard.edu Thu Feb 2 14:29:53 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 02 Feb 2006 09:29:53 -0500 Subject: [MOBY-dev] [moby] Here's a question.... In-Reply-To: References: <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> <1138820609.4897.27.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201124214.028c6ea0@email.med.harvard.edu> <5.2.1.1.2.20060201135356.011d72c0@email.med.harvard.edu> <5.2.1.1.2.20060201153352.028f30b0@email.med.harvard.edu> <1138826367.4897.55.camel@bioinfo.icapture.ubc.ca> Message-ID: <5.2.1.1.2.20060202092920.028bd2d0@email.med.harvard.edu> At 06:12 PM 2/1/2006, you wrote: >I second that. The way it used to work so far surprised me a bit as >well, but after I figured it out I was already glad it just >worked :). Yeah, I know. "make" and "MakeMaker" tend to have that effect on people! >If you are creating a better Makefile.PL would it be also >possible to add the pod2html documentation file building somewhere in >the process? Currently it's not, so the [module].html file with >documentation might be out of sync with [module].pm :(. Good idea, I'll see what I can do. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Thu Feb 2 17:12:23 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 2 Feb 2006 18:12:23 +0100 Subject: [MOBY-dev] [moby] Re: Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: <1138823258.4897.54.camel@bioinfo.icapture.ubc.ca> References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> <1138823258.4897.54.camel@bioinfo.icapture.ubc.ca> Message-ID: <6E1B1412-95CC-425E-B46A-F27858BC612C@wur.nl> On 1-Feb-2006, at 8:47 PM, Mark Wilkinson wrote: > On Mon, 2006-01-30 at 17:53 +0100, Pieter Neerincx wrote: > >> No I think you got it right. S::L shouldn't mess it up, but I can >> predict that fixing it by changing the prefix in BioMOBY is much >> faster than trying to get a fix into the next "stable" release of >> S::L. > > Please go ahead with this change. Ok I'll change the prefix for that namespace from soap to wsoap then. > > The other problems are a bit more frustrating, and harder to deal > with! > It isn't just a question of being S::L compatible, it's also a > question > of doing the right thing, since we have to be compatible with the > Java/Python libraries as well. If S::L is wrong, then we need to push > them to change; if *we* are wrong, then we need to recognize that and > fix the message structure. > > I need to do some more reading to figure out which is the case. Ok, please let me know what you think. As far as I understand it, the problem with that 'anyURI' thing is a S::L bug, but for the one with the double encoding I'm not sure. It doesn't really matter who encodes the string as long as not both the BioMOBY Perl modules and S::L try to do it... Pi > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From francis_gibbons at hms.harvard.edu Thu Feb 2 18:12:17 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 02 Feb 2006 13:12:17 -0500 Subject: [MOBY-dev] new Makefile.PL for Perl source Message-ID: <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> Just checked in a new Makefile.PL. You'll see what's in it from the "commit" email. I tried to write it as platform-independently as I could. I'm wary of making changes to this file, since if it's broken, you can do nothing at all with the Perl MOBY. Please inform me of problems, if any, and I'll fix them as soon as I possibly can. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Feb 2 18:09:49 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 02 Feb 2006 10:09:49 -0800 Subject: [MOBY-dev] [moby] [MOBY-guts] biomoby commit In-Reply-To: <200602021812.k12ICViR002268@pub.open-bio.org> References: <200602021812.k12ICViR002268@pub.open-bio.org> Message-ID: <1138903789.7790.61.camel@bioinfo.icapture.ubc.ca> Thanks Frank!!! I take it I can now remove the HTML documentation from the CVS tree as well? Halleluja!! M On Thu, 2006-02-02 at 13:12 -0500, Frank Gibbons wrote: > fgibbons > Thu Feb 2 13:12:31 EST 2006 > Update of /home/repository/moby/moby-live/Perl > In directory pub.open-bio.org:/tmp/cvs-serv2194 > > Modified Files: > Makefile.PL > Log Message: > - New & improved! > - Added extra rules to generate HTML from Perl modules. > * Docs now live in separate tree from source, defaulting to "docs/html" > * The doc-tree is built automatically, and echoes the source tree. > * HTML is generated from the default rule (just type 'make'). > * HTML can also be generated specifically by typing 'make html'. > * New rules incorporate dependencies between each module and its HTML. > * New HTML is generated only if the perl module has been changed. > - Your source tree lives under "MOBY". The "lib/MOBY" duplicate tree, > which was formerly required, and auto-generated by the Makefile, > is no longer used. To avoid confusion you should delete it. > > moby-live/Perl Makefile.PL,1.10,1.11 > =================================================================== > RCS file: /home/repository/moby/moby-live/Perl/Makefile.PL,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -u -r1.10 -r1.11 > --- /home/repository/moby/moby-live/Perl/Makefile.PL 2005/12/22 00:08:44 1.10 > +++ /home/repository/moby/moby-live/Perl/Makefile.PL 2006/02/02 18:12:31 1.11 > @@ -1,11 +1,15 @@ > use ExtUtils::MakeMaker; > use FindBin '$Bin'; > > -my $VERSION = '0.1'; > +my $VERSION = '0.87'; > > -system "mkdir lib" unless (-e 'lib' && -d 'lib'); # put the files into the lib directory so that they will be properly installed > -system "cp -rf MOBY lib"; > -system q{xcopy /E MOBY .\lib\MOBY\ }; > +# Anyone know why it was ever necessary to copy everything in "lib"? > +#system "mkdir lib" unless (-e 'lib' && -d 'lib'); # put the files into the lib directory so that they will be properly installed > +#my $os = $^O; > +#if ($os =~ /(linux|unix)/) { system "cp -rf MOBY lib"; } > +#elsif ($os =~ /ms.*win/i) { # windows only, usually $^O="mswin32", is this true on all Windows? > +# system q{xcopy /E MOBY .\lib\MOBY\ }; > +#} > > #my $WWW_ROOT_PATH = "/usr/local/apache" ; > #my $CGI_BIN = "cgi-bin" ; > @@ -71,21 +75,91 @@ > # See lib/ExtUtils/MakeMaker.pm for details of how to influence > # the contents of the Makefile that is written. > > +sub MY::postamble { > + use Pod::Find qw(pod_find simplify_name); > + use Cwd; > + my $cur_dir = getcwd(); > + # Find the files that contain POD, starting from the top-level build directory, and do it silently. > + my %pods = pod_find({ -verbose => 0}, > + File::Spec->catfile($cur_dir, "MOBY") ); > + my @PM = sort keys %pods; > + # Make home for all docs > + my $HTML_ROOT = File::Spec->catfile($cur_dir, qw(docs html)); > + mkdir File::Spec->catfile($cur_dir, "docs") > + unless -e File::Spec->catfile($cur_dir, "docs"); > + mkdir $HTML_ROOT unless -e $HTML_ROOT; > + # Create a new directory tree for the documentation, that mirrors the source tree. > + use File::Find; > + sub wanted { # Define nested subroutine, to inherit variable scope > + my $src_dir = $File::Find::dir; > + (my $doc_dir = $src_dir) =~ s/$cur_dir/$HTML_ROOT/; > + if (!(-e $doc_dir) && !($doc_dir =~ /CVS$/)) { > + my $made_dir = mkdir $doc_dir; > + if (!$made_dir) { print STDERR "Couldn't create directory '$doc_dir' because '$OS_ERROR'"; } > + } > + } > + find(\&wanted, File::Spec->catfile($cur_dir, "MOBY")); > + # Finally, start writing the rules. > + # Let's make a big rule to build all the docs at once, call it 'html' > + # Then other little rules to keep each PM-file's docs up to date, without having to build everything. > + my @HTML = map { # Edit beginning and end of PM files, to make HTML filenames > + my $x = $_; # Don't want to change the original... > + $x =~ s/\.p[lm]$/\.html/; > + $x =~ s/^$cur_dir/$HTML_ROOT/; > + $x} @PM; > + my $postamble = "# Rules to keep developer docs up-to-date.\n"; > + $postamble .= "POD_TO_HTML = " . join("\\\n", @HTML) > + . "\n\nhtml: \$(POD_TO_HTML)\n\n"; > + > + # Now, finally, we build rules for the makefile. > + # The TAB ('\t') characters are essential, otherwise 'make' will silently ignore the rules. > + # Don't be tempted to remove them. > + for (my $i = 0; $i < @PM; $i++) { > + $postamble .= < +$HTML[$i]:$PM[$i] > + \$(NOECHO) pod2html --outfile=$HTML[$i] $PM[$i] > + \$(NOECHO) \$(ECHO) Generating HTML for $PM[$i] > + > +RULE > + } > + return $postamble; > +} > + > +# Override built-in target, by adding the 'html' dependency > +# Now HTML gets updated every time you type "make" > +sub MY::top_targets { > + my $self = shift; > + my $string = $self->MM::top_targets; > + my $add = 'html'; > + $string =~ s/(pure_all\s+)(.*)/$1 $add $2/; > + return $string; > +} > + > +#sub MY::install { > +# my $self = shift; > +# my $string = $self->MM::install; > +# my $add = 'html'; > +# $string =~ s/(pure_install\s+)(.*)/$1 $add $2/; > +# print "INSTALL: $string\n"; > +# return $string; > +#} > + > WriteMakefile( > - 'NAME' => 'MOBY-S', > - 'VERSION' => $VERSION, > - 'PREREQ_PM' => { > - 'SOAP::Lite' => 0.55, > - 'XML::LibXML' => 1.58, > - 'Text::Shellwords' => 1.00, > - 'SOAP::MIME' => 0.55, > - 'XML::XPath' => 1.12, > - # 'LS::ID' => 1.1.1, > + NAME => 'MOBY-S', > + VERSION => $VERSION, > + PMLIBDIRS => ['MOBY'], #Get code from "MOBY", not "lib/MOBY" > + PREREQ_PM => { > + SOAP::Lite => 0.55, > + SOAP::MIME => 0.55, > + XML::LibXML => 1.58, > + XML::XPath => 1.12, > + Text::Shellwords => 1.00, > + # LS::ID => 1.1.1, > }, # e.g., Module::Name => 1.1 > - #'PM_FILTER' => "", > + #PM_FILTER => "", > ($] >= 5.005 ? ## Add these new keywords supported since 5.005 > - (ABSTRACT => 'Perl module binding for MOBY-S', > - AUTHOR => 'Mark Wilkinson [markw at illuminae.com]') : ()), > + (ABSTRACT => 'Perl binding for MOBY-S, a web-services toolkit for exchanging bioinformatic data', > + AUTHOR => 'Mark Wilkinson [markw at illuminae.com] and the BioMOBY Core Developers') : ()), > ); > > # > > _______________________________________________ > MOBY-guts mailing list > MOBY-guts at biomoby.org > http://biomoby.org/mailman/listinfo/moby-guts -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Feb 2 19:01:46 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 02 Feb 2006 11:01:46 -0800 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E0DF34.7070300@ac.uma.es> References: <43E0DF34.7070300@ac.uma.es> Message-ID: <1138906906.7790.95.camel@bioinfo.icapture.ubc.ca> Hi Johan, Thanks for providing such a clearly written proposal! I've added it to Bugzilla in order to get a tracking number (#1941), and have attached your PDF file to the enhancement request. Overall, it sounds like a great solution! I have read it a few times, and have just one or two questions/comments: 1) Page 3 - "illegitimate". I have modified the MessageStructure.html document so that it no longer says "illegitimate". Perhaps you can update that part of the document. 2) In section 3.1 you indicate that you would like the asynchronous information to be added to the data we capture in the registry; however later in that same section, you say "the proper way to do this" is through LSID resolution to metadata. Which is your preference? The former choice requires a change in the registry API, while the latter does not. I guess the choice comes down to a question of whether or not a client will ever want to search specifically for asynchronous services... if the answer to that is "yes" then it should be in the registry. What was your intention? 3) Let's define the new predicate as follows v.v. the RDF for Service Instances: mobyPred:isAsynchronous Domain: mygrid:operation Range: xsd:boolean Definition: a boolean indication of the service providers ability to provide the associated operation in asynchronous, as well as synchronous, mode, according to the specification for asynchronous Moby service calls in the Moby API. 4) I infer from your description that it should be possible to retrieve the results of some queryID's (the ones that have completed) while others are still running. Is that correct? If so, you should perhaps say so explicitly in this document. 5) You might want to create a new section of the document that describes the mobyStatus element so that it is explicitly clear that this is a new addition to the MOBY XML. 6) Section 3.3.2 final paragraph - could you add an explicit example of the proposed use of refQueryID in the mobyException block (if only because the mobyException block is quite a new addition to the API itself...) 7) Section 3.3.5 - what is the response if I request servicename_result on a queryID that has not completed? This is a great proposal!! You probably already have MOBY code that does it, since INB is already doing this (right?). Will you be committing that code for us when the RFC is adopted? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Feb 2 19:35:55 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 02 Feb 2006 11:35:55 -0800 Subject: [MOBY-dev] [moby] new Makefile.PL for Perl source In-Reply-To: <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> References: <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> Message-ID: <1138908955.7790.103.camel@bioinfo.icapture.ubc.ca> On a windows machine, using nmake, I get the following error right at the end of the make process: cp MOBY/Client/ServiceInstance.pm blib\lib\MOBY\Client \ServiceInstance.pm cp MOBY/MOBYXSLT.pm blib\lib\MOBY\MOBYXSLT.pm html @ rem 'html' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1' Stop. On Thu, 2006-02-02 at 13:12 -0500, Frank Gibbons wrote: > Just checked in a new Makefile.PL. You'll see what's in it from the > "commit" email. I tried to write it as platform-independently as I could. > I'm wary of making changes to this file, since if it's broken, you can do > nothing at all with the Perl MOBY. Please inform me of problems, if any, > and I'll fix them as soon as I possibly can. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Thu Feb 2 20:15:13 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 02 Feb 2006 15:15:13 -0500 Subject: [MOBY-dev] [moby] new Makefile.PL for Perl source In-Reply-To: <1138908955.7790.103.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> <5.2.1.1.2.20060202131031.028e19f8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060202151307.02912108@email.med.harvard.edu> Mark, can you send me the Makefile that gets generated on Windows. I added 'html' as a target, to aid in generating the HTML, but I don't understand what follows it: "@ rem". Thanks, -Frank At 02:35 PM 2/2/2006, you wrote: >On a windows machine, using nmake, I get the following error right at >the end of the make process: > >cp MOBY/Client/ServiceInstance.pm blib\lib\MOBY\Client >\ServiceInstance.pm >cp MOBY/MOBYXSLT.pm blib\lib\MOBY\MOBYXSLT.pm > html @ rem >'html' is not recognized as an internal or external command, >operable program or batch file. >NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code >'0x1' >Stop. > > > > > >On Thu, 2006-02-02 at 13:12 -0500, Frank Gibbons wrote: > > Just checked in a new Makefile.PL. You'll see what's in it from the > > "commit" email. I tried to write it as platform-independently as I could. > > I'm wary of making changes to this file, since if it's broken, you can do > > nothing at all with the Perl MOBY. Please inform me of problems, if any, > > and I'll fix them as soon as I possibly can. > > > > -Frank > > > > PhD, Computational Biologist, > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > > Tel: 617-432-3555 Fax: > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev >-- >-- >...his last words were 'Hey guys! Watch this!' >-- >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Fri Feb 3 17:41:58 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 03 Feb 2006 12:41:58 -0500 Subject: [MOBY-dev] Try to create service from serialized WSDL, get strange SOAP::Lite error Message-ID: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> Hi, It takes MOBY about half a second to retrieve WSDL from Central, to build a service. In an effort to improve performance in an application that may need to build many (maybe ten) services at a time, I'm trying to cache WSDL locally, and build services from that, as needed. I'm using Storable for serialization in Perl, which has worked well for me in the past. To paraphrase Yogi Berra: "Half a second here, half a second there, pretty soon you're talking about real time." I'm encountering a strange error in this, which appears to be emanating ultimately from SOAP::Lite (see below) In essence it says: Service description 'data:, can't be loaded: 501 Protocol scheme '' is not supported The WSDL is URI_encoded by MOBY, not by me - I just supply an XML-text description to MOBY::Client::Service->new(), pretty much exactly as provided from MCentral. I DO NOT see this problem when using the WSDL supplied by MOBY Central directly however, so there's clearly some kind of problem with serialization. I'm wondering if any of you have seen a similar behaviour in the past, and how you got around it. The WSDL I retrieve from the cache looks fine when I print it out, but I'm wondering if there might be some other funkiness to it that gets messed up with I store it. Thanks in advance. -Frank ============================== MOBY::Client::Service message below ========================= Service description 'data:,%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Cwsdl%3Adefinitions%20name% 3D%22MOBY_Central_Generated_WSDL%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%2 0%20%20%20targetNamespace%3D%22http%3A%2F%2Fbiomoby.org%2FCentral.wsdl%22%0A %20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Atns%3D%22http%3A%2F% 2Fbiomoby.org%2FCentral.wsdl%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20 %20%20xmlns%3Axsd1%3D%22http%3A%2F%2Fbiomoby.org%2FCentralXSDs.xsd%22%20%0A% 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Asoap%3D%22http%3A%2F% 2Fschemas.xmlsoap.org%2Fwsdl%2Fsoap%2F%22%0A%20%20%20%20%20%20%20%20%20%20%2 0%20%20%20%20%20xmlns%3Axsd%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2FXMLSchema% 22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3D%22http%3A%2F%2 Fschemas.xmlsoap.org%2Fwsdl%2F%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20% 20%20%20xmlns%3Awsdl%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fwsdl%2F%22%3E%0 A%0A%20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceInput%22%3E%0 A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22data%22%20type%3D% 22xsd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20%20%20%20 %20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceOutput%22%3E%0A%2 0%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22body%22%20type%3D%22x sd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20%20%20%20%20 %20%20%20%0A%20%20%3Cwsdl%3AportType%20name%3D%22ASimpleServicePortType%22%3 E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D%22ASimpleSer vice%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Ain put%20message%3D%22tns%3AASimpleServiceInput%22%2F%3E%0A%20%20%20%20%20%20%2 0%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%20message%3D%22tns%3AASimple ServiceOutput%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperatio n%3E%0A%20%20%3C%2Fwsdl%3AportType%3E%0A%20%0A%20%20%3Cwsdl%3Abinding%20name %3D%22ASimpleServiceBinding%22%20type%3D%22tns%3AASimpleServicePortType%22%3 E%0A%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abinding%20style%3D%22rpc%22%20tr ansport%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fhttp%22%2F%3E%0A%20%2 0%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D%22ASimpleService%22%3 E%3C!--%20in%20essense%2C%20this%20is%20the%20name%20of%20the%20subroutine%2 0that%20is%20called%20--%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% 20%20%3Csoap%3Aoperation%20soapAction%3D'http%3A%2F%2Fbiomoby.org%2F%23ASimp leService'%20style%3D'rpc'%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%2 0%20%20%20%3Cwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20 %20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encoded%22%20namespa ce%3D%22http%3A%2F%2Fbiomoby.org%2F%22%20encodingStyle%3D%22http%3A%2F%2Fsch emas.xmlsoap.org%2Fsoap%2Fencoding%2F%22%2F%3E%0A%20%20%20%20%20%20%20%20%20 %20%20%20%20%20%20%20%20%3C%2Fwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20% 20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20% 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encode d%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3 Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperation%3E%0A%20%2 0%3C%2Fwsdl%3Abinding%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% 0A%20%20%3Cwsdl%3Aservice%20name%3D%22ASimpleServiceService%22%3E%0A%20%20%2 0%20%20%20%20%20%20%20%3Cwsdl%3Adocumentation%3EAuthority%3A%20llama.med.har vard.edu%20%20-%20%20A%20simple%20service%20for%20testing%20purposes.%0AEnte r%20or%20edit%20the%20description%20of%20service%20ASimpleService.%0A%0A%3C% 2Fwsdl%3Adocumentation%3E%20%20%3C!--%20service%20description%20goes%20here% 20--%3E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aport%20name%3D%22ASimpleSe rvicePort%22%20binding%3D%22tns%3AASimpleServiceBinding%22%3E%0A%20%20%20%20 %20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Aaddress%20location%3D%22htt p%3A%2F%2Fllama.med.harvard.edu%2F~fgibbons%2Fcgi%2FBGN%2Fdispatcher.pl%22%2 F%3E%20%20%20%20%3C!--%20URL%20to%20service%20scriptname%20--%3E%0A%20%20%20 %20%20%20%20%20%20%20%3C%2Fwsdl%3Aport%3E%0A%20%20%3C%2Fwsdl%3Aservice%3E%0A %0A%3C%2Fwsdl%3Adefinitions%3E%0A%0A%0A' can't be loaded: 501 Protocol scheme '' is not supported PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 [1]http://llama.med.harvard.edu/~fgibbons References 1. http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Mon Feb 6 07:19:07 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 6 Feb 2006 07:19:07 +0000 (GMT) Subject: [MOBY-dev] jMoby update - creating Biomoby input dta Message-ID: Hi everybody, While finishing the last panel for Dashboard (allowing to call actually services) I created - as a side-product - a new simple graphical client that allows to create any complex Biomoby data types. The documentation (with some screenshots) is here: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/CreateInputClient.html. Any comments welcome. Also, I wonder if such component (with some additions that are not yet available but will be soon in the new Dashboard panel - such as collection and secondary parameters) can make it into Taverna as an alternative plug-in for calling Biomoby services. What do you think, Eddie? Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Feb 6 08:59:00 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 6 Feb 2006 08:59:00 +0000 (GMT) Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal In-Reply-To: <43E0DF34.7070300@ac.uma.es> Message-ID: RFC #1941 Asynchronous Service Call Proposal ============================================ I agree with Mark that it is a good proposal - we desperately need it. I just hope that more people will join this discussion (please, do so!). I suggest that we postpone the voting for about two more weeks. Mainly because some of my comments (see below) would require more details to be put in the document. And also to allow other people to jump the board (please, do so!). Before I start, let me express my main principle: we are going to change the Biomoby API because of a need for async services. But we are (sooner or later) going to add other new things to the API (especially we need to address in the future the 'iterator' pattern - sending data by chunks) - all these changes have the same common root - they require some session management. So we should add them in a way that is the least disruptive to the existing software, and in a similar way. That's one of my reasons for my 'major' comments. I have few smaller comments - but let me start with the significant ones: * Data returned by xxx_async and xxx_poll ----------------------------------------- Why does the proposal treat them differently (comparing to normal Biomoby data)? Why to introduced a new XML element 'mobyStatus' when we can easily - and keeping many software untouched - send these data in usual 'mobyData' element? The Biomoby data types (objects) have two functions: they are used to carry data and they are used in service discovery. Obviously the second function is no use here but the first function still can be used. And we do not need any new XML element (now it is 'mobyStatus', later we will need perhaps 'mobySession' or moreand more new tags). What I am suggesting is this: * To create several regular Biomoby data types (objects), such as: - PollingRequest - Event (with hierarchy and attributes taken from LSAE) (the contents would be the same as 'mobyStatus' proposed) I am prepared to be more specific how these objects should look like, and write it into a document (or even register them in Biomoby registry) - but before doing it I need some confirmation from you that it is the way to go. These objects will probably never be used in the service registration (but they can - see below). They should be treated in the similar way as the primitive data types - so in any newly created biomoby registry they should be registered by the installation script (or whatever is done for primitive types now). As a side effect, these data types *can* be used for normal services - if a service have use for them. Having these data types as regular biomoby objects also allows easier to create WSDL for all these new methods (Mark, these new methods should be generated in the WSDL by registry, for asynchronous services; more about it later.) * Dependency on LSID service metadata ------------------------------------- I do not like it (the RDF predicate indicating that a service can be asynchronous). Here is why: For me, the divider between service data and service metadata was always that metadata are good but are not crucial for a service execution. But the flag "this service can be called asynchronously" is very fundamental flag for a service, and it changes its behaviour and the behaviour of its clients. Also, it must be known to a registry - because registry is supposed to generate WSDL with xxx_async and xxx-poll method included. So register should have it, anyway! But in the same time, I agree with Mark that we should add changes to the current API prudently. But still, this request qualifies for a change of the Biomoby API (I think). But perhaps the change does not need to be big: What about to use the existing field 'category'. Because we are, in fact, talking about a new type of service category. Why not to allow a new category, for example, 'moby-async'? * Do not allow the 'mixed' mode ------------------------------- ...where some mobyData can be returned before other mobyData (from the same invocation). This would much complicate implementation - and for what? I was told that the main reason for having more mobyData in an invocation is mainly because some hardware can treat them more efficiently. I wonder if such hardware would give you back partial result, anyway. So please consider the implementation, and make it easier for us, developers. So my suggestion would be: one request == one xxx_result. * And here are my other, but smaller, comments ---------------------------------------------- a) Please whenever you talk about 'job', talk rather about 'session' because in jMoby we use the term 'job' for individual 'mobyData' - so the term would be too overloaded. b) "Id unique to each... in a message". No, the Id must be unique to the whole service provider (at least to the invoked service). If the unique-ness is just in a message there would be problems when I invoke the same service several times before the first one finished. c) How many times am I allowed to call xxx_result? I suggest just once - and any next invocation fails with an exception. This means that this call also serve as a cleaning call - the service implementation can clean the session. c) More must be written about exception states: What (if any) exception to raise when a given session handler is invalid/expired. There may be other states to document by an exception code. I think that this is enough for now. Again, I thank very much INB for the proposal, and please give us slightly more time to discuss and make changes. Then we need a new document, and few days to read it again. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Mon Feb 6 12:09:11 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 6 Feb 2006 13:09:11 +0100 Subject: [MOBY-dev] Try to create service from serialized WSDL, get strange SOAP::Lite error In-Reply-To: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> References: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> Message-ID: Hi Frank, Serialisation and SOP::Lite: ough! It wouldn't surprise me if it's some wierd S::L logic causing this error. First of all which version of S::L are you on? According to the docs, you should pass an URL to the S::L sub that parses the WSDL. Some people use an URL to a file with file:///some/path/to/file.xml, but as far as I can Google it the BioMOBY is the only piece of code that passes a string using 'data:, $wsdl'. So we are using more or less a hack and (de)serialising strings in S::L is not always transparent. It might be an encoding problem. Currently I have a problem with a service that takes the stored output from another one as input. Used to work and the XML still looks the same and valid, but for some reason libxml2 chokes on it. I suspect some encoding problem that occurs after several sessions of serialising and deserialising, but I haven't got a fix yet... Cheers, Pi On 3-Feb-2006, at 6:41 PM, Frank Gibbons wrote: > > Hi, > It takes MOBY about half a second to retrieve WSDL from Central, > to build a > service. In an effort to improve performance in an application > that may need > to build many (maybe ten) services at a time, I'm trying to > cache WSDL > locally, and build services from that, as needed. I'm using > Storable for > serialization in Perl, which has worked well for me in the > past. To > paraphrase Yogi Berra: "Half a second here, half a second there, > pretty soon > you're talking about real time." > I'm encountering a strange error in this, which appears to be > emanating > ultimately from SOAP::Lite (see below) In essence it says: > Service description 'data:, can't be loaded: > 501 Protocol > scheme '' is not supported > The WSDL is URI_encoded by MOBY, not by me - I just supply an > XML-text > description to MOBY::Client::Service->new(), pretty much exactly > as provided > from MCentral. I DO NOT see this problem when using the WSDL > supplied by > MOBY Central directly however, so there's clearly some kind of > problem with > serialization. I'm wondering if any of you have seen a similar > behaviour in > the past, and how you got around it. The WSDL I retrieve from > the cache > looks fine when I print it out, but I'm wondering if there might > be some > other funkiness to it that gets messed up with I store it. > Thanks in advance. > -Frank > ============================== MOBY::Client::Service message > below > ========================= > Service description > 'data:,%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Cwsdl% > 3Adefinitions%20name% > 3D%22MOBY_Central_Generated_WSDL%22%0A%20%20%20%20%20%20%20%20% > 20%20%20%20%2 > 0%20%20%20targetNamespace%3D%22http%3A%2F%2Fbiomoby.org% > 2FCentral.wsdl%22%0A > %20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Atns%3D% > 22http%3A%2F% > 2Fbiomoby.org%2FCentral.wsdl%22%0A%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20 > %20%20xmlns%3Axsd1%3D%22http%3A%2F%2Fbiomoby.org% > 2FCentralXSDs.xsd%22%20%0A% > 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Asoap%3D% > 22http%3A%2F% > 2Fschemas.xmlsoap.org%2Fwsdl%2Fsoap%2F%22%0A%20%20%20%20%20%20% > 20%20%20%20%2 > 0%20%20%20%20%20xmlns%3Axsd%3D%22http%3A%2F%2Fwww.w3.org%2F1999% > 2FXMLSchema% > 22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3D% > 22http%3A%2F%2 > Fschemas.xmlsoap.org%2Fwsdl%2F%22%0A%20%20%20%20%20%20%20%20%20% > 20%20%20%20% > 20%20%20xmlns%3Awsdl%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fwsdl > %2F%22%3E%0 > A%0A%20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D% > 22ASimpleServiceInput%22%3E%0 > A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22data% > 22%20type%3D% > 22xsd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20% > 20%20%20%20 > %20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceOutput > %22%3E%0A%2 > 0%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22body%22% > 20type%3D%22x > sd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20% > 20%20%20%20 > %20%20%20%0A%20%20%3Cwsdl%3AportType%20name%3D% > 22ASimpleServicePortType%22%3 > E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D% > 22ASimpleSer > vice%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% > 3Cwsdl%3Ain > put%20message%3D%22tns%3AASimpleServiceInput%22%2F%3E%0A%20%20% > 20%20%20%20%2 > 0%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%20message%3D% > 22tns%3AASimple > ServiceOutput%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl > %3Aoperatio > n%3E%0A%20%20%3C%2Fwsdl%3AportType%3E%0A%20%0A%20%20%3Cwsdl% > 3Abinding%20name > %3D%22ASimpleServiceBinding%22%20type%3D%22tns% > 3AASimpleServicePortType%22%3 > E%0A%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abinding%20style%3D% > 22rpc%22%20tr > ansport%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fhttp%22%2F > %3E%0A%20%2 > 0%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D% > 22ASimpleService%22%3 > E%3C!--%20in%20essense%2C%20this%20is%20the%20name%20of%20the% > 20subroutine%2 > 0that%20is%20called%20--%3E%0A%20%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20% > 20%20%3Csoap%3Aoperation%20soapAction%3D'http%3A%2F%2Fbiomoby.org > %2F%23ASimp > leService'%20style%3D'rpc'%2F%3E%0A%20%20%20%20%20%20%20%20%20% > 20%20%20%20%2 > 0%20%20%20%3Cwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20 > %20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encoded% > 22%20namespa > ce%3D%22http%3A%2F%2Fbiomoby.org%2F%22%20encodingStyle%3D%22http% > 3A%2F%2Fsch > emas.xmlsoap.org%2Fsoap%2Fencoding%2F%22%2F%3E%0A%20%20%20%20%20% > 20%20%20%20 > %20%20%20%20%20%20%20%20%3C%2Fwsdl%3Ainput%3E%0A%20%20%20%20%20% > 20%20%20%20% > 20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%3E%0A%20%20%20%20%20%20% > 20%20%20%20% > 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use% > 3D%22encode > d%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% > 3C%2Fwsdl%3 > Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperation > %3E%0A%20%2 > 0%3C%2Fwsdl%3Abinding%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20% > 0A%20%20%3Cwsdl%3Aservice%20name%3D%22ASimpleServiceService%22%3E > %0A%20%20%2 > 0%20%20%20%20%20%20%20%3Cwsdl%3Adocumentation%3EAuthority%3A% > 20llama.med.har > vard.edu%20%20-%20%20A%20simple%20service%20for%20testing% > 20purposes.%0AEnte > r%20or%20edit%20the%20description%20of%20service% > 20ASimpleService.%0A%0A%3C% > 2Fwsdl%3Adocumentation%3E%20%20%3C!--%20service%20description% > 20goes%20here% > 20--%3E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aport%20name%3D% > 22ASimpleSe > rvicePort%22%20binding%3D%22tns%3AASimpleServiceBinding%22%3E%0A% > 20%20%20%20 > %20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Aaddress% > 20location%3D%22htt > p%3A%2F%2Fllama.med.harvard.edu%2F~fgibbons%2Fcgi%2FBGN% > 2Fdispatcher.pl%22%2 > F%3E%20%20%20%20%3C!--%20URL%20to%20service%20scriptname%20--%3E% > 0A%20%20%20 > %20%20%20%20%20%20%20%3C%2Fwsdl%3Aport%3E%0A%20%20%3C%2Fwsdl% > 3Aservice%3E%0A > %0A%3C%2Fwsdl%3Adefinitions%3E%0A%0A%0A' can't be loaded: 501 > Protocol > scheme '' is not supported > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 [1]http://llama.med.harvard.edu/~fgibbons > > References > > 1. http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From rmb32 at cornell.edu Mon Feb 6 19:32:44 2006 From: rmb32 at cornell.edu (Robert Buels) Date: Mon, 06 Feb 2006 14:32:44 -0500 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43D92134.2060708@ac.uma.es> References: <43D92134.2060708@ac.uma.es> Message-ID: <43E7A45C.1060509@cornell.edu> Hi all, I've been lurking on this list for a while, but I haven't said anything. However, right now I'm looking at ways to implement a new BLAST service for SGN, where I work, so I'm watching this async thing developing with great interest, and I've got a few comments. About Martin's main comments: 1. I agree with Martin that it's probably not necessary to introduce a new mobyStatus tag for asynchronous services. I also think that new data types would serve just fine. 2. As for Martin's concern with the dependency on LSID service metadata, this is mitigated by the paragraph near the bottom of page 5 of Johan's proposal, which specifies that asynchronous services must also be able to be called synchronously. So clients can always just plod ahead and call the service synchronously, but if they're smart and can check the metadata, they could discover that they can call asynchronously also. I don't really understand the service categories he's talking about though, so I can't speak to that. 3. I kind of think the 'mixed' mode should be allowed. (Mark also referred to this in his comment number 4). The way I see it, implementation of the service is going to have to be keeping separate state for each job (regardless of how they're divided among invocations), so I don't think it would make implementation easier to impose that the grouping of jobs into invocations always has to remain the same. About Martin's smaller comments: a.) isn't Johan also using the term 'job' to refer to a particular block of mobyData input and the results that arise therefrom? Maybe I'm missing something, but I don't understand Martin's distinction here. b.) I agree, the wording should be changed there. Making the identifier unique to the service provider is also critical for supporting mixed mode. c.) "....can clean the session....": This seems a little dangerous. What if there's some kind of interruption of network connectivity and the client fails to get the whole result, but the server thinks the whole result was sent? That scenario could lead to total loss of the results if _result is a cleaning call. I think a better way would be to say that results are valid for X number of hours after the _async call, and have a cron job or equivalent go through cleaning them up periodically on the server. Until the job state is deleted, the client should be able to call _result as many times as it wants. d.) I agree we should more rigorously define in the RFC the exception codes to be used with async services. Now for some of my own comments: A. I think it would be a bit cleaner, rather than defining 3 separate services with patterns to their names, to define asynchronicity in terms of a single service that accepts the type of request you're making as part of its input XML. Building on Martin's idea, perhaps we could have a set of datatypes just for asynchronous services called, for example, AsyncJobID (ISA String), AsyncNewRequest, AsyncPollRequest (HASA AsyncJobID), and AsyncResultRequest (HASA AsyncJobID). Upon invocation, if no AsyncXXXRequest is present as a Primary article (inside a Simple) in the inputs, then the request is treated as synchronous. This scheme would preserve backward compatibility for calling things in a synchronous style, while also doing away with the complexity of having 4 service names (1 for synchronous, 3 for asynchronous) for what is really a single service. OK, end avalanche. I'm really glad this asynchronous discussion is happening, because I was about to implement my own hacked-together asynchronous protocol. Much better to have a real interoperable consensus. :-) What do you all think about my suggestion to choose synchronicity based on what data is in the input? Rob -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32 at cornell.edu http://www.sgn.cornell.edu From senger at ebi.ac.uk Tue Feb 7 04:18:08 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 04:18:08 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E7A45C.1060509@cornell.edu> Message-ID: Nice to have your answer. Thanks for helping this RFC! > 1. I agree with Martin that it's probably not necessary to introduce a > new mobyStatus tag for asynchronous services. I also think that new > data types would serve just fine. > That's good. Johan and Mark, would you in principle agree, so that I can suggest the datatypes I was talking about (based on LSAE) and send it here? > 2. As for Martin's concern with the dependency on LSID service metadata, > this is mitigated by the paragraph near the bottom of page 5 of Johan's > proposal, which specifies that asynchronous services must also be able > to be called synchronously. So clients can always just plod ahead and > call the service synchronously, but if they're smart and can check the > metadata > Yes, that's correct. I have been thinking in the same line. But this "go ahead and try" approach would work only for clients, not for registry when a registry needs to create a WSDL with all methods, sometimes including xxx_async, somethimes not. For that, you cannot expect that a registry will go and check LSID metadata. So I guess that using LSID metadata for that is simply not possible (unless registry caches them but then why not to keep them in a regular way as any other other registered attributes; or unless gnerated WSDL is crippled even more than it is now). > 3. I kind of think the 'mixed' mode should be allowed. > I am afraid that I have not stressed enough how important is *not* to use the mixed mode. Because if we do so, we cannot use xxx_result as a cleaning method (see more about cleaning below), we would need to have another method, such as xxx_clean. Also, why to make things complicated when they do not need to be? Simply speaking, if a client is willing to get results one by one, it can also call the service one by one (and not as a several jobs in one request). Summary why I do not support mixed mode: Just making it simple as much as possible, and not to need a special cleaning method. > a.) isn't Johan also using the term 'job' to refer to a particular block > of mobyData input and the results that arise therefrom? > No. Johan is using 'job' for one request (which can have more mobyData parts). Once you call xxx_async, the whole such request is identified by a 'job identifier'. I would call it rather 'session' and 'session identifier'. The reason I gave (that jMoby uses term 'job' for individual 'mobyData' parts) is minor. But if we accept to have normal moby data type returning from xxx_async (and others used in xxx_poll) we will re-use these data types also for other things (I mentioned iterator pattern for sending/getting data in chunks) where is much better to talk about sessions than job I think. > c.) "....can clean the session....": This seems a little dangerous. > I slightly disagree. Any good API/interface to a session management (which in our case is represented by the async API we are trying to establish) should have a way how to clean up, how to say "close the session". Of course, an implementation cannot rely that clients will always behave well and clean up - but the API should have this option (for example for cases when client want to ask for the same service thousand times in a short time). If the call to xxx_result fails, it fails, and you have nothing, and you have to start again. This is the sa,e as now with sync services. If you want to allow to get results several times, then we need to add xxx_clean method. But allowing to get results several times adds new features, beyond the simply async call. I thought that we wanted to kep it simple, so why to introduce new features when nobody asks for them explicitly? (Not that I do not see also advantages of allowing to call xxx_result more than once: you can use it - for example and if the service supports it - for getting partial result and display them to clients.... But so far nobody asked for such feature. Do we want it?) > A. I think it would be a bit cleaner, rather than defining 3 separate > services with patterns to their names, to define asynchronicity in terms > of a single service that accepts the type of request you're making as > part of its input XML. > But that's exactly what the proposal is saying. It will be oly one service, but it will have more than one method (and a 'method' in web services speak is a 'type of request'). > perhaps we could have a set of datatypes just for asynchronous > services called, for example, AsyncJobID (ISA String), > AsyncNewRequest, AsyncPollRequest (HASA AsyncJobID), and > AsyncResultRequest (HASA AsyncJobID). > These are fine, except AsyncResultRequest... > Upon invocation, if no AsyncXXXRequest is present as a Primary article > (inside a Simple) in the inputs, then the request is treated as > synchronous. > ...this would mean that a service behaviour is totally different depending on input data. Also, how would you send the real input data? To be honest, I do not understand fully what you meant here... But I think that INB suggestion that the initial input and the resulting output are exactly the same bothy for sync and async is very good and valuable, and guarantees backaward compatibility. So I do not see here any need to suggest anything else :-) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From rmb32 at cornell.edu Tue Feb 7 06:01:17 2006 From: rmb32 at cornell.edu (Robert Buels) Date: Tue, 07 Feb 2006 01:01:17 -0500 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43E837AD.1000708@cornell.edu> >use the mixed mode. Because if we do so, we cannot use xxx_result as a >cleaning method (see more about cleaning below), we would need to have >another method, such as xxx_clean. > > No. Johan is using 'job' for one request (which can have more mobyData >parts). Once you call xxx_async, the whole such request is identified by a >'job identifier'. > > It looks to me like our different interpretations here might be because of a lack of clarity in number 2 on page 8 of the RFC. It doesn't really specify whether one mobyStatus block is returned with an asyncID referring to all the submitted jobs/mobyData blocks, or whether one mobyStatus is returned for each mobyData in the input, with a separate ID for each. I assumed the latter, and I think Martin assumed the former. Whichever way it was intented, I definitely think we should get one unique asyncID per mobyData in the input. So if that's the case, then there would be no difficulties in making the xxx_result call be also the cleanup call. When a xxx_result call is issued for a job with asyncID X, you can clean up just the state related to asyncID X and leave the others alone. > If the call to xxx_result fails, it fails, and you have nothing, and >you have to start again. This is the sa,e as now with sync services. > Well, it would be kind of nice to have a little insurance. What if the job took a week of compute time? It would be nice to have a reliable way to do jobs like that. Maybe specifying a xxx_clean method is actually the way to go here, in order to have a more robust system. Or maybe one could only have to call the xxx_clean if one specified in the xxx_result input that it should NOT clean up? > But that's exactly what the proposal is saying. It will be oly one >service, but it will have more than one method (and a 'method' in web >services speak is a 'type of request'). > > > Yeah, you're right, it is just one service, but just with some kind of async flag in its spec. I was sort of thinking of simplicity on the implementation side, but on second thought implementing 4 methods versus implementing 1 method that's called 4 ways is about the same amount of labor. Nevermind. > But I think that INB suggestion that the initial input and the >resulting output are exactly the same bothy for sync and async is very >good and valuable, and guarantees backaward compatibility. So I do not see >here any need to suggest anything else :-) > > > Yep, you're right, it's good to have input and output the same for sync and async. Nevermind. :-) Rob -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32 at cornell.edu http://www.sgn.cornell.edu From senger at ebi.ac.uk Tue Feb 7 06:45:48 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 06:45:48 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E837AD.1000708@cornell.edu> Message-ID: For those who are not patient to read our long emails, these are the options for the 'mixed' mode, summarized so far (as I understand them). All these discussion is mainly relevant for cases when more 'mobyData' parts is sent in one request (but things about cleaning up are general): A) The method xxx_async would return so many 'job' IDs as the number of 'mobyData' parts. A client can use them to ask invividually for status of each 'mobyData' (using xxx_poll) and to get separately result for each 'mobyData' part (using xxx_result). If this option is agreed on, I strongly suggest to have also a 'job' ID (that I would call either 'request id' or 'sesson id') that is also returned by method xxx_async, and that can be used to ask for the status and result of all 'mobyData' parts in one go (this is because of compatibility with the current sync services). B) Or, there will not be individual IDs for each 'mobyData' part, but only a global (session, request) one. So the B option is actually the second paragraph in the A option. As I see it, we definitely needs B, but we may have also functionality described in the first paragraph of A - but that is an additional feature that I do not feel that important. Make things simple unless we need them! Finally, cleanning can be done by xxx_result (in both A and B), but Robert is right that some additional insurance for long-running jobs is welcome. It can be achieved by an additional method xxx_clean. Cheers, Martin PS. Where is Mark, Eddie, Paul, Frank, Rebecca with there comments!? M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From dgpisano at cnb.uam.es Tue Feb 7 11:05:32 2006 From: dgpisano at cnb.uam.es (David Gonzalez Pisano) Date: Tue, 07 Feb 2006 12:05:32 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E837AD.1000708@cornell.edu> References: <43E837AD.1000708@cornell.edu> Message-ID: <43E87EFC.7070400@cnb.uam.es> Robert Buels escribi?: >> use the mixed mode. Because if we do so, we cannot use xxx_result as a >> cleaning method (see more about cleaning below), we would need to have >> another method, such as xxx_clean. >> >> No. Johan is using 'job' for one request (which can have more mobyData >> parts). Once you call xxx_async, the whole such request is identified by a >> 'job identifier'. >> >> >> > It looks to me like our different interpretations here might be because > of a lack of clarity in number 2 on page 8 of the RFC. It doesn't > really specify whether one mobyStatus block is returned with an asyncID > referring to all the submitted jobs/mobyData blocks, or whether one > mobyStatus is returned for each mobyData in the input, with a separate > ID for each. I assumed the latter, and I think Martin assumed the > former. Whichever way it was intented, I definitely think we should get > one unique asyncID per mobyData in the input. > > Maybe the wording has to be change to make it clearer, but the idea is exactly like Robert interprets it: having a single and unique mobyStatus (ie, asyncID) for each one of the mobyData (ie, queryIDs) sent in the original execution request. David From Pieter.Neerincx at wur.nl Tue Feb 7 13:25:02 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 7 Feb 2006 14:25:02 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E7A45C.1060509@cornell.edu> References: <43D92134.2060708@ac.uma.es> <43E7A45C.1060509@cornell.edu> Message-ID: Hi all, On 6-Feb-2006, at 8:32 PM, Robert Buels wrote: > About Martin's main comments: > > 1. I agree with Martin that it's probably not necessary to introduce a > new mobyStatus tag for asynchronous services. I also think that new > data types would serve just fine. I agree too. But there is a catch. If we use "normal" BioMOBY objects to signal the status of a async queryID, it is more likely that people will start to invent other, new, maybe derived objects for similar things. Since anyone can register new objects, this makes the asynchronous service behaviour evolve faster, but it might also mean a less stable interface. Putting the additional info for asynchronous behaviour outside the mobyData blocks (hence in the proposed mobyStatus block) makes sure that it requires a well written RFC (many thanks for that to the INB people). Getting an RFC accepted takes much more time compared to registering a new object, but it also makes the interface more stable. > 3. I kind of think the 'mixed' mode should be allowed. (Mark also > referred to this in his comment number 4). The way I see it, > implementation of the service is going to have to be keeping separate > state for each job (regardless of how they're divided among > invocations), so I don't think it would make implementation easier to > impose that the grouping of jobs into invocations always has to remain > the same. I agree again. > > About Martin's smaller comments: > a.) isn't Johan also using the term 'job' to refer to a particular > block > of mobyData input and the results that arise therefrom? Maybe I'm > missing something, but I don't understand Martin's distinction here. > b.) I agree, the wording should be changed there. Making the > identifier > unique to the service provider is also critical for supporting > mixed mode. Agree for both a and b. > c.) "....can clean the session....": This seems a little dangerous. > What if there's some kind of interruption of network connectivity and > the client fails to get the whole result, but the server thinks the > whole result was sent? That scenario could lead to total loss of the > results if _result is a cleaning call. I think a better way would > be to > say that results are valid for X number of hours after the _async > call, > and have a cron job or equivalent go through cleaning them up > periodically on the server. Until the job state is deleted, the > client > should be able to call _result as many times as it wants. I agree with Rob here. I think it is much better to have an additional xxx_clean or something similar. If a client wants to make sure his data is no longer on the server they can always call xxx_result and immediately after that a xxx_clean. It's just one additional line of code client-side. Server-side it is also not that much work to implement. Just move the cleaning code to an additional sub that translates into an additional SOAP method > d.) I agree we should more rigorously define in the RFC the exception > codes to be used with async services. I agree. > Now for some of my own comments: > > A. I think it would be a bit cleaner, rather than defining 3 separate > services with patterns to their names, to define asynchronicity in > terms > of a single service that accepts the type of request you're making as > part of its input XML. Building on Martin's idea, perhaps we could > have > a set of datatypes just for asynchronous services called, for example, > AsyncJobID (ISA String), AsyncNewRequest, AsyncPollRequest (HASA > AsyncJobID), and AsyncResultRequest (HASA AsyncJobID). Upon > invocation, > if no AsyncXXXRequest is present as a Primary article (inside a > Simple) > in the inputs, then the request is treated as synchronous. This > scheme > would preserve backward compatibility for calling things in a > synchronous style, while also doing away with the complexity of > having 4 > service names (1 for synchronous, 3 for asynchronous) for what is > really > a single service. Currently the object ontology lists only what goes into a service and what comes out of it. Details about where the service resides and how to access it currently go into the service ontology. Therefore it makes more sense to me to put the info about (a)synchronous behaviour in the service ontology. > > OK, end avalanche. I'm really glad this asynchronous discussion is > happening, because I was about to implement my own hacked-together > asynchronous protocol. Much better to have a real interoperable > consensus. :-) I second that! Pi > What do you all think about my suggestion to choose synchronicity > based > on what data is in the input? > > Rob > > -- > Robert Buels > SGN Bioinformatics Analyst > 252A Emerson Hall, Cornell University > Ithaca, NY 14853 > Tel: 607-255-2360 > rmb32 at cornell.edu > http://www.sgn.cornell.edu > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Tue Feb 7 13:27:33 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 7 Feb 2006 14:27:33 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E87EFC.7070400@cnb.uam.es> References: <43E837AD.1000708@cornell.edu> <43E87EFC.7070400@cnb.uam.es> Message-ID: <609EC6A1-82E9-49C2-88EF-DE82607620D1@wur.nl> On 7-Feb-2006, at 12:05 PM, David Gonzalez Pisano wrote: > Robert Buels escribi?: >>> use the mixed mode. Because if we do so, we cannot use xxx_result >>> as a >>> cleaning method (see more about cleaning below), we would need to >>> have >>> another method, such as xxx_clean. >>> >>> No. Johan is using 'job' for one request (which can have more >>> mobyData >>> parts). Once you call xxx_async, the whole such request is >>> identified by a >>> 'job identifier'. >>> >>> >>> >> It looks to me like our different interpretations here might be >> because >> of a lack of clarity in number 2 on page 8 of the RFC. It doesn't >> really specify whether one mobyStatus block is returned with an >> asyncID >> referring to all the submitted jobs/mobyData blocks, or whether one >> mobyStatus is returned for each mobyData in the input, with a >> separate >> ID for each. I assumed the latter, and I think Martin assumed the >> former. Whichever way it was intented, I definitely think we >> should get >> one unique asyncID per mobyData in the input. >> >> > Maybe the wording has to be change to make it clearer, but the idea is > exactly like Robert interprets it: having a single and unique > mobyStatus > (ie, asyncID) for each one of the mobyData (ie, queryIDs) sent in the > original execution request. Well in that case, the queryID and asyncID are redundant aren't they? They are both just unique pointers to identify a certain mobyData block. It would be good though to have an additional ID / ticket to represent a session (that might be based on user's credentials etc.). I think we definitely need one mobyStatus per mobyData block. So I disagree with Martin there. If Martin wants to keep things simple he can always summarise all the mobyStatus elements for one session and tell a user whether the whole batch has finished or not. Pi > > David > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Tue Feb 7 13:44:12 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 13:44:12 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <609EC6A1-82E9-49C2-88EF-DE82607620D1@wur.nl> Message-ID: > Well in that case, the queryID and asyncID are redundant aren't they? > They are both just unique pointers to identify a certain mobyData > block. > They are not the same, at all: First, queryID is defined by a client, not a service provider - and two clients cannot guarantee that they assign different IDs. Second, asyncID must be unique even for more requests (of the same service, at least), but queryID does not need to be. For example, as a client I can send two requests, both with the same queryID, but I expect that the service provider distinguis them when I am polling for their status. > It would be good though to have an additional ID / ticket to > represent a session (that might be based on user's credentials etc.). > Agree. That's what I suggested. > I think we definitely need one mobyStatus per mobyData block. So I > disagree with Martin there. If Martin wants to keep things simple he > can always summarise all the mobyStatus elements for one session and > tell a user whether the whole batch has finished or not. > I already said that I do not mind to have states of individual mobyData blocks (named jobs, as we all in the meantime agreed). Fine with me. But I keep telling that I *mind* to use mobyStatus tag (but that beongs somewhere else). Good to have you on the discussion, Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 7 13:51:54 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 13:51:54 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: Message-ID: > > 1. I agree with Martin that it's probably not necessary to introduce a > > new mobyStatus tag for asynchronous services. I also think that new > > data types would serve just fine. > > I agree too. > Welcome on the board :-) > But there is a catch. If we use "normal" BioMOBY objects > to signal the status of a async queryID, it is more likely that > people will start to invent other, new, maybe derived objects for > similar things. > Not sure why this is a catch. This is an advantage: I can return much more detailed status if I want, and if I use a more specialized event object. But regarding the new API (if approved), all such event objects must inherit from the one defined in the API. As usual... > > 3. I kind of think the 'mixed' mode should be allowed. (Mark also > I agree again. > I think that the existence of a mixed mode is already agreed on (at least by those who expressed their views). Johan, you as the prime author should start to summarize what is agreed on and what needs to be discussed further. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 7 14:18:53 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Feb 2006 14:18:53 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E8A936.9040204@ebi.ac.uk> Message-ID: > Isn't there a risk that you're getting properties of the service > mechanism confused with those of the underlying service function? > I do not see it as a risk. > When you describe a service as 'asynchronous' you really mean that a > service invocation has persistent state on the server to which the > client must reconnect, making more than one call at the low level to > invoke the high level service, right? > Yes. > Every time a 'magic' moby object type is used the client tooling becomes > more complicated. > Precisely, that's why I do not want mobyStatus tag - that is a magic tag. If I use a normal moby object, I do not need to change anything in the client tooling as long as my client do not want to call a service asynchonosly. In that moment, the client obviously becomes more complicated. But if we use for status normal objects, the complication is smaller. > Just my two cents, I'd suggest a look at frameworks such as WSRF which > handle state explicitly (WSRF being derived from the state model in > Globus 2, loosely, but applied to web services), and at the least I'd > like to see a document explaining why these relatively standard > technologies aren't being applied here. > This is a very valid point (you see that I sometimes even agree with Tom?). I was myself trying to find how axis2 can help us with the asynchonicity without changing bimoby api (or changing it not much), and so far I failed to get it. Probably similar it is with other technologies. We do not have time to study in details such big products/specs as WSRF is, unless we have to. But we are usually open if somebody tells us: this and this you can use and it will solve your problem better. So far, we do not have such person for WSRF... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From tmo at ebi.ac.uk Tue Feb 7 14:05:42 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Tue, 07 Feb 2006 14:05:42 +0000 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43E8A936.9040204@ebi.ac.uk> Martin Senger wrote: >>> 1. I agree with Martin that it's probably not necessary to introduce a >>> new mobyStatus tag for asynchronous services. I also think that new >>> data types would serve just fine. >> I agree too. >> > Welcome on the board :-) > >> But there is a catch. If we use "normal" BioMOBY objects >> to signal the status of a async queryID, it is more likely that >> people will start to invent other, new, maybe derived objects for >> similar things. >> > Not sure why this is a catch. This is an advantage: I can return much > more detailed status if I want, and if I use a more specialized event > object. But regarding the new API (if approved), all such event objects > must inherit from the one defined in the API. As usual... This sounds messy to me - I know I haven't been involved up to now and to be honest don't have time to now (I'm only sending this because I'm on holiday!). Isn't there a risk that you're getting properties of the service mechanism confused with those of the underlying service function? When you describe a service as 'asynchronous' you really mean that a service invocation has persistent state on the server to which the client must reconnect, making more than one call at the low level to invoke the high level service, right? Every time a 'magic' moby object type is used the client tooling becomes more complicated. Any invocation framework is going to have to have special catch clauses to handle this magic type, even if the client is otherwise entirely agnostic to the data returned from the service. This is a bad thing. I don't think this message belongs in the standard moby object space, it is a property of the service invocation semantics in the same way as the inherent moby wrapper is at one level and that the low level SOAP wrapper is at another, I would avoid mingling it with the data layer. Just my two cents, I'd suggest a look at frameworks such as WSRF which handle state explicitly (WSRF being derived from the state model in Globus 2, loosely, but applied to web services), and at the least I'd like to see a document explaining why these relatively standard technologies aren't being applied here. If I were a reviewer on one of Mark's grants (hypothetically, they asked me but I had to reject on conflict of interest grounds) I'd want to see this comparison. Cheers, Tom From Pieter.Neerincx at wur.nl Tue Feb 7 16:46:42 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 7 Feb 2006 17:46:42 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E87EFC.7070400@cnb.uam.es> References: <43E837AD.1000708@cornell.edu> <43E87EFC.7070400@cnb.uam.es> Message-ID: <2A9C678A-F1E4-40A1-8A09-E2627ACBF327@wur.nl> Hi all, Ok, this is just a minor comment. It's about the names for the different SOAP methods. Currently proposed: [servicename]_async [servicename]_poll [servicename]_result It looks to me like they are a bit random. Off course they could be just _a, _b and _c as well. For the way it will work it won't matter, but since we will have these names for quite some time, I would suggest something more logical. Async is the the service type, you poll (=verb) for the status (=noun) and you retrieve (=verb) the result (=noun). To me it makes more sense if the methods are named after a verb that describes the action that the SOAP method performs. So that would mean something like this: [servicename]_submit [servicename]_poll [servicename]_retrieve and maybe also: [servicename]_clean or [servicename]_remove Just my 2c, Pi From edward.kawas at gmail.com Tue Feb 7 17:25:25 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 7 Feb 2006 09:25:25 -0800 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <2A9C678A-F1E4-40A1-8A09-E2627ACBF327@wur.nl> Message-ID: <000001c62c0b$7c42c1d0$7766a8c0@notebook> I haven't said much ... I like the idea of having verbs that describe actions. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Pieter Neerincx > Sent: Tuesday, February 07, 2006 8:47 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal > > Hi all, > > Ok, this is just a minor comment. It's about the names for > the different SOAP methods. Currently proposed: > > [servicename]_async > [servicename]_poll > [servicename]_result > > It looks to me like they are a bit random. Off course they > could be just _a, _b and _c as well. For the way it will work > it won't matter, but since we will have these names for quite > some time, I would suggest something more logical. > Async is the the service type, you poll (=verb) for the status > (=noun) and you retrieve (=verb) the result (=noun). To me it > makes more sense if the methods are named after a verb that > describes the action that the SOAP method performs. So that > would mean something like this: > > [servicename]_submit > [servicename]_poll > [servicename]_retrieve > and maybe also: > [servicename]_clean or [servicename]_remove > > Just my 2c, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Feb 7 19:43:21 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 07 Feb 2006 11:43:21 -0800 Subject: [MOBY-dev] [moby] Try to create service from serialized WSDL, get strange SOAP::Lite error In-Reply-To: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> References: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> Message-ID: <1139341401.25375.16.camel@bioinfo.icapture.ubc.ca> Hi Frank, I've read over your bug report below a few times and I can't quite extract from it what the bug actually is... Can you paraphrase? thanks, M On Fri, 2006-02-03 at 12:41 -0500, Frank Gibbons wrote: > Hi, > It takes MOBY about half a second to retrieve WSDL from Central, to build a > service. In an effort to improve performance in an application that may need > to build many (maybe ten) services at a time, I'm trying to cache WSDL > locally, and build services from that, as needed. I'm using Storable for > serialization in Perl, which has worked well for me in the past. To > paraphrase Yogi Berra: "Half a second here, half a second there, pretty soon > you're talking about real time." > I'm encountering a strange error in this, which appears to be emanating > ultimately from SOAP::Lite (see below) In essence it says: > Service description 'data:, can't be loaded: 501 Protocol > scheme '' is not supported > The WSDL is URI_encoded by MOBY, not by me - I just supply an XML-text > description to MOBY::Client::Service->new(), pretty much exactly as provided > from MCentral. I DO NOT see this problem when using the WSDL supplied by > MOBY Central directly however, so there's clearly some kind of problem with > serialization. I'm wondering if any of you have seen a similar behaviour in > the past, and how you got around it. The WSDL I retrieve from the cache > looks fine when I print it out, but I'm wondering if there might be some > other funkiness to it that gets messed up with I store it. > Thanks in advance. > -Frank > ============================== MOBY::Client::Service message below > ========================= > Service description > 'data:,%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Cwsdl%3Adefinitions%20name% > 3D%22MOBY_Central_Generated_WSDL%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%2 > 0%20%20%20targetNamespace%3D%22http%3A%2F%2Fbiomoby.org%2FCentral.wsdl%22%0A > %20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Atns%3D%22http%3A%2F% > 2Fbiomoby.org%2FCentral.wsdl%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20 > %20%20xmlns%3Axsd1%3D%22http%3A%2F%2Fbiomoby.org%2FCentralXSDs.xsd%22%20%0A% > 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3Asoap%3D%22http%3A%2F% > 2Fschemas.xmlsoap.org%2Fwsdl%2Fsoap%2F%22%0A%20%20%20%20%20%20%20%20%20%20%2 > 0%20%20%20%20%20xmlns%3Axsd%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2FXMLSchema% > 22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20xmlns%3D%22http%3A%2F%2 > Fschemas.xmlsoap.org%2Fwsdl%2F%22%0A%20%20%20%20%20%20%20%20%20%20%20%20%20% > 20%20%20xmlns%3Awsdl%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fwsdl%2F%22%3E%0 > A%0A%20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceInput%22%3E%0 > A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22data%22%20type%3D% > 22xsd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20%20%20%20 > %20%20%0A%20%20%3Cwsdl%3Amessage%20name%3D%22ASimpleServiceOutput%22%3E%0A%2 > 0%20%20%20%20%20%20%20%20%20%3Cwsdl%3Apart%20name%3D%22body%22%20type%3D%22x > sd%3Astring%22%2F%3E%0A%20%20%3C%2Fwsdl%3Amessage%3E%0A%20%20%20%20%20%20%20 > %20%20%20%0A%20%20%3Cwsdl%3AportType%20name%3D%22ASimpleServicePortType%22%3 > E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D%22ASimpleSer > vice%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Ain > put%20message%3D%22tns%3AASimpleServiceInput%22%2F%3E%0A%20%20%20%20%20%20%2 > 0%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%20message%3D%22tns%3AASimple > ServiceOutput%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperatio > n%3E%0A%20%20%3C%2Fwsdl%3AportType%3E%0A%20%0A%20%20%3Cwsdl%3Abinding%20name > %3D%22ASimpleServiceBinding%22%20type%3D%22tns%3AASimpleServicePortType%22%3 > E%0A%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abinding%20style%3D%22rpc%22%20tr > ansport%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fhttp%22%2F%3E%0A%20%2 > 0%20%20%20%20%20%20%20%20%3Cwsdl%3Aoperation%20name%3D%22ASimpleService%22%3 > E%3C!--%20in%20essense%2C%20this%20is%20the%20name%20of%20the%20subroutine%2 > 0that%20is%20called%20--%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% > 20%20%3Csoap%3Aoperation%20soapAction%3D'http%3A%2F%2Fbiomoby.org%2F%23ASimp > leService'%20style%3D'rpc'%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%2 > 0%20%20%20%3Cwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20 > %20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encoded%22%20namespa > ce%3D%22http%3A%2F%2Fbiomoby.org%2F%22%20encodingStyle%3D%22http%3A%2F%2Fsch > emas.xmlsoap.org%2Fsoap%2Fencoding%2F%22%2F%3E%0A%20%20%20%20%20%20%20%20%20 > %20%20%20%20%20%20%20%20%3C%2Fwsdl%3Ainput%3E%0A%20%20%20%20%20%20%20%20%20% > 20%20%20%20%20%20%20%20%3Cwsdl%3Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20% > 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Abody%20use%3D%22encode > d%22%2F%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3 > Aoutput%3E%0A%20%20%20%20%20%20%20%20%20%20%3C%2Fwsdl%3Aoperation%3E%0A%20%2 > 0%3C%2Fwsdl%3Abinding%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20% > 0A%20%20%3Cwsdl%3Aservice%20name%3D%22ASimpleServiceService%22%3E%0A%20%20%2 > 0%20%20%20%20%20%20%20%3Cwsdl%3Adocumentation%3EAuthority%3A%20llama.med.har > vard.edu%20%20-%20%20A%20simple%20service%20for%20testing%20purposes.%0AEnte > r%20or%20edit%20the%20description%20of%20service%20ASimpleService.%0A%0A%3C% > 2Fwsdl%3Adocumentation%3E%20%20%3C!--%20service%20description%20goes%20here% > 20--%3E%0A%20%20%20%20%20%20%20%20%20%20%3Cwsdl%3Aport%20name%3D%22ASimpleSe > rvicePort%22%20binding%3D%22tns%3AASimpleServiceBinding%22%3E%0A%20%20%20%20 > %20%20%20%20%20%20%20%20%20%20%20%20%20%3Csoap%3Aaddress%20location%3D%22htt > p%3A%2F%2Fllama.med.harvard.edu%2F~fgibbons%2Fcgi%2FBGN%2Fdispatcher.pl%22%2 > F%3E%20%20%20%20%3C!--%20URL%20to%20service%20scriptname%20--%3E%0A%20%20%20 > %20%20%20%20%20%20%20%3C%2Fwsdl%3Aport%3E%0A%20%20%3C%2Fwsdl%3Aservice%3E%0A > %0A%3C%2Fwsdl%3Adefinitions%3E%0A%0A%0A' can't be loaded: 501 Protocol > scheme '' is not supported > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 [1]http://llama.med.harvard.edu/~fgibbons > > References > > 1. http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Tue Feb 7 21:02:27 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 07 Feb 2006 16:02:27 -0500 Subject: [MOBY-dev] [moby] Try to create service from serialized WSDL, get strange SOAP::Lite error In-Reply-To: <1139341401.25375.16.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> <5.2.1.1.2.20060203122251.0288c028@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060207145434.023890c0@email.med.harvard.edu> Hi Mark, At 02:43 PM 2/7/2006, you wrote: >Hi Frank, > >I've read over your bug report below a few times and I can't quite >extract from it what the bug actually is... Can you paraphrase? Yeah, I don't really blame you - I've had a really hard time figuring out where the bug is myself! I've been working on this the past few days, and am happy to announce that I now have a deeper understanding of my confusion, though still no solution. [This posting turned out to be quite long.] First of all, it turns out that the specific problem I see below occurs only when I run my code under the Perl debugger, through emacs. So that may be a complete red herring, perhaps symptomatic of something else. I'm using Perl 5.8.6 from the SuSE distribution on dual-CPU i686-architecture hardware, but compiled for i586 architecture (sysadmin thought that shouldn't be a problem), with thread-support enabled (ditto). However, the problematic behaviour still exists. My code seg-faults 100% of the time. I can nail down the specifics a bit more precisely now. My goal is simple: cache WSDL locally, to avoid hitting MOBY Central too often, and to improve local performance in querying services: "discover once, use often" you might say. I can't keep service objects around, since I'm interested in using this in a web application, so services have to be constructed frequently. But they only need to be discovered sporadically (once an hour, once a day?). Simple enough. I have tried serializing with Storable and Data::Dumper, and find the same fundamental problem with both, which leads me to believe that the problem doesn't lie with serialization as a concept, or as an implementation. This is a relief, since all I want to serialize is the WSDL for each service, which is a string. If I can't serialize a string, I'm in deeper trouble than I thought! ;-D Using the serialized WSDL, I can thaw out ('deserialize'), successfully construct, and even execute services, so there is no inherent problem with the WSDL upon thawing. The MOBY::Client::Service objects returned are normal in every way. My problem comes when I try to return from the subroutine that does all this serializing, thawing, and reconstruction. The program crashes _always _and _only_ upon the return statement, and only when a MOBY::Client::Service has been created. If I simply serialize and thaw the WSDL, I get no problems upon returning. Under certain circumstances, the seg fault is accompanied by a message that "REFCNT decremented below 0!". Looks like a garbage-collection problem, where the GC tries to free something that's already been freed! A further clue is provided by Pieter Neerincx (private communication), who mentioned that he had a very similar problem which he traced back to XML::LibXML. The page http://cpan.uwinnipeg.ca/htdocs/XML-LibXML/Changes.html lists several recent bug fixes for threads from version 1.5.1 onwards (I'm using the latest, 1.5.8), including the specific one that Pieter encountered (the one using documentFragment()), which was supposedly fixed for 1.5.8. In fairness, I don't think the problem lies with MOBY itself, since it mostly just uses XML::LibXML in a fairly generic way (calls parse() a lot, but that's about it). However, the bug is serious enough to prevent caching of MOBY services, and presumably other potential uses which attempt to hide MOBY's interface in modules. So it affects MOBY in that sense, albeit indirectly. Briefly: use serialized WSDL, AND create MOBY::Client::Service, AND then return from subroutine ==> seg fault (always) use "fresh" WSDL, rest unchanged (can't cache services) ==> no seg fault don't return from subroutine, rest unchanged (can't encapsulate in other module) ==> no seg fault omit MOBY::Client::Service creation, rest unchanged (can't do anything useful at all) ==> no seg fault otherwise ==> no seg fault (ever) If you'd like to play around with it, go here: http://llama.med.harvard.edu/~fgibbons/tmp/api_moby.pl to get the self-contained stub I'm using to investigate this. Use the $config hashref to turn on caching (CACHE_SERVICE_INFO => 1), and watch it fault. (You'll have to run it twice: once to build the cache, then again to use it). Then turn off caching, and watch it return normally. I have NO IDEA where to go from here. I'd really rather not ask my sysadmin to build and reinstall Perl _without_ threads unless I'm positive that will cure my problems. If anyone has ANY ideas on where to go from here, I would be really, truly grateful. TIA, -Frank >On Fri, 2006-02-03 at 12:41 -0500, Frank Gibbons wrote: > > Hi, > > It takes MOBY about half a second to retrieve WSDL from Central, to > build a > > service. In an effort to improve performance in an application that > may need > > to build many (maybe ten) services at a time, I'm trying to cache WSDL > > locally, and build services from that, as needed. I'm using Storable for > > serialization in Perl, which has worked well for me in the past. To > > paraphrase Yogi Berra: "Half a second here, half a second there, > pretty soon > > you're talking about real time." > > I'm encountering a strange error in this, which appears to be emanating > > ultimately from SOAP::Lite (see below) In essence it says: > > Service description 'data:, can't be loaded: 501 > Protocol > > scheme '' is not supported > > The WSDL is URI_encoded by MOBY, not by me - I just supply an XML-text > > description to MOBY::Client::Service->new(), pretty much exactly as > provided > > from MCentral. I DO NOT see this problem when using the WSDL supplied by > > MOBY Central directly however, so there's clearly some kind of > problem with > > serialization. I'm wondering if any of you have seen a similar > behaviour in > > the past, and how you got around it. The WSDL I retrieve from the cache > > looks fine when I print it out, but I'm wondering if there might be some > > other funkiness to it that gets messed up with I store it. > > Thanks in advance. > > -Frank > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev >-- PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From rmb32 at cornell.edu Tue Feb 7 21:00:30 2006 From: rmb32 at cornell.edu (Robert Buels) Date: Tue, 07 Feb 2006 16:00:30 -0500 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <2A9C678A-F1E4-40A1-8A09-E2627ACBF327@wur.nl> References: <43E837AD.1000708@cornell.edu> <43E87EFC.7070400@cnb.uam.es> <2A9C678A-F1E4-40A1-8A09-E2627ACBF327@wur.nl> Message-ID: <43E90A6E.70009@cornell.edu> >[servicename]_submit >[servicename]_poll >[servicename]_retrieve >and maybe also: >[servicename]_clean or [servicename]_remove > > Those are nice names, I like them. Anybody else? Rob -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32 at cornell.edu http://www.sgn.cornell.edu From francis_gibbons at hms.harvard.edu Tue Feb 7 22:40:42 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 07 Feb 2006 17:40:42 -0500 Subject: [MOBY-dev] addendum to service creation from serialized WSDL Message-ID: <5.2.1.1.2.20060207173502.01215db0@email.med.harvard.edu> I've learned one or two more things: 1. The whole "return from a subroutine" is a red herring. Even if you create the services in main(), not in a subroutine, you still 'seg fault' at the end. 2. Serialization is too high-brow a term - even if you just save the WSDL in a file, using plain old "open my $WSDL, $wdfl_file; print $WSDL $my_wsdl" and read it back in later, the effect is the same. So it's really and truly got _nothing_ to do with serialization. 3. I've tried altering MOBY::Client::Service to use the other syntax for SOAP::Lite->service(), in which rather than a URI, you give it the name of a file on the local filesystem. Nothing changes. I haven't come across anything like what MOBY _actually_ uses, passing in the WSDL as a string - I guess we should just be thankful that it works. I hate to bring this up, but are there other alternatives to XML::LibXML....? I know we went to it for its support of namespaces, but that was a year ago, and perhaps there's something else that provides that support now, without the threading problems? I'm not advocating it, just wondering out loud. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Feb 7 23:35:23 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 07 Feb 2006 15:35:23 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E8A936.9040204@ebi.ac.uk> References: <43E8A936.9040204@ebi.ac.uk> Message-ID: <1139355323.1479.25.camel@bioinfo.icapture.ubc.ca> I just had a look at the WSRF proposal - it's a very young "standard" (or as Tom puts it, a very young "relatively standard technology"), but it's interesting and looks like it does a lot of what we need. It's surprisingly lightweight. It uses the SOAP Header to pass the state information, and thus would not require any changes to the MOBY Messaging structure (which is nice!). What is going to be slightly tricky for us, however, is that the Schema for the service-specific state information is contained in the WSDL file, and that file is created by MOBY Central. We would either have to extend MOBY Central to capture this information at registration, or we would have to agree on a standard set of XML tags that all stateful MOBY services would agree to use that we could then add into the default WSDL document template. I suspect that the latter would be the way we want to go, since we are already talking about creating standard objects. WSRF also has explicit support for things like "clean" that we have been talking about in this thread to destroy the server-side resources. It also has some standardized fault codes that are (apparently?) extensible such that we could report things like progress or Estimated-time-to-completion. I agree with Tom - much of what we are discussing here is dealt with by the WSRF spec. (thanks for the heads-up Tom!). I wonder if the authors of RFC1941 could browse the WSRF spec and see if they agree that it is useful, and if so, revise the proposal accordingly? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Wed Feb 8 00:36:24 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 8 Feb 2006 00:36:24 +0000 (GMT) Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <43E90A6E.70009@cornell.edu> Message-ID: > >[servicename]_submit > >[servicename]_poll > >[servicename]_retrieve > >and maybe also: > >[servicename]_clean or [servicename]_remove > Those are nice names, I like them. Anybody else? > I don't care (but 'submit' is confusing because even just a sync invocation is a submit...) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From gordonp at ucalgary.ca Wed Feb 8 18:31:42 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 08 Feb 2006 11:31:42 -0700 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43EA390E.6090305@ucalgary.ca> I am pretty much in agreement with all of Martin's points, especially using the existing mobyData tag and formulating job-ticket-like objects. As a client interface builder, this is MUCH more convenient for me... >>Well in that case, the queryID and asyncID are redundant aren't they? >>They are both just unique pointers to identify a certain mobyData >>block. >> >> >> > They are not the same, at all: First, queryID is defined by a client, >not a service provider - and two clients cannot guarantee that they assign >different IDs. Second, asyncID must be unique even for more requests (of >the same service, at least), but queryID does not need to be. For example, >as a client I can send two requests, both with the same queryID, but I >expect that the service provider distinguis them when I am polling for >their status. > > > >>It would be good though to have an additional ID / ticket to >>represent a session (that might be based on user's credentials etc.). >> >> >> > Agree. That's what I suggested. > > > >>I think we definitely need one mobyStatus per mobyData block. So I >>disagree with Martin there. If Martin wants to keep things simple he >>can always summarise all the mobyStatus elements for one session and >>tell a user whether the whole batch has finished or not. >> >> >> > I already said that I do not mind to have states of individual mobyData >blocks (named jobs, as we all in the meantime agreed). Fine with me. But I >keep telling that I *mind* to use mobyStatus tag (but that beongs >somewhere else). > > Good to have you on the discussion, > Cheers, > Martin > > > From francis_gibbons at hms.harvard.edu Wed Feb 8 19:35:57 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 08 Feb 2006 14:35:57 -0500 Subject: [MOBY-dev] MOBY Central OK? Message-ID: <5.2.1.1.2.20060208143403.02362410@email.med.harvard.edu> Just wondering: is MOBY Central OK. I'm still working out my own issues (aren't we all, you say ;-), but now find I'm unable to connect to MOBY Central: I get the dreaded "ERROR ERROR ERROR". I'm wondering if it's just me, or whether others are also encountering this problem. It's been (apparently) down for a few hours now. Thanks -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From edward.kawas at gmail.com Wed Feb 8 19:32:38 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 8 Feb 2006 11:32:38 -0800 Subject: [MOBY-dev] MOBY Central OK? In-Reply-To: <5.2.1.1.2.20060208143403.02362410@email.med.harvard.edu> Message-ID: <002801c62ce6$6c79f530$6700a8c0@notebook> I have been using it all morning, so it should be up. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Frank Gibbons > Sent: Wednesday, February 08, 2006 11:36 AM > To: MOBY-dev at biomoby.org > Subject: [MOBY-dev] MOBY Central OK? > > Just wondering: is MOBY Central OK. I'm still working out my > own issues (aren't we all, you say ;-), but now find I'm > unable to connect to MOBY > Central: I get the dreaded "ERROR ERROR ERROR". I'm wondering > if it's just me, or whether others are also encountering this > problem. It's been > (apparently) down for a few hours now. > > Thanks > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston > MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Wed Feb 8 20:17:33 2006 From: markw at illuminae.com (mark wilkinson) Date: Wed, 8 Feb 2006 20:17:33 +0000 GMT Subject: [MOBY-dev] MOBY Central OK? Message-ID: <655160667-1139429953-cardhu_blackberry.rim.net-28443-@engine08-cell01> The dreaded Error cubed, eh? I dunno... I have also been using it this morning, and haven't touched anything today except the gbrowse rendering modules, so...?? Can you ping or traceroute to the machine? M -----Original Message----- From: Frank Gibbons Date: Wed, 08 Feb 2006 14:35:57 To:MOBY-dev at biomoby.org Subject: [MOBY-dev] MOBY Central OK? Just wondering: is MOBY Central OK. I'm still working out my own issues (aren't we all, you say ;-), but now find I'm unable to connect to MOBY Central: I get the dreaded "ERROR ERROR ERROR". I'm wondering if it's just me, or whether others are also encountering this problem. It's been (apparently) down for a few hours now. Thanks -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From francis_gibbons at hms.harvard.edu Wed Feb 8 21:49:59 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 08 Feb 2006 16:49:59 -0500 Subject: [MOBY-dev] MOBY Central OK? In-Reply-To: <655160667-1139429953-cardhu_blackberry.rim.net-28443-@engi ne08-cell01> Message-ID: <5.2.1.1.2.20060208160929.02368428@email.med.harvard.edu> At 03:17 PM 2/8/2006, you wrote: >The dreaded Error cubed, eh? > >I dunno... I have also been using it this morning, and haven't touched >anything today except the gbrowse rendering modules, so...?? > >Can you ping or traceroute to the machine? Actually, I've now diagnosed that it's _not_ a connectivity problem: for example, MOBY::Client::Central->findServices() works fine. But when I try to retrieve an individual service, I end up with: Empty String at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2457 ERROR ERROR ERROR At first, I thought this was truly bizarre for a number of reasons, not least of which is the fact that there is NO Perl 5.8.5 installed on my machine, and even the perl executable I'm using (which is 5.8.6) is running from my home directory, and therefore should have nothing at all to do with /usr/lib. ....but then I realized that it's coming from the remote MOBY::Central, not from my local MOBY::Client::Central. When I go to that line in MOBY::Central.pm, I notice that it's in _retrieveService(), and the die() propagates up from XML::LibXML being passed in an empty $payload. At least I think that's what's going on. What do you think? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Wed Feb 8 21:55:25 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 08 Feb 2006 13:55:25 -0800 Subject: [MOBY-dev] MOBY Central OK? In-Reply-To: <5.2.1.1.2.20060208160929.02368428@email.med.harvard.edu> References: <5.2.1.1.2.20060208160929.02368428@email.med.harvard.edu> Message-ID: Can you send me the exact code fragment that is causing the problem (or even the search parameters for the findServices call). I'll do a local call directly against the MOBY/Central.pm in debug mode and see if I can track down the problem. M On Wed, 08 Feb 2006 13:49:59 -0800, Frank Gibbons wrote: > At 03:17 PM 2/8/2006, you wrote: >> The dreaded Error cubed, eh? >> >> I dunno... I have also been using it this morning, and haven't touched >> anything today except the gbrowse rendering modules, so...?? >> >> Can you ping or traceroute to the machine? > > Actually, I've now diagnosed that it's _not_ a connectivity problem: for > example, MOBY::Client::Central->findServices() works fine. But when I > try to retrieve an individual service, I end up with: > > Empty String at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2457 > > ERROR ERROR ERROR > > At first, I thought this was truly bizarre for a number of reasons, not > least of which is the fact that there is NO Perl 5.8.5 installed on my > machine, and even the perl executable I'm using (which is 5.8.6) is > running from my home directory, and therefore should have nothing at all > to do with /usr/lib. > > ....but then I realized that it's coming from the remote MOBY::Central, > not from my local MOBY::Client::Central. When I go to that line in > MOBY::Central.pm, I notice that it's in _retrieveService(), and the > die() propagates up from XML::LibXML being passed in an empty $payload. > > At least I think that's what's going on. What do you think? > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From johan at ac.uma.es Thu Feb 9 09:16:30 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 09 Feb 2006 10:16:30 +0100 Subject: [MOBY-dev] RFC #1941: INB Asynchronous Service Call Proposal - discussion summary (so far) Message-ID: <43EB086E.2050108@ac.uma.es> Hello everyone, It is very encouraging to get such a reaction to a RFC. It clearly demonstrates that the proposal is needed. The result of all these discussion and comments will be a much-needed mechanism to call long-running services (something we are eager to implement in our system). However, let me first point out that the RFC is a collaborative result from the entire INB. Martin suggested me to summarize what has been discussed so far and this is what I have come up with (really, it is not an easy task...). Please, if I misinterpret "agreement", I apologize and ask that you let me know. The motivation for the summary is to see if we are reaching some form of consensus. It does not mean that discussion on the "agreed" points is over, anyone with comments are very welcome. "agreed?": ======== * Three additional methods to represent starting an asynchronous session, polling for status and getting the result. * It should be allowed to retrieve results or status for specific mobyData inputs ("jobs"), although all clients must not support this (if they do not want) * XML from LSAE should be used to carry status information (somehow) * More specifics needed about which mobyExceptions for async-related fails/warnings * Information about if a service can be run asynchronously should be stored in the registry. Still debated or unresolved: ========= * Using mobyStatus vs. using status objects in the ontology (actually this is the most debated question). (Martin) * How clients determine if a service can be called asynchronously (Martin) * Names of the methods, use instead verbs to better describe the methods. (Pieter Neerincx) * Alternate solution, WSRF (this one really would mean a completely new RFC) (Tom Oinn) * _result cleans the result vs a specific _clean (Martin) * session_id (Martin) Also, there has been several (justified) requests for rewrites (unclear sentences, better documented predicate etc) to clarify what is meant. We are working on this. Additional comments coming in answers to your specific emails. So far, many and valuable comments from the community but we want to hear from more people what they think. Kind regards, Johan From Pieter.Neerincx at wur.nl Thu Feb 9 15:28:35 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 9 Feb 2006 16:28:35 +0100 Subject: [MOBY-dev] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <8FF00FBE-FDB8-4C0E-8333-0A22A1F4D750@wur.nl> On 8-Feb-2006, at 1:36 AM, Martin Senger wrote: >>> [servicename]_submit >>> [servicename]_poll >>> [servicename]_retrieve >>> and maybe also: >>> [servicename]_clean or [servicename]_remove >> Those are nice names, I like them. Anybody else? >> > I don't care (but 'submit' is confusing because even just a sync > invocation is a submit...) I disagree. If you do a sync call you do a _submit and _retrieve in one go. If you specify individual parts of the job execution process, than that is exactly what you get. If you don't specify individual parts you get a "all-in-one" sync call. What do the others think? Pi > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Thu Feb 9 17:00:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 9 Feb 2006 18:00:37 +0100 Subject: [MOBY-dev] RFC #1941: INB Asynchronous Service Call Proposal - sync mode required or not? In-Reply-To: <43EB086E.2050108@ac.uma.es> References: <43EB086E.2050108@ac.uma.es> Message-ID: <338278A6-F198-4953-B40F-EF43B538EC5D@wur.nl> Hi Johan et al., Thanks for the summary. There is one more point I'd like to discuss with you all. The proposal lists that a service provider should always support sync mode. So it's either sync only or sync and async. I have a service for which supporting sync doesn't make any sense. The jobs take way to long for sync mode. I'd rather not waste resources on all the clients that try sync mode first and run into webserver time-outs after a minute or 5. So my question is do we really have to support sync for all services? If the answer to that question is yes, I hereby request an additional error code for the recently adopted error handling RFC to signal that a service can only be invoked in async mode. So if I have to implement sync, I will do it but throw an error by default :). Cheers, Pi From markw at illuminae.com Thu Feb 9 18:13:05 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 09 Feb 2006 10:13:05 -0800 Subject: [MOBY-dev] [moby] RFC #1941: INB Asynchronous Service Call Proposal - sync mode required or not? In-Reply-To: <338278A6-F198-4953-B40F-EF43B538EC5D@wur.nl> References: <43EB086E.2050108@ac.uma.es> <338278A6-F198-4953-B40F-EF43B538EC5D@wur.nl> Message-ID: <1139508785.6165.51.camel@bioinfo.icapture.ubc.ca> I guess this speaks to the issue of whether synch/asynch/both need to be flags registered in the registry, or not. If they were, then clients that didn't report themselves as asynch-enabled could be excluded from discovering services that were asynch only... I'm not advocating one position or another, just suggesting that it could be handled that way. I'm looking forward to seeing the next draft of the RFC proposal where these ideas are more formally synthesized!! M On Thu, 2006-02-09 at 18:00 +0100, Pieter Neerincx wrote: > Hi Johan et al., > > Thanks for the summary. There is one more point I'd like to discuss > with you all. The proposal lists that a service provider should > always support sync mode. So it's either sync only or sync and async. > I have a service for which supporting sync doesn't make any sense. > The jobs take way to long for sync mode. I'd rather not waste > resources on all the clients that try sync mode first and run into > webserver time-outs after a minute or 5. So my question is do we > really have to support sync for all services? If the answer to that > question is yes, I hereby request an additional error code for the > recently adopted error handling RFC to signal that a service can only > be invoked in async mode. So if I have to implement sync, I will do > it but throw an error by default :). > > Cheers, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From johan at ac.uma.es Thu Feb 9 20:10:41 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 09 Feb 2006 21:10:41 +0100 Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <43EBA1C1.6000504@ac.uma.es> (Martins first email with comments is a good starting point, I know that there has been discussions after he sent the email and some things have changed, but it is an excellent overview of the "hottest" points.) Martin Senger wrote: > I agree with Mark that it is a good proposal - we desperately need > it. I just hope that more people will join this discussion (please, do > so!). I suggest that we postpone the voting for about two more > weeks. Mainly because some of my comments (see below) would require > more details to be put in the document. And also to allow other people > to jump the board (please, do so!). Yes, this is reasonable. We still have some very fundamental discussions open and we should give time for more people to give comments. > * Data returned by xxx_async and xxx_poll > ----------------------------------------- > > Why does the proposal treat them differently (comparing to normal > Biomoby data)? Why to introduced a new XML element 'mobyStatus' when > we can easily - and keeping many software untouched - send these data > in usual 'mobyData' element? The answers to both your questions are really implied by your first question: The proposal treats them differently because they are very different (not normal Biomoby data). Status information is not Moby data (clearly not biological data or results) and not related to service discovery. It is data about a service execution. But more about "Data returned by xxx_async and xxx_poll" in a separate email (this email is already long enough...). > * Dependency on LSID service metadata > ------------------------------------- > > I do not like it (the RDF predicate indicating that a service can be > asynchronous). Here is why: > > For me, the divider between service data and service metadata was > always that metadata are good but are not crucial for a service > execution. But the flag "this service can be called asynchronously" is > very fundamental flag for a service, and it changes its behaviour and > the behaviour of its clients. Also, it must be known to a registry - > because registry is supposed to generate WSDL with xxx_async and > xxx-poll method included. So register should have it, anyway! > This is an interesting discussion (also referring to later emails about this subject). Three (?) sub-topics: 1) Should the information be in the RDF? The RDF predicate "isAsynchronous" is information about how a service can be used, in the same way as information about a service instance?s input/output parameters, object types etc (just some of the information available as RDF for service instances) . They are all necessary clues of how to call a service (not just good to have but actually needed, although they are _also_ provided in another way as WSDL). Same thing goes for information if a service can be called asynchronously, it is needed and should be in the RDF. We could offer this information both as WSDL and as RDF? 2) Should this information be stored in the registry? Information if a service is asynchronous must be stored by the registry, this we agree on (it was in the proposal). An excellent reason to keep the information in the database of the registry was given by Martin in later emails; basically that the registry can't be expected to check a RDF file (LSID metadata) every time WSDL is generated (even if this information is cached). This information must be in the database, yes, but what is said in the proposal about LSID resolution is not how the registry finds out if a service is asynchronous, it says one way how a client can find out. Also, regarding what Mark asked in his first comments. There is no real value added by doing a search for asynchronous services if that is the only search term (other than for statistical reasons maybe). Simply the fact that the service is asynchronous does not (or at least should not) motivate clients to call it. But the information still belongs in the registry. 3) How does a client tell if a service is async? We agree that the information should be in the information from the Moby Central (retrieveService), but as said above, it should also be possible to get as RDF. So, maybe it is better not to specify how the client tells if the service is async? We need to define places where to put the information but we do not have any control over if a client finds out that a service is asynchronous by reading the WSDL (or the RDF) or by just simply calling xxx_async, hoping that it will work (not saying that this is a good option, but it would be one possible way to do it). We have to consider how to do it, but maybe not specify in the RFC how to do it? Regarding "category": One possible place to put this information would be, as Martin suggested, in the "category"-field. If everyone agrees, then we will add this to the proposal. Right now, the allowed values are "moby", "wsdl" and "cgi"? Does "moby-async" makes it clear that "yes, it is a moby-type service, but it should be called asynchronously"? We need some form of flag, either way. What do others think? > b) "Id unique to each... in a message". No, the Id must be unique to > the whole service provider (at least to the invoked service). If > the unique-ness is just in a message there would be problems when I > invoke the same service several times before the first one > finished. You are completely right, this will be corrected in the RFC document. > c) How many times am I allowed to call xxx_result? I suggest just once > - and any next invocation fails with an exception. This means that > this call also serve as a cleaning call - the service > implementation can clean the session. > This has also been further discussed and the agreement was to allow several calls to _result? As was pointed out also by Robert Buels, results could take a long time to produce and transfer (and it would probably be very annoying for a client to loose the result he/she has been waiting for if the connection is broken during a call to _result because of network errors or whatever). It should be (in principle) possible to call _result as many times as the client wants, but the service providers must be allowed to clean old results after a (service provider-specific) time period. After that time period, calls to _result with the asyncID should return an empty mobyData with a mobyException (saying "result not found"?). However, as Martin pointed out, this probably does not belong in the RFC, it is more an implementation detail (a service provider with large resources might choose to never clean the results, unless specifically asked to do so). Of course, it would also be good to add an explicit xxx_clean method to allow clients that want to say "ok, I will not need this result ever again, you may remove it". Naturally messages to and the behavior of _clean must be documented if there is a consensus that it should be added to the RFC. This possibility has been discussed earlier in INB but we decided not to include it in the RFC to keep the proposal as simple as possible, but there seems to be a need for a clean-method, even if the service provider automatically cleans services (after some time). Actually, we have been thinking about how to provide ways to stop, pause and restart service executions (in similar ways to _async, _poll, etc) but, again, we did not want to complicate discussions. However, while this discussion is important, it would be better if we agreed on the current proposal first. > c) More must be written about exception states: What (if any) > exception to raise when a given session handler is > invalid/expired. There may be other states to document by an > exception code. > Yes, we are adding some example(s) to the proposal, mainly to show how it can be done. It is, however, difficult to list all possible exceptions, anyone with suggestions is welcome to let us know. > I think that this is enough for now. Again, I thank very much INB > for the proposal, and please give us slightly more time to discuss and > make changes. Then we need a new document, and few days to read it > again. Thank you for your comments and suggestions. We are working on a new version, so please stay tuned! Kind regards, Johan From johan at ac.uma.es Thu Feb 9 20:20:46 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 09 Feb 2006 21:20:46 +0100 Subject: [MOBY-dev] RFC #1941: Data returned by xxx_async and xxx_poll Message-ID: <43EBA41E.5010409@ac.uma.es> This is really one of the hot-points. Should we wrap this data in mobyStatus or in mobyData? It really comes down to a question of viewpoints (both ways would be possible to implement). (btw, sorry if we mix the terms "event" and "status" but we are talking about, in this context, the same information (mobyStatus vs Event-base class) Just to summarize what (we think) Martin is suggesting: ===== He suggests that we do not need mobyStatus and instead the status information should be put in normal Moby objects, all registered in the shared Moby object ontology. The methods _async and _poll would return mobyObjects instead of mobyStatus. These mobyObjects would have the same information as is in mobyStatus (asyncID, LSAE status XML etc). The mobyObjects for this would also be ordered in the moby object ontology (placed in a hierarchy, separate subtree). Some comments from Martin: (1) We should change the API/protocol as little as possible (more of a general comment). (2) There could be services that would like to register with such mobyObjects. (3) Service providers could easily register new such mobyObjects and inherit (extend) existing status mobyObjects (all new status objects must inherit the base-object Event). ===== Martin, please correct us if we misunderstood something. Now, let us try to explain our position (which is to keep mobyStatus): We do not want to put such information in mobyObjects because it would mean that we put what is really status (event) information about jobs in the Moby object ontology. It is difficult enough to maintain a good ontology but, at least, let us keep the biomoby ontology for objects related to biological information (results belonging in the domain). This is a very important principle. (1) Martin is correct that our mobyStatus alters the protocol more (the new async clients would need to handle the tag) than putting the information as mobyObjects. However, the only clients and services that would be affected by the alteration (mobyStatus) would be asynchronous clients and services ("new" services/clients, or at least new "interfaces"). Old clients would never receive or send mobyStatus content, so they would not be affected by it. In our opinion, it is better to create new placeholders (mobyStatus) for such new and different information than to put it where it does not belong (the ontology). The protocol would only be altered for this new type of communication, not for the "standard" communication (which would still be available). (2) We have a hard time imagining such services. Martin, could you give some examples? (3) By using "standard" LSAE in our approach (mobyStatus), new events can be extended from existing events (but as we will explain, this should, if possible, be avoided), so the possibility to extend events is not an argument in itself to put this information in the moby object ontology. If the events are placed as mobyObjects in the ontology, new events would be instantly shared by all clients (but of course, the clients would not understand the new, added, attributes unless there are changes in their implementation). Same thing is possible with mobyStatus and LSAE, but the changes would not be "shared", at least not directly. The five basic event types (Heartbeat_event, Percent_progress_event, State_changed_event, Step_progress_event and Time_progress_event) in LSAE covers most (if not all) situations. We are proposing that the only status messages all async clients _must_ understand are the ones specified already in LSAE. If a service provider needs to define new status messages by extending already existing, they run the risk of clients not understanding their new status messages (at all). In the LSAE specification, it even says that clients should simply ignore new status/events that they do not understand. Only specialized clients would in this scenario be able to understand the new status/events (that would come from a very specialized service). If, in the future, there is a need for new "standard" event types, this could be carefully considered (in this mailing list for example) and added to the official documentation/API. While this is a simpler and slower mechanism than what Martin suggests, it is also a more _stable_ mechanism than ordering the events in a dynamic, uncontrolled and shared hierarchy. MobyStatus and LSAE events still do what we need, but in a more stable and controlled way. While mobyStatus would need to be handled by new async clients, it does not complicate future client tooling to have a stable interface, does it? Kind regards, Johan From markw at illuminae.com Thu Feb 9 21:33:19 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 09 Feb 2006 13:33:19 -0800 Subject: [MOBY-dev] [moby] RFC #1941: Data returned by xxx_async and xxx_poll In-Reply-To: <43EBA41E.5010409@ac.uma.es> References: <43EBA41E.5010409@ac.uma.es> Message-ID: <1139520799.8542.18.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-02-09 at 21:20 +0100, Johan Karlsson wrote: > This is really one of the hot-points. Should we wrap this data in > mobyStatus or in mobyData? It really comes down to a question of > viewpoints (both ways would be possible to implement). > > Now, let us try to explain our position (which is to keep mobyStatus): > > We do not want to put such information in mobyObjects because it would > mean that we put what is really status (event) information about jobs in > the Moby object ontology. I would argue that you have simply moved the problem to another level of the system - you are now passing event information in the data payload :-) This is what I liked about Tom's suggestion - after reading about WSRF it seemed to me that the SOAP header would be the appropriate place to pass status information, and that the behaviour of MOBY services from the client perspective would therefore be identical to what it is now. You call XXX_result and you get an empty response; however in the SOAP header, for those clients that can read it, there is a variety of status information. No need for new non-biological object types, no need for new payload tags. I disagree with an earlier comment that this would require a new RFC - I think it is a simplification and improvement on the current RFC, and in fact, it requires less of a change in the existing behaviour than any other suggestion so far (at least as I understand them...) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Thu Feb 9 23:26:59 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 09 Feb 2006 18:26:59 -0500 Subject: [MOBY-dev] problems with retrieveService() in Perl API Message-ID: <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> Hi, Just wondering if anyone has had problems with the Perl API. As you know, I've been having difficulties the last few days. My current roadblock is that, while I can discover services from MOBY Central, I am unable to retrieve the service description (WSDL). I have tried Mark's at iCapture, as well as the one at MIPS, and the symptoms are identical at both. Retrieval fails because the MOBY Central thinks it got an empty message from me, and XML parser *hates* being asked to parse empty messages. Yet, if I insert code immediately preceding the line in which I call the remote MOBY Central, I can verify that I'm *not* sending an empty message. So now I'm wondering whether there could some problem with the transport layer, or possibly with some kind of dependency on a module that no-one is aware of. Has anyone run into this kind of issue before? I don't understand what's going on: I installed a new perl interpreter to deal with some issues I was having parsing XML, and now I can't even get the XML I was having difficulty with! Any ideas would be most welcome. Thanks. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From rmb32 at cornell.edu Thu Feb 9 14:02:49 2006 From: rmb32 at cornell.edu (Robert Buels) Date: Thu, 09 Feb 2006 09:02:49 -0500 Subject: [MOBY-dev] RFC #1941: INB Asynchronous Service Call Proposal - discussion summary (so far) In-Reply-To: <43EB086E.2050108@ac.uma.es> References: <43EB086E.2050108@ac.uma.es> Message-ID: <43EB4B89.8030400@cornell.edu> I agree with Tom Oinn's comment that we should thoroughly consider the way WSRF does things. I don't know anything about it. Johan, what do you and your team think about WSRF? Rob -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32 at cornell.edu http://www.sgn.cornell.edu From senger at ebi.ac.uk Fri Feb 10 00:46:08 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 00:46:08 +0000 (GMT) Subject: [MOBY-dev] [moby] RFC #1941: Data returned by xxx_async and xxx_poll In-Reply-To: <1139520799.8542.18.camel@bioinfo.icapture.ubc.ca> Message-ID: > I disagree with an earlier comment that this would require a new RFC - I > think it is a simplification and improvement on the current RFC, and in > fact, it requires less of a change in the existing behaviour than any > other suggestion so far (at least as I understand them...) > It does not matter how you call it, new RFC or comments to the old one, but you need to tell us what you are suggesting - preferrably in the same level of details as INB did. Otherwise, I am not able to follow your points. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Feb 10 00:51:29 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 00:51:29 +0000 (GMT) Subject: [MOBY-dev] [moby] RFC #1941: INB Asynchronous Service Call Proposal - sync mode required or not? In-Reply-To: <1139508785.6165.51.camel@bioinfo.icapture.ubc.ca> Message-ID: > I guess this speaks to the issue of whether synch/asynch/both need to be > flags registered in the registry, or not. If they were, then clients > that didn't report themselves as asynch-enabled could be excluded from > discovering services that were asynch only... > I thought that "whether synch/asynch/both need to be flags registered in the registry" was sort of already agreed on (actually without having it in registry I would not know how the registry can generate rich enough WSDL). The rest of your message is unclear to me. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 10 06:06:59 2006 From: markw at illuminae.com (mark wilkinson) Date: Fri, 10 Feb 2006 06:06:59 +0000 GMT Subject: [MOBY-dev] Frank's problems Message-ID: <1379816415-1139551722-cardhu_blackberry.rim.net-20105-@engine02-cell01> Hi Frank, Let's maybe try to get in touch by phone tomorrow. I'll put some debugging and soap trace statements into the code on my mobycentral instance on bioinfo.icapture.ubc.ca (same os and codebase as the public registry) and we can play around for a while - maybe we'll be able to figure out what is going wrong... I want to see what is being received at this end to see if I am receiving the same message that you are sending! Hopefully the problem will be obvious... Have you done a trace on your soap messages (add "use SOAP::Lite +trace;" somewhere in your code) to see exactly what is going out on the wire as it leaves your client? I have never seen anything like the bug that you are reporting, so it might help if we are on the phone and I can watch the server error logs etc while you make a call... Bioinfo is quiet - only you and I and one of our special projects students will be using it tomorrow so it will be easier to monitor than the public registry. Let me know what time is good for you, and a number I can call to find you, M -- Mark Wilkinson ...on the road! From markw at illuminae.com Fri Feb 10 06:18:39 2006 From: markw at illuminae.com (mark wilkinson) Date: Fri, 10 Feb 2006 06:18:39 +0000 GMT Subject: [MOBY-dev] Moby dashboard Message-ID: <2126268158-1139552423-cardhu_blackberry.rim.net-27277-@engine12-cell01> Hey Martin! I used Dashboard today for the first time "in anger" (as Michael Ashburner would say). It is absolutely amazing! I registered a couple of namespaces, registered a new service, and edited an existing one - it all worked exactly as advertised :-). There are a few things in the interface that confused me, though - Eddie was hovering over me watching so he knows what bits were not intuitive - would you mind if he went in and modified them himself, or would you prefer that we send you comments that you can use or discard as you see fit? (One example was the label "Set" instead of "Collection" when registering a service that operates on or returns Collection's... I interpreted the label as a verb, rather than an adjective, and found myself saying "Set what... To what?") We won't touch it without your OK :-) M -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Fri Feb 10 06:40:04 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 06:40:04 +0000 (GMT) Subject: [MOBY-dev] Moby dashboard In-Reply-To: <2126268158-1139552423-cardhu_blackberry.rim.net-27277-@engine12-cell01> Message-ID: > There are a few things in the interface that confused me, though - > Eddie was hovering over me watching so he knows what bits were not > intuitive - would you mind if he went in and modified them himself, or > would you prefer that we send you comments that you can use or discard > as you see fit? > I am now intensively working on Dashboard - so it will be a pleasure to implement your suggestions. Very welcome them, indeed. (Which does not mean that I am refusing other people to add/change there things. Vice-versa, I welcome that, too.) > (One example was the label "Set" instead of "Collection" when > registering a service > Done. (Not yet committed, will be later today, when I clean my other code I am working on just now...) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Fri Feb 10 10:57:55 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 10 Feb 2006 11:57:55 +0100 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> References: <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> Message-ID: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> Hi Frank, On 10-Feb-2006, at 12:26 AM, Frank Gibbons wrote: > Hi, > > Just wondering if anyone has had problems with the Perl API. You know I've had one. I kind off found a workaround for the time being, but I do know it's XML parsing related and really hope I won't run into more problems. I'm still suspecting a minor security update for messing up either libxml2, libxslt or something related and as a result XML::LibXML not playing nice anymore. The createDocumentFragment() method used to work for me for over 1.5 years, so something must have changed. I'm on SuSE by the way as well. SLES 9 (i386) with service pack 3 to be precise. XML::LibXML is 1.58. I tried the latest libxml2 2.6.23 and recompiled XML::LibXML for that one, but that gave me the same results. I currently running on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 today... If you reinstalled Perl, did you also reinstall SOAP::Lite? If yes which version? In case it's 0.60+ you might have an "anyURI" problem. I you have a snipped of code that produces the problem, I could run it in my setup to see if I can reproduce the problem. Pi > As you know, > I've been having difficulties the last few days. My current > roadblock is > that, while I can discover services from MOBY Central, I am unable to > retrieve the service description (WSDL). I have tried Mark's at > iCapture, > as well as the one at MIPS, and the symptoms are identical at both. > > Retrieval fails because the MOBY Central thinks it got an empty > message > from me, and XML parser *hates* being asked to parse empty > messages. Yet, > if I insert code immediately preceding the line in which I call the > remote > MOBY Central, I can verify that I'm *not* sending an empty message. > > So now I'm wondering whether there could some problem with the > transport > layer, or possibly with some kind of dependency on a module that no- > one is > aware of. Has anyone run into this kind of issue before? I don't > understand > what's going on: I installed a new perl interpreter to deal with some > issues I was having parsing XML, and now I can't even get the XML I > was > having difficulty with! Any ideas would be most welcome. > > Thanks. > > -Frank > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From francis_gibbons at hms.harvard.edu Fri Feb 10 14:29:33 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 09:29:33 -0500 Subject: [MOBY-dev] Frank's problems In-Reply-To: <1379816415-1139551722-cardhu_blackberry.rim.net-20105-@eng ine02-cell01> Message-ID: <5.2.1.1.2.20060210092639.022efe20@email.med.harvard.edu> Hey Mark, I was just thinking about turning on the SOAP::Lite trace facility. I have a meeting at 4pm eastern time, but am otherwise free, so if it's all the same to you, maybe we could talk around 2pm - hopefully that'll give us time to track things down. If that time doesn't work for you, suggest another - I'm free most of the day. My number is 617-432-3555. It's a shared line, so ask for me, if I don't pick up. Thanks, -Frank At 01:06 AM 2/10/2006, you wrote: >Hi Frank, > >Let's maybe try to get in touch by phone tomorrow. I'll put some >debugging and soap trace statements into the code on my mobycentral >instance on bioinfo.icapture.ubc.ca (same os and codebase as the public >registry) and we can play around for a while - maybe we'll be able to >figure out what is going wrong... I want to see what is being received at >this end to see if I am receiving the same message that you are >sending! Hopefully the problem will be obvious... > >Have you done a trace on your soap messages (add "use SOAP::Lite +trace;" >somewhere in your code) to see exactly what is going out on the wire as it >leaves your client? I have never seen anything like the bug that you are >reporting, so it might help if we are on the phone and I can watch the >server error logs etc while you make a call... Bioinfo is quiet - only you >and I and one of our special projects students will be using it tomorrow >so it will be easier to monitor than the public registry. > >Let me know what time is good for you, and a number I can call to find you, > >M > > >-- >Mark Wilkinson >...on the road! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From gordonp at ucalgary.ca Fri Feb 10 14:54:08 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 10 Feb 2006 07:54:08 -0700 Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: <43E0DF34.7070300@ac.uma.es> References: <43E0DF34.7070300@ac.uma.es> Message-ID: <43ECA910.30304@ucalgary.ca> From francis_gibbons at hms.harvard.edu Fri Feb 10 14:56:06 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 09:56:06 -0500 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> References: <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060210095209.0110b210@email.med.harvard.edu> At 05:57 AM 2/10/2006, you wrote: >for that one, but that gave me the same results. I currently running >on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 >today... If you reinstalled Perl, did you also reinstall SOAP::Lite? >If yes which version? In case it's 0.60+ you might have an "anyURI" >problem. Yes, when I re-installed the interpreter (built from source 5.8.6), I reinstalled all of the modules too, from CPAN. I have SOAP::Lite version 0.67 installed. What is the "anyURI" problem you mention? Thanks for the response, Pieter. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Fri Feb 10 15:34:19 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 15:34:19 +0000 (GMT) Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: <43ECA910.30304@ucalgary.ca> Message-ID: If this error would be the only missing link/feature in the Biomoby doc, I would shut up... But I must admit that Mark's previous documentation (API in one long page) was not that great but much better. Proof? If I need to look at it I am still using my local copy of his page because the new pages simply are not linked together. BTW, the checkbot on the page ttp://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/index_API.html reports 26 missing links (from 58; ratio 44%). Could somebody remind me who has access to the pages - is it possible to correct it in a CVS? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Fri Feb 10 15:36:38 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 10:36:38 -0500 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: <5.2.1.1.2.20060210095209.0110b210@email.med.harvard.edu> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> OK, so there is a problem with SOAP::Lite 0.67. I downgraded my installation to 0.60 (which by the way, is reported here (http://soaplite.com/download.html) as being the recommended stable release, and now at least I can retrieveService details sufficiently to build a service instance. If upgraded back to 0.67, and the problem re-appears, so I'm downgrading to 0.60, where I will stay. However, as I discovered, when a user simply installs SOAP::Lite from CPAN, they may get quite a different version than 0.60 (I got 0.67), in which case, the message gets sent out correctly on the wire, but is perceived as empty by MOBY Central. I don't know much about the details of packaging SOAP requests, and you can read the gory details below for yourselves, but it appears that SOAP::Lite 0.60 and SOAP::Lite 0.67 do not understand each other. The clue was given by the User-Agent and SOAPServer lines, showing that my request was sent using SOAP::Lite/Perl/0.67, and the error message sent in response was generated by SOAP::Lite/Perl/0.60 So, mystery solved. I'll put a check for SOAP::Lite's version, and a warning for this into the Makefile, until we can figure out what the real solution to this problem is. Thanks to Mark & Pieter for their help and suggestions. -Frank ================================== SOAP::Lite +trace output ============================ SOAP::Transport::HTTP::Client::send_receive: POST http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl HTTP/1.1 Accept: text/xml Accept: multipart/* Accept: application/soap User-Agent: SOAP::Lite/Perl/0.67 Content-Length: 1539 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://mips.gsf.de/MOBY/Central#retrieveService" Retrieval 1 moby paulien.adamse at wur.nl http://www.watdb.nl/moby-live/cgi-bin/MOBY/Services/Watdb_mobyservices.py Object PO_acc Object WAtDB_id SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x8906a8c) SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error Connection: close Date: Fri, 10 Feb 2006 15:31:05 GMT Server: Apache Content-Length: 559 Content-Type: text/xml; charset=utf-8 Client-Date: Fri, 10 Feb 2006 15:29:58 GMT Client-Peer: 146.107.217.142:80 Client-Response-Num: 1 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:ServerEmpty String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 SOAP::Deserializer::deserialize: () SOAP::Parser::decode: () SOAP::SOM::new: () SOAP::SOM::DESTROY: () Connection to MOBY Central at URI 'http://mips.gsf.de/MOBY/Central' died because: SOAP-ENV:Server : Empty String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 ERROR ERROR ERROR At 09:56 AM 2/10/2006, you wrote: >At 05:57 AM 2/10/2006, you wrote: > >for that one, but that gave me the same results. I currently running > >on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 > >today... If you reinstalled Perl, did you also reinstall SOAP::Lite? > >If yes which version? In case it's 0.60+ you might have an "anyURI" > >problem. > >Yes, when I re-installed the interpreter (built from source 5.8.6), I >reinstalled all of the modules too, from CPAN. I have SOAP::Lite version >0.67 installed. What is the "anyURI" problem you mention? > >Thanks for the response, Pieter. > >-Frank > > >PhD, Computational Biologist, >Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. >Tel: 617-432-3555 Fax: >617-432-3557 http://llama.med.harvard.edu/~fgibbons > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Fri Feb 10 15:57:38 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 10:57:38 -0500 Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: References: <43ECA910.30304@ucalgary.ca> Message-ID: <5.2.1.1.2.20060210104000.011f12d8@email.med.harvard.edu> Martin, At 10:34 AM 2/10/2006, you wrote: >If this error would be the only missing link/feature in the Biomoby doc, I >would shut up... But I must admit that Mark's previous documentation (API >in one long page) was not that great but much better. Proof? If I need to >look at it I am still using my local copy of his page because the new >pages simply are not linked together. I'm not sure what you mean - the pages of the API are linked, at least to the extent that the older single-page document was linked. In addition, there's a table of contents on the right-hand side of each page, so you don't have to back-track to find what you need. I think this version makes it easier to see what is known, but I'm open to the idea that it might not work for everyone. Certainly, if you're looking for something to print out, then having one long page is better. >BTW, the checkbot on the page >ttp://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/index_API.html >reports 26 missing links (from 58; ratio 44%). I wasn't familiar with checkbot, but found its homepage from google. Unfortunately, checkbot's homepage is down (the irony is killing me ;-D. Could you send a list of the broken links, Martin? I'll be happy to fix them. >Could somebody remind me who has access to the pages - is it possible to >correct it in a CVS? As far as possible, it is all under CVS. Only the front page, and the pages linked to from the bar at the top, are not under CVS. I think the entire website's contents should be under CVS, so that any one of us could set up a complete mirror site. Basically, whatever is shown on the website as having an URL containing CVS_CONTENT is accessible in CVS. The website is updated from CVS every few hours. I encourage every developer to get in there, and add links to things as they see fit. The docs you check out under CVS also link to the biomoby.org website, where possible, so you can start at your local docs, but surf to biomoby.org seamlessly. As for the search function, I pointed out that it was broken about a month ago. Does anyone know if it ever worked? In other words, is it simply a case of some pointers being broken, and if we reset them, everything will work again? Or, if it never worked in the first place, is it more of a black-box, where we don't know what's wrong, or how long it might take to fix? Just as much as the code, perhaps even more so since much of it is language-independent, the documentation should be the work of all developers. I know that few people particularly enjoy writing docs, and certainly there are no kudos for doing it, compared to writing code. To my mind, having a single long page of almost plain text is not a particularly easy way for a newbie to get to learn how MOBY works. That's more who I felt we should be aiming for - put it all out there, make it as easy to find as possible. But you know, perhaps we need both, I'm open to that. We could have a rule in the makefile/build.xml to paste all the pages together into a single document for people who prefer to navigate MOBY like that. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Fri Feb 10 16:04:43 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 16:04:43 +0000 (GMT) Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: <5.2.1.1.2.20060210104000.011f12d8@email.med.harvard.edu> Message-ID: > I'm not sure what you mean - > For example, try to click on 'Primary articles' link in page http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/SecondaryArticle.html and you will get: The requested URL /CVS_CONTENT/moby-live/Docs/MOBY-S_API/PrimaryMessage.html was not found on this server. > Certainly, if you're looking for something to print out, then having > one long page is better. > I like the new design. I simply only complain that there are many broken links. > I wasn't familiar with checkbot, but found its homepage from google. > Unfortunately, checkbot's homepage is down > I took from here: http://public.planetmirror.com/pub/checkbot/checkbot-1.77.tar.gz > Could you send a list of the broken links, Martin? > See below. Thanks for fixin it. Cheers, Martin 404 Not Found http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/CentralRegistry.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ConstructYourService.html http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/DataClassOntology.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/ObjectValue http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/InputMessage.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Secondarymessage.html http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ConstructingYourService.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/Articles.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/CentralRegistry.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/DataClassOntology.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/Examples.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ExceptionCodes.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ExceptionReporting.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/InformationBlocks.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/InputMessage.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/InstallingLocalMOBYCentral.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/MessageStructure.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/MobyCentralObjects.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ObjectStructure.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ObsoleteExceptionMechanism.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/OntologyExamples.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/OutputMessage.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/PrimaryArticle.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/RFC.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/SecondaryArticle.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/XMLPayloads.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/index_API.html http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/DesignAnObject.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/MobyNamespace * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/Perl/ObjectOntology http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/SecondaryArticle.html * http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/PrimaryMessage.html -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 10 16:29:24 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 08:29:24 -0800 Subject: [MOBY-dev] [personal] Re: [moby] RFC #1941: INB Asynchronous Service Call Proposal - sync mode required or not? In-Reply-To: References: Message-ID: <1139588964.12961.10.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 00:51 +0000, Martin Senger wrote: > I thought that "whether synch/asynch/both need to be flags registered > in the registry" was sort of already agreed on (actually without having it > in registry I would not know how the registry can generate rich enough > WSDL). I agree entirely. The alternative would be for the registry to resolve the LSID and figure it out that way; however I think it should be in the registry. I just don't want to presume to tell the authors of the RFC what they are proposing, before they have had a chance to tell us what they are proposing, in their next draft. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Fri Feb 10 16:33:34 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 08:33:34 -0800 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: <1139589214.12961.13.camel@bioinfo.icapture.ubc.ca> Does that mean we don't need a phone call today? M On Fri, 2006-02-10 at 10:36 -0500, Frank Gibbons wrote: > OK, so there is a problem with SOAP::Lite 0.67. I downgraded my > installation to 0.60 (which by the way, is reported here > (http://soaplite.com/download.html) as being the recommended stable > release, and now at least I can retrieveService details sufficiently to > build a service instance. If upgraded back to 0.67, and the problem > re-appears, so I'm downgrading to 0.60, where I will stay. > > However, as I discovered, when a user simply installs SOAP::Lite from CPAN, > they may get quite a different version than 0.60 (I got 0.67), in which > case, the message gets sent out correctly on the wire, but is perceived as > empty by MOBY Central. I don't know much about the details of packaging > SOAP requests, and you can read the gory details below for yourselves, but > it appears that SOAP::Lite 0.60 and SOAP::Lite 0.67 do not understand each > other. The clue was given by the User-Agent and SOAPServer lines, showing > that my request was sent using SOAP::Lite/Perl/0.67, and the error message > sent in response was generated by SOAP::Lite/Perl/0.60 > > So, mystery solved. I'll put a check for SOAP::Lite's version, and a > warning for this into the Makefile, until we can figure out what the real > solution to this problem is. > > Thanks to Mark & Pieter for their help and suggestions. > > -Frank > ================================== SOAP::Lite +trace output > ============================ > > SOAP::Transport::HTTP::Client::send_receive: POST > http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl HTTP/1.1 > Accept: text/xml > Accept: multipart/* > Accept: application/soap > User-Agent: SOAP::Lite/Perl/0.67 > Content-Length: 1539 > Content-Type: text/xml; charset=utf-8 > SOAPAction: "http://mips.gsf.de/MOBY/Central#retrieveService" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> xmlns="http://mips.gsf.de/MOBY/Central"> > > lsid="urn:lsid:biomoby.org:serviceinstance:www.watdb.nl,getWAtDBIdByPOAcc"> > Retrieval > 1 > moby > a certain PO accession number]]> > paulien.adamse at wur.nl > > http://www.watdb.nl/moby-live/cgi-bin/MOBY/Services/Watdb_mobyservices.py > > > lsid="urn:lsid:biomoby.org:objectclass:Object">Object > lsid="urn:lsid:biomoby.org:namespacetype:PO_acc">PO_acc > > > > > lsid="urn:lsid:biomoby.org:objectclass:Object">Object > lsid="urn:lsid:biomoby.org:namespacetype:WAtDB_id">WAtDB_id > > > > > > > SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x8906a8c) > SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error > Connection: close > Date: Fri, 10 Feb 2006 15:31:05 GMT > Server: Apache > Content-Length: 559 > Content-Type: text/xml; charset=utf-8 > Client-Date: Fri, 10 Feb 2006 15:29:58 GMT > Client-Peer: 146.107.217.142:80 > Client-Response-Num: 1 > SOAPServer: SOAP::Lite/Perl/0.60 > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">SOAP-ENV:ServerEmpty > String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 > > SOAP::Deserializer::deserialize: () > SOAP::Parser::decode: () > SOAP::SOM::new: () > SOAP::SOM::DESTROY: () > > Connection to MOBY Central at URI 'http://mips.gsf.de/MOBY/Central' died > because: > SOAP-ENV:Server : Empty String at > /home/users/plant/lib/perl/MOBY/Central.pm line 2457 > > ERROR ERROR ERROR > > > > At 09:56 AM 2/10/2006, you wrote: > >At 05:57 AM 2/10/2006, you wrote: > > >for that one, but that gave me the same results. I currently running > > >on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 > > >today... If you reinstalled Perl, did you also reinstall SOAP::Lite? > > >If yes which version? In case it's 0.60+ you might have an "anyURI" > > >problem. > > > >Yes, when I re-installed the interpreter (built from source 5.8.6), I > >reinstalled all of the modules too, from CPAN. I have SOAP::Lite version > >0.67 installed. What is the "anyURI" problem you mention? > > > >Thanks for the response, Pieter. > > > >-Frank > > > > > >PhD, Computational Biologist, > >Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > >Tel: 617-432-3555 Fax: > >617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Fri Feb 10 16:35:39 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 08:35:39 -0800 Subject: [MOBY-dev] [moby] Re: FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: <5.2.1.1.2.20060210104000.011f12d8@email.med.harvard.edu> References: <43ECA910.30304@ucalgary.ca> <5.2.1.1.2.20060210104000.011f12d8@email.med.harvard.edu> Message-ID: <1139589339.12961.16.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 10:57 -0500, Frank Gibbons wrote: > As for the search function, I pointed out that it was broken about a month > ago. Does anyone know if it ever worked? In other words, is it simply a > case of some pointers being broken, and if we reset them, everything will > work again? Or, if it never worked in the first place, is it more of a > black-box, where we don't know what's wrong, or how long it might take to fix? AFAIK it never worked. It's a bit of PHP script that I looked at for a while, couldn't make immediate sense of, and left on my "future TODO list" for a day when I didn't have a dozen other things to do. -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From dgpisano at cnb.uam.es Fri Feb 10 17:01:41 2006 From: dgpisano at cnb.uam.es (David Gonzalez Pisano) Date: Fri, 10 Feb 2006 18:01:41 +0100 Subject: [MOBY-dev] [personal] Re: [moby] RFC #1941: INBAsynchronous Service Call Proposal - sync mode required or not? In-Reply-To: <1139588964.12961.10.camel@bioinfo.icapture.ubc.ca> References: <1139588964.12961.10.camel@bioinfo.icapture.ubc.ca> Message-ID: <43ECC6F5.6000006@cnb.uam.es> Mark Wilkinson escribi?: > On Fri, 2006-02-10 at 00:51 +0000, Martin Senger wrote: > > >> I thought that "whether synch/asynch/both need to be flags registered >> in the registry" was sort of already agreed on (actually without having it >> in registry I would not know how the registry can generate rich enough >> WSDL). >> > > I agree entirely. The alternative would be for the registry to resolve > the LSID and figure it out that way; however I think it should be in the > registry. I just don't want to presume to tell the authors of the RFC > what they are proposing, before they have had a chance to tell us what > they are proposing, in their next draft. > > M > > > > Well, in fact something could be missed in the proposal we sent, but the philosophy we had in mind was always to extend the registerService API call to include the "sync" flag and store it in registry. Between other benefits, that would allow the client to know whether the service can run in asynchrous mode, at service discovery time. We'll write it more clearly in the next iteration of the proposal. David From Pieter.Neerincx at wur.nl Fri Feb 10 17:03:10 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 10 Feb 2006 18:03:10 +0100 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: On 10-Feb-2006, at 4:36 PM, Frank Gibbons wrote: > OK, so there is a problem with SOAP::Lite 0.67. I downgraded my > installation to 0.60 (which by the way, is reported here > (http://soaplite.com/download.html) as being the recommended stable > release, and now at least I can retrieveService details > sufficiently to > build a service instance. If upgraded back to 0.67, and the problem > re-appears, so I'm downgrading to 0.60, where I will stay. > However, as I discovered, when a user simply installs SOAP::Lite > from CPAN, > they may get quite a different version than 0.60 (I got 0.67), in > which > case, the message gets sent out correctly on the wire, but is > perceived as > empty by MOBY Central. Ok, still have to test 0.67, but 0.66 definitely had some problems. However we can not cling onto 0.60 forever. especially now that 0.67 is up at CPAN and that is what new Perlisch Mobifiers will get when they try MOBY out. So either we have to adapt or S::L has to be patched or both. I posted the "anyURI" problem at the S::L list and so far haven't had any feedback :(. I'll test 0.67 this weekend and repost. If S::L is not fixed fast enough I'll make a list of the small patches you'll need to make BioMOBY work with the latest "stable" S::L. Is your XML parsing problem now fixed by the installation of the new Perl interpreter or is that one still pending a fix? > I don't know much about the details of packaging > SOAP requests, and you can read the gory details below for > yourselves, but > it appears that SOAP::Lite 0.60 and SOAP::Lite 0.67 do not > understand each > other. The clue was given by the User-Agent and SOAPServer lines, > showing > that my request was sent using SOAP::Lite/Perl/0.67, and the error > message > sent in response was generated by SOAP::Lite/Perl/0.60 > > So, mystery solved. I'll put a check for SOAP::Lite's version, and a > warning for this into the Makefile, until we can figure out what > the real > solution to this problem is. > > Thanks to Mark & Pieter for their help and suggestions. > > -Frank > ================================== SOAP::Lite +trace output > ============================ > > SOAP::Transport::HTTP::Client::send_receive: POST > http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl HTTP/1.1 > Accept: text/xml > Accept: multipart/* > Accept: application/soap > User-Agent: SOAP::Lite/Perl/0.67 > Content-Length: 1539 > Content-Type: text/xml; charset=utf-8 > SOAPAction: "http://mips.gsf.de/MOBY/Central#retrieveService" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:soap="http://schemas.xmlsoap.org/soap/ > envelope/"> xmlns="http://mips.gsf.de/MOBY/Central"> xsi:type="xsd:anyURI"> > > serviceName="getWAtDBIdByPOAcc" > lsid="urn:lsid:biomoby.org:serviceinstance:www.watdb.nl,getWAtDBIdByPO > Acc"> > Retrieval > 1 > moby > ids with > a certain PO accession number]]> > paulien.adamse at wur.nl > > http://www.watdb.nl/moby-live/cgi-bin/MOBY/Services/ > Watdb_mobyservices.py > > > lsid="urn:lsid:biomoby.org:objectclass:Object">Object > lsid="urn:lsid:biomoby.org:namespacetype:PO_acc">PO_acc > > > > > lsid="urn:lsid:biomoby.org:objectclass:Object">Object > lsid="urn:lsid:biomoby.org:namespacetype:WAtDB_id">WAtDB_id Namespace> > > > > > > soap:Body> > SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH > (0x8906a8c) > SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal > Server Error > Connection: close > Date: Fri, 10 Feb 2006 15:31:05 GMT > Server: Apache > Content-Length: 559 > Content-Type: text/xml; charset=utf-8 > Client-Date: Fri, 10 Feb 2006 15:29:58 GMT > Client-Peer: 146.107.217.142:80 > Client-Response-Num: 1 > SOAPServer: SOAP::Lite/Perl/0.60 > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/ > encoding/">SOAP- > ENV:ServerEmpty > String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 > > SOAP::Deserializer::deserialize: () > SOAP::Parser::decode: () > SOAP::SOM::new: () > SOAP::SOM::DESTROY: () > > Connection to MOBY Central at URI 'http://mips.gsf.de/MOBY/Central' > died > because: > SOAP-ENV:Server : Empty String at > /home/users/plant/lib/perl/MOBY/Central.pm line 2457 > > ERROR ERROR ERROR > > > > At 09:56 AM 2/10/2006, you wrote: >> At 05:57 AM 2/10/2006, you wrote: >>> for that one, but that gave me the same results. I currently running >>> on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 >>> today... If you reinstalled Perl, did you also reinstall SOAP::Lite? >>> If yes which version? In case it's 0.60+ you might have an "anyURI" >>> problem. >> >> Yes, when I re-installed the interpreter (built from source 5.8.6), I >> reinstalled all of the modules too, from CPAN. I have SOAP::Lite >> version >> 0.67 installed. What is the "anyURI" problem you mention? >> >> Thanks for the response, Pieter. >> >> -Frank >> >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: >> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Feb 10 17:07:49 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 09:07:49 -0800 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: <1139591269.12961.32.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > I'll test 0.67 this weekend and > repost. If S::L is not fixed fast enough I'll make a list of the > small patches you'll need to make BioMOBY work with the latest > "stable" S::L. Do you know if the MOBY patches are backwards-compatible with S::L .60? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Fri Feb 10 17:11:26 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 09:11:26 -0800 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: <1139591486.12961.36.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > I posted the "anyURI" problem at the S::L list and > so far haven't had any feedback :( That problem surely must be a bug in S::L - just because the content *contains* a URI, doesn't mean that it *is* a URI! What confuses me is why S::L is making this choice given that we are now explicitly telling it in the WSDL that the body is *not* a URI but rather a block of XML...?? Maybe S::L doesn't really read the WSDL properly at all?? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Fri Feb 10 17:19:57 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 12:19:57 -0500 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: <1139591486.12961.36.camel@bioinfo.icapture.ubc.ca> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060210121638.011e0fa0@email.med.harvard.edu> At 12:11 PM 2/10/2006, you wrote: >On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > > > I posted the "anyURI" problem at the S::L list and > > so far haven't had any feedback :( > >That problem surely must be a bug in S::L - just because the content >*contains* a URI, doesn't mean that it *is* a URI! > >What confuses me is why S::L is making this choice given that we are now >explicitly telling it in the WSDL that the body is *not* a URI but >rather a block of XML...?? Maybe S::L doesn't really read the WSDL >properly at all?? Well, if you take a look at the structure of the SOAP messages, you can see that 0.67 is using a 2001 schema, while 0.60 is still using a 1999 schema. This means that almost all tags in the SOAP message are completely difference, even the most basic ones. Of course, there are additional ones too, but to me it seems most likely that the older SOAP is looking for high-level tags, which are no longer provided by S::L 0.67, and therefore it thinks that the entire message is empty. I could be wrong (it's happened once or twice before ;-), but my sense is that my problem at least (and that of any new MOBY users who happen along) is not necessarily at the level of "anyURL", WSDL, or some other feature. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Fri Feb 10 17:25:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 10 Feb 2006 18:25:37 +0100 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: <1139591269.12961.32.camel@bioinfo.icapture.ubc.ca> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> <1139591269.12961.32.camel@bioinfo.icapture.ubc.ca> Message-ID: On 10-Feb-2006, at 6:07 PM, Mark Wilkinson wrote: > On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > >> I'll test 0.67 this weekend and >> repost. If S::L is not fixed fast enough I'll make a list of the >> small patches you'll need to make BioMOBY work with the latest >> "stable" S::L. > > Do you know if the MOBY patches are backwards-compatible with S::L . > 60? So far I have only tested client S::L version X with local BioMOBY Central same version X, but before suggesting patches on the BioMOBY side I'll test mixed version as well. What I can not test is the Java and Python stuff. But if a patched client S::L 0.67 with patched client ~Perl/MOBY works fine with the official Central we can leave that one for some more time to come on S::L 0.60... I'll report back on monday... Pi > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Feb 10 17:32:38 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 09:32:38 -0800 Subject: [MOBY-dev] the Search function on biomoby.org Message-ID: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> I take that back - it does work! However, it only searches through what has been "blogged", not through the full content of the site (i.e. it excludes what is in the CVS_CONTENT folder) I don't know how easy it would be to modify this behaviour, as the search utility is part of Wordpress... M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Fri Feb 10 17:31:47 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 10 Feb 2006 18:31:47 +0100 Subject: [MOBY-dev] [moby] Re: problems with retrieveService() in Perl API In-Reply-To: <1139591486.12961.36.camel@bioinfo.icapture.ubc.ca> References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060209182213.02318500@email.med.harvard.edu> <5.2.1.1.2.20060210102435.011ee750@email.med.harvard.edu> <1139591486.12961.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <95689DA5-537A-4FA5-9D10-DC39854FB4EF@wur.nl> On 10-Feb-2006, at 6:11 PM, Mark Wilkinson wrote: > On Fri, 2006-02-10 at 18:03 +0100, Pieter Neerincx wrote: > >> I posted the "anyURI" problem at the S::L list and >> so far haven't had any feedback :( > > That problem surely must be a bug in S::L - just because the content > *contains* a URI, doesn't mean that it *is* a URI! I know, I'll check if it's still there in 0.67 or whether Franks' second problem was yet another new bug. > What confuses me is why S::L is making this choice given that we > are now > explicitly telling it in the WSDL that the body is *not* a URI but > rather a block of XML...?? Maybe S::L doesn't really read the WSDL > properly at all?? In 0.66 it simply does a regexp on the entire message and if it finds 'http://' *anywhere* in the XML it puts that *&#!@ anyURI label on the payload, which is not serialised client-side. Have a nice weekend, Pi > > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Feb 10 17:56:50 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 09:56:50 -0800 Subject: [MOBY-dev] [moby] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <1138906906.7790.95.camel@bioinfo.icapture.ubc.ca> References: <43E0DF34.7070300@ac.uma.es> <1138906906.7790.95.camel@bioinfo.icapture.ubc.ca> Message-ID: <1139594210.12961.64.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-02-02 at 11:01 -0800, Mark Wilkinson wrote: > 3) Let's define the new predicate as follows v.v. the RDF for Service > Instances: > mobyPred:isAsynchronous > Domain: mygrid:operation > Range: xsd:boolean > Definition: a boolean indication of the service providers ability to > provide the associated operation in asynchronous, as well as > synchronous, mode, according to the specification for asynchronous Moby > service calls in the Moby API. I'd like to modify my suggestion above. I think we may want to have one more "layer" between the operation metadata and the synchronous/asyncronous tag, in the form of a "hasCallingDetail" parameter, where one of the properties of a callingDetail includes whether it is synchronous, asynchronous, or both. This also changes it from having a range of xsd:boolean to being a controlled vocabulary (I propose "synchronous", "asynchronous", "sych_asych") An example as N3: a :operation; :hasCallingDetail [ a :callingDetail; :hasSynchType moby:asynchronous ]; an example as RDF: This is somewhat tangential to the discussion, but since your RFC talked about adding this information into the Service Instance metadata, it is ~relevant to the discussion. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From edward.kawas at gmail.com Fri Feb 10 18:05:10 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 10 Feb 2006 10:05:10 -0800 Subject: [MOBY-dev] FYI: Search function on MOBY Web site gives "404 Not Found" error... In-Reply-To: Message-ID: <000701c62e6c$8935fc00$6500a8c0@notebook> > Could somebody remind me who has access to the pages - is it > possible to correct it in a CVS? You can get/modify the documentation from the cvs, under moby-live/Docs Eddie From senger at ebi.ac.uk Fri Feb 10 18:10:19 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 18:10:19 +0000 (GMT) Subject: [MOBY-dev] [moby] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <1139594210.12961.64.camel@bioinfo.icapture.ubc.ca> Message-ID: > I'd like to modify my suggestion above.... > I am confused. Why are you talking now about RDF predicates when in your last email you said that you probably would agree to have this flag in registry? Or does your last sentence (below) answer my question above? > This is somewhat tangential to the discussion, but since your RFC talked > about adding this information into the Service Instance metadata, it is > ~relevant to the discussion. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 10 18:16:00 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 10:16:00 -0800 Subject: [MOBY-dev] [personal] Re: [moby] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: References: Message-ID: <1139595360.12961.67.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-10 at 18:10 +0000, Martin Senger wrote: > I am confused. Why are you talking now about RDF predicates when in > your last email you said that you probably would agree to have this flag > in registry? > Or does your last sentence (below) answer my question above? It clearly needs to be in both places. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Feb 10 18:17:36 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 10 Feb 2006 18:17:36 +0000 (GMT) Subject: [MOBY-dev] [personal] Re: [moby] RFC #1941 Asynchronous Service Call Proposal In-Reply-To: <1139595360.12961.67.camel@bioinfo.icapture.ubc.ca> Message-ID: > It clearly needs to be in both places. > Good. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 10 18:44:05 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 10:44:05 -0800 Subject: [MOBY-dev] [moby] Re: the Search function on biomoby.org In-Reply-To: References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <1139597045.12961.73.camel@bioinfo.icapture.ubc.ca> Excellent! Thanks Simon M On Fri, 2006-02-10 at 12:43 -0600, Twigger Simon wrote: > Hi Mark, > > I might have missed the first part of this but it should be possible > to add in functionality to search static pages too - I did this via a > plug-in for one of my own wordpress installations. Im not sure where > the CVS_CONTENT folder is in relation to the wordpress file hierarchy > but I'll log in and see if I installed the plugin on the MOBY site > and if not, I'll add it in and we'll see what happens... > > Simon. > > > -- > > Simon N. Twigger, Ph.D. > Assistant Professor, Department of Physiology > Medical College of Wisconsin > 8701 Watertown Plank Road, > Milwaukee, WI, USA > tel: 414-456-8802 > fax: 414-456-6595 > AIM/iChat: simontatmcw > > > On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: > > > I take that back - it does work! However, it only searches through > > what > > has been "blogged", not through the full content of the site (i.e. it > > excludes what is in the CVS_CONTENT folder) > > > > I don't know how easy it would be to modify this behaviour, as the > > search utility is part of Wordpress... > > > > M > > > > > > -- > > -- > > ...his last words were 'Hey guys! Watch this!' > > -- > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > "For most of this century we have viewed communications as a conduit, > > a pipe between physical locations on the planet. > > What's happened now is that the conduit has become so big and > > interesting > > that communication has become more than a conduit, > > it has become a destination in its own right..." > > > > Paul Saffo - Director, Institute for the Future > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From simont at hmgc.mcw.edu Fri Feb 10 18:43:05 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Fri, 10 Feb 2006 12:43:05 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, I might have missed the first part of this but it should be possible to add in functionality to search static pages too - I did this via a plug-in for one of my own wordpress installations. Im not sure where the CVS_CONTENT folder is in relation to the wordpress file hierarchy but I'll log in and see if I installed the plugin on the MOBY site and if not, I'll add it in and we'll see what happens... Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: > I take that back - it does work! However, it only searches through > what > has been "blogged", not through the full content of the site (i.e. it > excludes what is in the CVS_CONTENT folder) > > I don't know how easy it would be to modify this behaviour, as the > search utility is part of Wordpress... > > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From francis_gibbons at hms.harvard.edu Fri Feb 10 19:30:57 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 14:30:57 -0500 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> Simon, That's a big improvement on what we had before. Can we tweak the style a little though? If I search for "constructing", I get a single result, which looks like plain text. It's not until I mouse over the heading "BioMoby Perl Service Providers Tutorial" that I realise it's a link. That's becuase it's just big bold black text. Is there some way to format the results, so that the heading comes out as something that's more obviously a link? (Color being the usual indicator for a link, my vote would be that it follow the style of the other links on the page.) Great work, -Frank At 01:43 PM 2/10/2006, you wrote: >Hi Mark, > >I might have missed the first part of this but it should be possible >to add in functionality to search static pages too - I did this via a >plug-in for one of my own wordpress installations. Im not sure where >the CVS_CONTENT folder is in relation to the wordpress file hierarchy >but I'll log in and see if I installed the plugin on the MOBY site >and if not, I'll add it in and we'll see what happens... > >Simon. > > >-- > >Simon N. Twigger, Ph.D. >Assistant Professor, Department of Physiology >Medical College of Wisconsin >8701 Watertown Plank Road, >Milwaukee, WI, USA >tel: 414-456-8802 >fax: 414-456-6595 >AIM/iChat: simontatmcw > > >On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: > > > I take that back - it does work! However, it only searches through > > what > > has been "blogged", not through the full content of the site (i.e. it > > excludes what is in the CVS_CONTENT folder) > > > > I don't know how easy it would be to modify this behaviour, as the > > search utility is part of Wordpress... > > > > M > > > > > > -- > > -- > > ...his last words were 'Hey guys! Watch this!' > > -- > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > "For most of this century we have viewed communications as a conduit, > > a pipe between physical locations on the planet. > > What's happened now is that the conduit has become so big and > > interesting > > that communication has become more than a conduit, > > it has become a destination in its own right..." > > > > Paul Saffo - Director, Institute for the Future > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Fri Feb 10 19:32:51 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 10 Feb 2006 14:32:51 -0500 Subject: [MOBY-dev] [moby] Re: the Search function on biomoby.org In-Reply-To: <1139597045.12961.73.camel@bioinfo.icapture.ubc.ca> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <5.2.1.1.2.20060210143122.0121e180@email.med.harvard.edu> Mark, Search for "installation", and you come up with both old and new instructions. It's not clear that the old ones are, in fact, OLD. Since the old installation instructions are not under CVS, would you mind editing them to say that, and putting a link in to the newer instructions. Thanks, -Frank At 01:44 PM 2/10/2006, you wrote: >Excellent! Thanks Simon > >M > >On Fri, 2006-02-10 at 12:43 -0600, Twigger Simon wrote: > > Hi Mark, > > > > I might have missed the first part of this but it should be possible > > to add in functionality to search static pages too - I did this via a > > plug-in for one of my own wordpress installations. Im not sure where > > the CVS_CONTENT folder is in relation to the wordpress file hierarchy > > but I'll log in and see if I installed the plugin on the MOBY site > > and if not, I'll add it in and we'll see what happens... > > > > Simon. > > > > > > -- > > > > Simon N. Twigger, Ph.D. > > Assistant Professor, Department of Physiology > > Medical College of Wisconsin > > 8701 Watertown Plank Road, > > Milwaukee, WI, USA > > tel: 414-456-8802 > > fax: 414-456-6595 > > AIM/iChat: simontatmcw > > > > > > On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: > > > > > I take that back - it does work! However, it only searches through > > > what > > > has been "blogged", not through the full content of the site (i.e. it > > > excludes what is in the CVS_CONTENT folder) > > > > > > I don't know how easy it would be to modify this behaviour, as the > > > search utility is part of Wordpress... > > > > > > M > > > > > > > > > -- > > > -- > > > ...his last words were 'Hey guys! Watch this!' > > > -- > > > Mark Wilkinson > > > Asst. Professor > > > Dept. of Medical Genetics > > > University of British Columbia > > > PI in Bioinformatics > > > iCAPTURE Centre > > > St. Paul's Hospital > > > Rm. 166, 1081 Burrard St. > > > Vancouver, BC, V6Z 1Y6 > > > tel: 604 682 2344 x62129 > > > fax: 604 806 9274 > > > > > > "For most of this century we have viewed communications as a conduit, > > > a pipe between physical locations on the planet. > > > What's happened now is that the conduit has become so big and > > > interesting > > > that communication has become more than a conduit, > > > it has become a destination in its own right..." > > > > > > Paul Saffo - Director, Institute for the Future > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://biomoby.org/mailman/listinfo/moby-dev > > >-- >-- >...his last words were 'Hey guys! Watch this!' >-- >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From jmfernandez at cnb.uam.es Fri Feb 10 21:03:37 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri, 10 Feb 2006 22:03:37 +0100 Subject: [MOBY-dev] problems with retrieveService() in Perl API In-Reply-To: References: <10366E59-BA87-413E-B433-7CCA1D9AC486@wur.nl><5.2.1.1.2.20060209 182213.02318500@email.med.harvard.edu><5.2.1.1.2.20060209182213.02318500@em ail.med.harvard.edu><5.2.1.1.2.20060210102435.011ee750@email.med.harvard.ed u> Message-ID: <43ECFFA9.6040705@cnb.uam.es> Hi everybody, I have been reading perldoc documentation associated to SOAP::Lite 0.67 (aka Captain Ahab ;-)). Have you played with the new methods soapversion, ns and default_ns? Perhaps they can help. I'm including the fragments of the related documentation: * soapversion(optional value) $client->soapversion('1.2'); If no parameter is given, returns the current version of SOAP that is being used by the client object to encode requests. If a parameter is given, the method attempts to set that as the version of SOAP being used. The value should be either 1.1 or 1.2. * default_ns($uri) Sets the default namespace for the request to the specified uri. This overrides any previous namespace declaration that may have been set using a previous call to "ns()" or "default_ns()". Setting the default namespace causes elements to be serialized without a namespace prefix, like so: * ns($uri,$prefix=undef) Sets the namespace uri and optionally the namespace prefix for the request to the specified values. This overrides any previous namespace declaration that may have been set using a previous call to "ns()" or "default_ns()". If a prefix is not specified, one will be generated for you automatically. Setting the namespace causes elements to be serialized with a declared namespace prefix, like so: Pieter Neerincx wrote: > On 10-Feb-2006, at 4:36 PM, Frank Gibbons wrote: > >> OK, so there is a problem with SOAP::Lite 0.67. I downgraded my >> installation to 0.60 (which by the way, is reported here >> (http://soaplite.com/download.html) as being the recommended stable >> release, and now at least I can retrieveService details >> sufficiently to >> build a service instance. If upgraded back to 0.67, and the problem >> re-appears, so I'm downgrading to 0.60, where I will stay. > >> However, as I discovered, when a user simply installs SOAP::Lite >> from CPAN, >> they may get quite a different version than 0.60 (I got 0.67), in >> which >> case, the message gets sent out correctly on the wire, but is >> perceived as >> empty by MOBY Central. > > Ok, still have to test 0.67, but 0.66 definitely had some problems. > However we can not cling onto 0.60 forever. especially now that 0.67 > is up at CPAN and that is what new Perlisch Mobifiers will get when > they try MOBY out. So either we have to adapt or S::L has to be > patched or both. I posted the "anyURI" problem at the S::L list and > so far haven't had any feedback :(. I'll test 0.67 this weekend and > repost. If S::L is not fixed fast enough I'll make a list of the > small patches you'll need to make BioMOBY work with the latest > "stable" S::L. > > Is your XML parsing problem now fixed by the installation of the new > Perl interpreter or is that one still pending a fix? > >> I don't know much about the details of packaging >> SOAP requests, and you can read the gory details below for >> yourselves, but >> it appears that SOAP::Lite 0.60 and SOAP::Lite 0.67 do not >> understand each >> other. The clue was given by the User-Agent and SOAPServer lines, >> showing >> that my request was sent using SOAP::Lite/Perl/0.67, and the error >> message >> sent in response was generated by SOAP::Lite/Perl/0.60 >> >> So, mystery solved. I'll put a check for SOAP::Lite's version, and a >> warning for this into the Makefile, until we can figure out what >> the real >> solution to this problem is. >> >> Thanks to Mark & Pieter for their help and suggestions. >> >> -Frank >> ================================== SOAP::Lite +trace output >> ============================ >> >> SOAP::Transport::HTTP::Client::send_receive: POST >> http://mips.gsf.de/cgi-bin/proj/planet/moby/MOBY-Central.pl HTTP/1.1 >> Accept: text/xml >> Accept: multipart/* >> Accept: application/soap >> User-Agent: SOAP::Lite/Perl/0.67 >> Content-Length: 1539 >> Content-Type: text/xml; charset=utf-8 >> SOAPAction: "http://mips.gsf.de/MOBY/Central#retrieveService" >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" >> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" >> xmlns:soap="http://schemas.xmlsoap.org/soap/ >> envelope/">> xmlns="http://mips.gsf.de/MOBY/Central">> xsi:type="xsd:anyURI"> >> >> > serviceName="getWAtDBIdByPOAcc" >> lsid="urn:lsid:biomoby.org:serviceinstance:www.watdb.nl,getWAtDBIdByPO >> Acc"> >> Retrieval >> 1 >> moby >> > ids with >> a certain PO accession number]]> >> paulien.adamse at wur.nl >> >> http://www.watdb.nl/moby-live/cgi-bin/MOBY/Services/ >> Watdb_mobyservices.py >> >> >> > lsid="urn:lsid:biomoby.org:objectclass:Object">Object >> > lsid="urn:lsid:biomoby.org:namespacetype:PO_acc">PO_acc >> >> >> >> >> > lsid="urn:lsid:biomoby.org:objectclass:Object">Object >> > lsid="urn:lsid:biomoby.org:namespacetype:WAtDB_id">WAtDB_id> Namespace> >> >> >> >> >> >> > soap:Body> >> SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH >> (0x8906a8c) >> SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal >> Server Error >> Connection: close >> Date: Fri, 10 Feb 2006 15:31:05 GMT >> Server: Apache >> Content-Length: 559 >> Content-Type: text/xml; charset=utf-8 >> Client-Date: Fri, 10 Feb 2006 15:29:58 GMT >> Client-Peer: 146.107.217.142:80 >> Client-Response-Num: 1 >> SOAPServer: SOAP::Lite/Perl/0.60 >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" >> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/ >> encoding/">SOAP- >> ENV:ServerEmpty >> String at /home/users/plant/lib/perl/MOBY/Central.pm line 2457 >> >> SOAP::Deserializer::deserialize: () >> SOAP::Parser::decode: () >> SOAP::SOM::new: () >> SOAP::SOM::DESTROY: () >> >> Connection to MOBY Central at URI 'http://mips.gsf.de/MOBY/Central' >> died >> because: >> SOAP-ENV:Server : Empty String at >> /home/users/plant/lib/perl/MOBY/Central.pm line 2457 >> >> ERROR ERROR ERROR >> >> >> >> At 09:56 AM 2/10/2006, you wrote: >>> At 05:57 AM 2/10/2006, you wrote: >>>> for that one, but that gave me the same results. I currently running >>>> on SOAP::Lite 0.66 with custom patches, but I'm going to try 0.67 >>>> today... If you reinstalled Perl, did you also reinstall SOAP::Lite? >>>> If yes which version? In case it's 0.60+ you might have an "anyURI" >>>> problem. >>> Yes, when I re-installed the interpreter (built from source 5.8.6), I >>> reinstalled all of the modules too, from CPAN. I have SOAP::Lite >>> version >>> 0.67 installed. What is the "anyURI" problem you mention? >>> >>> Thanks for the response, Pieter. >>> >>> -Frank >>> >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: >>> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: >> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From simont at hmgc.mcw.edu Fri Feb 10 23:00:51 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Fri, 10 Feb 2006 17:00:51 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> Message-ID: <5EAB1B87-47EF-4861-A519-4CD958B3178E@hmgc.mcw.edu> Just to note that I havent done anything yet - so any improvements you may have noted are not due to anything I did! =) I checked and we do have the plugin installed and activated to search both posts and pages. The pages are going to be things inside wordpress though and it stores them in the db I believe so Im not sure that merely being in the filesystem somewhere is going to count. I'll go on a hunt for something that might address this, I also saw that wordpress 2 has come out, I'll see what new features that brings too. I see what you mean about the style problem for the search results, I'll have a stab at improving that. S. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 10, 2006, at 1:30 PM, Frank Gibbons wrote: > Simon, > > That's a big improvement on what we had before. Can we tweak the > style a > little though? If I search for "constructing", I get a single > result, which > looks like plain text. It's not until I mouse over the heading > "BioMoby > Perl Service Providers Tutorial" that I realise it's a link. That's > becuase > it's just big bold black text. Is there some way to format the > results, so > that the heading comes out as something that's more obviously a link? > (Color being the usual indicator for a link, my vote would be that it > follow the style of the other links on the page.) > > Great work, > > -Frank > > > At 01:43 PM 2/10/2006, you wrote: >> Hi Mark, >> >> I might have missed the first part of this but it should be possible >> to add in functionality to search static pages too - I did this via a >> plug-in for one of my own wordpress installations. Im not sure where >> the CVS_CONTENT folder is in relation to the wordpress file hierarchy >> but I'll log in and see if I installed the plugin on the MOBY site >> and if not, I'll add it in and we'll see what happens... >> >> Simon. >> >> >> -- >> >> Simon N. Twigger, Ph.D. >> Assistant Professor, Department of Physiology >> Medical College of Wisconsin >> 8701 Watertown Plank Road, >> Milwaukee, WI, USA >> tel: 414-456-8802 >> fax: 414-456-6595 >> AIM/iChat: simontatmcw >> >> >> On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: >> >>> I take that back - it does work! However, it only searches through >>> what >>> has been "blogged", not through the full content of the site >>> (i.e. it >>> excludes what is in the CVS_CONTENT folder) >>> >>> I don't know how easy it would be to modify this behaviour, as the >>> search utility is part of Wordpress... >>> >>> M >>> >>> >>> -- >>> -- >>> ...his last words were 'Hey guys! Watch this!' >>> -- >>> Mark Wilkinson >>> Asst. Professor >>> Dept. of Medical Genetics >>> University of British Columbia >>> PI in Bioinformatics >>> iCAPTURE Centre >>> St. Paul's Hospital >>> Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "For most of this century we have viewed communications as a >>> conduit, >>> a pipe between physical locations on the planet. >>> What's happened now is that the conduit has become so big and >>> interesting >>> that communication has become more than a conduit, >>> it has become a destination in its own right..." >>> >>> Paul Saffo - Director, Institute for the Future >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri Feb 10 23:27:37 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 15:27:37 -0800 Subject: [MOBY-dev] WSRF solution to the asynchronous services problem Message-ID: Hi all, Well, I seem to have mis-understood and mis-represented WSRF in my previous messages. It isn't the utopea that I thought it was the first time I read the spec, but that was my mistake - I was reading it with the assumption that it would be clever and elegant. There are two near-identical specifications in OASIS for dealing with stateful services: WSRF and ASAP. Neither of them have yet been accepted as "standards", so they are still prone to change. Here's a brief overview of the two spec's: WSRF: Web Services Resource Framework - WS Resources are uniquely identifiable entities - One WS Resource is created per Web Service invocation (**NB**) - WS Resources have Property Documents (defined by an XML schema) - Property Documents contain Properties (duh!) describing the state of that WS Resource - Using WSRF-defined, predictable API calls it is possible to obtain the full Property Document or named parts of the Property Document, and/or set the property values - the Web Service must implement these API call(s) as method on the service - a variety of Faults are defined to deal with cases e.g. where the WS Resource or property named in the request is unknown - [[speculation]] cleanup could be achieved by having one of the properties, e.g. "discard", be settable by the client through the appropriate API call ASAP: Asynchronous Service Access Protocol - Specifically for Asynchronous services - Server must implement a "Factory" interface - "Factory" generates "Instances" of a service upon Service invocation - Instances have a variety of API calls to manipulate their parameters and check their status, including their current state, the input data, and the output data. - Instances generate event notifications to the client (**NB**) to tell it that it is finished (active notification, NOT passive notification!!), as well as when its state has changed, etc. - clean-up happens through a server-side, timed event, where one of the properties of an Instance is the duration for which it will be held, after which it is no longer accessible. - it isn't clear from the spec which parts are required and which are optional... unfortunately, there are a LOT of API methods described in the spec, so this is a bit worrisome as they would have to be implemented for every asynch service. My instincts tell me that ASAP is too complex for our needs, and it would be better to work with the more generic of the two specifications anyway just in case we need to use it for something other than asynchronicity (e.g. message chunking!) The problems I see with WSRF are the following: a) It doesn't (natively) handle batching the way we do in MOBY Collections, so anything we come up with is going to be a bit of a hack in that regard. b) It requires that service providers implement one or more of the defined WSRF API methods, and this means that there will be messages passed between MOBY Client and MOBY Service that are not MOBY messages. I'm going to try to put together a strawman proposal for how we might implement MOBY Services asynchronously using WSRF, but it will take me a little while because it isn't entirely trivial nor intuitive to do so... We can then compare it to whatever the RFC proposal is and decide if we gain any significant advantage from following an existing "standard", or if our own proposal is sufficient. M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From markw at illuminae.com Sat Feb 11 06:04:51 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 10 Feb 2006 22:04:51 -0800 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <5EAB1B87-47EF-4861-A519-4CD958B3178E@hmgc.mcw.edu> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> <5EAB1B87-47EF-4861-A519-4CD958B3178E@hmgc.mcw.edu> Message-ID: If we put a symlink in the wordpress folder will it traverse? On Fri, 10 Feb 2006 15:00:51 -0800, Twigger Simon wrote: > Just to note that I havent done anything yet - so any improvements > you may have noted are not due to anything I did! =) > > I checked and we do have the plugin installed and activated to search > both posts and pages. The pages are going to be things inside > wordpress though and it stores them in the db I believe so Im not > sure that merely being in the filesystem somewhere is going to count. > I'll go on a hunt for something that might address this, I also saw > that wordpress 2 has come out, I'll see what new features that brings > too. > > I see what you mean about the style problem for the search results, > I'll have a stab at improving that. > > S. > > -- > > Simon N. Twigger, Ph.D. > Assistant Professor, Department of Physiology > Medical College of Wisconsin > 8701 Watertown Plank Road, > Milwaukee, WI, USA > tel: 414-456-8802 > fax: 414-456-6595 > AIM/iChat: simontatmcw > > > On Feb 10, 2006, at 1:30 PM, Frank Gibbons wrote: > >> Simon, >> >> That's a big improvement on what we had before. Can we tweak the >> style a >> little though? If I search for "constructing", I get a single >> result, which >> looks like plain text. It's not until I mouse over the heading >> "BioMoby >> Perl Service Providers Tutorial" that I realise it's a link. That's >> becuase >> it's just big bold black text. Is there some way to format the >> results, so >> that the heading comes out as something that's more obviously a link? >> (Color being the usual indicator for a link, my vote would be that it >> follow the style of the other links on the page.) >> >> Great work, >> >> -Frank >> >> >> At 01:43 PM 2/10/2006, you wrote: >>> Hi Mark, >>> >>> I might have missed the first part of this but it should be possible >>> to add in functionality to search static pages too - I did this via a >>> plug-in for one of my own wordpress installations. Im not sure where >>> the CVS_CONTENT folder is in relation to the wordpress file hierarchy >>> but I'll log in and see if I installed the plugin on the MOBY site >>> and if not, I'll add it in and we'll see what happens... >>> >>> Simon. >>> >>> >>> -- >>> >>> Simon N. Twigger, Ph.D. >>> Assistant Professor, Department of Physiology >>> Medical College of Wisconsin >>> 8701 Watertown Plank Road, >>> Milwaukee, WI, USA >>> tel: 414-456-8802 >>> fax: 414-456-6595 >>> AIM/iChat: simontatmcw >>> >>> >>> On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: >>> >>>> I take that back - it does work! However, it only searches through >>>> what >>>> has been "blogged", not through the full content of the site >>>> (i.e. it >>>> excludes what is in the CVS_CONTENT folder) >>>> >>>> I don't know how easy it would be to modify this behaviour, as the >>>> search utility is part of Wordpress... >>>> >>>> M >>>> >>>> >>>> -- >>>> -- >>>> ...his last words were 'Hey guys! Watch this!' >>>> -- >>>> Mark Wilkinson >>>> Asst. Professor >>>> Dept. of Medical Genetics >>>> University of British Columbia >>>> PI in Bioinformatics >>>> iCAPTURE Centre >>>> St. Paul's Hospital >>>> Rm. 166, 1081 Burrard St. >>>> Vancouver, BC, V6Z 1Y6 >>>> tel: 604 682 2344 x62129 >>>> fax: 604 806 9274 >>>> >>>> "For most of this century we have viewed communications as a >>>> conduit, >>>> a pipe between physical locations on the planet. >>>> What's happened now is that the conduit has become so big and >>>> interesting >>>> that communication has become more than a conduit, >>>> it has become a destination in its own right..." >>>> >>>> Paul Saffo - Director, Institute for the Future >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://biomoby.org/mailman/listinfo/moby-dev >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: >> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From simont at hmgc.mcw.edu Mon Feb 13 17:44:40 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Mon, 13 Feb 2006 11:44:40 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> <5EAB1B87-47EF-4861-A519-4CD958B3178E@hmgc.mcw.edu> Message-ID: Hi Mark, I think the content would need to be actually loaded into the wordpress database as that is where it stores the text rather than in flat files. From looking at a local install of the db we'd need to load the HTML into the *_posts table with appropriate meta data to keep the page hierarchy straight and we'd have to deal with redirecting/rewriting hyperlinks from their flat file form to a wordpress URL form. This seems a little messy so I'll keep looking on the wp site to see if anything easier crops up. S. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 11, 2006, at 12:04 AM, Mark Wilkinson wrote: > If we put a symlink in the wordpress folder will it traverse? > > > On Fri, 10 Feb 2006 15:00:51 -0800, Twigger Simon > > wrote: > >> Just to note that I havent done anything yet - so any improvements >> you may have noted are not due to anything I did! =) >> >> I checked and we do have the plugin installed and activated to search >> both posts and pages. The pages are going to be things inside >> wordpress though and it stores them in the db I believe so Im not >> sure that merely being in the filesystem somewhere is going to count. >> I'll go on a hunt for something that might address this, I also saw >> that wordpress 2 has come out, I'll see what new features that brings >> too. >> >> I see what you mean about the style problem for the search results, >> I'll have a stab at improving that. >> >> S. >> >> -- >> >> Simon N. Twigger, Ph.D. >> Assistant Professor, Department of Physiology >> Medical College of Wisconsin >> 8701 Watertown Plank Road, >> Milwaukee, WI, USA >> tel: 414-456-8802 >> fax: 414-456-6595 >> AIM/iChat: simontatmcw >> >> >> On Feb 10, 2006, at 1:30 PM, Frank Gibbons wrote: >> >>> Simon, >>> >>> That's a big improvement on what we had before. Can we tweak the >>> style a >>> little though? If I search for "constructing", I get a single >>> result, which >>> looks like plain text. It's not until I mouse over the heading >>> "BioMoby >>> Perl Service Providers Tutorial" that I realise it's a link. That's >>> becuase >>> it's just big bold black text. Is there some way to format the >>> results, so >>> that the heading comes out as something that's more obviously a >>> link? >>> (Color being the usual indicator for a link, my vote would be >>> that it >>> follow the style of the other links on the page.) >>> >>> Great work, >>> >>> -Frank >>> >>> >>> At 01:43 PM 2/10/2006, you wrote: >>>> Hi Mark, >>>> >>>> I might have missed the first part of this but it should be >>>> possible >>>> to add in functionality to search static pages too - I did this >>>> via a >>>> plug-in for one of my own wordpress installations. Im not sure >>>> where >>>> the CVS_CONTENT folder is in relation to the wordpress file >>>> hierarchy >>>> but I'll log in and see if I installed the plugin on the MOBY site >>>> and if not, I'll add it in and we'll see what happens... >>>> >>>> Simon. >>>> >>>> >>>> -- >>>> >>>> Simon N. Twigger, Ph.D. >>>> Assistant Professor, Department of Physiology >>>> Medical College of Wisconsin >>>> 8701 Watertown Plank Road, >>>> Milwaukee, WI, USA >>>> tel: 414-456-8802 >>>> fax: 414-456-6595 >>>> AIM/iChat: simontatmcw >>>> >>>> >>>> On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: >>>> >>>>> I take that back - it does work! However, it only searches >>>>> through >>>>> what >>>>> has been "blogged", not through the full content of the site >>>>> (i.e. it >>>>> excludes what is in the CVS_CONTENT folder) >>>>> >>>>> I don't know how easy it would be to modify this behaviour, as the >>>>> search utility is part of Wordpress... >>>>> >>>>> M >>>>> >>>>> >>>>> -- >>>>> -- >>>>> ...his last words were 'Hey guys! Watch this!' >>>>> -- >>>>> Mark Wilkinson >>>>> Asst. Professor >>>>> Dept. of Medical Genetics >>>>> University of British Columbia >>>>> PI in Bioinformatics >>>>> iCAPTURE Centre >>>>> St. Paul's Hospital >>>>> Rm. 166, 1081 Burrard St. >>>>> Vancouver, BC, V6Z 1Y6 >>>>> tel: 604 682 2344 x62129 >>>>> fax: 604 806 9274 >>>>> >>>>> "For most of this century we have viewed communications as a >>>>> conduit, >>>>> a pipe between physical locations on the planet. >>>>> What's happened now is that the conduit has become so big and >>>>> interesting >>>>> that communication has become more than a conduit, >>>>> it has become a destination in its own right..." >>>>> >>>>> Paul Saffo - Director, Institute for the Future >>>>> >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev at biomoby.org >>>>> http://biomoby.org/mailman/listinfo/moby-dev >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://biomoby.org/mailman/listinfo/moby-dev >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: >>> 617-432-3557 http://llama.med.harvard.edu/~fgibbons >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Tue Feb 14 15:57:07 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 14 Feb 2006 15:57:07 +0000 (GMT) Subject: [MOBY-dev] non-compliant services Message-ID: I wonder (I forgot it) what was the decision, after the big change regarding not inheriting from primitive types, what to do and when with services that do not comply with the new specification. I think that the discussion was about what to do with old data types, there was even a script to rectify them semi-automatically, but I do not recall what we said about the services. An example is a service getFASTAFromUniprot - a nice, fast, possibly reliable and important service, but it returns something like this: which is, according my limited knowledge wrong (the FASTA should have a String with the value there). Are we going to remove one day such services from a registry? Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Tue Feb 14 17:00:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 14 Feb 2006 09:00:20 -0800 Subject: [MOBY-dev] [moby] non-compliant services In-Reply-To: References: Message-ID: <1139936420.21275.31.camel@bioinfo.icapture.ubc.ca> I see this as the second question of a two-question set, where the first question is "how do we FIND these non-compliant services in the first place?" You and I run across them somewhat randomly, but only because we happen to know what the correct input data would be to get some output from the service in question. (this speaks to the discussion we had at the last meeting about adding sample input/output to the service metadata, but that's beside the point for this discusson). I am entirely in favour of removing these services from the registry, since they only serve to confuse people. I suspect, however, that these services will naturally disappear when we switch on the RDF agent (the delay now is in creating the MOBY Administrative interface that know you and he have been discussing. It's almost done - I wrote it for him yesterday :-) ). Anyone who has not downloaded their RDF is also unlikely to have fixed their services, so they will get culled from the registry. Regardless, we are still left with the question of what to do when you receive an illegally structured object. I think the client should raise a warning, including the service providers email address, but do its best to render the data that it receives. However, I don't think the client should attempt to pass this invalid data on to another service. A clever client might be able to re-format the data to make it right, but that obviously shouldn't be a requirement. It would be great if we could do a registry "purge" at some point in the near future to get rid of the clutter... Certainly, I think we MUST do a purge of "test" services/objects before we publish our respective articles on gbrowse_moby and dashboard, or we will frustrate and confuse the reviewers! M On Tue, 2006-02-14 at 15:57 +0000, Martin Senger wrote: > I wonder (I forgot it) what was the decision, after the big change > regarding not inheriting from primitive types, what to do and when with > services that do not comply with the new specification. I think that the > discussion was about what to do with old data types, there was even a > script to rectify them semi-automatically, but I do not recall what we > said about the services. > An example is a service getFASTAFromUniprot - a nice, fast, possibly > reliable and important service, but it returns something like this: > > xmlns:moby='http://www.biomoby.org/moby' > xmlns='http://www.biomoby.org/moby'> moby:authority='mmb.pcb.ub.es'> > > id='Q7T7Q6'> AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI > SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV > DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF > CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS > NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF > TITFPTGGDGTA > ]]> > > > > which is, according my limited knowledge wrong (the FASTA should have a > String with the value there). > > Are we going to remove one day such services from a registry? > > Cheers, > Martin > -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From akerhornou at imim.es Tue Feb 14 17:28:08 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Tue, 14 Feb 2006 18:28:08 +0100 Subject: [MOBY-dev] non-compliant services In-Reply-To: References: Message-ID: <43F21328.6080701@imim.es> Hi everyone, On this note, I have a service that generates GFF objects, e.g. Is this object correct. If so would taverna (v1.3.1) be affected by the new object specifications ? I have a workflow that connects the output port of a service returning a collection of GFF objects, and feeds a parse_moby_data local processor with this list of simples and when i have GFF objects as above, i get a list of empty objects. Thanks Arnaud Martin Senger wrote: >I wonder (I forgot it) what was the decision, after the big change >regarding not inheriting from primitive types, what to do and when with >services that do not comply with the new specification. I think that the >discussion was about what to do with old data types, there was even a >script to rectify them semi-automatically, but I do not recall what we >said about the services. > An example is a service getFASTAFromUniprot - a nice, fast, possibly >reliable and important service, but it returns something like this: > >xmlns:moby='http://www.biomoby.org/moby' >xmlns='http://www.biomoby.org/moby'>moby:authority='mmb.pcb.ub.es'> > > id='Q7T7Q6'>AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI >SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV >DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF >CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS >NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF >TITFPTGGDGTA >]]> > > > >which is, according my limited knowledge wrong (the FASTA should have a >String with the value there). > > Are we going to remove one day such services from a registry? > > Cheers, > Martin > > > From edward.kawas at gmail.com Tue Feb 14 16:09:13 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 14 Feb 2006 08:09:13 -0800 Subject: [MOBY-dev] non-compliant services In-Reply-To: Message-ID: <000c01c63181$0671eeb0$6500a8c0@notebook> Hi Martin, I don't think that it is possible to weed those services out, because moby just keeps track of service signatures (inputs/outputs, service details, etc). It is up to the provider to structure the service and its logic according to the api. The best that we can do is email the service provider and request that they fix the service. If they don't, the service will ultimately 'remove' itself, since other moby services will not be able to interact with it. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Martin Senger > Sent: Tuesday, February 14, 2006 7:57 AM > To: Moby Developers > Subject: [MOBY-dev] non-compliant services > > I wonder (I forgot it) what was the decision, after the big > change regarding not inheriting from primitive types, what > to do and when with services that do not comply with the new > specification. I think that the discussion was about what to > do with old data types, there was even a script to rectify > them semi-automatically, but I do not recall what we said > about the services. > An example is a service getFASTAFromUniprot - a nice, > fast, possibly reliable and important service, but it returns > something like this: > > xmlns:moby='http://www.biomoby.org/moby' > xmlns='http://www.biomoby.org/moby'> moby:authority='mmb.pcb.ub.es'> > > id='Q7T7Q6'> (Fragment) > AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI > SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV > DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF > CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS > NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF > TITFPTGGDGTA > ]]> > > > > which is, according my limited knowledge wrong (the FASTA > should have a String with the value there). > > Are we going to remove one day such services from a registry? > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From officeparis at yahoo.co.jp Tue Feb 14 17:55:50 2006 From: officeparis at yahoo.co.jp (Kazuo Ishii) Date: Wed, 15 Feb 2006 02:55:50 +0900 (JST) Subject: [MOBY-dev] (no subject) Message-ID: <20060214175550.39642.qmail@web2812.mail.bbt.yahoo.co.jp> -------------------------------------- GANBARE! NIPPON! Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE PARTNER http://pr.mail.yahoo.co.jp/ganbare-nippon/ From edward.kawas at gmail.com Tue Feb 14 17:44:10 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 14 Feb 2006 09:44:10 -0800 Subject: [MOBY-dev] non-compliant services In-Reply-To: <43F21328.6080701@imim.es> Message-ID: <000d01c6318e$48b709b0$6500a8c0@notebook> Hi, Can you send me the workflow and example inputs? BTW, the xml looks fine to me. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Arnaud Kerhornou > Sent: Tuesday, February 14, 2006 9:28 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] non-compliant services > > Hi everyone, > > On this note, I have a service that generates GFF objects, e.g. > > > ENSBTAG00000014911 MatScan I$HSF_01 490 494 > 4.99 > - . # AGAAG > ENSBTAG00000014911 MatScan I$HSF_01 487 491 > 5.48 > - . # AGAAA > ]]> > > > > Is this object correct. If so would taverna (v1.3.1) be > affected by the new object specifications ? > > I have a workflow that connects the output port of a service > returning a collection of GFF objects, and feeds a > parse_moby_data local processor with this list of simples and > when i have GFF objects as above, i get a list of empty objects. > > Thanks > Arnaud > > Martin Senger wrote: > > >I wonder (I forgot it) what was the decision, after the big change > >regarding not inheriting from primitive types, what to do and when > >with services that do not comply with the new specification. I think > >that the discussion was about what to do with old data > types, there was > >even a script to rectify them semi-automatically, but I do > not recall > >what we said about the services. > > An example is a service getFASTAFromUniprot - a nice, > fast, possibly > >reliable and important service, but it returns something like this: > > > > >xmlns:moby='http://www.biomoby.org/moby' > >xmlns='http://www.biomoby.org/moby'> >moby:authority='mmb.pcb.ub.es'> > > > > >id='Q7T7Q6'> >AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI > >SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV > >DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF > >CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS > >NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF > >TITFPTGGDGTA > >]]> > > > > > > > >which is, according my limited knowledge wrong (the FASTA > should have a > >String with the value there). > > > > Are we going to remove one day such services from a registry? > > > > Cheers, > > Martin > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From akerhornou at imim.es Tue Feb 14 18:39:25 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Tue, 14 Feb 2006 19:39:25 +0100 Subject: [MOBY-dev] non-compliant services In-Reply-To: <000d01c6318e$48b709b0$6500a8c0@notebook> References: <000d01c6318e$48b709b0$6500a8c0@notebook> Message-ID: <43F223DD.5070708@imim.es> Hi Eddie, See files attached, Thanks for looking at it, Arnaud Edward Kawas wrote: >Hi, > >Can you send me the workflow and example inputs? > >BTW, the xml looks fine to me. > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces at biomoby.org >>[mailto:moby-dev-bounces at biomoby.org] On Behalf Of Arnaud Kerhornou >>Sent: Tuesday, February 14, 2006 9:28 AM >>To: Core developer announcements >>Subject: Re: [MOBY-dev] non-compliant services >> >>Hi everyone, >> >>On this note, I have a service that generates GFF objects, e.g. >> >> >> > ENSBTAG00000014911 MatScan I$HSF_01 490 494 >> 4.99 >>- . # AGAAG >> ENSBTAG00000014911 MatScan I$HSF_01 487 491 >> 5.48 >>- . # AGAAA >> ]]> >> >> >> >>Is this object correct. If so would taverna (v1.3.1) be >>affected by the new object specifications ? >> >>I have a workflow that connects the output port of a service >>returning a collection of GFF objects, and feeds a >>parse_moby_data local processor with this list of simples and >>when i have GFF objects as above, i get a list of empty objects. >> >>Thanks >>Arnaud >> >>Martin Senger wrote: >> >> >> >>>I wonder (I forgot it) what was the decision, after the big change >>>regarding not inheriting from primitive types, what to do and when >>>with services that do not comply with the new specification. I think >>>that the discussion was about what to do with old data >>> >>> >>types, there was >> >> >>>even a script to rectify them semi-automatically, but I do >>> >>> >>not recall >> >> >>>what we said about the services. >>> An example is a service getFASTAFromUniprot - a nice, >>> >>> >>fast, possibly >> >> >>>reliable and important service, but it returns something like this: >>> >>>>>xmlns:moby='http://www.biomoby.org/moby' >>>xmlns='http://www.biomoby.org/moby'>>>moby:authority='mmb.pcb.ub.es'> >>> >>> >>id='Q7T7Q6'>>>AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI >>>SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV >>>DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF >>>CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS >>>NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF >>>TITFPTGGDGTA >>>]]> >>> >>> >>> >>>which is, according my limited knowledge wrong (the FASTA >>> >>> >>should have a >> >> >>>String with the value there). >>> >>> Are we going to remove one day such services from a registry? >>> >>> Cheers, >>> Martin >>> >>> >>> >>> >>> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PromoterAnalysisWorkflow_coexpressedGenesMode_MEME_Mode_Fasta_Version.xml Type: text/xml Size: 15899 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ENSG00000174697.orthologs.500.fa.xml Type: text/xml Size: 6955 bytes Desc: not available URL: From senger at ebi.ac.uk Wed Feb 15 11:00:52 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 15 Feb 2006 11:00:52 +0000 (GMT) Subject: [MOBY-dev] [moby] non-compliant services In-Reply-To: <1139936420.21275.31.camel@bioinfo.icapture.ubc.ca> Message-ID: > I see this as the second question of a two-question set, where the first > question is "how do we FIND these non-compliant services in the first > place?" > Correct. > You and I run across them somewhat randomly > Yes - but if it happens, what is the policy? Should I informe Eddie, or you to inform the contact, or should I send her/him myself an email? Both is fine with me. But what happen when there is no reaction? Are you willing to remove such service (after some waiting period)? > I am entirely in favour of removing these services from the registry, > since they only serve to confuse people. > Good, my question answered. And I second it. > Anyone who has not downloaded their RDF is also unlikely to have fixed > their services, so they will get culled from the registry. > That I would not be so sure. I surely will suggest GCP service providers to wait quite long before starting to register their services with the RDF URL. We need to trust first that an agent can come at once (within seconds, I mean) when we call it - otherwise will will rather take a risk to be unregistered by a malicious person. For that reasons, we already started to put scripts that can help with fast re-registration if a need comes. > Regardless, we are still left with the question of what to do when you > receive an illegally structured object. I think the client should raise > a warning > Well, that's an additional effort in client development. I understand your point, and I will try to help to make such clever clients, but I do not feel that is my priority. I would just stick with the policy tht I asked for/about above... > It would be great if we could do a registry "purge" at some point in the > near future to get rid of the clutter... > ...and the wrong CSHL objects :-) > Certainly, I think we MUST do a purge of "test" services/objects > before we publish our respective articles on gbrowse_moby and > dashboard, or we will frustrate and confuse the reviewers! > Agree! BTW, let me know when the time is coming and you need something from me for hese articles... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Wed Feb 15 20:37:04 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 15 Feb 2006 15:37:04 -0500 Subject: [MOBY-dev] Fwd: Re: [MOBY-l] error when do make test Message-ID: <5.2.1.1.2.20060215153638.021bad50@email.med.harvard.edu> Mark, it looks like DBD::mysql is now required (see Nicholas's email below), because of MOBY::OntologyServer.pm, is that right? I see that the constructor new() tries to instantiate a connection to a remote DB. If it's a requirement, then I'll put it into the Makefile.PL, otherwise perhaps there's a way we could find a work-around for users who don't have it installed. -Frank At 02:13 PM 2/15/2006, you wrote: >Hello, > >I just downloaded the biomoby tarball from the CVS reprository >(http://cvs.open-bio.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=biomoby), and >tried to install it here to my system. > >So I went to moby/moby-live/Perl folder, and do "perl Makefile.PL >PREFIX=/MyInstallationFolder". >Then, I do make. > >But it seems that it's failing when i did the make test. >I copied and pasted the error message in the bottom of this email. > >Do you guys can give me any clue why this happen? Maybe I miss something? > >I did the same thing with the latest code release version (09/16/2004).., >but it >seems I can install it without this problem. > > >Thanks a lot, >Nicholas. > > >alhagib 86 % make test >PERL_DL_NONLAZY=1 /p/perl/bin/perl "-MExtUtils::Command::MM" "-e" >"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t >t/Central...................................# Failed test (t/Central.t at >line 26) ># Tried to use 'MOBY::Central'. >t/Central...................................NOK 1# Error: Can't locate >DBD/mysql.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >line 70. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >line 70. PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Wed Feb 15 22:34:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 15 Feb 2006 14:34:53 -0800 Subject: [MOBY-dev] Fwd: Re: [MOBY-l] error when do make test In-Reply-To: <5.2.1.1.2.20060215153638.021bad50@email.med.harvard.edu> References: <5.2.1.1.2.20060215153638.021bad50@email.med.harvard.edu> Message-ID: Hmmmm.... that's a tricky one. DBD::mysql should not be required if the person is running MOBY as a client only, but it is required when running it as a Registry. I don't think that MOBY::OntologyServer is used client-side either. AFAIK MOBY::Client::OntologyServer is used by the client software. The upshot is that people not running a registry do not need to successfully load the MOBY::Central module, or the MOBY::OntologyServer module, so the first test (Central.t) should not be run for these cases. Thus, DBD::mysql is also not a requirement in these cases. M On Wed, 15 Feb 2006 12:37:04 -0800, Frank Gibbons wrote: > Mark, > > it looks like DBD::mysql is now required (see Nicholas's email below), > because of MOBY::OntologyServer.pm, is that right? I see that the > constructor new() tries to instantiate a connection to a remote DB. If > it's a requirement, then I'll put it into the Makefile.PL, otherwise > perhaps there's a way we could find a work-around for users who don't > have it installed. > > -Frank > > At 02:13 PM 2/15/2006, you wrote: >> Hello, >> >> I just downloaded the biomoby tarball from the CVS reprository >> (http://cvs.open-bio.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=biomoby), >> and >> tried to install it here to my system. >> >> So I went to moby/moby-live/Perl folder, and do "perl Makefile.PL >> PREFIX=/MyInstallationFolder". >> Then, I do make. >> >> But it seems that it's failing when i did the make test. >> I copied and pasted the error message in the bottom of this email. >> >> Do you guys can give me any clue why this happen? Maybe I miss >> something? >> >> I did the same thing with the latest code release version >> (09/16/2004).., but it >> seems I can install it without this problem. >> >> >> Thanks a lot, >> Nicholas. >> >> >> alhagib 86 % make test >> PERL_DL_NONLAZY=1 /p/perl/bin/perl "-MExtUtils::Command::MM" "-e" >> "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t >> t/Central...................................# Failed test >> (t/Central.t at >> line 26) >> # Tried to use 'MOBY::Central'. >> t/Central...................................NOK 1# Error: Can't >> locate >> DBD/mysql.pm in @INC (@INC contains: >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >> /p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/5.8.4 >> /p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/site_perl/5.8.4 >> /p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >> /p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/5.8.4 >> /p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >> /p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >> line 70. >> # BEGIN failed--compilation aborted at >> /.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >> line 70. > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From senger at ebi.ac.uk Thu Feb 16 03:05:43 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 16 Feb 2006 03:05:43 +0000 (GMT) Subject: [MOBY-dev] Fwd: Re: [MOBY-l] error when do make test In-Reply-To: Message-ID: > person is running MOBY as a client only, but it is required when running > it as a Registry > This reminds me: the main biomoby page should either not to have "get code" at all (because it is confusing what code is meant), or should have (preferrably) sublist of code for registry, perl user. java users etc. I can provide the link for 'gettting Java code' (it would be: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/Download.html). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Thu Feb 16 15:22:30 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 16 Feb 2006 10:22:30 -0500 Subject: [MOBY-dev] [MOBY-l] error when do make test In-Reply-To: <1140030803.43f37d537d852@webmail.purdue.edu> References: <000f01c63253$26985670$6500a8c0@notebook> <000f01c63253$26985670$6500a8c0@notebook> Message-ID: <5.2.1.1.2.20060216102036.01226e38@email.med.harvard.edu> Nicholas, I've edited the Makefile.PL to tell you if you're missing certain modules. I've also modified the tests, so that if you are simply missing the database-connection modules, it explains the situation better. You might want to do 'cvs update' in moby-live/Perl to get these changes, then do 'perl Makefile.PL PREFIX=....' and 'make test'. Hope that helps, -F At 02:13 PM 2/15/2006, you wrote: >Hello, > >I just downloaded the biomoby tarball from the CVS reprository >(http://cvs.open-bio.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=biomoby), and >tried to install it here to my system. > >So I went to moby/moby-live/Perl folder, and do "perl Makefile.PL >PREFIX=/MyInstallationFolder". >Then, I do make. > >But it seems that it's failing when i did the make test. >I copied and pasted the error message in the bottom of this email. > >Do you guys can give me any clue why this happen? Maybe I miss something? > >I did the same thing with the latest code release version (09/16/2004).., >but it >seems I can install it without this problem. > > >Thanks a lot, >Nicholas. > > >alhagib 86 % make test >PERL_DL_NONLAZY=1 /p/perl/bin/perl "-MExtUtils::Command::MM" "-e" >"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t >t/Central...................................# Failed test (t/Central.t at >line 26) ># Tried to use 'MOBY::Central'. >t/Central...................................NOK 1# Error: Can't locate >DBD/mysql.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >line 70. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/OntologyServer.pm >line 70. ># Compilation failed in require at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/Central.pm >line 14. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/Central.pm >line 14. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/Central.t at line 57) >t/Central...................................NOK 2# >MOBY::Central->can('Registration') failed ># MOBY::Central->can('registerObjectClass') failed ># MOBY::Central->can('_registerObjectPayload') failed ># MOBY::Central->can('deregisterObjectClass') failed ># MOBY::Central->can('_deregisterObjectPayload') failed ># MOBY::Central->can('_testObjectTypeAgainstPrimitives') failed ># MOBY::Central->can('registerServiceType') failed ># MOBY::Central->can('_registerServiceTypePayload') failed ># MOBY::Central->can('deregisterServiceType') failed ># MOBY::Central->can('_deregisterServiceTypePayload') failed ># MOBY::Central->can('retrieveNamespaces') failed ># MOBY::Central->can('_registerNamespacePayload') failed ># MOBY::Central->can('deregisterNamespace') failed ># MOBY::Central->can('_deregisterNamespacePayload') failed ># MOBY::Central->can('registerService') failed ># MOBY::Central->can('_registerServicePayload') failed ># MOBY::Central->can('_getServiceInstanceRDF') failed ># MOBY::Central->can('_registerArticles') failed ># MOBY::Central->can('deregisterService') failed ># MOBY::Central->can('_deregisterServicePayload') failed ># MOBY::Central->can('findService') failed ># MOBY::Central->can('_findServicePayload') failed ># MOBY::Central->can('_extractObjectTypes') failed ># MOBY::Central->can('registerServiceWSDL') failed ># MOBY::Central->can('_extract_ids') failed ># MOBY::Central->can('_searchForServicesWithArticle') failed ># MOBY::Central->can('_searchForSimple') failed ># MOBY::Central->can('_searchForCollection') failed ># MOBY::Central->can('_extractObjectTypesAndNamespaces') failed ># MOBY::Central->can('retrieveService') failed ># MOBY::Central->can('_retrieveServicePayload') failed ># MOBY::Central->can('retrieveResourceURLs') failed ># MOBY::Central->can('retrieveServiceProviders') failed ># MOBY::Central->can('retrieveServiceNames') failed ># MOBY::Central->can('retrieveServiceTypes') failed ># MOBY::Central->can('retrieveRelationshipTypes') failed ># MOBY::Central->can('retrieveObjectNames') failed ># MOBY::Central->can('retrieveObjectDefinition') failed ># MOBY::Central->can('retrieveNamespaces') failed ># MOBY::Central->can('retrieveObject') failed ># MOBY::Central->can('_retrieveObjectPayload') failed ># MOBY::Central->can('Relationships') failed ># MOBY::Central->can('DUMP_MySQL') failed ># MOBY::Central->can('_ISAPayload') failed ># MOBY::Central failed to implement full API ># Looks like you failed 2 tests of 2. >t/Central...................................dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/Client-Central............................ok >t/Client-CollectionArticle..................ok >t/Client-OntologyServer.....................ok >t/Client-Registration.......................ok >t/Client-SecondaryArticle...................ok >t/Client-Service............................ok >t/Client-ServiceInstance....................ok >t/Client-SimpleArticle......................ok >t/CommonSubs................................ok >t/Config....................................skipped > all skipped: Required only for local MOBY Central >t/CrossReference............................ok >t/dbConnect.................................# Failed test >(t/dbConnect.t at >line 18) ># Tried to use 'MOBY::lsid::authority::dbConnect'. >t/dbConnect.................................NOK 1# Error: Can't locate >DBD/mysql.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/dbConnect.pm >line 17. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/dbConnect.pm >line 17. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/dbConnect.t at line 25) ># MOBY::lsid::authority::dbConnect->can('dbConnect') failed ># API not correctly implemented >t/dbConnect.................................NOK 2# Looks like you failed 2 >tests >of 2. >t/dbConnect.................................dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/lsid-authority-ClassResolver..............# Failed test >(t/lsid-authority-ClassResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::ClassResolver'. >t/lsid-authority-ClassResolver..............NOK 1# Error: Can't locate >XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/ClassResolver.pm >line 5. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/ClassResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/lsid-authority-ClassResolver.t at line 25) ># MOBY::lsid::authority::ClassResolver->can('resolve_classtype') failed ># Didn't implement full API >t/lsid-authority-ClassResolver..............NOK 2# Looks like you failed 2 >tests >of 2. >t/lsid-authority-ClassResolver..............dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/lsid-authority-dbConnect..................# Failed test >(t/lsid-authority-dbConnect.t at line 18) >t/lsid-authority-dbConnect..................NOK 1# Tried to use >'MOBY::lsid::authority::dbConnect'. ># Error: Can't locate DBD/mysql.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/dbConnect.pm >line 17. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/dbConnect.pm >line 17. ># Compilation failed in require at (eval 1) line 2. ># Looks like you failed 1 tests of 1. >t/lsid-authority-dbConnect..................dubious > Test returned status 1 (wstat 256, 0x100) >DIED. FAILED test 1 > Failed 1/1 tests, 0.00% okay >t/lsid-authority-Error......................ok >t/lsid-authority-NamespaceResolver..........# Failed test >(t/lsid-authority-NamespaceResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::NamespaceResolver'. ># Error: Can't locate XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/NamespaceResolver.pm >line 5. >t/lsid-authority-NamespaceResolver..........NOK 1# BEGIN failed--compilation >aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/NamespaceResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/lsid-authority-NamespaceResolver.t at line 25) ># >MOBY::lsid::authority::NamespaceResolver->can('resolve_namespacetype') failed ># NamespaceResolver didn't implement API correctly ># Looks like you failed 2 tests of 2. >t/lsid-authority-NamespaceResolver..........dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/lsid-authority-PredicateResolver..........# Failed test >(t/lsid-authority-PredicateResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::PredicateResolver'. ># Error: Can't locate XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/PredicateResolver.pm >line 5. >t/lsid-authority-PredicateResolver..........NOK 1# BEGIN failed--compilation >aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/PredicateResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Looks like you failed 1 tests of 1. >t/lsid-authority-PredicateResolver..........dubious > Test returned status 1 (wstat 256, 0x100) >DIED. FAILED test 1 > Failed 1/1 tests, 0.00% okay >t/lsid-authority-RDFConfigure...............ok >t/lsid-authority-RelationshipResolver.......# Failed test >(t/lsid-authority-RelationshipResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::RelationshipResolver'. >t/lsid-authority-RelationshipResolver.......NOK 1# Error: Can't locate >XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/RelationshipResolver.pm >line 5. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/RelationshipResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Failed test (t/lsid-authority-RelationshipResolver.t at line 25) ># >MOBY::lsid::authority::RelationshipResolver->can('resolve_relationshiptype') >failed ># RelationshipResolver didn't implement full API >t/lsid-authority-RelationshipResolver.......NOK 2# Looks like you failed 2 >tests >of 2. >t/lsid-authority-RelationshipResolver.......dubious > Test returned status 2 (wstat 512, 0x200) >DIED. FAILED tests 1-2 > Failed 2/2 tests, 0.00% okay >t/lsid-authority-ServiceInstanceResolver....skipped > all skipped: Skip until apparent namespace pollution fixed in >ServiceInstanceResolver >t/lsid-authority-ServiceResolver............# Failed test >(t/lsid-authority-ServiceResolver.t at line 18) ># Tried to use 'MOBY::lsid::authority::ServiceResolver'. >t/lsid-authority-ServiceResolver............NOK 1# Error: Can't locate >XML/DOM.pm in @INC (@INC contains: >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/arch >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/perl/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl . >/p/perl-5.8.4/lib/5.8.4/sun4-solaris-thread-multi /p/perl-5.8.4/lib/5.8.4 >/p/perl-5.8.4/lib/site_perl/5.8.4/sun4-solaris-thread-multi >/p/perl-5.8.4/lib/site_perl/5.8.4 /p/perl-5.8.4/lib/site_perl .) at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/ServiceResolver.pm >line 5. ># BEGIN failed--compilation aborted at >/.ulphius/p29/www-cgi/cgi-bin/nsutanto/moby/moby-live/Perl/blib/lib/MOBY/lsid/authority/ServiceResolver.pm >line 5. ># Compilation failed in require at (eval 1) line 2. ># Looks like you failed 1 tests of 1. >t/lsid-authority-ServiceResolver............dubious > Test returned status 1 (wstat 256, 0x100) >DIED. FAILED test 1 > Failed 1/1 tests, 0.00% okay >t/Template..................................skipped > all skipped: This is just a template >Failed Test Stat Wstat Total Fail Failed List of >Failed >------------------------------------------------------------------------------- >t/Central.t 2 512 2 2 100.00% 1-2 >t/dbConnect.t 2 512 2 2 100.00% 1-2 >t/lsid-authority-ClassResolver.t 2 512 2 2 100.00% 1-2 >t/lsid-authority-NamespaceResolve 2 512 2 2 100.00% 1-2 >t/lsid-authority-PredicateResolve 1 256 1 1 100.00% 1 >t/lsid-authority-RelationshipReso 2 512 2 2 100.00% 1-2 >t/lsid-authority-ServiceResolver. 1 256 1 1 100.00% 1 >t/lsid-authority-dbConnect.t 1 256 1 1 100.00% 1 >3 tests skipped. >Failed 8/23 test scripts, 65.22% okay. 13/380 subtests failed, 96.58% okay. >*** Error code 29 >make: Fatal error: Command failed for target `test_dynamic' > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Feb 16 17:58:23 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 09:58:23 -0800 Subject: [MOBY-dev] Cleaning out the registry Message-ID: <1140112703.28350.46.camel@bioinfo.icapture.ubc.ca> Hi All, As you have read, Martin and I are discussing the problem of cleaning up the registry. Though MOBY was not intended to be curated per se, it isThere are four kinds of "bad" services in the registry right now: 1) Services that are registered using some form of the word "test" in their service name, service type, object name, and or namespace. 2) Services that do not work at all - 404 errors, or other clear indications that the service is simply dead. 3) Services that return invalid data-types (according to the recent revision of the Object ontology). 4) Services that may function perfectly well, but have been registered entirely incorrectly (e.g. require plain-text input, but have been registered as accepting base Object a input). There are a HUGE number of these in there, and they are quite annoying... Regarding (1) and (2): The main public registry is not intended to be a laboratory, nor a lavatory! I intend to remove these nuisance services without any warning unless someone strongly objects and has a good reason for objecting... even so, as the host of my instance of the registry, I feel it is within my jurisdiction to do my best to keep it clean and make it useful, so the objection will have to be VERY good... Regarding (3): Martin and I discussed this on-list the other day, and I think it is appropriate that we contact the service provider as we discover these errors, and if the service provider doesn't fix the error in a reasonable time, then we delete the service. At some point this will become automated, when we begin adding sample input and output data to the Service Instance RDF (an RFC will be sent to the list in a few weeks relating to this) Regarding (4): I am loathe to fix the registration parameters of other people's service, even in cases where the correct registration parameters are obvious, because I don't want to become a full-time curator of the Registry. It is also important to not change them because I don't know what tools that service provider may have that are relying on that service signature (even if it is wrong). Moreover, it is important that service providers see their errors, and understand why they are errors, such that their future registrations are correct. Of course, tools like Dashboard are going to make this all a piece of cake, but in the meantime, I will be contacting service providers about services that are obviously registered incorrectly, and I encourage others to do the same :-) However, I will not touch these services. Please send comments ASAP, since I am about to submit a manuscript where the reviewers will be using the registry, and I want to get it cleaned- up as quickly as possible! Best wishes all! Mark -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Feb 16 18:06:22 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 10:06:22 -0800 Subject: [MOBY-dev] [moby] Cleaning out the registry In-Reply-To: <1140112703.28350.46.camel@bioinfo.icapture.ubc.ca> References: <1140112703.28350.46.camel@bioinfo.icapture.ubc.ca> Message-ID: <1140113182.28350.50.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-02-16 at 09:58 -0800, Mark Wilkinson wrote: > As you have read, Martin and I are discussing the problem of cleaning up > the registry. Though MOBY was not intended to be curated per se, it > isThere are four kinds of "bad" services in the registry right now: I didn't finish my sentence there - I mean to say "it is becoming so cluttered as to be almost unusable for some tasks." M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Feb 16 18:28:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 10:28:20 -0800 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object Message-ID: <1140114500.28350.70.camel@bioinfo.icapture.ubc.ca> Hi again, On a related note: There are obviously other "rubbish" entities in the Object ontology, and I will not feel guilty for removing those either. However, just as in the service instance registry, there are some Objects in the ontology that are not "rubbish", but do not reflect best-practices (yes, I know... this has to be defined somewhere in writing, and it is not at the moment...). Martin, Richard and I had a (heated :-) ) discussion about one of these "best practices" over Christmas, and I don't think we came to a resolution, so I don't want to take any preemptive action. I'd prefer to have the discussion in the open community such that (a) we all learn a little bit about the various ways that MOBY can be used/mis-used, and (b) so that we can, as a community, decide what the definition of "mis- used" is going be. Here is my position statement - please feel free to attack it or support it: Statement: Any Object that is registered as deriving from base Object, without any HAS or HASA relationships, should be considered invalid. Rationale: Base "Object" is used exclusively for passing identifiers. Extending base Object, without making it more complex, can only (IMO) indicate that you are attempting to create a specific type of identifier container. This is the role of the Namespace (the Namespace ontology being a list of types of identifiers, and their meanings). It is incorrect use of the Object (syntax) ontology to imply that a given Syntax is specific to a particular type of identifier. The Object and Namespace ontologies are mutually exclusive. My proposal: The Registry should trap attempts to register Objects that derive from base Object without any additional syntactic complexity, and refuse to register them. Thoughts? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Feb 17 00:19:08 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 00:19:08 +0000 (GMT) Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <1140114500.28350.70.camel@bioinfo.icapture.ubc.ca> Message-ID: > Here is my position statement - please feel free to attack it or support > it: > I am not going to attack it, and I am far away from supporting it. > Statement: Any Object that is registered as deriving from base Object, > without any HAS or HASA relationships, should be considered invalid. > My position is clear here, and without any heat in my heart (my heart has already burned in the pre-xmas discussion you mentioned) I just state that this is unacceptable for me. > My proposal: The Registry should trap attempts to register Objects that > derive from base Object without any additional syntactic complexity, and > refuse to register them. > Which would mean (IMO), at least, to loose quite a chunk of Biomoby users and developers. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 17 00:34:01 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 16:34:01 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: <1140136441.28350.139.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-17 at 00:19 +0000, Martin Senger wrote: > My position is clear here, and without any heat in my heart (my heart > has already burned in the pre-xmas discussion you mentioned) I just state > that this is unacceptable for me. I made the argument from my perspective, but I'd like your counter- argument to be known and clearly understood by the community. The two approaches to the use of the MOBY Object ontology are not entirely interoperable with each other, so it is important for everyone two know why they might want to chose one philosophy or the other before making a decision on how to construct their services. but you will feel no heat from me either :-) Only respectful discussion and (perhaps) disagreement. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Feb 17 02:53:04 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 02:53:04 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <1140136441.28350.139.camel@bioinfo.icapture.ubc.ca> Message-ID: > I made the argument from my perspective, but I'd like your counter- > argument to be known and clearly understood by the community. > Okay, here we go: * I prefer to have semantics (if I accept that they can be any semantics in computers) in the object names because they have mechanism of inheritance and containment - while namespaces do not. * I made my decision also because of the lack of description how to use namespaces at all (it was never documented). > The two approaches to the use of the MOBY Object ontology are not > entirely interoperable with each other > I think they are, I do not see any harm to have both concepts sitting in the same registry. My bottom line is: This is not a question that we need to agree on (like asynchonous API or error handling - which *must* be accepted by any service). I would rather advocate the principle "live and let live". But you are right that we should to explain about the concepts we decided to take - especially for newcomers. We have it available in the GCP CropWiki (and if it is not yet fully up-to-date it will be in the due time). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Feb 17 03:02:37 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 03:02:37 +0000 (GMT) Subject: [MOBY-dev] Cleaning out the registry In-Reply-To: <1140112703.28350.46.camel@bioinfo.icapture.ubc.ca> Message-ID: > Please send comments ASAP, since I am about to submit a manuscript where > I agree with the approach you suggested. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 17 03:56:09 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 16 Feb 2006 19:56:09 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: On Thu, 16 Feb 2006 18:53:04 -0800, Martin Senger wrote: > * I prefer to have semantics (if I accept that they can be any > semantics in computers) in the object names because they have mechanism > of inheritance and containment - while namespaces do not. Could we find common ground if we made an API change that resulted in the Namespace ontology being hierarchical rather than flat? If I understand the problem you are trying to solve, this would make a significant difference - but would it make *enough* difference that you wouldn't have to create more specific types of simple Objects? You have thought through your solution from beginning to end, and I haven't, so I don't want to presume. Though I agree that the "live and let live" solution doesn't do anyone any harm, it would enhance interoperability if we were all using the same philosophy to build the objects that we are supposed to be sharing... M From Pieter.Neerincx at wur.nl Fri Feb 17 10:32:36 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 17 Feb 2006 11:32:36 +0100 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> Hi all, I'm with Martin here. I have quite a few Objects that inherit from the base Object without having any HAS or HASA relationships. Most of them are very generic things like for example "Program", "DataBase" and "User". They can have different IDs and have different namespaces depending on the service they are used for. And the namespace alone is not enough. Within the same namespace I can have multiple things which are only an ID, but one pointing to a user and another pointing to a program and I think it's to be able to see the difference directly from the name of the element instead of adding all kind of child elements that only cause more overhead in XML parsing. Just my ? 2c, Pi On 17-Feb-2006, at 1:19 AM, Martin Senger wrote: >> Here is my position statement - please feel free to attack it or >> support >> it: >> > I am not going to attack it, and I am far away from supporting it. > >> Statement: Any Object that is registered as deriving from base >> Object, >> without any HAS or HASA relationships, should be considered invalid. >> > My position is clear here, and without any heat in my heart (my > heart > has already burned in the pre-xmas discussion you mentioned) I just > state > that this is unacceptable for me. > >> My proposal: The Registry should trap attempts to register >> Objects that >> derive from base Object without any additional syntactic >> complexity, and >> refuse to register them. >> > Which would mean (IMO), at least, to loose quite a chunk of Biomoby > users and developers. > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Feb 17 14:12:35 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 17 Feb 2006 15:12:35 +0100 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> Message-ID: <68287F71-664B-405C-B27D-0EA9104BA744@wur.nl> On 17-Feb-2006, at 11:32 AM, Pieter Neerincx wrote: Oops missed an essential word there: > Within the same namespace I can have multiple things > which are only an ID, but one pointing to a user and another pointing > to a program and I think it's *GOOD* to be able to see the difference > directly from the name of the element instead of adding all kind of > child elements that only cause more overhead in XML parsing. > From francis_gibbons at hms.harvard.edu Fri Feb 17 14:19:35 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 17 Feb 2006 09:19:35 -0500 Subject: [MOBY-dev] Fwd: Re: Fwd: Re: [MOBY-l] error when do make test Message-ID: <5.2.1.1.2.20060217091459.011b2de0@email.med.harvard.edu> > > > > Sorry, I should have checked before asking... I did not know that > it is > > >about CVS, I thought that it is for Mark's Perl magics. > > > > OK - well, I was going to offer to make some links on this page, but it's > > not under CVS, so Mark or Simon will have to do it. > > > I have checked again - and I see that actually I was right! The link to >"Latest Code Release" is only to the package with Perl, there is no Java >at all. So it is very confusing... I think we should separate it to to >links (the java would be the one I gave you: >http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/CVS.html). Martin, You're quite right - I had confused the "Getting the code" in the main field on that page, with "Latest code release", in tiny text in the sidebar on the right-hand side of the page. Yes, it points only to Perl releases. I'd like to help, but don't have access to that page - it's one of the few top-level pages that are not under CVS control. As Documentation Guy I guess it would fall to me to fix this, but I don't have access to that particular page. Mark - what's the best solution here, I see three possibilities: 1. You make the changes, as Martin requests. 2. I gain access to the webserver, and make the changes 3. (my favourite) the entire website goes into CVS, and changes can be made by any developer. If you're worried about security, only developers will be able to check in changes, and we can always roll things back if undesirable changes get made. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Fri Feb 17 14:28:40 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 14:28:40 +0000 (GMT) Subject: [MOBY-dev] Fwd: Re: Fwd: Re: [MOBY-l] error when do make test In-Reply-To: <5.2.1.1.2.20060217091459.011b2de0@email.med.harvard.edu> Message-ID: Frank, Many thanks for help and involvement. It is good that you are managing docs. It is not an easy task... > 3. (my favourite) the entire website goes into CVS, and changes can be made > by any developer > I strongly second this option. "Open-source" and "Open-content" are similar in a sense that both concepts should be supported by us... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From simont at hmgc.mcw.edu Fri Feb 17 16:10:49 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Fri, 17 Feb 2006 10:10:49 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> References: <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> Message-ID: Hi Frank, I tweaked the style sheet for the search results so now the headers are in the same blue as the other links and if you mouse over they go a little darker and have an underline - same as the other links on the page. Hopefully this should make things a little easier to follow, let me know what you think. Cheers, Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 10, 2006, at 1:30 PM, Frank Gibbons wrote: > Simon, > > That's a big improvement on what we had before. Can we tweak the > style a > little though? If I search for "constructing", I get a single > result, which > looks like plain text. It's not until I mouse over the heading > "BioMoby > Perl Service Providers Tutorial" that I realise it's a link. That's > becuase > it's just big bold black text. Is there some way to format the > results, so > that the heading comes out as something that's more obviously a link? > (Color being the usual indicator for a link, my vote would be that it > follow the style of the other links on the page.) > > Great work, > > -Frank > > > At 01:43 PM 2/10/2006, you wrote: >> Hi Mark, >> >> I might have missed the first part of this but it should be possible >> to add in functionality to search static pages too - I did this via a >> plug-in for one of my own wordpress installations. Im not sure where >> the CVS_CONTENT folder is in relation to the wordpress file hierarchy >> but I'll log in and see if I installed the plugin on the MOBY site >> and if not, I'll add it in and we'll see what happens... >> >> Simon. >> >> >> -- >> >> Simon N. Twigger, Ph.D. >> Assistant Professor, Department of Physiology >> Medical College of Wisconsin >> 8701 Watertown Plank Road, >> Milwaukee, WI, USA >> tel: 414-456-8802 >> fax: 414-456-6595 >> AIM/iChat: simontatmcw >> >> >> On Feb 10, 2006, at 11:32 AM, Mark Wilkinson wrote: >> >>> I take that back - it does work! However, it only searches through >>> what >>> has been "blogged", not through the full content of the site >>> (i.e. it >>> excludes what is in the CVS_CONTENT folder) >>> >>> I don't know how easy it would be to modify this behaviour, as the >>> search utility is part of Wordpress... >>> >>> M >>> >>> >>> -- >>> -- >>> ...his last words were 'Hey guys! Watch this!' >>> -- >>> Mark Wilkinson >>> Asst. Professor >>> Dept. of Medical Genetics >>> University of British Columbia >>> PI in Bioinformatics >>> iCAPTURE Centre >>> St. Paul's Hospital >>> Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "For most of this century we have viewed communications as a >>> conduit, >>> a pipe between physical locations on the planet. >>> What's happened now is that the conduit has become so big and >>> interesting >>> that communication has become more than a conduit, >>> it has become a destination in its own right..." >>> >>> Paul Saffo - Director, Institute for the Future >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Fri Feb 17 16:28:14 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 17 Feb 2006 09:28:14 -0700 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> Message-ID: <43F5F99E.8090609@ucalgary.ca> I support Martin's position, but would add a caveat: since we are all sharing the same ontology, it would be nice if no one hogged the generic words like "Person" and "DataBase" if they are specific to their services instead of generic objects representing any Person or DataBase. Perhaps DutchPerson or DutchDatabase in your app Pieter? Well maybe not, but you get the idea... :-) 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. I think proper namespace restriction in service registration is a bigger issue than people creating new name-only ontology objects... My CAN $0.02. >Hi all, > >I'm with Martin here. I have quite a few Objects that inherit from >the base Object without having any HAS or HASA relationships. Most of >them are very generic things like for example "Program", "DataBase" >and "User". They can have different IDs and have different namespaces >depending on the service they are used for. And the namespace alone >is not enough. Within the same namespace I can have multiple things >which are only an ID, but one pointing to a user and another pointing >to a program and I think it's to be able to see the difference >directly from the name of the element instead of adding all kind of >child elements that only cause more overhead in XML parsing. > >Just my ? 2c, > >Pi > >On 17-Feb-2006, at 1:19 AM, Martin Senger wrote: > > > >>>Here is my position statement - please feel free to attack it or >>>support >>>it: >>> >>> >>> >> I am not going to attack it, and I am far away from supporting it. >> >> >> >>>Statement: Any Object that is registered as deriving from base >>>Object, >>>without any HAS or HASA relationships, should be considered invalid. >>> >>> >>> >> My position is clear here, and without any heat in my heart (my >>heart >>has already burned in the pre-xmas discussion you mentioned) I just >>state >>that this is unacceptable for me. >> >> >> >>>My proposal: The Registry should trap attempts to register >>>Objects that >>>derive from base Object without any additional syntactic >>>complexity, and >>>refuse to register them. >>> >>> >>> >> Which would mean (IMO), at least, to loose quite a chunk of Biomoby >>users and developers. >> >> Martin >> >>-- >>Martin Senger >> email: martin.senger at gmail.com >> skype: martinsenger >>consulting for: >> International Rice Research Institute >> Biometrics and Bioinformatics Unit >> DAPO BOX 7777, Metro Manila >> Philippines, phone: +63-2-580-5600 (ext.2324) >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev >> >> > > >Wageningen University and Research centre (WUR) >Laboratory of Bioinformatics >Transitorium (building 312) room 1034 >Dreijenlaan 3 >6703 HA Wageningen >The Netherlands >phone: 0317-483 060 >fax: 0317-483 584 >mobile: 06-143 66 783 >pieter.neerincx at wur.nl > > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev > > From simont at hmgc.mcw.edu Fri Feb 17 17:01:56 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Fri, 17 Feb 2006 11:01:56 -0600 Subject: [MOBY-dev] the Search function on biomoby.org In-Reply-To: <5.2.1.1.2.20060217115136.022246f8@email.med.harvard.edu> References: <5.2.1.1.2.20060217113413.0219f938@email.med.harvard.edu> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <1139592758.12961.52.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060210142609.021d80e8@email.med.harvard.edu> <5.2.1.1.2.20060217113413.0219f938@email.med.harvard.edu> <5.2.1.1.2.20060217115136.022246f8@email.med.harvard.edu> Message-ID: The 404 search problem should be fixed now too. I hard coded the search URL to point to the top level page so now it works everywhere rather than having the subdirectory path added in. Im not sure that I'm not messing up some functionality - maybe it was meant to search only within a particular set of pages... Anyway, it wasn't working before and now at least it will search as expected. I have the same problem on all my other wordpress sites now I look at them. Perhaps upgrading to v2 will fix some of these things. Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Feb 17, 2006, at 10:51 AM, Frank Gibbons wrote: > Yeah, reloading did the trick - nice! > > -Frank > > At 11:47 AM 2/17/2006, you wrote: >> Try reloading the page and the style sheet changes should kick in. I >> had the same observation when I made the changes initially. >> >> I see what you mean about the search problem - the URL for the search >> script is incorrect on these other pages, I'll see what I can do to >> fix that. >> >> S. >> >> -- >> >> Simon N. Twigger, Ph.D. >> Assistant Professor, Department of Physiology >> Medical College of Wisconsin >> 8701 Watertown Plank Road, >> Milwaukee, WI, USA >> tel: 414-456-8802 >> fax: 414-456-6595 >> AIM/iChat: simontatmcw >> >> > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 http:// > llama.med.harvard.edu/~fgibbons From markw at illuminae.com Fri Feb 17 17:07:36 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 17 Feb 2006 09:07:36 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <43F5F99E.8090609@ucalgary.ca> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> <43F5F99E.8090609@ucalgary.ca> Message-ID: <1140196056.32702.29.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-17 at 09:28 -0700, Paul Gordon wrote: > object without dying a horrible death. I think proper namespace > restriction in service registration is a bigger issue than people > creating new name-only ontology objects... I agree, and I believe that much of this confusion is happening because: 1) My fault - insufficient documentation of what the namespace *means* in MOBY. It's discussed in publications and such, but not discussed clearly in the tutorials. 2) My fault - the Namespaces have been modelled incorrectly (IMO) right from the start as a flat list, because of our need (or at least desire) to be compatible with the GO community. I think this has to change - we either have to break away from them again, or better, bring them with us. Either way, we need to allow for hierarchical namespaces such that people do not need to mix the semantics of what an object represents (the Namespace) with the syntax of how it is represented (the Object) The short-term gain that people are observing by creating domain- specific Objects is just that - short term gain. It is not an extensible solution, since it leads to a combinatorial explosion of data-types: Object DatabaseObject GenbankObject GenbankSequence GenbankDNASequence GenbankAASequence EMBLObject EMBLSequence EMBLDNASequence EMBLAASequence PDBObject PDBSequence etc. etc. From the Rectorian ontology-philosophy, this is a perfect example of the "exploding bicycle", and the end result is well documented and disasterous! Even in that example, there would be no way to discover a Blast service that operated on GenericSequence objects if you had a GenbankDNASequence object in-hand. I **desperately** want to solve this problem. The discussion over the past couple of days has revealed that there is a serious need for a rapid solution since several of our key users are already starting down this path. I maintain that the solution is NOT to generate domain-specific objects, but rather to model the orthogonal Namespace ontology properly, and facilitate hierarchical searching over Namespaces in the registry, such that creating these mixed objects is no longer necessary. If I am understanding correctly the reason why people are creating these objects, then this srikes me as being the Right Thing to do. Am I mis-interpreting the problem? If so, please explain it to me. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From rebecca.ernst at gsf.de Fri Feb 17 16:42:55 2006 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Fri, 17 Feb 2006 17:42:55 +0100 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> Message-ID: <43F5FD0F.9000903@gsf.de> Hi all! I go with Mark in this discussion. If, like Pieter explained here, one ID is pointing to a user and another to a program this should be specified in the namespace. Like namespace_user and namespace_program. I usually compare the namespace/id principle with phonenumbers. If someone tells you his phonenumber '77345' this is not sufficient but together with a namespace 'area-code' this is a valid pair of information. If I get it right Pieter and Martin want is a namespace 'City' which can then be used for objects 'phonenumber', 'citycode', 'adress', etc. I believe that this is not what namespaces (and objects) are meant to be. Cheers, Rebecca Pieter Neerincx wrote: >Hi all, > >I'm with Martin here. I have quite a few Objects that inherit from >the base Object without having any HAS or HASA relationships. Most of >them are very generic things like for example "Program", "DataBase" >and "User". They can have different IDs and have different namespaces >depending on the service they are used for. And the namespace alone >is not enough. Within the same namespace I can have multiple things >which are only an ID, but one pointing to a user and another pointing >to a program and I think it's to be able to see the difference >directly from the name of the element instead of adding all kind of >child elements that only cause more overhead in XML parsing. > >Just my ? 2c, > >Pi > >On 17-Feb-2006, at 1:19 AM, Martin Senger wrote: > > > >>>Here is my position statement - please feel free to attack it or >>>support >>>it: >>> >>> >>> >> I am not going to attack it, and I am far away from supporting it. >> >> >> >>>Statement: Any Object that is registered as deriving from base >>>Object, >>>without any HAS or HASA relationships, should be considered invalid. >>> >>> >>> >> My position is clear here, and without any heat in my heart (my >>heart >>has already burned in the pre-xmas discussion you mentioned) I just >>state >>that this is unacceptable for me. >> >> >> >>>My proposal: The Registry should trap attempts to register >>>Objects that >>>derive from base Object without any additional syntactic >>>complexity, and >>>refuse to register them. >>> >>> >>> >> Which would mean (IMO), at least, to loose quite a chunk of Biomoby >>users and developers. >> >> Martin >> >>-- >>Martin Senger >> email: martin.senger at gmail.com >> skype: martinsenger >>consulting for: >> International Rice Research Institute >> Biometrics and Bioinformatics Unit >> DAPO BOX 7777, Metro Manila >> Philippines, phone: +63-2-580-5600 (ext.2324) >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev >> >> > > >Wageningen University and Research centre (WUR) >Laboratory of Bioinformatics >Transitorium (building 312) room 1034 >Dreijenlaan 3 >6703 HA Wageningen >The Netherlands >phone: 0317-483 060 >fax: 0317-483 584 >mobile: 06-143 66 783 >pieter.neerincx at wur.nl > > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From senger at ebi.ac.uk Fri Feb 17 17:21:31 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 17:21:31 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <1140196056.32702.29.camel@bioinfo.icapture.ubc.ca> Message-ID: > Am I mis-interpreting the problem? If so, please explain it to me. > Yes, you are. The problem is that you want to remove things from registry if you do not like how they are created. If our objects will not be easy discoverable, fine, our decision. And you can make your objects as good as you wish. You are mixing subjects: "what to allow" and "what to recommend". Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 17 17:46:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 17 Feb 2006 09:46:53 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: <1140198413.32702.65.camel@bioinfo.icapture.ubc.ca> I don't want to remove things from the registry! I want to find a solution to the problem you are experiencing that also enhances the interoperability between your services and the services of others - this is clearly of mutual benefit. For your objects to not be easily discovered is, of course, entirely your business... but wouldn't it be better if they were? M On Fri, 2006-02-17 at 17:21 +0000, Martin Senger wrote: > > Am I mis-interpreting the problem? If so, please explain it to me. > > > Yes, you are. The problem is that you want to remove things from > registry if you do not like how they are created. If our objects will not > be easy discoverable, fine, our decision. And you can make your objects as > good as you wish. You are mixing subjects: "what to allow" and "what to > recommend". > > Martin > -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Feb 17 17:52:31 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 17 Feb 2006 17:52:31 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <1140198413.32702.65.camel@bioinfo.icapture.ubc.ca> Message-ID: > I don't want to remove things from the registry! > Good. So my problem is solved :-) > others - this is clearly of mutual benefit. For your objects to not be > easily discovered is, of course, entirely your business... but wouldn't > it be better if they were? > Of course. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 17 19:25:26 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 17 Feb 2006 11:25:26 -0800 Subject: [MOBY-dev] New website parts of the CVS Message-ID: <1140204326.754.19.camel@bioinfo.icapture.ubc.ca> Hi all, Responding to the discussion of a misleading link to "code releases" there are now three links in the right panel of the homepage: 1) Code releases -> moby-live/Docs/ProjectDocs/Releases 2) General Docs -> moby-live/Docs/ProjectDocs 3) CVS Repository -> view.cgi CVS viewer v.v. editing the website in general: The website is not run as a dictatorship - anyone who wants to be able to edit the Wordpress pages is welcome to ask Simon for a password - however to put the entire website into the CVS is just begging to return to the state we were in before where the pages are hard to maintain and generally unstyled and "ugly". We get a LOT of benefit from having the core pages under Wordpress, and Simon put a lot of effort into setting this up. I don't see the need to throw the baby out with the bathwater for the sake of giving an appearance of openness that, in fact, already exists. I would prefer that we thank Simon for his efforts and work within the framework that he has set up for us, rather than against it. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Sat Feb 18 14:50:04 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 18 Feb 2006 14:50:04 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: Message-ID: Mark, Do I understand correctly that you have started to remove some services from the registry? (I may be wrong - perhaps my services diaappeared from a different reasons.) If it is true, you probably also removed services that had URL pointing to the localhost. This may seem correct, but it is not. It is true that such services cannot be used by other users, but they had been there as part of tutorial - for service developers that *have* these sample services on their local machines. Could you clarify what steps (if any) have you taken? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Sun Feb 19 17:47:32 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sun, 19 Feb 2006 18:47:32 +0100 Subject: [MOBY-dev] Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: <43F5F99E.8090609@ucalgary.ca> References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> <43F5F99E.8090609@ucalgary.ca> Message-ID: On 17Feb2006, at 17:28, Paul Gordon wrote: > I support Martin's position, but would add a caveat: since we are all > sharing the same ontology, it would be nice if no one hogged the > generic > words like "Person" and "DataBase" if they are specific to their > services instead of generic objects representing any Person or > DataBase. Perhaps DutchPerson or DutchDatabase in your app Pieter? > Well maybe not, but you get the idea... :-) Don't worry, I realize that the power of the ontology is the level of recycle-ability of objects. If everybody designs yet another object specific to their services, building workflows will be just as difficult with as without ontology. Therefore a "DataBase" or "User" object should be generic. If I need some kind of specialized "DutchBase" object specific for a certain service I'll create a new one that inherits from the "base" DataBase object and/or I'll restrict the namespaces. > > 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. I think proper namespace > restriction in service registration is a bigger issue than people > creating new name-only ontology objects... You are absolutely right! Add to that dead services and improper registered services and it can be pretty difficult for BioMOBY newbies to find some working workflow examples. > > My CAN $0.02. Looks like we could use a BioMOBY currency converter service :) Pi > >> Hi all, >> >> I'm with Martin here. I have quite a few Objects that inherit from >> the base Object without having any HAS or HASA relationships. Most of >> them are very generic things like for example "Program", "DataBase" >> and "User". They can have different IDs and have different namespaces >> depending on the service they are used for. And the namespace alone >> is not enough. Within the same namespace I can have multiple things >> which are only an ID, but one pointing to a user and another pointing >> to a program and I think it's to be able to see the difference >> directly from the name of the element instead of adding all kind of >> child elements that only cause more overhead in XML parsing. >> >> Just my ? 2c, >> >> Pi >> >> On 17-Feb-2006, at 1:19 AM, Martin Senger wrote: >> >> >> >>>> Here is my position statement - please feel free to attack it or >>>> support >>>> it: >>>> >>>> >>>> >>> I am not going to attack it, and I am far away from supporting it. >>> >>> >>> >>>> Statement: Any Object that is registered as deriving from base >>>> Object, >>>> without any HAS or HASA relationships, should be considered >>>> invalid. >>>> >>>> >>>> >>> My position is clear here, and without any heat in my heart (my >>> heart >>> has already burned in the pre-xmas discussion you mentioned) I just >>> state >>> that this is unacceptable for me. >>> >>> >>> >>>> My proposal: The Registry should trap attempts to register >>>> Objects that >>>> derive from base Object without any additional syntactic >>>> complexity, and >>>> refuse to register them. >>>> >>>> >>>> >>> Which would mean (IMO), at least, to loose quite a chunk of >>> Biomoby >>> users and developers. >>> >>> Martin >>> >>> -- >>> Martin Senger >>> email: martin.senger at gmail.com >>> skype: martinsenger >>> consulting for: >>> International Rice Research Institute >>> Biometrics and Bioinformatics Unit >>> DAPO BOX 7777, Metro Manila >>> Philippines, phone: +63-2-580-5600 (ext.2324) >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Sun Feb 19 19:09:57 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 19 Feb 2006 19:09:57 +0000 (GMT) Subject: [MOBY-dev] New website parts of the CVS In-Reply-To: Message-ID: > > 2) General Docs -> moby-live/Docs/ProjectDocs > > > Actually, I do not know how to put things there. I have 'cvs update', then edited moby-live/Docs/ProjectDocs/index.html, committed, then run my cronjob on biomoby.org in order to update docs, but nothing changed on the page http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/ProjectDocs/ (where the link you created points to). Where is the problem? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Feb 20 06:03:59 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 20 Feb 2006 06:03:59 +0000 (GMT) Subject: [MOBY-dev] biomoby.org down? Message-ID: Is this just my local problem? My browser connects, but then is "waiting for biomoby.org" indefinitely... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Feb 20 14:36:47 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 20 Feb 2006 06:36:47 -0800 Subject: [MOBY-dev] biomoby.org down? In-Reply-To: References: Message-ID: Looks like it is failing DNS lookup. I'll tell Chris. M On Sun, 19 Feb 2006 22:03:59 -0800, Martin Senger wrote: > Is this just my local problem? My browser connects, but then is "waiting > for biomoby.org" indefinitely... > > Martin > From edward.kawas at gmail.com Mon Feb 20 15:28:18 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 20 Feb 2006 07:28:18 -0800 Subject: [MOBY-dev] biomoby.org down? In-Reply-To: Message-ID: <000701c63632$47424d30$6b00a8c0@notebook> I think it's a local problem, I can browse biomoby.org without a cache. Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Martin Senger > Sent: Sunday, February 19, 2006 10:04 PM > To: Mark Wilkinson > Cc: Moby Developers > Subject: [MOBY-dev] biomoby.org down? > > Is this just my local problem? My browser connects, but then > is "waiting for biomoby.org" indefinitely... > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Feb 20 16:16:45 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 20 Feb 2006 08:16:45 -0800 Subject: [MOBY-dev] [moby] Re: New website parts of the CVS In-Reply-To: References: Message-ID: <1140452205.19091.7.camel@bioinfo.icapture.ubc.ca> It seems you have solved this problem - the page loads as edited. Correct? M On Sun, 2006-02-19 at 19:09 +0000, Martin Senger wrote: > > > 2) General Docs -> moby-live/Docs/ProjectDocs > > > > > > Actually, I do not know how to put things there. I have 'cvs update', > then edited moby-live/Docs/ProjectDocs/index.html, committed, then run my > cronjob on biomoby.org in order to update docs, but nothing changed on the > page http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/ProjectDocs/ > (where the link you created points to). > Where is the problem? > > Martin > -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Mon Feb 20 16:18:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 20 Feb 2006 08:18:10 -0800 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: <8F68C19D-7A7E-4B11-B4AF-E7DFC7893AEE@wur.nl> <43F5F99E.8090609@ucalgary.ca> Message-ID: <1140452290.19091.9.camel@bioinfo.icapture.ubc.ca> On Sun, 2006-02-19 at 18:47 +0100, Pieter Neerincx wrote: > > My CAN $0.02. > > Looks like we could use a BioMOBY currency converter service :) Yes... if we all want to go bankrupt! ;-) M From edward.kawas at gmail.com Mon Feb 20 20:42:38 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 20 Feb 2006 12:42:38 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks Message-ID: <000301c6365e$30fe3670$9d66a8c0@notebook> Hi, The RDF agent that we have heard so much about will begin 'crawling' in 2 weeks starting Monday March 6, 2006. As a service provider, your only task will be to generate one or more RDF documents describing your service(s) and to place that document somewhere reachable from the outside world. If you no longer wish to host that service, then removing its description from the document will effectively deregister the service. The place to obtain your service RDF is from the following url: http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm This page will update your service signature URL location. In 2 weeks, the agent will start removing services that do not have a signature url specified for it. The agent is also configured to remove any service that fails to uphold to the latest API, as specified on biomoby.org. Specifically, the agent is looking for un-named inputs or outputs (i.e. simples or collections without article names). However, if a service was modified, then the agent will use the API to re-register it and if the service was invalid for other reasons, the registry will reject that particular service. In 2 weeks, the agent will attempt to read from the signature url that you provided. If the agent cannot read from the url on 3 (maybe more or less - details will be revealed later) different consecutive occasions, then the agent will remove all services described by that url. The agent will then, depending on configuration, email the service provider and detail what happened to cause their service deregistration. If the deregistration was in error, service providers will be able to reregister their services very easily. Contained in the email message to the provider is RDF-XML that describes the last known footprint of their service. Using this RDF-XML, and a tool to be released soon, you can re-register your service in any registry. As a service provider, you are free to add any valid RDF statements to your document. At the very least, the document must contain statements with predicates found at http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/moby_me tadata. All other statements are ignored by the agent. If you end up modifying the RDF-XML, and you want to verify that the XML is valid, you could always use the following tool to validate and visualize your RDF document: http://www.w3.org/RDF/Validator/. If you are new to RDF and you do make changes to the document, it's highly recommended to check your document with this tool. A common error is placing multiple tags within a single file. This is not allowed and will result in parsing errors. This error is usually achieved by downloading multiple RDF documents and then placing the contents of each document into one document. Those of you that wish to consolidate RDF documents should consolidate the contents between the tags. All questions and concerns regarding this agent should be posted to the list so that they can be discussed amongst us all. Thanks, Eddie From senger at ebi.ac.uk Tue Feb 21 00:52:34 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 00:52:34 +0000 (GMT) Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000301c6365e$30fe3670$9d66a8c0@notebook> Message-ID: Eddie, I have not seen an answer to the most pertinent question that we always had about the RDF agent: How can we ask it to come? And how often does it come if we do not ask? And please do not tell me that I cannot ask - if that would be the case, please do not start it yet. > In 2 weeks, the agent will start removing services that do not have a > signature url specified for it. > I strongy oppose this - and I said it several times. Please do not do that. It was never said that services must have the signature URL - it was always said that services without such signature are vulnerable to be remove by some malicious guys. But a mandatory existence of such signature URL has never been in the Biomoby API, and if you do what you are saying, it is breaking API without consulting us/users. It is related to the question above: if I have a way to ask an agent to come at once (by at once I mean in seconds) I am not afraid to put signature url in the service. If not, I cannot edit my service anymore and I am not willing to put there the signature. > In 2 weeks, the agent will attempt to read from the signature url that you > provided. If the agent cannot read from the url on 3 (maybe more or less - > details will be revealed later) different consecutive occasions, then the > agent will remove all services described by that url. > Again, this should not be done so rigidly. I simply need, for example, few services, that are registered to the localhost (so they will never be used by reasonably clever clients) but they are used in tutorials, and they can be used when a service is being developed (so it can be called via registry by its author, because she has the service on her local machine). There will never be many of such services, but they should stay. I also do not like your wording "details will be revealed later". This sounds like a typical dictatorship. > If the deregistration was in error, service providers will be able to > reregister their services very easily. Contained in the email message to the > provider is RDF-XML that describes the last known footprint of their > service. Using this RDF-XML, and a tool to be released soon, you can > re-register your service in any registry. > This is a home-made addition to the Biomoby API - we have never discussed it. We need a way that can be automatized - so if I need to react to the email message, I need to know first exact format of such email etc. This is doable but needs to be discussed. > All questions and concerns regarding this agent should be posted to the list > so that they can be discussed amongst us all. > Thanks, that's encouraging. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 21 00:53:46 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 00:53:46 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: New website parts of the CVS In-Reply-To: <1140452205.19091.7.camel@bioinfo.icapture.ubc.ca> Message-ID: > It seems you have solved this problem - the page loads as edited. > Correct? > Yes, problem solved - but I do not know how. Well, it is there now... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 21 08:33:50 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 08:33:50 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: Message-ID: > Could we find common ground if we made an API change that resulted in the > Namespace ontology being hierarchical rather than flat? If I understand > the problem you are trying to solve, this would make a significant > difference - but would it make *enough* difference that you wouldn't have > to create more specific types of simple Objects? > Honestly, I do not know. I even do not fully understand your "combinatorial explosion", and - mainly - why it would not happen with a hierarchy and inheritance within namespaces? That would also mean that we would have two trees, one (roughly speaking) describing syntax (data type tree) and one describing semantics (namapsce tree). That would not be easy to explain, maintain and use... I am tempted to say that I wuold still use data types to express how a reality is related, and I would use namespaces as an additional information - where I would welcome less flat alternative. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Tue Feb 21 14:31:20 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 21 Feb 2006 09:31:20 -0500 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: References: <000301c6365e$30fe3670$9d66a8c0@notebook> Message-ID: <5.2.1.1.2.20060221091746.0110f008@email.med.harvard.edu> Eddie, Mark, Martin, & others, I have to second Martin's comments below. We tried this RDF agent once before, and some of us dutifully followed the link provided to create the RDF, and we placed it in the appropriate spot. Then we found that the agent never came, and we could no longer remove our services at all! I propose that you start the agent before we convert our services - I'd like to see the agent come and visit a few times before I hand over control of my services to it. So I think we need to know the two very specific things that Martin mentions: how often will it come, and how do we ask it to come? The policies don't have to be set in stone, but we need to know what is proposed, and to agree upon it. In particular, for people who are developing services, there has to be a way to cause a service to be registered within a short time (I would propose less than 60 seconds). I'd like to have a dry run, in which I ask the agent to come, and then - hey presto! - there it is, within the required interval. It wouldn't have to do anything, just come over and say 'hi'. As to his second point (that use of RDF-document is now mandatory for services to be considered registered), I also agree: there should at least be some kind of grandfather-clause. People who want the extra security of being able to guarantee that their service will remain registered until they take down the RDF document, should be able to do that; but others, who simply wish to register by function-call should also be able to use that. Is there a reason that both systems cannot coexist? I understand the necessity of cleaning up the registry, and wonder if that is driving this decision on mandatory-RDF, since it would automatically clear out the abandoned services. At the very least (and I contradict myself here), there could be a phase-out/in period, during which services registered under the old system can remain, but all new services must be created using RDF. Then after three (?) months, such old services might be retired - or perhaps kept on indefinitely. They would be the _only_ services which would continue to be deregistered using the function-call syntax - all new registrations would have to use RDF. -F At 07:52 PM 2/20/2006, you wrote: > I have not seen an answer to the most pertinent question that we always >had about the RDF agent: How can we ask it to come? And how often does it >come if we do not ask? > And please do not tell me that I cannot ask - if that would be the >case, please do not start it yet. > > > In 2 weeks, the agent will start removing services that do not have a > > signature url specified for it. > > > I strongy oppose this - and I said it several times. Please do not >do that. It was never said that services must have the signature URL - it >was always said that services without such signature are vulnerable to be >remove by some malicious guys. But a mandatory existence of such signature >URL has never been in the Biomoby API, and if you do what you are saying, >it is breaking API without consulting us/users. PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Tue Feb 21 15:01:13 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 15:01:13 +0000 (GMT) Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000601c636f5$74fea250$6500a8c0@notebook> Message-ID: > I am going to create a test registry soon and you (and everyone else) > can use this registry for these types of services. > I think that a selected authority (in my case net.jmoby.samples) is good enough not to confuse people - and I prefer to use a real registry when I am teching how to use it. Why the address 'localhost' would cause any problems? Every client, including your code in taverna, can easily ignore these services and not to show them... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Feb 21 15:21:10 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Feb 2006 15:21:10 +0000 (GMT) Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000701c636f9$32d2a4e0$6500a8c0@notebook> Message-ID: Thanks for your answer. I am a bit reluctant to contiue with this argument because this is relatively mior issue, comparing to other points I made. Just one more perhaps: > people what moby is, or how to use it when 90% of the services don?t > really 'work'. > If the localhost services will be there and everything else will work, the percentage will be close to 1%. See it in perspective :-) > Sure I can write a client that ignores certain authorities, > but I am not worried about me. > I am - because most people see moby through client you or Mark wrote - so if you two ignore these services, everybody wins. But this is insignificant comparing to the dungeon you two are preparing for us with secret agents :-) [This was a joke, really.] Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Tue Feb 21 15:12:13 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 21 Feb 2006 07:12:13 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: Message-ID: <000701c636f9$32d2a4e0$6500a8c0@notebook> > > > I am going to create a test registry soon and you (and > everyone else) > > can use this registry for these types of services. > > > I think that a selected authority (in my case > net.jmoby.samples) is good enough not to confuse people - and > I prefer to use a real registry when I am teching how to use > it. Why the address 'localhost' would cause any problems? > Every client, including your code in taverna, can easily > ignore these services and not to show them... Using localhost doesn?t cause any problems, and you are right about clients being able to ignore them. My *personal* opinion is that if some na?ve user comes and wants to try out moby and they encounter services that they would like to use, but they are all localhost or point to some unreachable domain, they would probably become frustrated and leave moby alone. The main registry should contain real services. It is very frustrating trying to show people what moby is, or how to use it when 90% of the services don?t really 'work'. Sure I can write a client that ignores certain authorities, but I am not worried about me. Anyways, this is just my opinion. I thought that I would create a test registry so that others could benefit from it without feeling like the main registry was the only place they had to register their test services. Ed > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > From edward.kawas at gmail.com Tue Feb 21 14:45:26 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 21 Feb 2006 06:45:26 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: Message-ID: <000601c636f5$74fea250$6500a8c0@notebook> Hi Martin, > Eddie, > I have not seen an answer to the most pertinent question > that we always had about the RDF agent: How can we ask it to > come? And how often does it come if we do not ask? > And please do not tell me that I cannot ask - if that > would be the case, please do not start it yet. You can indeed call the agent over to visit your signature url. Performing a register service call and only providing the url will cause the agent to visit you right away. > > In 2 weeks, the agent will attempt to read from the > signature url that > > you provided. If the agent cannot read from the url on 3 > (maybe more > > or less - details will be revealed later) different consecutive > > occasions, then the agent will remove all services > described by that url. > > > Again, this should not be done so rigidly. I simply need, > for example, few services, that are registered to the > localhost (so they will never be used by reasonably clever > clients) but they are used in tutorials, and they can be used > when a service is being developed (so it can be called via > registry by its author, because she has the service on her > local machine). There will never be many of such services, > but they should stay. > I also do not like your wording "details will be revealed > later". This sounds like a typical dictatorship. I am going to create a test registry soon and you (and everyone else) can use this registry for these types of services. I personally think that the main registry should not be used for testing, but until we have a real test registry running production code I understand that there may be no other choice. So details to be revealed later meant that I would consult for an appropriate number of times that the agent should have to visit someone before declaring the url invalid. > > If the deregistration was in error, service providers will > be able to > > reregister their services very easily. Contained in the > email message > > to the provider is RDF-XML that describes the last known > footprint of > > their service. Using this RDF-XML, and a tool to be > released soon, you > > can re-register your service in any registry. > > > This is a home-made addition to the Biomoby API - we have > never discussed it. We need a way that can be automatized - > so if I need to react to the email message, I need to know > first exact format of such email etc. This is doable but > needs to be discussed. > You are right, this can be automated. I have created classes that parse RDF into MobyService objects and then using the api, you can register them very easily. As for the message, the rdf is appended to the body of the message. Feel free to ask me more. > > All questions and concerns regarding this agent should be posted to > > the list so that they can be discussed amongst us all. > > > Thanks, that's encouraging. > Martin > Eddie > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > From edward.kawas at gmail.com Tue Feb 21 16:34:58 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 21 Feb 2006 08:34:58 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <5.2.1.1.2.20060221091746.0110f008@email.med.harvard.edu> Message-ID: <000c01c63704$c78c5ee0$6500a8c0@notebook> Hi Frank, > I have to second Martin's comments below. We tried this RDF > agent once before, and some of us dutifully followed the link > provided to create the RDF, and we placed it in the > appropriate spot. Then we found that the agent never came, > and we could no longer remove our services at all! I propose > that you start the agent before we convert our services - I'd > like to see the agent come and visit a few times before I > hand over control of my services to it. This is kind of a chicken and the egg problem. The agent can't visit unless it knows who to visit. It can't know who to visit unless providers convert their services... :-) > So I think we need to know the two very specific things that Martin > mentions: how often will it come, and how do we ask it to > come? The policies don't have to be set in stone, but we need > to know what is proposed, and to agree upon it. In > particular, for people who are developing services, there has > to be a way to cause a service to be registered within a > short time (I would propose less than 60 seconds). I'd like > to have a dry run, in which I ask the agent to come, and then > - hey presto! - there it is, within the required interval. It > wouldn't have to do anything, just come over and say 'hi'. So currently, it is up to the administrator of a registry to set how often the agent would run, if at all, (easily be placed on a cron job). As for manually calling it, right now it can be called by performing a registerService call and only providing the signatureURL. Manually calling it should cause the agent to come instantly. Eddie From francis_gibbons at hms.harvard.edu Tue Feb 21 17:08:41 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 21 Feb 2006 12:08:41 -0500 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000c01c63704$c78c5ee0$6500a8c0@notebook> References: <5.2.1.1.2.20060221091746.0110f008@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> Hi Eddie, At 11:34 AM 2/21/2006, you wrote: >This is kind of a chicken and the egg problem. The agent can't >visit unless it knows who to visit. It can't know who to visit >unless providers convert their services... :-) OK, I understand that it can't make a _routine_ visit unless it knows who to visit. But it should still be possible to call it, even if I haven't registered at all. Perhaps you could set up a form where I could put in my URL, click 'submit' , and then watch my web-logs to see if it comes. Perhaps better yet would be if you could provide some generic RDF, with no service-specific information, which would simply allow the agent to visit, and verify that it can read the RDF. It could then email me that it was able to read this "test RDF" on my site. Who knows, there might be problems not with the agent, but with my local configuration, and it would be nice to be able to verify that the whole infrastructure was working correctly, without complicating it with details of my services. I'm just worried about going through a bunch of trouble to get ready for the agent, and then some unforeseen problem crops up (at either end), and the agent's deployment is delayed by 6 weeks, and in the meantime, I'm unable to change my services. I'm not denigrating the agent, I just have recent personal (painful!) experience of how difficult it can be to debug things "over the wire". -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From edward.kawas at gmail.com Tue Feb 21 17:16:34 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 21 Feb 2006 09:16:34 -0800 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> Message-ID: <000d01c6370a$9236bfa0$6500a8c0@notebook> > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Frank Gibbons > Sent: Tuesday, February 21, 2006 9:09 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Notice that the ever elusive agent > will start curating in 2 weeks > > Hi Eddie, > > At 11:34 AM 2/21/2006, you wrote: > >This is kind of a chicken and the egg problem. The agent can't visit > >unless it knows who to visit. It can't know who to visit unless > >providers convert their services... :-) > > OK, I understand that it can't make a _routine_ visit unless > it knows who to visit. But it should still be possible to > call it, even if I haven't registered at all. Perhaps you > could set up a form where I could put in my URL, click > 'submit' , and then watch my web-logs to see if it comes. > Perhaps better yet would be if you could provide some generic > RDF, with no service-specific information, which would simply > allow the agent to visit, and verify that it can read the > RDF. It could then email me that it was able to read this > "test RDF" on my site. Who knows, there might be problems not > with the agent, but with my local configuration, and it would > be nice to be able to verify that the whole infrastructure > was working correctly, without complicating it with details > of my services. This sounds doable. I will create a form that contains a field for a url and an email address. The agent will then parse the rdf located at the url and email the address entered into the form with the details of what it found. Probably, email is not necessary and I could just output to the browser what the agent found. What do you think? > > I'm just worried about going through a bunch of trouble to > get ready for the agent, and then some unforeseen problem > crops up (at either end), and the agent's deployment is > delayed by 6 weeks, and in the meantime, I'm unable to change > my services. I'm not denigrating the agent, I just have > recent personal (painful!) experience of how difficult it can > be to debug things "over the wire". I understand your concerns completely. Eddie > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston > MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From francis_gibbons at hms.harvard.edu Tue Feb 21 17:40:54 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 21 Feb 2006 12:40:54 -0500 Subject: [MOBY-dev] Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <000d01c6370a$9236bfa0$6500a8c0@notebook> References: <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060221123804.0120ea58@email.med.harvard.edu> At 12:16 PM 2/21/2006, you wrote: >This sounds doable. I will create a form that contains a field > for a url and an email address. The agent will then parse the >rdf located at the url and email the address entered into the > form with the details of what it found. Probably, email is not > necessary and I could just output to the browser what the agent >found. What do you think? Hey Eddie, Yeah, you're right email is probably not necessary, but otherwise it sounds good. I guess I was thinking asynchronously, but if the agent can respond quickly, output to the browser would be fine. Since this would just test the functionality, independent of any services, it would be useful if you could provide an RDF stub - correctly formed, but without meaningful content - so a user could verify that all is well. (Mark, did you do something like this last time? I remember the form, just not whether you provided the stub RDF.) Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Feb 21 18:11:42 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 21 Feb 2006 10:11:42 -0800 Subject: [MOBY-dev] [moby] Re: Notice that the ever elusive agent will start curating in 2 weeks In-Reply-To: <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> References: <5.2.1.1.2.20060221091746.0110f008@email.med.harvard.edu> <5.2.1.1.2.20060221120240.01224170@email.med.harvard.edu> Message-ID: <1140545502.30116.36.camel@bioinfo.icapture.ubc.ca> I suppose I should wade in here, though Eddie is doing a great job of making the case :-) Here are my thoughts on the issue, in no particular order: * I would support the proposal to extend the duration over which the agent "visits" but does not de-register. Three months seems reasonable, maybe longer if we discover problems. * The Agent idea has been the most protracted API change we have ever had. The "guts" of the API change were made almost a year ago, the discussions about it have been going on for longer than that, and the registry API has been behaving as if the agent were functional for at least that long (e.g. not being able to deregister services that had a Signature URL). As such, the switch to an agent-based curation system should not come as any surprise, and we should not over-react to it. The changes are not that large given that the API as it exists has already accommodated them, and primarily give us benefit more than they cause barriers. * The move to an RDF signature-based system is an ENORMOUS benefit to us - and we have all agreed on that in previous meetings. It allows us, as service providers, to add additional metadata about our services, and perhaps more importantly, it forms the basis of the LSID resolution for Service Instance LSID's (the service provider themselves becomes the LSID resolution service by putting their signature RDF at the location that they have registered in MOBY Central). * The "immediacy" of calls to MOBY Central should not (if I understand Eddie's changes to the code) be affected. If you want to register a service, you can continue to use the registerService API call. If you want to deregister a service, you simply remove that service RDF signature and it will be deregistered "passively". To "actively" or immediately deregister a service, simply remove the service RDF and call "registerService" passing the SignatureURL. This will invoke the agent to immediately crawl to you, discover that the document is now gone, and deregister your service. This we maintain the immediacy of registration/deregistration but gain the security that only you can deregister your services. * The policy of the curation behaviour of the agent is not hard-coded. Every registry curator can set their own policy in the agent configuration file - individual registry curators may or may not chose to deregister services, or to give more or less warning, or to run the agent more or less often, as they see fit. * The policy of the MOBY Central registry at iCAPTURE is currently being drawn-up. A first draft is available (click on Project Docs on the right side of the moby homepage) for comment. Like any other public resource, the host and curator of that resource must make appropriate decisions that are both sustainable, and provide the maximum benefit to their community given the resources available. As host and curator of the iCAPTURE registry, I will set the policy of this instance of the registry with that goal in mind. Some may consider this being a dictator, some may consider it being responsible. * I do not support "gradfathering", since this will require changes at the code level, and in fact, behavioural changes in the API that would have to be documented. A three-month passive trial period for the Agent sounds like a functionally equivalent but better alternative, particularly since the move to RDF is essential and parallel to our adoption of the LSID resolution system. * I disagree with having to code circumstantial exceptions into the clients (e.g. ignoring localhost). Not only would this exception have to be coded into every client, but in those instances where "localhost" was meaningful and useful (e.g. if you are using Taverna and you are hosting a MOBY Central registry on your own hard drive that Taverna is connecting to) that exception would have to be removed from the client such that you could discover your own services... and moreover, by removing that exception, you then begin to discover services that are "localhost" to someone else's machine... Individual registry hosts can create their own policy on this, but it seems to me that the only feasible way to deal with this problem is for clients to accept localhost whenever they find it, but for registry hosts to determine whether a localhost registration is appropriate in their registry. Those are just the thoughts off the top of my head. I need to drop out of this discussion again for a while as I have a ton of essay marking to do :-) Darn students! They do love to express themselves.... Cheers all! Mark -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From gordonp at ucalgary.ca Wed Feb 22 23:46:28 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 22 Feb 2006 16:46:28 -0700 Subject: [MOBY-dev] Namespace matching Message-ID: <43FCF7D4.9070901@ucalgary.ca> Hi all: Perhaps I am dense, but how can I prevent a findService central API call from finding ALL services that consume a particular object when the object doesn't have a namespace? e.g. Suppose I just built a GenericSequence with some anonymous data I have laying around. I have no namespace or ID for it, it's just a plain old sequence someone typed in: 3 tga When I submit to findService it has the format: GenericSequence But the central server interprets the blank namespace as a wildcard, not a undefined namespace. I want all services that take GenericSequence or VirtualSequence but don't care about the namespace, but I get all services that take VitualSequence including those expecting particular namespaces. Can I get around this without inventing my own useless namespace, or is this the only way to go? I thought you needed a "*" between the Namespace tags in findService for it to act as a wildcard... From gordonp at ucalgary.ca Thu Feb 23 17:56:11 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 23 Feb 2006 10:56:11 -0700 Subject: [MOBY-dev] Suggestion for new tag in Parameter (Secondary Input specification) Message-ID: <43FDF73B.5040105@ucalgary.ca> Can we add an optional description field to the secondary article tag? It might help people fill it out if they have a hint *what* they're filling out besides the articleName. i.e.: This field sets the frameshift penalty in the alignment. The higher it is set, the less likely frameshifts will be detected and corrected. Integer|Float|String|DateTime ... ... ... ... ... Sound reasonable? Does this require a RFC? From senger at ebi.ac.uk Thu Feb 23 18:03:59 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 23 Feb 2006 18:03:59 +0000 (GMT) Subject: [MOBY-dev] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <43FDF73B.5040105@ucalgary.ca> Message-ID: Sounds reasonable to me. I support it. (No problem to add it to the Dashboard when/if it is added.) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Feb 23 18:11:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 23 Feb 2006 10:11:29 -0800 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <43FDF73B.5040105@ucalgary.ca> References: <43FDF73B.5040105@ucalgary.ca> Message-ID: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> Absolutely - I believe the INB had also requested this a while ago, too. Do we need to go through an RFC for this? I hope not... If nobody objects, I'll add it to the API right away. It should only take a couple of minutes to code. M On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: > Can we add an optional description field to the secondary article tag? > It might help people fill it out if they have a hint *what* they're > filling out besides the articleName. i.e.: > > > This field sets the frameshift penalty in the alignment. The higher it is set, the less likely frameshifts will be detected and corrected. > Integer|Float|String|DateTime > ... > ... > ... > ... > ... > > > Sound reasonable? Does this require a RFC? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Thu Feb 23 18:12:38 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 23 Feb 2006 13:12:38 -0500 Subject: [MOBY-dev] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <43FDF73B.5040105@ucalgary.ca> Message-ID: <5.2.1.1.2.20060223131213.01e9ffe0@email.med.harvard.edu> Sounds like a good idea to me too. -Frank At 12:56 PM 2/23/2006, you wrote: >Can we add an optional description field to the secondary article tag? >It might help people fill it out if they have a hint *what* they're >filling out besides the articleName. i.e.: > > > This field sets the frameshift penalty in the > alignment. The higher it is set, the less likely frameshifts will be > detected and corrected. > Integer|Float|String|DateTime > ... > ... > ... > ... > ... > > >Sound reasonable? Does this require a RFC? > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Thu Feb 23 18:17:01 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 23 Feb 2006 18:17:01 +0000 (GMT) Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> Message-ID: > Do we need to go through an RFC for this? I hope not... > No (it does not break anything in the current software). > If nobody objects, I'll add it to the API right away. It should only > take a couple of minutes to code. > No objection in Philippines. Just also please update the docs. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Thu Feb 23 19:12:51 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 23 Feb 2006 14:12:51 -0500 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> At 01:17 PM 2/23/2006, you wrote: > > If nobody objects, I'll add it to the API right away. It should only > > take a couple of minutes to code. > > > No objection in Philippines. Just also please update the docs. Wow, what efficiency, what compatibility, what.... interoperability! I'd just like to make a plug for adding a line to the Perl tests, to verify that this new feature "works". You get to define what "works" means - at the very least, I suggest that if I try to register a service that either specifies or doesn't specify the field, the registration should go through successfully (assuming there's no other reason for it to fail). I encourage all Perl developers to write tight tests, so you may want to take it further than that minimal definition. Just on this topic, what does the java crew use for unit-testing? -F PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Feb 23 19:22:08 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 23 Feb 2006 11:22:08 -0800 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> Message-ID: <1140722528.5536.33.camel@bioinfo.icapture.ubc.ca> Ah! right! That reminds me I need to write a test for the updates to the Relationships API call (and document them properly). M On Thu, 2006-02-23 at 14:12 -0500, Frank Gibbons wrote: > At 01:17 PM 2/23/2006, you wrote: > > > If nobody objects, I'll add it to the API right away. It should only > > > take a couple of minutes to code. > > > > > No objection in Philippines. Just also please update the docs. > > > Wow, what efficiency, what compatibility, what.... interoperability! > > I'd just like to make a plug for adding a line to the Perl tests, to verify > that this new feature "works". You get to define what "works" means - at > the very least, I suggest that if I try to register a service that either > specifies or doesn't specify the field, the registration should go > through successfully (assuming there's no other reason for it to fail). I > encourage all Perl developers to write tight tests, so you may want to take > it further than that minimal definition. > > Just on this topic, what does the java crew use for unit-testing? > > -F > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From gordonp at ucalgary.ca Thu Feb 23 20:12:39 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 23 Feb 2006 13:12:39 -0700 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> Message-ID: <43FE1737.60402@ucalgary.ca> AFAIK, nothing. I have written JUnit tests to check several of the classes I wrote, but they are not part of the repository. We should really get on that :-) >Just on this topic, what does the java crew use for unit-testing? > > From Pieter.Neerincx at wur.nl Thu Feb 23 23:47:58 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 00:47:58 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> Message-ID: <16CA102E-7DD9-439E-A901-808D178A9AE1@wur.nl> On 23Feb2006, at 20:12, Frank Gibbons wrote: > At 01:17 PM 2/23/2006, you wrote: >>> If nobody objects, I'll add it to the API right away. It should >>> only >>> take a couple of minutes to code. >>> >> No objection in Philippines. Just also please update the docs. > > > Wow, what efficiency, what compatibility, what.... interoperability! I would welcome the description for secondaries too. Currently figuring what some secondaries do requires voodoo :(. Cheers, Pi > I'd just like to make a plug for adding a line to the Perl tests, > to verify > that this new feature "works". You get to define what "works" means > - at > the very least, I suggest that if I try to register a service that > either > specifies or doesn't specify the field, the registration > should go > through successfully (assuming there's no other reason for it to > fail). I > encourage all Perl developers to write tight tests, so you may want > to take > it further than that minimal definition. > > Just on this topic, what does the java crew use for unit-testing? > > -F > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Fri Feb 24 00:09:02 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 24 Feb 2006 00:09:02 +0000 (GMT) Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> Message-ID: > Just on this topic, what does the java crew use for unit-testing? > Nothing. We should use jUnit, a standard way in Java, but I have never started with it. As a I said, we should... (I think that Paul has started to use it, at least somebody put junit.jar in jMoby.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 24 02:08:50 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 23 Feb 2006 18:08:50 -0800 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <1140722528.5536.33.camel@bioinfo.icapture.ubc.ca> References: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <5.2.1.1.2.20060223140820.01e94e98@email.med.harvard.edu> <1140722528.5536.33.camel@bioinfo.icapture.ubc.ca> Message-ID: <1140746930.14621.1.camel@bioinfo.icapture.ubc.ca> Secondaries should now be able to have descriptions. a XML tag has been added to the API for secondary articles. Seems to pass the tests. Please let me know if it doesn't work for you. M From johan at ac.uma.es Fri Feb 24 11:44:14 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Fri, 24 Feb 2006 12:44:14 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> References: <43FDF73B.5040105@ucalgary.ca> <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <43FEF18E.3040103@ac.uma.es> Hi! As Mark says, description of secondaries is something the INB have been requesting for a while now. Actually, we are already capturing this information together with some additional information during service registration. We store this information in a separate database, apart from the Moby Central database. We have recently started a new registration procedure at the INB where (as part of the procedure) service providers can add the following additional information about their services: ? Name of the author. ? For each input and output (primary/collection parameters), a description of the parameter, and a data type example. ? For each secondary parameter, a description of the parameter and an example value. ? Help file for the service (in XML format) ? Keywords describing the service (we are working on "semantic" searches) Maybe some of this information can be useful to the BioMoby community? Kind regards, Johan Karlsson Mark Wilkinson wrote: > Absolutely - I believe the INB had also requested this a while ago, too. > > Do we need to go through an RFC for this? I hope not... > > If nobody objects, I'll add it to the API right away. It should only > take a couple of minutes to code. > > M > > > > On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: > >> Can we add an optional description field to the secondary article tag? >> It might help people fill it out if they have a hint *what* they're >> filling out besides the articleName. i.e.: >> >> >> This field sets the frameshift penalty in the alignment. The higher it is set, the less likely frameshifts will be detected and corrected. >> Integer|Float|String|DateTime >> ... >> ... >> ... >> ... >> ... >> >> >> Sound reasonable? Does this require a RFC? >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> From Pieter.Neerincx at wur.nl Fri Feb 24 12:00:13 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 13:00:13 +0100 Subject: [MOBY-dev] [moby] Re: Cleaning up the Object ontology - Inheriting from base Object In-Reply-To: References: Message-ID: <60FEE9FB-F15B-471F-BF7D-452ED27D1CA1@wur.nl> On 21-Feb-2006, at 9:33 AM, Martin Senger wrote: >> Could we find common ground if we made an API change that resulted >> in the >> Namespace ontology being hierarchical rather than flat? If I >> understand >> the problem you are trying to solve, this would make a significant >> difference - but would it make *enough* difference that you >> wouldn't have >> to create more specific types of simple Objects? >> > Honestly, I do not know. I even do not fully understand your > "combinatorial explosion", and - mainly - why it would not happen > with a > hierarchy and inheritance within namespaces? I'm with Martin again here. I do see how what Martin and I want could be done with namespaces instead, but I fail to see how this prevents the problem Mark described here: > Object > DatabaseObject > GenbankObject > GenbankSequence > GenbankDNASequence > GenbankAASequence > EMBLObject > EMBLSequence > EMBLDNASequence > EMBLAASequence > PDBObject > PDBSequence > > etc. etc. From the Rectorian ontology-philosophy, this is a perfect > example of the "exploding bicycle", and the end result is well > documented and disasterous! Even in that example, there would be > no way > to discover a Blast service that operated on GenericSequence > objects if > you had a GenbankDNASequence object in-hand. What are the relationships in the example above? Would it be possible to do the following: Object DatabaseObject ISA Object GenbankObject ISA DatabaseObject HASA GenbankSequence HASA GenbankDNASequence ISA GenericSequence HASA GenbankAASequence ISA GenericSequence EMBLObject EMBLSequence EMBLDNASequence EMBLAASequence PDBObject PDBSequence That would still not be an elegant object structure, but it's difficult to make sure people don't register clumsy object structures or create yet another redundant object for something that's already there. I don't see how using a less flat namespace ontology would prevent that, because in that case I could register: Namespace DatabaseNS GenbankNS GenbankSequenceNS GenbankDNASequenceNS GenbankAASequenceNS EMBL_NS EMBLSequenceNS EMBLDNASequenceNS EMBLAASequenceNS PDB_NS PDBSequenceNS In that case if a service is registered to take a GenericSequence object as input, but it's limited to the GenbankDNASequenceNS namepsace, you still won't be able to use it if GenbankDNASequenceNS wasn't registered to be 'ISA GenericSequenceNS'. I'm a bit confused here.... Pi > That would also mean that we > would have two trees, one (roughly speaking) describing syntax > (data type > tree) and one describing semantics (namapsce tree). That would not > be easy > to explain, maintain and use... > I am tempted to say that I wuold still use data types to express > how a > reality is related, and I would use namespaces as an additional > information - where I would welcome less flat alternative. > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Fri Feb 24 13:05:30 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 24 Feb 2006 13:05:30 +0000 (GMT) Subject: [MOBY-dev] Dashboard update Message-ID: Dear all, I have added few more things to the Dashboard and - mainly! - finalized its documentation and help pages. The main update is a new SimpleClient panel that allows you to call any service, and to display its results using various viewers (applying the same plug-in mechanism as Taverna has, even re-using shamelessly some of the Taverna viewers). This concludes the cycle that a Biomoby service provider needs to go through (register service, implement service, deploy service and test/call service). The documentation was significantly extended especially for developers that wish to add there their own panels and viewers. I am looking forward to seeing some additions (Eddie, what about a browser of the RDF used in Biomoby, or perhaps a browser of the LSID metadata resolution?), and I am here to help as much as I can (my time zone will be GMT from the next week). Please let me know about any problems and suggestions for improvements. The latest Dashboard documentation is available here: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/Dashboard.html With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Fri Feb 24 14:21:18 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 15:21:18 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <43FEF18E.3040103@ac.uma.es> References: <43FDF73B.5040105@ucalgary.ca> <1140718289.5536.1.camel@bioinfo.icapture.ubc.ca> <43FEF18E.3040103@ac.uma.es> Message-ID: <9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> Hi Johan et al., On 24-Feb-2006, at 12:44 PM, Johan Karlsson wrote: > Hi! > > As Mark says, description of secondaries is something the INB have > been > requesting for a while now. > > Actually, we are already capturing this information together with some > additional information during service registration. We store this > information in a separate database, apart from the Moby Central > database. > > We have recently started a new registration procedure at the INB where > (as part of the procedure) service providers can add the following > additional information about their services: > > ? Name of the author. > ? For each input and output (primary/collection parameters), a > description of the parameter, and a data type example. > ? For each secondary parameter, a description of the parameter > and an > example value. > ? Help file for the service (in XML format) > ? Keywords describing the service (we are working on "semantic" > searches) > > Maybe some of this information can be useful to the BioMoby community? I read the INB paper "Intelligent client for integrating bioinformatics services" published in Bioinformatics. The things mentioned above were described there and it made me wonder... For asynchronous service calls the INB leads an initiative to extend the BioMOBY standard, which is great! This may take a bit longer to get accepted and implemented as compared to hacking together some custom extension, but it makes sure that your BioMOBY services are compatible with the rest of the BioMOBY world. The INB did the same for error handling. But for the things mentioned above the INB people chose to go their own way. The "extended service registration" procedure is INB specific and the additional (help) info is available form a "fourth party" server (not the BioMOBY client, nor the service provider, nor the INB BioMOBY Central). I think this is bad. The INB BioMOBY Central is out of sync with the official BioMOBY Central and no longer compatible, because of the modified registration procedure : (. Personally I think this is even worse... Anyway the things mentioned above would definitely be useful! The secondary parameter description was just added to the service registration call. So that's solved. When I retrieve a service I get the BioMOBY WSDL that contains amongst others all the description fields. If I have a typical BLAST service that supports all 40+ parameters it also means that this WSDL will hold the description for 40+ params. It's getting big...:). So adding additional help in XML format and example input and output there (during registration) would make the WSDL we send around even longer. Not my favourite solution. I would rather like to see a solution where this additional information is provided by the service (provider) and only when the client requests it explicitly. This way it doesn't need to be stored in a BioMOBY Central. This could be done for example using an additional method [ServiceName]_help. If this would be standardised the new RDF agent, might be extended and use this method to get the example input, excute the service with this example input and validate the results. It can than check: * whether the service works * if the input and output are valid as compared to how the service was registered. If these checks fail it might send an automated e-mail to the maintainer of that service and eventually if the issues are not resolved remove the service from BioMOBY Central. In the "cleaning out the registry" thread Mark mentioned that he would contact service providers whose services work perfectly well, but were registered incorrectly. No matter how efficient Mark might work, sooner or later BioMOBY will be so popular and BioMOBY Central so big, that doing this manually won't be feasible anymore. So this needs to be automated sooner or later anyway. Having example input and output might be used for that. So what do the others think... Just my 2c, Pi > > Kind regards, > Johan Karlsson > > Mark Wilkinson wrote: >> Absolutely - I believe the INB had also requested this a while >> ago, too. >> >> Do we need to go through an RFC for this? I hope not... >> >> If nobody objects, I'll add it to the API right away. It should only >> take a couple of minutes to code. >> >> M >> >> >> >> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: >> >>> Can we add an optional description field to the secondary article >>> tag? >>> It might help people fill it out if they have a hint *what* they're >>> filling out besides the articleName. i.e.: >>> >>> >>> This field sets the frameshift penalty in the alignment. >>> The higher it is set, the less likely frameshifts will be >>> detected and corrected. >>> Integer|Float|String|DateTime >>> ... >>> ... >>> ... >>> ... >>> ... >>> >>> >>> Sound reasonable? Does this require a RFC? >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >>> > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Fri Feb 24 14:38:38 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 24 Feb 2006 14:38:38 +0000 (GMT) Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> Message-ID: > I would rather like to see a solution where this additional > information is provided by the service (provider) > This solution already exists. It is called LSID metadata resolution and any service provider can (should) do it. Even the RDF predicates to be used for things like example input and expected output were (I think) defined in an RFC describing the LSID metadata resolution. Regarding INB, it is not that important how they add and how they store the additional information about their services, but how they make access to this information. If they choose to provide them via LSID metadata resolution, it's perfect, standard and everybody can benefit fom it. Martin's 2c's. Cheers, M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Feb 24 16:26:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 24 Feb 2006 08:26:10 -0800 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: References: Message-ID: <1140798370.15348.8.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-02-24 at 14:38 +0000, Martin Senger wrote: > > I would rather like to see a solution where this additional > > information is provided by the service (provider) > > > This solution already exists. It is called LSID metadata resolution and > any service provider can (should) do it. Absolutely correct! The "core" predicates were defined in the RFC, and are documented here: http://biomoby.open-bio.org/index.php/for- developers/moby_extensions/moby_metadata It's probably a good idea to discuss what the common extension predicates are going to be amongst the community so that we all know what to look for in your RDF (and these may eventually become part of the core API), but that doesn't stop anyone from adding whatever metadata they wish to their own RDF. M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From ots at ac.uma.es Fri Feb 24 18:04:33 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 24 Feb 2006 19:04:33 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter(Secondary Input specification) References: <43FDF73B.5040105@ucalgary.ca><1140718289.5536.1.camel@bioinfo.icapture.ubc.ca><43FEF18E.3040103@ac.uma.es> <9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> Message-ID: <02b201c6396c$c46655d0$346dd696@ac.uma.es> Hi all and Pieter in particular: This is Oswaldo from the gnv5 -University of Malaga- group at the INB. Perhaps Pieter's mail needs some additional information from our group to better understand some aspects of the INB architecture. The INB project was started in March'04, a major decision was make to use BioMOBY as the underlying integration protocol. However, several of the desirable functionalities were not available in the protocol, specially important from the INB perspective were the ability to launch large-CPU tasks using asynchronous messaging; a protocol for error handling (and, in the way, some specific rules for dealing with collections; help information, DB optimization, etc etc. we expect to propose extensions in these fields. soon). However, we design the architecture keeping in mind to maintain full compatibility with moby. A good example is our current async implementation (see the attached document for a longer description). What can we learn from this document? that we extend the protocol -async- even with the double cost of maintain moby compatibility: Even more, our current proposal for async was born during the INB meeting (July'05) and discussed with Martin and Eddie. This proposal is completely new and -if approved- we will need to re-write our async code (well, not at all). Thus, once we are part of the moby group and our ideas can be taken into account, we will move closer in the moby direction to avoid double work from our side (as you can imagine, this is what we want). On the other hand, our registration procedure -in my opinion- does not break our moby compatibility. In fact you can use directly all the services we have developed. If you see the new fields, most of them are used to allow (user-friendly and self explicative) automatic interface building. SO they don't have any influence in the services call protocol. We of course will be happy to propose a documentation system and other extensions, but at this moment there are other priorities. In sumary; in fact we have our own ideas about a full protocol. For strategic reasons we develeop at our own cost, some moby extension (from a practical point of view, we took our own decisions because we needed a fast development -you know that error handling have spent more than 4 months in discussion!!!!). But we dont want to break moby (and we are not going to do that). sorry for this long (and boring) dissertation. Oswaldo PS with repect to the registration procedure, it can be done using moby functionality, but we request additional information to be used by our client (if you want addictional information on our protocol dont hesitate to request) > I read the INB paper "Intelligent client for integrating > bioinformatics services" published in Bioinformatics. The things > mentioned above were described there and it made me wonder... For > asynchronous service calls the INB leads an initiative to extend the > BioMOBY standard, which is great! This may take a bit longer to get > accepted and implemented as compared to hacking together some custom > extension, but it makes sure that your BioMOBY services are > compatible with the rest of the BioMOBY world. The INB did the same > for error handling. But for the things mentioned above the INB people > chose to go their own way. The "extended service registration" > procedure is INB specific and the additional (help) info is available > form a "fourth party" server (not the BioMOBY client, nor the service > provider, nor the INB BioMOBY Central). I think this is bad. The INB > BioMOBY Central is out of sync with the official BioMOBY Central and > no longer compatible, because of the modified registration procedure : > (. Personally I think this is even worse... > > Anyway the things mentioned above would definitely be useful! The > secondary parameter description was just added to the service > registration call. So that's solved. When I retrieve a service I get > the BioMOBY WSDL that contains amongst others all the description > fields. If I have a typical BLAST service that supports all 40+ > parameters it also means that this WSDL will hold the description for > 40+ params. It's getting big...:). So adding additional help in XML > format and example input and output there (during registration) would > make the WSDL we send around even longer. Not my favourite solution. > > I would rather like to see a solution where this additional > information is provided by the service (provider) and only when the > client requests it explicitly. This way it doesn't need to be stored > in a BioMOBY Central. This could be done for example using an > additional method [ServiceName]_help. If this would be standardised > the new RDF agent, might be extended and use this method to get the > example input, excute the service with this example input and > validate the results. It can than check: > * whether the service works > * if the input and output are valid as compared to how the service > was registered. > If these checks fail it might send an automated e-mail to the > maintainer of that service and eventually if the issues are not > resolved remove the service from BioMOBY Central. In the "cleaning > out the registry" thread Mark mentioned that he would contact service > providers whose services work perfectly well, but were registered > incorrectly. No matter how efficient Mark might work, sooner or later > BioMOBY will be so popular and BioMOBY Central so big, that doing > this manually won't be feasible anymore. So this needs to be > automated sooner or later anyway. Having example input and output > might be used for that. So what do the others think... > > Just my 2c, > > Pi > > > > > Kind regards, > > Johan Karlsson > > > > Mark Wilkinson wrote: > >> Absolutely - I believe the INB had also requested this a while > >> ago, too. > >> > >> Do we need to go through an RFC for this? I hope not... > >> > >> If nobody objects, I'll add it to the API right away. It should only > >> take a couple of minutes to code. > >> > >> M > >> > >> > >> > >> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: > >> > >>> Can we add an optional description field to the secondary article > >>> tag? > >>> It might help people fill it out if they have a hint *what* they're > >>> filling out besides the articleName. i.e.: > >>> > >>> > >>> This field sets the frameshift penalty in the alignment. > >>> The higher it is set, the less likely frameshifts will be > >>> detected and corrected. > >>> Integer|Float|String|DateTime > >>> ... > >>> ... > >>> ... > >>> ... > >>> ... > >>> > >>> > >>> Sound reasonable? Does this require a RFC? > >>> > >>> _______________________________________________ > >>> MOBY-dev mailing list > >>> MOBY-dev at biomoby.org > >>> http://biomoby.org/mailman/listinfo/moby-dev > >>> > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Fri Feb 24 19:12:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 20:12:37 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: References: Message-ID: <59188CE8-6F85-4D93-BFC4-F753D4CED8D7@wur.nl> On 24-Feb-2006, at 3:38 PM, Martin Senger wrote: >> I would rather like to see a solution where this additional >> information is provided by the service (provider) >> > This solution already exists. It is called LSID metadata > resolution and > any service provider can (should) do it. > Even the RDF predicates to be > used for things like example input and expected output were (I > think) defined in an RFC describing the LSID metadata resolution. Oops, looks like I missed something :). I'll have a second look at the LSID things. So far I didn't look at it thoroughly, because I never got the Perl LS::ID.pm module to install correctly. Always failed the tests. I simply copied it over and so far it doesn't create problems. > Regarding INB, it is not that important how they add and how > they store > the additional information about their services, but how they make > access > to this information. If they choose to provide them via LSID metadata > resolution, it's perfect, standard and everybody can benefit fom it. If I understood the paper correctly that's not the case, but correct me if I'm wrong. Cheers, Pi > Martin's 2c's. > Cheers, M. > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Feb 24 19:30:44 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 20:30:44 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter (Secondary Input specification) In-Reply-To: <1140798370.15348.8.camel@bioinfo.icapture.ubc.ca> References: <1140798370.15348.8.camel@bioinfo.icapture.ubc.ca> Message-ID: <010E264E-92CA-47D1-801A-5CBABE7CB3DF@wur.nl> On 24-Feb-2006, at 5:26 PM, Mark Wilkinson wrote: > > On Fri, 2006-02-24 at 14:38 +0000, Martin Senger wrote: >>> I would rather like to see a solution where this additional >>> information is provided by the service (provider) >>> >> This solution already exists. It is called LSID metadata >> resolution and >> any service provider can (should) do it. > > > Absolutely correct! > > The "core" predicates were defined in the RFC, and are documented > here: > http://biomoby.open-bio.org/index.php/for- > developers/moby_extensions/moby_metadata Check, I took a second look at the site. Looks like LSID resolution could perfectly work for these things as well. Thanks Martin and Mark for clarifying the extensibility of LSID metadata resolution. I previously overlooked that completely. > It's probably a good idea to discuss what the common extension > predicates are going to be amongst the community so that we all know > what to look for in your RDF (and these may eventually become part of > the core API), I would welcome that discussion. I could not find tags for things like example input, example output and extended help yet, but those would be useful for many of us. And it would hamper interoperability if everyone designs their own lollypop for that functionality. > but that doesn't stop anyone from adding whatever > metadata they wish to their own RDF. Which is great as well! I saw the light, Pi > > M > > > > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Feb 24 19:57:03 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 24 Feb 2006 20:57:03 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <02b201c6396c$c46655d0$346dd696@ac.uma.es> References: <43FDF73B.5040105@ucalgary.ca><1140718289.5536.1.camel@bioinfo.icapture.ubc.ca><43FEF18E.3040103@ac.uma.es> <9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> <02b201c6396c$c46655d0$346dd696@ac.uma.es> Message-ID: <2B8E89C5-BA34-4F11-97CB-C210016AF76B@wur.nl> Hi Oswaldo, On 24-Feb-2006, at 7:04 PM, Oswaldo Trelles wrote: > Hi all and Pieter in particular: > > > > This is Oswaldo from the gnv5 -University of Malaga- group at the INB. > Perhaps Pieter's mail needs some additional information from our > group to > better understand some aspects of the INB architecture. > > > > The INB project was started in March'04, a major decision was make > to use > BioMOBY as the underlying integration protocol. However, several of > the > desirable functionalities were not available in the protocol, > specially > important from the INB perspective were the ability to launch large- > CPU > tasks using asynchronous messaging; a protocol for error handling > (and, in > the way, some specific rules for dealing with collections; help > information, > DB optimization, etc etc. we expect to propose extensions in these > fields. > soon). So far those proposals from the INB group have resulted in valuable extensions :), so I'm looking forward to any new proposals. > > > However, we design the architecture keeping in mind to maintain full > compatibility with moby. A good example is our current async > implementation > (see the attached document for a longer description). What can we > learn from > this document? that we extend the protocol -async- even with the > double cost > of maintain moby compatibility: Even more, our current proposal for > async > was born during the INB meeting (July'05) and discussed with Martin > and > Eddie. This proposal is completely new and -if approved- we will > need to > re-write our async code I understand. Same here. I experimented with some async stuff, which is different from what was proposed, so I rewrote them. In fact we have course in two weeks where I want to use one of those services, so you will see some async stuff popup in the BioMOBY Central next week. Those services were rewritten to make them at least partially compatible with the current proposal. Rest assured that I will rewrite them once more once the proposal is finished and accepted. > (well, not at all). Thus, once we are part of the > moby group and our ideas can be taken into account, we will move > closer in > the moby direction to avoid double work from our side (as you can > imagine, > this is what we want). > > > > On the other hand, our registration procedure -in my opinion- does > not break > our moby compatibility. In fact you can use directly all the > services we > have developed. If you see the new fields, most of them are used to > allow > (user-friendly and self explicative) automatic interface building. > SO they > don't have any influence in the services call protocol. Ok, that's good to read. I thought it might have broken interoperability. > We of course will be happy to propose a documentation system and other > extensions, but at this moment there are other priorities. > > In sumary; in fact we have our own ideas about a full protocol. For > strategic reasons we develeop at our own cost, some moby extension > (from a > practical point of view, we took our own decisions because we > needed a fast > development -you know that error handling have spent more than 4 > months in > discussion!!!!) I know it took a while. It was a bit too long I think, but in the end the proposal did improve because of the discussion. Just be glad your into bioinformatics and not politics, because otherwise the proposal would have taken easily 4 years :). Cheers, Pi > . But we dont want to break moby (and we are not going to do > that). > > sorry for this long (and boring) dissertation. > > Oswaldo > > PS with repect to the registration procedure, it can be done using > moby > functionality, but we request additional information to be used by our > client (if you want addictional information on our protocol dont > hesitate to > request) > > > >> I read the INB paper "Intelligent client for integrating >> bioinformatics services" published in Bioinformatics. The things >> mentioned above were described there and it made me wonder... For >> asynchronous service calls the INB leads an initiative to extend the >> BioMOBY standard, which is great! This may take a bit longer to get >> accepted and implemented as compared to hacking together some custom >> extension, but it makes sure that your BioMOBY services are >> compatible with the rest of the BioMOBY world. The INB did the same >> for error handling. But for the things mentioned above the INB people >> chose to go their own way. The "extended service registration" >> procedure is INB specific and the additional (help) info is available >> form a "fourth party" server (not the BioMOBY client, nor the service >> provider, nor the INB BioMOBY Central). I think this is bad. The INB >> BioMOBY Central is out of sync with the official BioMOBY Central and >> no longer compatible, because of the modified registration >> procedure : >> (. Personally I think this is even worse... >> >> Anyway the things mentioned above would definitely be useful! The >> secondary parameter description was just added to the service >> registration call. So that's solved. When I retrieve a service I get >> the BioMOBY WSDL that contains amongst others all the description >> fields. If I have a typical BLAST service that supports all 40+ >> parameters it also means that this WSDL will hold the description for >> 40+ params. It's getting big...:). So adding additional help in XML >> format and example input and output there (during registration) would >> make the WSDL we send around even longer. Not my favourite solution. >> >> I would rather like to see a solution where this additional >> information is provided by the service (provider) and only when the >> client requests it explicitly. This way it doesn't need to be stored >> in a BioMOBY Central. This could be done for example using an >> additional method [ServiceName]_help. If this would be standardised >> the new RDF agent, might be extended and use this method to get the >> example input, excute the service with this example input and >> validate the results. It can than check: >> * whether the service works >> * if the input and output are valid as compared to how the service >> was registered. >> If these checks fail it might send an automated e-mail to the >> maintainer of that service and eventually if the issues are not >> resolved remove the service from BioMOBY Central. In the "cleaning >> out the registry" thread Mark mentioned that he would contact service >> providers whose services work perfectly well, but were registered >> incorrectly. No matter how efficient Mark might work, sooner or later >> BioMOBY will be so popular and BioMOBY Central so big, that doing >> this manually won't be feasible anymore. So this needs to be >> automated sooner or later anyway. Having example input and output >> might be used for that. So what do the others think... >> >> Just my 2c, >> >> Pi >> >>> >>> Kind regards, >>> Johan Karlsson >>> >>> Mark Wilkinson wrote: >>>> Absolutely - I believe the INB had also requested this a while >>>> ago, too. >>>> >>>> Do we need to go through an RFC for this? I hope not... >>>> >>>> If nobody objects, I'll add it to the API right away. It should >>>> only >>>> take a couple of minutes to code. >>>> >>>> M >>>> >>>> >>>> >>>> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: >>>> >>>>> Can we add an optional description field to the secondary article >>>>> tag? >>>>> It might help people fill it out if they have a hint *what* >>>>> they're >>>>> filling out besides the articleName. i.e.: >>>>> >>>>> >>>>> This field sets the frameshift penalty in the alignment. >>>>> The higher it is set, the less likely frameshifts will be >>>>> detected and corrected. >>>>> Integer|Float|String|DateTime >>>>> ... >>>>> ... >>>>> ... >>>>> ... >>>>> ... >>>>> >>>>> >>>>> Sound reasonable? Does this require a RFC? >>>>> >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev at biomoby.org >>>>> http://biomoby.org/mailman/listinfo/moby-dev >>>>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Sat Feb 25 03:21:20 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 03:21:20 +0000 (GMT) Subject: [MOBY-dev] where are all signature URLs? Message-ID: I know that the signatureURLs were not used (waiting for the agent) - but they still have been, at least sometimes, registered. Where are they now? I am getting *all* services from the registry without them now. I wonder if the problem is in jMoby fetching software, or if they are really not there anymore. Please tell me. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Feb 25 03:43:32 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 03:43:32 +0000 (GMT) Subject: [MOBY-dev] where are all signature URLs? In-Reply-To: <35793108-1140838578-cardhu_blackberry.rim.net-302-@engine12-cell01> Message-ID: It happens to all of us... :-) But it reminds me something else: if you do anytime a manual change in the registry, please do not forget always to change also the timestamp field (unless it's done automatically by the RDBS) - otherwise the software relying on the new LSID versioning will not notice the change and cannot update various caches properly. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Feb 25 03:33:57 2006 From: markw at illuminae.com (mark wilkinson) Date: Sat, 25 Feb 2006 03:33:57 +0000 GMT Subject: [MOBY-dev] where are all signature URLs? Message-ID: <35793108-1140838578-cardhu_blackberry.rim.net-302-@engine12-cell01> That was my fault. An accident. We noticed last week that there were entries in the database that were not representing anything (eg things that got it and never got erased during code tests). They were popping out from certain findService requests in fragmented ways and breaking the code because they were incomplete or badly formatted. I was trying to clean them by manual and scripted trash collection but I made an error. I have a backup, and could replace them, it will just take a bit of careful scripting. M -----Original Message----- From: Martin Senger Date: Sat, 25 Feb 2006 03:21:20 To:Edward Kawas Cc:Moby Developers Subject: [MOBY-dev] where are all signature URLs? I know that the signatureURLs were not used (waiting for the agent) - but they still have been, at least sometimes, registered. Where are they now? I am getting *all* services from the registry without them now. I wonder if the problem is in jMoby fetching software, or if they are really not there anymore. Please tell me. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Sat Feb 25 06:06:43 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 06:06:43 +0000 (GMT) Subject: [MOBY-dev] Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <2B8E89C5-BA34-4F11-97CB-C210016AF76B@wur.nl> Message-ID: Dear all, I have updated jMoby in order to handle description in/for the secondary inputs (parameters). Regards, Martin [ Details: * MobySecondaryData includes now set/get method for description. Also its toString(), toXML() and from XML method have been updated. * Dashboard Registration panel now has an additional column in a table creating definitions of the secondary inputs - allowing multi-line descripion to be entered. ] -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Feb 25 06:43:27 2006 From: markw at illuminae.com (mark wilkinson) Date: Sat, 25 Feb 2006 06:43:27 +0000 GMT Subject: [MOBY-dev] where are all signature URLs? Message-ID: <1899503299-1140849949-cardhu_blackberry.rim.net-5259-@engine08-cell01> Thanks for your forgiveness - I was quite embarrassed by it, actually! The reason I didn't fix it right away was that it was the last operation I did that day, so to roll-back would have re-introduced all of the crap that I had just spent the morning removing. I just kicked myself and decided that I would only script the replacement of the sigURL's if someone asked me to... I have night-terrors when I have to edit the main registry database by hand!! Over the past three years it had picked up a lot of junk from various code bugs and such, so the cleaning needed to happen, but I messed it up... And I sincerely apologize for that!!! Vv changing the timestamp: that was an even bigger problem. Last week eddie mentioned to me that, sor some reason that we still don't understand, many of the namespace terms ended up with an underscore appended to them ("EMBL_"). This happened before the LSID timestamp was added, and so our LSID's ended up with this underscore in them as well! This caused a problem (that nobody seemed to notice??) That namespaces registered for a service were no longer valid namespaces (the lsid is used as the primary key, and it no longer matched with the namespace in the namespaces database tables). The only solutiuon was to modify the lsid in the namespace table (remove the underscore) but keep the same timestamp, since that was the timestamp that the service was registered under. Again, I apologize for any frustration that caused, but in this case I couldn't see a good alternative that didn't involve changing the registration of every service (and that terrifies me!)... I wish I knew where those underscores came from in the first place, though...?????? Anyway, that's the full history of the manual registry database edits from last week... M -----Original Message----- From: Martin Senger Date: Sat, 25 Feb 2006 03:43:32 To:mark wilkinson Cc:Core developer announcements Subject: Re: [MOBY-dev] where are all signature URLs? It happens to all of us... :-) But it reminds me something else: if you do anytime a manual change in the registry, please do not forget always to change also the timestamp field (unless it's done automatically by the RDBS) - otherwise the software relying on the new LSID versioning will not notice the change and cannot update various caches properly. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Sat Feb 25 13:57:00 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 13:57:00 +0000 (GMT) Subject: [MOBY-dev] where are all signature URLs? In-Reply-To: <1899503299-1140849949-cardhu_blackberry.rim.net-5259-@engine08-cell01> Message-ID: Thanks for the details, interesting. When reading your comments, I suddenly was not sure if we have the same understanding for LSID versioning. I guess we have but here is what slightly confused me: > was to modify the lsid in the namespace table (remove the underscore) > but keep the same timestamp, since that was the timestamp that the > service was registered under > This seems to me like a service version depends on the version of a namespace used by this service. Is it true? If yes then it differs from my version understanding - I thought that a version of a, for example, service is changed when the same service is registered again. But it does not change if the entities used by this service are changed (which is normally impossible, anyway, because except manual editing you cannot unregister and register again anything that other entities depend on). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Feb 25 13:57:11 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 13:57:11 +0000 (GMT) Subject: [MOBY-dev] jMoby updated - LSIDs used Message-ID: Dear all, Let me inform you that I have updated some classes in jMoby in order to take advantage of the new LSID versioning. The update of the local cache should be now able to pick up also changes inside individual entities. Please cvs update. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Feb 25 16:11:12 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 25 Feb 2006 08:11:12 -0800 Subject: [MOBY-dev] where are all signature URLs? In-Reply-To: References: Message-ID: I think we have the same understanding. I just didn't explain clearly what it is that I had to do. What had happened was (in temporal order, as best I can understand it): 1) Services were registered as consuming a particular namespace - the LSID of that namespace, without timestamp, as the primary key, was entered into that service's registry entry. 2) Then, somehow (?!?!?) a small number of namespace terms in the namespace database were altered by the addition of an underscore. I don't know why or when this happened... this, however, didn't affect the namespace's LSID, which is a different field in the namespace database, nor did it affect the namespace LSID's that were associated with the service instances in the registry. We didn't notice this at the time. 3) a few weeks ago I scripted the addition of a timestamp to every namespace LSID. For the Namespace database, I used the namespace term (some of them how with additional '_') as the template to create the associated namespace LSID. However, in the Service Instance table, I used the namespace LSID itself as the template, and simply appended a timestamp on to each namespace that the service instance was using. This SHOULD have been a safe operation... but because of this peculiar and unexplained addition of an underscore to certain namespaces, it was not. 4) At that point, the namespace LSID's associated with service instances went out of sync with the namespace LSID's that were in the namespace table. The namespace table LSIDs were e.g. urn:lsid:....:EMBL_:timestamp, but the service instance table LSIDs were urn:lsid:...:EMBL:timestamp Since the LSID is the primary key used to validate and retrieve namespace information, this ended up making some service regisrations "invalid" (they could not be retrieved properly anymore). What I was describing below was the operation that I did to fix the problem - I modified the LSIDs in the namespace table by removing the '_', but I didn't modify the timestamp, because if I had, then I would have had to update the namespace LSID in each of the services that used that namespace to keep them in sync (and then I'd have to update that service's service instance LSID as well...) Ugh... I hate working on the database manually! :-) M On Sat, 25 Feb 2006 05:57:00 -0800, Martin Senger wrote: > Thanks for the details, interesting. > When reading your comments, I suddenly was not sure if we have the > same > understanding for LSID versioning. I guess we have but here is what > slightly confused me: > >> was to modify the lsid in the namespace table (remove the underscore) >> but keep the same timestamp, since that was the timestamp that the >> service was registered under >> > This seems to me like a service version depends on the version of a > namespace used by this service. Is it true? If yes then it differs from > my > version understanding - I thought that a version of a, for example, > service is changed when the same service is registered again. But it does > not change if the entities used by this service are changed (which is > normally impossible, anyway, because except manual editing you cannot > unregister and register again anything that other entities depend on). > > Martin > From senger at ebi.ac.uk Sat Feb 25 16:25:07 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 25 Feb 2006 16:25:07 +0000 (GMT) Subject: [MOBY-dev] where are all signature URLs? In-Reply-To: Message-ID: Many thanks, I understand it now clearly. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From jmfernandez at cnb.uam.es Mon Feb 27 14:51:08 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon, 27 Feb 2006 15:51:08 +0100 Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) Message-ID: <440311DC.6040807@cnb.uam.es> Hi everybody, I'm trying to use the getSignatureForm CGI from Eddie, in order to update the RDF URL and description of my services, with no success. I have set up my domain (pdg.cnb.uam.es), no service instance name (I want only an RDF document for all my services) and the signature URL I'm going to use (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). The answer is: Unable to update your information Make sure that you specify a valid signature url! This field looks like the following: http://myAuthority.domain/path/to/rdf/for/service. Also make sure that you have specified the right case-sensitive service name, if applicable. What am I doing wrong? Best Regards, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From edward.kawas at gmail.com Mon Feb 27 15:27:52 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 27 Feb 2006 07:27:52 -0800 Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) In-Reply-To: <440311DC.6040807@cnb.uam.es> Message-ID: <000101c63bb2$60cb1fe0$6500a8c0@notebook> Give it a try now, the regular expression that I had didn?t like the - in the url. Sorry! Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Monday, February 27, 2006 6:51 AM > To: mobydev > Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) > > Hi everybody, > I'm trying to use the getSignatureForm CGI from Eddie, > in order to update the RDF URL and description of my > services, with no success. I have set up my domain > (pdg.cnb.uam.es), no service instance name (I want only an > RDF document for all my services) and the signature URL I'm > going to use > (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). The answer is: > > Unable to update your information > > Make sure that you specify a valid signature url! This > field looks like the following: > http://myAuthority.domain/path/to/rdf/for/service. > Also make sure that you have specified the right > case-sensitive service name, if applicable. > > What am I doing wrong? > > Best Regards, > Jos? Mar?a > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > (Spain) _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Mon Feb 27 17:39:34 2006 From: jmfernandez at cnb.uam.es (=?windows-1252?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon, 27 Feb 2006 18:39:34 +0100 Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) In-Reply-To: <000101c63bb2$60cb1fe0$6500a8c0@notebook> References: <000101c63bb2$60cb1fe0$6500a8c0@notebook> Message-ID: <44033956.9010900@cnb.uam.es> Thanks Eddie! Now it works! Now I have seen a cosmetic bug: the name of the returned file is '-moby-signature-moby.rdf' instead of 'signature-moby.rdf'. In other words, the returned file has in its name the prefix '-moby-'. Best Regards, Jos? Mar?a Edward Kawas wrote: > Give it a try now, the regular expression that I had didn?t like the - in > the url. > > Sorry! > > Eddie > >> -----Original Message----- >> From: moby-dev-bounces at biomoby.org >> [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a >> Fern?ndez Gonz?lez >> Sent: Monday, February 27, 2006 6:51 AM >> To: mobydev >> Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) >> >> Hi everybody, >> I'm trying to use the getSignatureForm CGI from Eddie, >> in order to update the RDF URL and description of my >> services, with no success. I have set up my domain >> (pdg.cnb.uam.es), no service instance name (I want only an >> RDF document for all my services) and the signature URL I'm >> going to use >> (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). The answer is: >> >> Unable to update your information >> >> Make sure that you specify a valid signature url! This >> field looks like the following: >> http://myAuthority.domain/path/to/rdf/for/service. >> Also make sure that you have specified the right >> case-sensitive service name, if applicable. >> >> What am I doing wrong? >> >> Best Regards, >> Jos? Mar?a >> -- >> Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es >> Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 >> Grupo de Dise?o de Proteinas Protein Design Group >> Centro Nacional de Biotecnolog?a National Center of Biotechnology >> C.P.: 28049 Zip Code: 28049 >> C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid >> (Spain) _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From markw at illuminae.com Mon Feb 27 18:03:30 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 27 Feb 2006 10:03:30 -0800 Subject: [MOBY-dev] [moby] Re: Problems with getSignatureForm (RDF related) In-Reply-To: <44033956.9010900@cnb.uam.es> References: <000101c63bb2$60cb1fe0$6500a8c0@notebook> <44033956.9010900@cnb.uam.es> Message-ID: <1141063410.23301.43.camel@bioinfo.icapture.ubc.ca> Also, Eddie, heads-up that you will need to add a predicate and node for the new "name" for secondary parameters. M On Mon, 2006-02-27 at 18:39 +0100, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Thanks Eddie! Now it works! > > Now I have seen a cosmetic bug: the name of the returned file is > '-moby-signature-moby.rdf' instead of 'signature-moby.rdf'. In other > words, the returned file has in its name the prefix '-moby-'. > > Best Regards, > Jos? Mar?a > > Edward Kawas wrote: > > Give it a try now, the regular expression that I had didn?t like the - in > > the url. > > > > Sorry! > > > > Eddie > > > >> -----Original Message----- > >> From: moby-dev-bounces at biomoby.org > >> [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > >> Fern?ndez Gonz?lez > >> Sent: Monday, February 27, 2006 6:51 AM > >> To: mobydev > >> Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) > >> > >> Hi everybody, > >> I'm trying to use the getSignatureForm CGI from Eddie, > >> in order to update the RDF URL and description of my > >> services, with no success. I have set up my domain > >> (pdg.cnb.uam.es), no service instance name (I want only an > >> RDF document for all my services) and the signature URL I'm > >> going to use > >> (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). The answer is: > >> > >> Unable to update your information > >> > >> Make sure that you specify a valid signature url! This > >> field looks like the following: > >> http://myAuthority.domain/path/to/rdf/for/service. > >> Also make sure that you have specified the right > >> case-sensitive service name, if applicable. > >> > >> What am I doing wrong? > >> > >> Best Regards, > >> Jos? Mar?a > >> -- > >> Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > >> Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > >> Grupo de Dise?o de Proteinas Protein Design Group > >> Centro Nacional de Biotecnolog?a National Center of Biotechnology > >> C.P.: 28049 Zip Code: 28049 > >> C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > >> (Spain) _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > > > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From edward.kawas at gmail.com Mon Feb 27 18:23:19 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 27 Feb 2006 10:23:19 -0800 Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) In-Reply-To: <44033956.9010900@cnb.uam.es> Message-ID: <000301c63bca$e4803d80$6500a8c0@notebook> I was aware of that bug. I didn?t want to parse the url myself, so using the tools available to me the file returned is called actually called x-filename where x is the path to the filename obtained from the url, i.e. http://myDomain.com/my/path/to/rdfDescription.rdf, x = -my-path-to- Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Monday, February 27, 2006 9:40 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Problems with getSignatureForm (RDF related) > > Thanks Eddie! Now it works! > > Now I have seen a cosmetic bug: the name of the > returned file is '-moby-signature-moby.rdf' instead of > 'signature-moby.rdf'. In other words, the returned file has > in its name the prefix '-moby-'. > > Best Regards, > Jos? Mar?a > > Edward Kawas wrote: > > Give it a try now, the regular expression that I had didn?t > like the - > > in the url. > > > > Sorry! > > > > Eddie > > > >> -----Original Message----- > >> From: moby-dev-bounces at biomoby.org > >> [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > >> Fern?ndez Gonz?lez > >> Sent: Monday, February 27, 2006 6:51 AM > >> To: mobydev > >> Subject: [MOBY-dev] Problems with getSignatureForm (RDF related) > >> > >> Hi everybody, > >> I'm trying to use the getSignatureForm CGI from Eddie, > in order to > >> update the RDF URL and description of my services, with no > success. I > >> have set up my domain (pdg.cnb.uam.es), no service > instance name (I > >> want only an RDF document for all my services) and the > signature URL > >> I'm going to use > (http://www.pdg.cnb.uam.es/moby/signature-moby.rdf). > >> The answer is: > >> > >> Unable to update your information > >> > >> Make sure that you specify a valid signature url! This field > >> looks like the following: > >> http://myAuthority.domain/path/to/rdf/for/service. > >> Also make sure that you have specified the right case-sensitive > >> service name, if applicable. > >> > >> What am I doing wrong? > >> > >> Best Regards, > >> Jos? Mar?a > >> -- > >> Jos? Mar?a Fern?ndez Gonz?lez e-mail: > jmfernandez at cnb.uam.es > >> Tlfn: (+34) 91 585 54 50 Fax: (+34) > 91 585 45 06 > >> Grupo de Dise?o de Proteinas Protein Design Group > >> Centro Nacional de Biotecnolog?a National Center of Biotechnology > >> C.P.: 28049 Zip Code: 28049 > >> C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > >> (Spain) _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > > > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > (Spain) _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Mon Feb 27 21:36:25 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 27 Feb 2006 14:36:25 -0700 Subject: [MOBY-dev] Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: References: Message-ID: <440370D9.3050009@ucalgary.ca> On a related note, can we clarify the documentation for Secondary Input in the MOBY API? Can min and max apply to floating point numbers, as well as to integers (e.g. I'd like to limit a real number between 0 and 1)? Can we set a minimum floating point accuracy or integer size a conforming implementation must acheive? Can we explicitly say in the doc that enumerations are for the String type only? >Dear all, > I have updated jMoby in order to handle description in/for the >secondary inputs (parameters). > > Regards, > Martin > > [ Details: > * MobySecondaryData includes now set/get method for description. Also >its toString(), toXML() and from XML method have been updated. > * Dashboard Registration panel now has an additional column in a table >creating definitions of the secondary inputs - allowing multi-line >descripion to be entered. ] > > > > From Pieter.Neerincx at wur.nl Mon Feb 27 22:44:58 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 27 Feb 2006 23:44:58 +0100 Subject: [MOBY-dev] Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <440370D9.3050009@ucalgary.ca> References: <440370D9.3050009@ucalgary.ca> Message-ID: <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> On 27Feb2006, at 22:36, Paul Gordon wrote: > On a related note, can we clarify the documentation for Secondary > Input > in the MOBY API? That would be a good idea. Currently they are only mentioned very briefly. > Can min and max apply to floating point numbers, as > well as to integers (e.g. I'd like to limit a real number between 0 > and > 1)? Can we set a minimum floating point accuracy or integer size a > conforming implementation must acheive? Can we explicitly say in > the doc > that enumerations are for the String type only? Hmmm I use enum for some integers as well. I think it's perfectly normal to say for example: enum [1,2,4,8]. Cheers, Pi > >> Dear all, >> I have updated jMoby in order to handle description in/for the >> secondary inputs (parameters). >> >> Regards, >> Martin >> >> [ Details: >> * MobySecondaryData includes now set/get method for >> description. Also >> its toString(), toXML() and from XML method have been updated. >> * Dashboard Registration panel now has an additional column in >> a table >> creating definitions of the secondary inputs - allowing multi-line >> descripion to be entered. ] >> >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 markw at illuminae.com Mon Feb 27 22:53:06 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 27 Feb 2006 14:53:06 -0800 Subject: [MOBY-dev] [moby] Re: Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> References: <440370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> Message-ID: <1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: > Hmmm I use enum for some integers as well. I think it's perfectly > normal to say for example: enum [1,2,4,8]. Perhaps Paul can clarify what problem he is trying to solve. My instincts tell me that maybe he is having difficulty with casting un- typed XML blocks as either Integer or String, as appropriate... is that a correct interpretation of the problem Paul? I think the combination of the block and the block should be able to indicate whether the ENUM is of type String or of type Integer (or Float, or whatever). Is that not sufficient? Or am I misunderstanding what the root of the problem is? M From gordonp at ucalgary.ca Mon Feb 27 23:55:12 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 27 Feb 2006 16:55:12 -0700 Subject: [MOBY-dev] [moby] Re: Suggestion for new tag in Parameter(Secondary Input specification) In-Reply-To: <1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> References: <440370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> <1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> Message-ID: <44039160.6090609@ucalgary.ca> The main problem: If somebody specifies a float, can I legally submit a e-value cutoff like "1.0e-180" (i.e. are we going to assume bit capacity, such as 2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary precision)? Underflow and overflow can cause problems on many systems... same thing for integers > 2^32... Actually, do we support scientific notation? That isn't mentioned either. Cheers, Paul P.S. Yes, you are right Pieter. You could enumerate integers, or even floats for that matter: this distinction matters for a server with strong types, but not for the client. I've been too client centric lately :-) >On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: > > > >>Hmmm I use enum for some integers as well. I think it's perfectly >>normal to say for example: enum [1,2,4,8]. >> >> > >Perhaps Paul can clarify what problem he is trying to solve. My >instincts tell me that maybe he is having difficulty with casting un- >typed XML blocks as either Integer or String, as appropriate... is that >a correct interpretation of the problem Paul? > >I think the combination of the block and the block >should be able to indicate whether the ENUM is of type String or of type >Integer (or Float, or whatever). Is that not sufficient? Or am I >misunderstanding what the root of the problem is? > >M > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev > > From gordonp at ucalgary.ca Tue Feb 28 01:35:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 27 Feb 2006 18:35:43 -0700 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" Message-ID: <4403A8EF.5070603@ucalgary.ca> I'm not sure who runs the service "RunNCBIBlastn", but when I get an exception returned, it comes in a ServiceNotes tag, not a serviceNotes tag (note capitalization). Can this be fixed please? Thanks! From jmfernandez at cnb.uam.es Tue Feb 28 12:14:44 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Tue, 28 Feb 2006 13:14:44 +0100 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <44039160.6090609@ucalgary.ca> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl>< 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> Message-ID: <44043EB4.1070108@cnb.uam.es> I think we should choose the corresponding XML Schema types for each primitive object. For instance: moby:String -> xsd:string (it would not allow XML content) or xsd:anyType (any content) moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* integer) moby:Float -> xsd:double (IEEE double-precision 64-bit floating point type), xsd:float (IEEE single-precision 32-bit floating point type) or xsd:decimal (*any* real number with a finite number of decimal digits) moby:DateTime -> xsd:dateTime moby:Boolean -> xsd:boolean or an enumerated xsd:string {'0','1','false','true'} Best Regards, Jos? Mar?a Paul Gordon wrote: > The main problem: > > If somebody specifies a float, can I legally submit a e-value cutoff > like "1.0e-180" (i.e. are we going to assume bit capacity, such as > 2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary > precision)? Underflow and overflow can cause problems on many > systems... same thing for integers > 2^32... > > Actually, do we support scientific notation? That isn't mentioned either. > > Cheers, > Paul > > P.S. Yes, you are right Pieter. You could enumerate integers, or even > floats for that matter: this distinction matters for a server with > strong types, but not for the client. I've been too client centric > lately :-) > >> On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: >> >> >> >>> Hmmm I use enum for some integers as well. I think it's perfectly >>> normal to say for example: enum [1,2,4,8]. >>> >>> >> Perhaps Paul can clarify what problem he is trying to solve. My >> instincts tell me that maybe he is having difficulty with casting un- >> typed XML blocks as either Integer or String, as appropriate... is that >> a correct interpretation of the problem Paul? >> >> I think the combination of the block and the block >> should be able to indicate whether the ENUM is of type String or of type >> Integer (or Float, or whatever). Is that not sufficient? Or am I >> misunderstanding what the root of the problem is? >> >> M >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From senger at ebi.ac.uk Tue Feb 28 13:05:48 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 28 Feb 2006 13:05:48 +0000 (GMT) Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: <4403A8EF.5070603@ucalgary.ca> Message-ID: > I'm not sure who runs the service "RunNCBIBlastn", but when I get an > exception returned, it comes in a ServiceNotes tag, not a serviceNotes > tag (note capitalization). > BTW, both are wrong, of course: it should be in .... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Tue Feb 28 14:37:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 28 Feb 2006 15:37:37 +0100 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: References: Message-ID: On 28-Feb-2006, at 2:05 PM, Martin Senger wrote: >> I'm not sure who runs the service "RunNCBIBlastn", but when I get an >> exception returned, it comes in a ServiceNotes tag, not a >> serviceNotes >> tag (note capitalization). >> > BTW, both are wrong, of course: it should be in > .... Which reminds me: in Perl MOBY/Commonsubs.pm also still generates .... So basically all the services that use the Perl API are incompatible as well :(. Does Anyone have objections if I change that to ...? Cheers, Pi > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Tue Feb 28 14:52:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 28 Feb 2006 06:52:29 -0800 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: References: Message-ID: On Tue, 28 Feb 2006 06:37:37 -0800, Pieter Neerincx wrote: > So basically all the services that > use the Perl API are incompatible as well :(. Does Anyone have > objections if I change that to ... serviceNotes>? Please do! M From gordonp at ucalgary.ca Tue Feb 28 15:09:53 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 28 Feb 2006 08:09:53 -0700 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <44043EB4.1070108@cnb.uam.es> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl>< 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> <44043EB4.1070108@cnb.uam.es> Message-ID: <440467C1.5060801@ucalgary.ca> Given that the size of the human genome exceeds the limits of a xsd:int, and that we often use e-values exceeding the limits of xsd:double, may I suggest that we mandate the equivalents to xsd:integer and xsd:decimal? I have built my jMOBY code using arbitrary precision numbers, but I'm sure we'll need to change other parts of it, and of the Perl libraries... >I think we should choose the corresponding XML Schema types for each >primitive object. For instance: > >moby:String -> xsd:string (it would not allow XML content) or >xsd:anyType (any content) > >moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* >integer) > >moby:Float -> xsd:double (IEEE double-precision 64-bit floating point >type), xsd:float (IEEE single-precision 32-bit floating point type) or >xsd:decimal (*any* real number with a finite number of decimal digits) > >moby:DateTime -> xsd:dateTime > >moby:Boolean -> xsd:boolean or an enumerated xsd:string >{'0','1','false','true'} > > Best Regards, > Jos? Mar?a > >Paul Gordon wrote: > > >>The main problem: >> >>If somebody specifies a float, can I legally submit a e-value cutoff >>like "1.0e-180" (i.e. are we going to assume bit capacity, such as >>2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary >>precision)? Underflow and overflow can cause problems on many >>systems... same thing for integers > 2^32... >> >>Actually, do we support scientific notation? That isn't mentioned either. >> >>Cheers, >>Paul >> >>P.S. Yes, you are right Pieter. You could enumerate integers, or even >>floats for that matter: this distinction matters for a server with >>strong types, but not for the client. I've been too client centric >>lately :-) >> >> >> >>>On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: >>> >>> >>> >>> >>> >>>>Hmmm I use enum for some integers as well. I think it's perfectly >>>>normal to say for example: enum [1,2,4,8]. >>>> >>>> >>>> >>>> >>>Perhaps Paul can clarify what problem he is trying to solve. My >>>instincts tell me that maybe he is having difficulty with casting un- >>>typed XML blocks as either Integer or String, as appropriate... is that >>>a correct interpretation of the problem Paul? >>> >>>I think the combination of the block and the block >>>should be able to indicate whether the ENUM is of type String or of type >>>Integer (or Float, or whatever). Is that not sufficient? Or am I >>>misunderstanding what the root of the problem is? >>> >>>M >>> >>> >>> >>>_______________________________________________ >>>MOBY-dev mailing list >>>MOBY-dev at biomoby.org >>>http://biomoby.org/mailman/listinfo/moby-dev >>> >>> >>> >>> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev >> >> >> >> > > > From ots at ac.uma.es Fri Feb 24 18:24:36 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 24 Feb 2006 19:24:36 +0100 Subject: [MOBY-dev] [moby] Suggestion for new tag in Parameter(SecondaryInput specification) References: <43FDF73B.5040105@ucalgary.ca><1140718289.5536.1.camel@bioinfo.icapture.ubc.ca><43FEF18E.3040103@ac.uma.es><9ED0FD16-EE18-4047-963B-81B908CADDF4@wur.nl> <02b201c6396c$c46655d0$346dd696@ac.uma.es> Message-ID: <02f301c6396f$91123340$346dd696@ac.uma.es> sorry, as usual.. here the attach for the previous email O. ----- Original Message ----- From: "Oswaldo Trelles" To: "Core developer announcements" Cc: Sent: Friday, February 24, 2006 7:04 PM Subject: Re: [MOBY-dev] [moby] Suggestion for new tag in Parameter(SecondaryInput specification) > Hi all and Pieter in particular: > > > > This is Oswaldo from the gnv5 -University of Malaga- group at the INB. > Perhaps Pieter's mail needs some additional information from our group to > better understand some aspects of the INB architecture. > > > > The INB project was started in March'04, a major decision was make to use > BioMOBY as the underlying integration protocol. However, several of the > desirable functionalities were not available in the protocol, specially > important from the INB perspective were the ability to launch large-CPU > tasks using asynchronous messaging; a protocol for error handling (and, in > the way, some specific rules for dealing with collections; help information, > DB optimization, etc etc. we expect to propose extensions in these fields. > soon). > > > > However, we design the architecture keeping in mind to maintain full > compatibility with moby. A good example is our current async implementation > (see the attached document for a longer description). What can we learn from > this document? that we extend the protocol -async- even with the double cost > of maintain moby compatibility: Even more, our current proposal for async > was born during the INB meeting (July'05) and discussed with Martin and > Eddie. This proposal is completely new and -if approved- we will need to > re-write our async code (well, not at all). Thus, once we are part of the > moby group and our ideas can be taken into account, we will move closer in > the moby direction to avoid double work from our side (as you can imagine, > this is what we want). > > > > On the other hand, our registration procedure -in my opinion- does not break > our moby compatibility. In fact you can use directly all the services we > have developed. If you see the new fields, most of them are used to allow > (user-friendly and self explicative) automatic interface building. SO they > don't have any influence in the services call protocol. > > > > We of course will be happy to propose a documentation system and other > extensions, but at this moment there are other priorities. > > In sumary; in fact we have our own ideas about a full protocol. For > strategic reasons we develeop at our own cost, some moby extension (from a > practical point of view, we took our own decisions because we needed a fast > development -you know that error handling have spent more than 4 months in > discussion!!!!). But we dont want to break moby (and we are not going to do > that). > > sorry for this long (and boring) dissertation. > > Oswaldo > > PS with repect to the registration procedure, it can be done using moby > functionality, but we request additional information to be used by our > client (if you want addictional information on our protocol dont hesitate to > request) > > > > > I read the INB paper "Intelligent client for integrating > > bioinformatics services" published in Bioinformatics. The things > > mentioned above were described there and it made me wonder... For > > asynchronous service calls the INB leads an initiative to extend the > > BioMOBY standard, which is great! This may take a bit longer to get > > accepted and implemented as compared to hacking together some custom > > extension, but it makes sure that your BioMOBY services are > > compatible with the rest of the BioMOBY world. The INB did the same > > for error handling. But for the things mentioned above the INB people > > chose to go their own way. The "extended service registration" > > procedure is INB specific and the additional (help) info is available > > form a "fourth party" server (not the BioMOBY client, nor the service > > provider, nor the INB BioMOBY Central). I think this is bad. The INB > > BioMOBY Central is out of sync with the official BioMOBY Central and > > no longer compatible, because of the modified registration procedure : > > (. Personally I think this is even worse... > > > > Anyway the things mentioned above would definitely be useful! The > > secondary parameter description was just added to the service > > registration call. So that's solved. When I retrieve a service I get > > the BioMOBY WSDL that contains amongst others all the description > > fields. If I have a typical BLAST service that supports all 40+ > > parameters it also means that this WSDL will hold the description for > > 40+ params. It's getting big...:). So adding additional help in XML > > format and example input and output there (during registration) would > > make the WSDL we send around even longer. Not my favourite solution. > > > > I would rather like to see a solution where this additional > > information is provided by the service (provider) and only when the > > client requests it explicitly. This way it doesn't need to be stored > > in a BioMOBY Central. This could be done for example using an > > additional method [ServiceName]_help. If this would be standardised > > the new RDF agent, might be extended and use this method to get the > > example input, excute the service with this example input and > > validate the results. It can than check: > > * whether the service works > > * if the input and output are valid as compared to how the service > > was registered. > > If these checks fail it might send an automated e-mail to the > > maintainer of that service and eventually if the issues are not > > resolved remove the service from BioMOBY Central. In the "cleaning > > out the registry" thread Mark mentioned that he would contact service > > providers whose services work perfectly well, but were registered > > incorrectly. No matter how efficient Mark might work, sooner or later > > BioMOBY will be so popular and BioMOBY Central so big, that doing > > this manually won't be feasible anymore. So this needs to be > > automated sooner or later anyway. Having example input and output > > might be used for that. So what do the others think... > > > > Just my 2c, > > > > Pi > > > > > > > > Kind regards, > > > Johan Karlsson > > > > > > Mark Wilkinson wrote: > > >> Absolutely - I believe the INB had also requested this a while > > >> ago, too. > > >> > > >> Do we need to go through an RFC for this? I hope not... > > >> > > >> If nobody objects, I'll add it to the API right away. It should only > > >> take a couple of minutes to code. > > >> > > >> M > > >> > > >> > > >> > > >> On Thu, 2006-02-23 at 10:56 -0700, Paul Gordon wrote: > > >> > > >>> Can we add an optional description field to the secondary article > > >>> tag? > > >>> It might help people fill it out if they have a hint *what* they're > > >>> filling out besides the articleName. i.e.: > > >>> > > >>> > > >>> This field sets the frameshift penalty in the alignment. > > >>> The higher it is set, the less likely frameshifts will be > > >>> detected and corrected. > > >>> Integer|Float|String|DateTime > > >>> ... > > >>> ... > > >>> ... > > >>> ... > > >>> ... > > >>> > > >>> > > >>> Sound reasonable? Does this require a RFC? > > >>> > > >>> _______________________________________________ > > >>> MOBY-dev mailing list > > >>> MOBY-dev at biomoby.org > > >>> http://biomoby.org/mailman/listinfo/moby-dev > > >>> > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://biomoby.org/mailman/listinfo/moby-dev > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: asynchMOBY.pdf Type: application/pdf Size: 56693 bytes Desc: not available URL: From Sebastien.Carrere at toulouse.inra.fr Tue Feb 28 15:06:19 2006 From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere) Date: Tue, 28 Feb 2006 16:06:19 +0100 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: References: Message-ID: <440466EB.9000205@toulouse.inra.fr> Hello Pieter, I agree with you for making this change in the responseHeader sub. However, shouldn't we rewritte completely this sub to also include Error handling in the block ? Maybe this sub should have a "-exception" parameter . What do you think about this ? Cordialement, Sebastien Pieter Neerincx a ?crit : > On 28-Feb-2006, at 2:05 PM, Martin Senger wrote: > > >>> I'm not sure who runs the service "RunNCBIBlastn", but when I get an >>> exception returned, it comes in a ServiceNotes tag, not a >>> serviceNotes >>> tag (note capitalization). >>> >>> >> BTW, both are wrong, of course: it should be in >> .... >> > > Which reminds me: in Perl MOBY/Commonsubs.pm also still generates > .... So basically all the services that > use the Perl API are incompatible as well :(. Does Anyone have > objections if I change that to ... serviceNotes>? > > Cheers, > > Pi > > >> Martin >> >> -- >> Martin Senger >> email: martin.senger at gmail.com >> skype: martinsenger >> consulting for: >> International Rice Research Institute >> Biometrics and Bioinformatics Unit >> DAPO BOX 7777, Metro Manila >> Philippines, phone: +63-2-580-5600 (ext.2324) >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Tue Feb 28 16:35:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 28 Feb 2006 08:35:29 -0800 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <440467C1.5060801@ucalgary.ca> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> < 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> <44043EB4.1070108@cnb.uam.es> <440467C1.5060801@ucalgary.ca> Message-ID: <1141144529.17722.30.camel@bioinfo.icapture.ubc.ca> Hi Paul, Could you collect together the various ideas that have come up in this thread and present a formal proposal? Cheers! M On Tue, 2006-02-28 at 08:09 -0700, Paul Gordon wrote: > Given that the size of the human genome exceeds the limits of a xsd:int, > and that we often use e-values exceeding the limits of xsd:double, may I > suggest that we mandate the equivalents to xsd:integer and xsd:decimal? > I have built my jMOBY code using arbitrary precision numbers, but I'm > sure we'll need to change other parts of it, and of the Perl libraries... > > >I think we should choose the corresponding XML Schema types for each > >primitive object. For instance: > > > >moby:String -> xsd:string (it would not allow XML content) or > >xsd:anyType (any content) > > > >moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* > >integer) > > > >moby:Float -> xsd:double (IEEE double-precision 64-bit floating point > >type), xsd:float (IEEE single-precision 32-bit floating point type) or > >xsd:decimal (*any* real number with a finite number of decimal digits) > > > >moby:DateTime -> xsd:dateTime > > > >moby:Boolean -> xsd:boolean or an enumerated xsd:string > >{'0','1','false','true'} > > > > Best Regards, > > Jos? Mar?a > > > >Paul Gordon wrote: > > > > > >>The main problem: > >> > >>If somebody specifies a float, can I legally submit a e-value cutoff > >>like "1.0e-180" (i.e. are we going to assume bit capacity, such as > >>2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary > >>precision)? Underflow and overflow can cause problems on many > >>systems... same thing for integers > 2^32... > >> > >>Actually, do we support scientific notation? That isn't mentioned either. > >> > >>Cheers, > >>Paul > >> > >>P.S. Yes, you are right Pieter. You could enumerate integers, or even > >>floats for that matter: this distinction matters for a server with > >>strong types, but not for the client. I've been too client centric > >>lately :-) > >> > >> > >> > >>>On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: > >>> > >>> > >>> > >>> > >>> > >>>>Hmmm I use enum for some integers as well. I think it's perfectly > >>>>normal to say for example: enum [1,2,4,8]. > >>>> > >>>> > >>>> > >>>> > >>>Perhaps Paul can clarify what problem he is trying to solve. My > >>>instincts tell me that maybe he is having difficulty with casting un- > >>>typed XML blocks as either Integer or String, as appropriate... is that > >>>a correct interpretation of the problem Paul? > >>> > >>>I think the combination of the block and the block > >>>should be able to indicate whether the ENUM is of type String or of type > >>>Integer (or Float, or whatever). Is that not sufficient? Or am I > >>>misunderstanding what the root of the problem is? > >>> > >>>M > >>> > >>> > >>> > >>>_______________________________________________ > >>>MOBY-dev mailing list > >>>MOBY-dev at biomoby.org > >>>http://biomoby.org/mailman/listinfo/moby-dev > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev at biomoby.org > >>http://biomoby.org/mailman/listinfo/moby-dev > >> > >> > >> > >> > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From gordonp at ucalgary.ca Tue Feb 28 17:23:28 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 28 Feb 2006 10:23:28 -0700 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <1141144529.17722.30.camel@bioinfo.icapture.ubc.ca> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl> < 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> <44043EB4.1070108@cnb.uam.es> <440467C1.5060801@ucalgary.ca> <1141144529.17722.30.camel@bioinfo.icapture.ubc.ca> Message-ID: <44048710.2000903@ucalgary.ca> Sure. >Hi Paul, > >Could you collect together the various ideas that have come up in this >thread and present a formal proposal? > >Cheers! > >M > > > >On Tue, 2006-02-28 at 08:09 -0700, Paul Gordon wrote: > > >>Given that the size of the human genome exceeds the limits of a xsd:int, >>and that we often use e-values exceeding the limits of xsd:double, may I >>suggest that we mandate the equivalents to xsd:integer and xsd:decimal? >>I have built my jMOBY code using arbitrary precision numbers, but I'm >>sure we'll need to change other parts of it, and of the Perl libraries... >> >> >> >>>I think we should choose the corresponding XML Schema types for each >>>primitive object. For instance: >>> >>>moby:String -> xsd:string (it would not allow XML content) or >>>xsd:anyType (any content) >>> >>>moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* >>>integer) >>> >>>moby:Float -> xsd:double (IEEE double-precision 64-bit floating point >>>type), xsd:float (IEEE single-precision 32-bit floating point type) or >>>xsd:decimal (*any* real number with a finite number of decimal digits) >>> >>>moby:DateTime -> xsd:dateTime >>> >>>moby:Boolean -> xsd:boolean or an enumerated xsd:string >>>{'0','1','false','true'} >>> >>> Best Regards, >>> Jos? Mar?a >>> >>>Paul Gordon wrote: >>> >>> >>> >>> >>>>The main problem: >>>> >>>>If somebody specifies a float, can I legally submit a e-value cutoff >>>>like "1.0e-180" (i.e. are we going to assume bit capacity, such as >>>>2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary >>>>precision)? Underflow and overflow can cause problems on many >>>>systems... same thing for integers > 2^32... >>>> >>>>Actually, do we support scientific notation? That isn't mentioned either. >>>> >>>>Cheers, >>>>Paul >>>> >>>>P.S. Yes, you are right Pieter. You could enumerate integers, or even >>>>floats for that matter: this distinction matters for a server with >>>>strong types, but not for the client. I've been too client centric >>>>lately :-) >>>> >>>> >>>> >>>> >>>> >>>>>On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hmmm I use enum for some integers as well. I think it's perfectly >>>>>>normal to say for example: enum [1,2,4,8]. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Perhaps Paul can clarify what problem he is trying to solve. My >>>>>instincts tell me that maybe he is having difficulty with casting un- >>>>>typed XML blocks as either Integer or String, as appropriate... is that >>>>>a correct interpretation of the problem Paul? >>>>> >>>>>I think the combination of the block and the block >>>>>should be able to indicate whether the ENUM is of type String or of type >>>>>Integer (or Float, or whatever). Is that not sufficient? Or am I >>>>>misunderstanding what the root of the problem is? >>>>> >>>>>M >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>MOBY-dev mailing list >>>>>MOBY-dev at biomoby.org >>>>>http://biomoby.org/mailman/listinfo/moby-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>MOBY-dev mailing list >>>>MOBY-dev at biomoby.org >>>>http://biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev >> >> From francis_gibbons at hms.harvard.edu Tue Feb 28 17:58:48 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 28 Feb 2006 12:58:48 -0500 Subject: [MOBY-dev] service registration situation.... Message-ID: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> OK, I got caught up in the service clean-up enthusiasm (roll on spring!), dereg'd all of my services, then rereg'd some of them. All seemed to go smoothly, and I can retrieve service details without difficulty. But now nothing works. As usual, due to the layering inherent in web services (SOAP/HTTP, XML parsing, etc.), I'm having a really hard time figuring out *where* the problem lies. I've tried using scripts/DebugYourService.pl, >DebugYourService.pl -a llama.med.harvard.edu -n Uetz -i simple.xml with this input (simple.xml): > > > > > and got this output: >Using default BioMOBY Central. >--------------- >Using service: > name: Uetz > authority: llama.med.harvard.edu > Description: Protein-protein interactions, by Uetz et al >--------------- >Service execution failed: 500 Can't connect to :80 (Bad hostname '') at >MOBY/Client/Service.pm line 289 The last line is totally weird! The test suite runs without errors, and I'm using the latest moby-live/Perl code under Perl 5.8.6, with SOAP::Lite v0.60. Anybody have any ideas where I should look? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Feb 28 18:40:37 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 28 Feb 2006 10:40:37 -0800 Subject: [MOBY-dev] [moby] service registration situation.... In-Reply-To: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> References: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> Message-ID: <1141152037.18276.9.camel@bioinfo.icapture.ubc.ca> Your service registrations are not correct - this is what is in the WSDL: This is confirmed by looking at the database entry: | moby | Uetz | urn:lsid:biomoby.org:servicetype:Retrieval:2001-09-21T16-00-00Z | 43 | http:///~fgibbons/cgi/BGN/dispatcher.pl | fgibbons at hms.harvard.edu | 0 | Protein-protein interactions, by Uetz et al. | 9727 | NULL | urn:lsid:biomoby.org:serviceinstance:llama.med.harvard.edu,Uetz:2006-02-27T19-03-39Z | Can you check if this is a problem with the registration system that you are using, or is it something mis-configured at your end? Whose bug is it?? M On Tue, 2006-02-28 at 12:58 -0500, Frank Gibbons wrote: > OK, > > I got caught up in the service clean-up enthusiasm (roll on spring!), > dereg'd all of my services, then rereg'd some of them. All seemed to go > smoothly, and I can retrieve service details without difficulty. > > But now nothing works. As usual, due to the layering inherent in web > services (SOAP/HTTP, XML parsing, etc.), I'm having a really hard time > figuring out *where* the problem lies. > > I've tried using scripts/DebugYourService.pl, > > >DebugYourService.pl -a llama.med.harvard.edu -n Uetz -i simple.xml > > with this input (simple.xml): > > > > > > > > > > > > > and got this output: > > >Using default BioMOBY Central. > >--------------- > >Using service: > > name: Uetz > > authority: llama.med.harvard.edu > > Description: Protein-protein interactions, by Uetz et al > >--------------- > >Service execution failed: 500 Can't connect to :80 (Bad hostname '') at > >MOBY/Client/Service.pm line 289 > > The last line is totally weird! The test suite runs without errors, and I'm > using the latest moby-live/Perl code under Perl 5.8.6, with SOAP::Lite v0.60. > > Anybody have any ideas where I should look? > > -Frank > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From francis_gibbons at hms.harvard.edu Tue Feb 28 18:58:12 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 28 Feb 2006 13:58:12 -0500 Subject: [MOBY-dev] [moby] service registration situation.... In-Reply-To: <1141152037.18276.9.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060228135638.01258b30@email.med.harvard.edu> Thanks Mark - looks like I mis-registered the address, likely a mis-configuration of the script I use to register services. Strangely, it used to work, but I haven't used it in a while. I'll fix it and try again - thanks for quick response, sorry for inconvenience. My bug. -Frank At 01:40 PM 2/28/2006, you wrote: >Your service registrations are not correct - this is what is in the >WSDL: > > > >This is confirmed by looking at the database entry: >| moby | Uetz | >urn:lsid:biomoby.org:servicetype:Retrieval:2001-09-21T16-00-00Z | >43 | http:///~fgibbons/cgi/BGN/dispatcher.pl | fgibbons at hms.harvard.edu >| 0 | Protein-protein interactions, by Uetz et al. > | 9727 | NULL | >urn:lsid:biomoby.org:serviceinstance:llama.med.harvard.edu,Uetz:2006-02-27T19-03-39Z >| > > >Can you check if this is a problem with the registration system that you >are using, or is it something mis-configured at your end? > >Whose bug is it?? > >M > > > > > >On Tue, 2006-02-28 at 12:58 -0500, Frank Gibbons wrote: > > OK, > > > > I got caught up in the service clean-up enthusiasm (roll on spring!), > > dereg'd all of my services, then rereg'd some of them. All seemed to go > > smoothly, and I can retrieve service details without difficulty. > > > > But now nothing works. As usual, due to the layering inherent in web > > services (SOAP/HTTP, XML parsing, etc.), I'm having a really hard time > > figuring out *where* the problem lies. > > > > I've tried using scripts/DebugYourService.pl, > > > > >DebugYourService.pl -a llama.med.harvard.edu -n Uetz -i simple.xml > > > > with this input (simple.xml): > > > > > > > > > > > > > > > > > > > > > and got this output: > > > > >Using default BioMOBY Central. > > >--------------- > > >Using service: > > > name: Uetz > > > authority: llama.med.harvard.edu > > > Description: Protein-protein interactions, by Uetz et al > > >--------------- > > >Service execution failed: 500 Can't connect to :80 (Bad hostname '') at > > >MOBY/Client/Service.pm line 289 > > > > The last line is totally weird! The test suite runs without errors, and > I'm > > using the latest moby-live/Perl code under Perl 5.8.6, with SOAP::Lite > v0.60. > > > > Anybody have any ideas where I should look? > > > > -Frank > > > > > > PhD, Computational Biologist, > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > > Tel: 617-432-3555 Fax: > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev >-- > >-- >Mark Wilkinson >Asst. Professor, Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics, iCAPTURE Centre >St. Paul's Hospital, Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Feb 28 19:18:39 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 28 Feb 2006 11:18:39 -0800 Subject: [MOBY-dev] [moby] service registration situation.... In-Reply-To: <5.2.1.1.2.20060228135638.01258b30@email.med.harvard.edu> References: <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> <5.2.1.1.2.20060228124656.012514f8@email.med.harvard.edu> <5.2.1.1.2.20060228135638.01258b30@email.med.harvard.edu> Message-ID: <1141154319.18276.35.camel@bioinfo.icapture.ubc.ca> no worries :-) M On Tue, 2006-02-28 at 13:58 -0500, Frank Gibbons wrote: > Thanks Mark - looks like I mis-registered the address, likely a > mis-configuration of the script I use to register services. Strangely, it > used to work, but I haven't used it in a while. I'll fix it and try again - > thanks for quick response, sorry for inconvenience. > > My bug. > > -Frank > > At 01:40 PM 2/28/2006, you wrote: > >Your service registrations are not correct - this is what is in the > >WSDL: > > > > > > > >This is confirmed by looking at the database entry: > >| moby | Uetz | > >urn:lsid:biomoby.org:servicetype:Retrieval:2001-09-21T16-00-00Z | > >43 | http:///~fgibbons/cgi/BGN/dispatcher.pl | fgibbons at hms.harvard.edu > >| 0 | Protein-protein interactions, by Uetz et al. > > | 9727 | NULL | > >urn:lsid:biomoby.org:serviceinstance:llama.med.harvard.edu,Uetz:2006-02-27T19-03-39Z > >| > > > > > >Can you check if this is a problem with the registration system that you > >are using, or is it something mis-configured at your end? > > > >Whose bug is it?? > > > >M > > > > > > > > > > > >On Tue, 2006-02-28 at 12:58 -0500, Frank Gibbons wrote: > > > OK, > > > > > > I got caught up in the service clean-up enthusiasm (roll on spring!), > > > dereg'd all of my services, then rereg'd some of them. All seemed to go > > > smoothly, and I can retrieve service details without difficulty. > > > > > > But now nothing works. As usual, due to the layering inherent in web > > > services (SOAP/HTTP, XML parsing, etc.), I'm having a really hard time > > > figuring out *where* the problem lies. > > > > > > I've tried using scripts/DebugYourService.pl, > > > > > > >DebugYourService.pl -a llama.med.harvard.edu -n Uetz -i simple.xml > > > > > > with this input (simple.xml): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and got this output: > > > > > > >Using default BioMOBY Central. > > > >--------------- > > > >Using service: > > > > name: Uetz > > > > authority: llama.med.harvard.edu > > > > Description: Protein-protein interactions, by Uetz et al > > > >--------------- > > > >Service execution failed: 500 Can't connect to :80 (Bad hostname '') at > > > >MOBY/Client/Service.pm line 289 > > > > > > The last line is totally weird! The test suite runs without errors, and > > I'm > > > using the latest moby-live/Perl code under Perl 5.8.6, with SOAP::Lite > > v0.60. > > > > > > Anybody have any ideas where I should look? > > > > > > -Frank > > > > > > > > > PhD, Computational Biologist, > > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > > USA. > > > Tel: 617-432-3555 Fax: > > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://biomoby.org/mailman/listinfo/moby-dev > >-- > > > >-- > >Mark Wilkinson > >Asst. Professor, Dept. of Medical Genetics > >University of British Columbia > >PI in Bioinformatics, iCAPTURE Centre > >St. Paul's Hospital, Rm. 166, 1081 Burrard St. > >Vancouver, BC, V6Z 1Y6 > >tel: 604 682 2344 x62129 > >fax: 604 806 9274 > > > >"For most of this century we have viewed communications as a conduit, > > a pipe between physical locations on the planet. > >What's happened now is that the conduit has become so big and interesting > > that communication has become more than a conduit, > > it has become a destination in its own right..." > > > > Paul Saffo - Director, Institute for the Future > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Tue Feb 28 19:59:01 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 28 Feb 2006 20:59:01 +0100 Subject: [MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification) In-Reply-To: <44043EB4.1070108@cnb.uam.es> References: <4 40370D9.3050009@ucalgary.ca> <59D68A1B-3E73-4783-9462-DCBAEB7310DB@wur.nl>< 1141080786.25053.13.camel@bioinfo.icapture.ubc.ca> <44039160.6090609@ucalgary.ca> <44043EB4.1070108@cnb.uam.es> Message-ID: <76307C2D-96BF-4AA2-83E1-8E4B66030AD2@wur.nl> Sounds like a good plan to me... Cheers, Pi On 28Feb2006, at 13:14, Jos? Mar?a Fern?ndez Gonz?lez wrote: > I think we should choose the corresponding XML Schema types for each > primitive object. For instance: > > moby:String -> xsd:string (it would not allow XML content) or > xsd:anyType (any content) > > moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* > integer) > > moby:Float -> xsd:double (IEEE double-precision 64-bit floating point > type), xsd:float (IEEE single-precision 32-bit floating point type) or > xsd:decimal (*any* real number with a finite number of decimal digits) > > moby:DateTime -> xsd:dateTime > > moby:Boolean -> xsd:boolean or an enumerated xsd:string > {'0','1','false','true'} > > Best Regards, > Jos? Mar?a > > Paul Gordon wrote: >> The main problem: >> >> If somebody specifies a float, can I legally submit a e-value cutoff >> like "1.0e-180" (i.e. are we going to assume bit capacity, such as >> 2^-149 for 16-byte IEEE floating point, or are we supporting >> arbitrary >> precision)? Underflow and overflow can cause problems on many >> systems... same thing for integers > 2^32... >> >> Actually, do we support scientific notation? That isn't mentioned >> either. >> >> Cheers, >> Paul >> >> P.S. Yes, you are right Pieter. You could enumerate integers, or >> even >> floats for that matter: this distinction matters for a server with >> strong types, but not for the client. I've been too client centric >> lately :-) >> >>> On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote: >>> >>> >>> >>>> Hmmm I use enum for some integers as well. I think it's perfectly >>>> normal to say for example: enum [1,2,4,8]. >>>> >>>> >>> Perhaps Paul can clarify what problem he is trying to solve. My >>> instincts tell me that maybe he is having difficulty with casting >>> un- >>> typed XML blocks as either Integer or String, as appropriate... >>> is that >>> a correct interpretation of the problem Paul? >>> >>> I think the combination of the block and the block >>> should be able to indicate whether the ENUM is of type String or >>> of type >>> Integer (or Float, or whatever). Is that not sufficient? Or am I >>> misunderstanding what the root of the problem is? >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> >> > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 Pieter.Neerincx at wur.nl Tue Feb 28 21:52:02 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 28 Feb 2006 22:52:02 +0100 Subject: [MOBY-dev] To Whom It May Concern Regarding The Service "RunNCBIBlastn" In-Reply-To: <440466EB.9000205@toulouse.inra.fr> References: <440466EB.9000205@toulouse.inra.fr> Message-ID: On 28Feb2006, at 16:06, Sebastien Carrere wrote: > Hello Pieter, > > I agree with you for making this change in the responseHeader sub. Done :). > However, shouldn't we rewritte completely this sub to also include > Error > handling in the block ? > Maybe this sub should have a "-exception" parameter . > > What do you think about this ? Yes we should, but that requires a bit more work and debugging. Moving the human readable stuff to Notes inside serviceNotes was a 5 minute fix. So at least we're compatible with the current specs again although the advanced error handling is not implemented yet. Cheers, Pi > Cordialement, > Sebastien > > > > Pieter Neerincx a ?crit : >> On 28-Feb-2006, at 2:05 PM, Martin Senger wrote: >> >> >>>> I'm not sure who runs the service "RunNCBIBlastn", but when I >>>> get an >>>> exception returned, it comes in a ServiceNotes tag, not a >>>> serviceNotes >>>> tag (note capitalization). >>>> >>>> >>> BTW, both are wrong, of course: it should be in >>> .... >>> >> >> Which reminds me: in Perl MOBY/Commonsubs.pm also still generates >> .... So basically all the services that >> use the Perl API are incompatible as well :(. Does Anyone have >> objections if I change that to ...> serviceNotes>? >> >> Cheers, >> >> Pi >> >> >>> Martin >>> >>> -- >>> Martin Senger >>> email: martin.senger at gmail.com >>> skype: martinsenger >>> consulting for: >>> International Rice Research Institute >>> Biometrics and Bioinformatics Unit >>> DAPO BOX 7777, Metro Manila >>> Philippines, phone: +63-2-580-5600 (ext.2324) >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-dev >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev >> >> >> > > -- > __________________________________________________________ > > Sebastien CARRERE LIPM (INRA-CNRS) > B.P.52627 -- 31326 CASTANET TOLOSAN > tel:(33) 5-61-28-53-29 > fax:(33) 5-61-28-50-61 > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl