From ola.spjuth at farmbio.uu.se Thu Nov 1 17:51:46 2007 From: ola.spjuth at farmbio.uu.se (Ola Spjuth) Date: Thu, 1 Nov 2007 22:51:46 +0100 Subject: [MOBY-dev] Service inputs: Required or optional? Message-ID: <698036CE-995F-491F-A1F9-AF177F61CB8C@farmbio.uu.se> Hi, I have a general question regarding what information is required and which is optional for different services. When trying to validatate primary inputs for the service GeneticMap2GFF , which only takes a GeneticMap as input, I have some questions how the following should be interpreted: From Dashboard for reference: GeneticMap A genetic map contains mapped loci. The length component should indicate the length of the map in map units, but does NOT have to be zero-based; i.e. the length is simply the distance from the most proximal to the most distal marker on the map, regardless of whether or not the proximal marker is at position '0' on the map. It is likely that, in many cases, the namespace and id of this GeneticMap will be identical to the namespace and id of the 'chromosome' component of the MappedLoci's MapPosition, but this isn't required if the various Loci are more sensibly associated with another map. HAS: MappedLocus [MappedLocus] HASA: Length [Float] MappedLocus A locus that is mapped to a genetic map. the Locus component should hold a Locus (with the associated namespace and id as appropriate), while the MapPosition component should hold the chromosome, start, and end position for that Locus. Start and end may be the same to indicate point maps rather than range maps. HASA: Locus [Locus] HASA: MapPosition Locus Descr: A lightweight object representing a Locus. The namespace and id should indicate the specific Locus being described. The contained Allele objects may be used to indicate a series of Alleles for that locus, if appropriate. If there is no Allele information, or if specification of an Allele is not appropriate (e.g. in the case of a MappedLocus object), then a single Allele object with blank namespace, id, and description would be appropriate. HAS: Allele[Allele] Allele Descr: A lightweight object representing an Allele. The namespace and id should indicate the specific Allele being described. The contained String object is a human-readable description of the Allele in whatever form is most appropriate (e.g. the phenotype). HASA: description [String] MapPosition Descr: A position on a genetic map. HASA: chromosome [String] HASA: start [Float] HASA: end [Float] Please correct me if I'm wrong with the following statements: 1) Primitive MobyObjects cannot have ID and NAMESPACE but must have a VALUE. 2) A GeneticMap must have at least one (but could have many) MappedLocus and must have a Length. It must also have an ID and a Namespace, even though the description says something that it is not a requirement 3) A MappedLocus must have a Locus and a MapPosition. Judging from the Descrition it seems that no ID and no NAMESPACE is required. Is this true, and how can this information be extracted from the DataType? 4) A Locus must have at least one Allele. It seems that it also needs an ID and a NAMESPACE. 5) A HASA relationship indicates that this object is required, for example it is not a valid MapPosition if it does not have a chromosome string-value, and start and end float-values. I guess my questions boil down to: How can I tell what parameters are required and which can be omitted when invoking a service? Can service providers specify that ID and NAMESPACE are required or optional for a PrimaryInput or is the only way of knowing this to read the Description (or sometimes comment)? For simple services (like retrieval from a DB) this is trivial, but for complex cases (like above) it is still a bit unclear for me. Hope you can help me out! Cheers, .../Ola From akerhornou at imim.es Fri Nov 2 15:28:40 2007 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri, 02 Nov 2007 19:28:40 +0000 Subject: [MOBY-dev] Add BioMOBY Parser functionality in taverna (1.6.2) Message-ID: <472B7A68.70804@imim.es> Hi everyone, I can not get a BioMOBY Parser for a Moby service called fromGenericSequenceCollectionToFASTA. I have no problem getting a parser with fromGenericSequenceToFASTA, which is very similar, the only difference is that it takes a GenericSequence object, instead of a collection of GenericSequence objects. I have attached a workflow and an input document, Any idea why I can't get a parser for fromGenericSequenceCollectionToFASTA service ? Thanks Arnaud -------------- next part -------------- A non-text attachment was scrubbed... Name: FASTA_parsing_Test.xml Type: text/xml Size: 3467 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20071102/4ea5da71/attachment-0002.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: identifier_input_example.xml Type: text/xml Size: 1008 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20071102/4ea5da71/attachment-0003.xml From edward.kawas at gmail.com Fri Nov 2 16:14:50 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 2 Nov 2007 13:14:50 -0700 Subject: [MOBY-dev] Service inputs: Required or optional? In-Reply-To: <698036CE-995F-491F-A1F9-AF177F61CB8C@farmbio.uu.se> References: <698036CE-995F-491F-A1F9-AF177F61CB8C@farmbio.uu.se> Message-ID: <004a01c81d8d$073cf9d0$6400a8c0@notebook> Hi Ola, Most of your assertions are correct. The one assertion that you made that is false is about ns/id for primitive datatypes. All datatypes have a ns/id attribute associated with them. Sometimes they are filled in and mean something, and in other cases they are left blank. Usually if I create a retrieval type service, like getFASTAById, I fill in the ns/id with id for the sequence and the ns being the database that the sequence came from. To answer your last question, take a look at the following url: http://biomoby.open-bio.org/index.php/2007/06/02/do-all-contained-objects-ha ve-to-be-there/ Hope that this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Ola Spjuth > Sent: Thursday, November 01, 2007 2:52 PM > To: Core developer announcements > Subject: [MOBY-dev] Service inputs: Required or optional? > > Hi, > > I have a general question regarding what information is > required and which is optional for different services. > > When trying to validatate primary inputs for the service > GeneticMap2GFF , which only takes a GeneticMap as input, I > have some questions how the following should be interpreted: > > From Dashboard for reference: > > GeneticMap > A genetic map contains mapped loci. The length component > should indicate the length of the map in map units, but does > NOT have to be zero-based; i.e. the length is simply the > distance from the most proximal to the most distal marker on > the map, regardless of whether or not the proximal marker is > at position '0' on the map. It is likely that, in many > cases, the namespace and id of this GeneticMap will be > identical to the namespace and id of the 'chromosome' > component of the MappedLoci's MapPosition, but this isn't > required if the various Loci are more sensibly associated > with another map. > HAS: MappedLocus [MappedLocus] > HASA: Length [Float] > > MappedLocus > A locus that is mapped to a genetic map. the Locus component > should hold a Locus (with the associated namespace and id as > appropriate), while the MapPosition component should hold the > chromosome, start, and end position for that Locus. Start > and end may be the same to indicate point maps rather than range maps. > HASA: Locus [Locus] > HASA: MapPosition > > Locus > Descr: A lightweight object representing a Locus. The > namespace and id should indicate the specific Locus being > described. The contained Allele objects may be used to > indicate a series of Alleles for that locus, if appropriate. > If there is no Allele information, or if specification of an > Allele is not appropriate (e.g. in the case of a MappedLocus > object), then a single Allele object with blank namespace, > id, and description would be appropriate. > HAS: Allele[Allele] > > Allele > Descr: A lightweight object representing an Allele. The > namespace and id should indicate the specific Allele being > described. The contained String object is a human-readable > description of the Allele in whatever form is most > appropriate (e.g. the phenotype). > HASA: description [String] > > MapPosition > Descr: A position on a genetic map. > HASA: chromosome [String] > HASA: start [Float] > HASA: end [Float] > > > Please correct me if I'm wrong with the following statements: > > 1) Primitive MobyObjects cannot have ID and NAMESPACE but > must have a VALUE. > > 2) A GeneticMap must have at least one (but could have many) > MappedLocus and must have a Length. It must also have an ID > and a Namespace, even though the description says something > that it is not a requirement > > 3) A MappedLocus must have a Locus and a MapPosition. Judging > from the Descrition it seems that no ID and no NAMESPACE is > required. Is this true, and how can this information be > extracted from the DataType? > > 4) A Locus must have at least one Allele. It seems that it > also needs an ID and a NAMESPACE. > > 5) A HASA relationship indicates that this object is > required, for example it is not a valid MapPosition if it > does not have a chromosome string-value, and start and end > float-values. > > I guess my questions boil down to: > How can I tell what parameters are required and which can be > omitted when invoking a service? Can service providers > specify that ID and NAMESPACE are required or optional for a > PrimaryInput or is the only way of knowing this to read the > Description (or sometimes comment)? > For simple services (like retrieval from a DB) this is > trivial, but for complex cases (like above) it is still a bit > unclear for me. Hope you can help me out! > > Cheers, > > .../Ola > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Fri Nov 2 16:31:30 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 2 Nov 2007 13:31:30 -0700 Subject: [MOBY-dev] Add BioMOBY Parser functionality in taverna (1.6.2) In-Reply-To: <472B7A68.70804@imim.es> References: <472B7A68.70804@imim.es> Message-ID: <004d01c81d8f$5a27b660$6400a8c0@notebook> Hi Arnaud, That must be a bug. I will try to track it down and fix it. Thanks for the thorough report! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Arnaud Kerhornou > Sent: Friday, November 02, 2007 12:29 PM > To: taverna-users mailing list; Core developer announcements > Subject: [MOBY-dev] Add BioMOBY Parser functionality in > taverna (1.6.2) > > Hi everyone, > > I can not get a BioMOBY Parser for a Moby service called > fromGenericSequenceCollectionToFASTA. > I have no problem getting a parser with > fromGenericSequenceToFASTA, which is very similar, the only > difference is that it takes a GenericSequence object, instead > of a collection of GenericSequence objects. > > I have attached a workflow and an input document, > > Any idea why I can't get a parser for > fromGenericSequenceCollectionToFASTA service ? > > Thanks > Arnaud > > > > > From dmitry.repchevski at bsc.es Mon Nov 5 06:40:11 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 05 Nov 2007 12:40:11 +0100 Subject: [MOBY-dev] Secondary Parameters "min" "max" datatype Message-ID: <472F011B.4000707@bsc.es> Hello! I'm little confused about min, max values in Secondary Parameters... according the schema: is it the String? Cheers, Dmitry From dmitry.repchevski at bsc.es Mon Nov 5 09:14:18 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 05 Nov 2007 15:14:18 +0100 Subject: [MOBY-dev] Secondary Parameters question. Message-ID: <472F253A.6030004@bsc.es> Hello! I have another question about Secondary Parameters. using findService operation I can obtain the list of Secondary Parameters, for example; ***************************************************************** Integer ***************************************************************** The problem I have is that they are specified outside the tag, right? So there could be only one list of parameters per request, right? So in case of having two tags (two mobyData) in which one I should to put those parameters? Imagine the situation where I have two Simple inputs (with two corresponding mobyData) and one list of parameters. In the service description there could be only one (?) list of parameters, but in moby message there could be as many, as mobyData. Could anyone illuminate me, please? Sincerely, Dmitry From martin.senger at gmail.com Mon Nov 5 09:28:51 2007 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 5 Nov 2007 14:28:51 +0000 Subject: [MOBY-dev] Secondary Parameters question. In-Reply-To: <472F253A.6030004@bsc.es> References: <472F253A.6030004@bsc.es> Message-ID: <4d93f07c0711050628y723e83d4n26ce3f2ff0986e4a@mail.gmail.com> Dmitry, Can I suggest you the following please? [Just my personal suggestion.] You are doing a good job by comparing the latest XSD of the registry with the official BioMoby API, as documented on the BioMoby pages. I suggest that you take the API as the primary source, and point out where the XSD differs. Eddie then can update the XSD (if he agrees that there is a difference). If you find, during your trip through the BioMoby API pages, that there is something ambiguous or missing in the pages, you can point it out, as well, and somebody (Wendy?) will correct the documentation. This way we can all benefit from your research in a more persistent way (meaning: the clarified things will be kept in the docs and XSD) than just by emails. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Mon Nov 5 12:08:19 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 5 Nov 2007 09:08:19 -0800 Subject: [MOBY-dev] Secondary Parameters question. In-Reply-To: <472F253A.6030004@bsc.es> References: <472F253A.6030004@bsc.es> Message-ID: <000401c81fce$7850bba0$2766a8c0@notebook> Hi Dmitry, The secondary parameters are one per request, i.e. for a single request, 10 and for multiple requests: 10 10 Secondary parameters are optional parameters and usually a service provider will choose defaults for them. If you want to specify parameters for both inputs (mobyData) blocks, then you will have to specify them twice. Does this clarify the situation? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Dmitry Repchevsky > Sent: Monday, November 05, 2007 6:14 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] Secondary Parameters question. > > Hello! > > I have another question about Secondary Parameters. > > using findService operation I can obtain the list of > Secondary Parameters, for example; > ***************************************************************** > > > Integer > > > > > > > > ***************************************************************** > The problem I have is that they are specified outside the > tag, right? > So there could be only one list of parameters per request, right? > So in case of having two tags (two mobyData) in which > one I should to put those parameters? > Imagine the situation where I have two Simple inputs (with > two corresponding mobyData) and one list of parameters. > In the service description there could be only one (?) list > of parameters, but in moby message there could be as many, as > mobyData. > > Could anyone illuminate me, please? > > Sincerely, > > Dmitry > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Mon Nov 5 12:09:52 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 5 Nov 2007 09:09:52 -0800 Subject: [MOBY-dev] Secondary Parameters "min" "max" datatype In-Reply-To: <472F011B.4000707@bsc.es> References: <472F011B.4000707@bsc.es> Message-ID: <000501c81fce$aefbf110$2766a8c0@notebook> Hi Dmitry, The type is a 'string' of text, but in reality its a float, integer, DateTime, etc. I should fix that later. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Dmitry Repchevsky > Sent: Monday, November 05, 2007 3:40 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] Secondary Parameters "min" "max" datatype > > Hello! > > I'm little confused about min, max values in Secondary Parameters... > > according the schema: > type="xs:string" /> is it the String? > > Cheers, > > Dmitry > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From dmitry.repchevski at bsc.es Mon Nov 5 12:50:47 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 05 Nov 2007 18:50:47 +0100 Subject: [MOBY-dev] Secondary Parameters question. References: 472F253A.6030004@bsc.es Message-ID: <472F57F7.2070204@bsc.es> Hello Edward, Yeah got it. I just didn't get that the mobyData is the same format... I mean that they are actually 2 requests to the same service... I mistakenly thought that I could specify the service with two mobyData inputs. Thank you very much, Dmitry From Pieter.Neerincx at wur.nl Fri Nov 9 11:50:09 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 9 Nov 2007 17:50:09 +0100 Subject: [MOBY-dev] [Taverna-users] Add BioMOBY Parser functionality in taverna (1.6.2) In-Reply-To: <43abb4040711050251j440001cdj25de307728fd4f44@mail.gmail.com> References: <472B7A68.70804@imim.es> <004d01c81d8f$5a27b660$6400a8c0@notebook> <43abb4040711050251j440001cdj25de307728fd4f44@mail.gmail.com> Message-ID: Hi Eddie, I'm not sure if this is related, but recently I'm having problems with the BioMOBY Parsers as well. For example try to decompose the base64_encoded_svgz object to get to the SVGZ out... doesn't work. It gives me an "empty list". Simple Objects without childs (primitives) work fine, but decomposition of more complex objects either doesn't work or sometimes I can not even add the parser. If the latter happens it takes a long time and my local test Central is hammered with queries, but if I leave it overnight there is no parser the next morning. I do get java errors on the commandline though. See below for the details. For an example try to decompose the collection "GI_Clusters" produced by the service GeneIlluminator_Disambiguate. For an example workflow for this service (without decomposition so far) have a look at https://www.bioinformatics.nl/phenolink/home/ -> Gene Illuminator services -> GeneIlluminator_Disambiguate. Could you please look into this? Cheers, Pi ---------------------------------------------- exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError at java.lang.ClassLoader.findBootstrapClass(Native Method) at java.lang.ClassLoader.findBootstrapClass0 (ClassLoader.java:891) at java.lang.ClassLoader.loadClass(ClassLoader.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java: 268) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.loadClass( LocalArtifactClassLoader.java:224) at net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.findClass( LocalArtifactClassLoader.java:184) at net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.findClass( LocalArtifactClassLoader.java:154) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java: 319) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) at java.lang.Class.getDeclaredMethod(Class.java:1907) at org.apache.commons.discovery.tools.ClassUtils.findPublicStaticMethod (ClassUtils.java:116) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor y(EngineConfigurationFactoryFinder.java:178) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.access $200(EngineConfigurationFactoryFinder.java:46) at org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run (EngineConfigurationFactoryFinder.java:128) at java.security.AccessController.doPrivileged(Native Method) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor y(EngineConfigurationFactoryFinder.java:113) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor y(EngineConfigurationFactoryFinder.java:160) at org.apache.axis.client.Service.getEngineConfiguration (Service.java:813) at org.apache.axis.client.Service.getAxisClient(Service.java: 104) at org.apache.axis.client.Service.(Service.java:113) at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:192) at org.biomoby.client.CentralImpl.getDataTypeAsXML (CentralImpl.java:1045) at org.biomoby.client.CentralImpl.getDataType (CentralImpl.java:1038) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil dType(MobyParseDatatypeProcessor.java:271) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.processData type(MobyParseDatatypeProcessor.java:211) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil dType(MobyParseDatatypeProcessor.java:283) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.processData type(MobyParseDatatypeProcessor.java:211) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil dType(MobyParseDatatypeProcessor.java:283) ... last two messages repeated many times ... ---------------------------------------------- On 5-nov-2007, at 11:51, Stian Soiland wrote: > Eddie, who's one of the BioMoby developers, will have a look at > this bug. > > On 11/2/07, Edward Kawas wrote: >> Hi Arnaud, >> >> That must be a bug. I will try to track it down and fix it. >> >> Thanks for the thorough report! >> >> Eddie >> >>> -----Original Message----- >>> From: moby-dev-bounces at lists.open-bio.org >>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of >>> Arnaud Kerhornou >>> Sent: Friday, November 02, 2007 12:29 PM >>> To: taverna-users mailing list; Core developer announcements >>> Subject: [MOBY-dev] Add BioMOBY Parser functionality in >>> taverna (1.6.2) >>> >>> Hi everyone, >>> >>> I can not get a BioMOBY Parser for a Moby service called >>> fromGenericSequenceCollectionToFASTA. >>> I have no problem getting a parser with >>> fromGenericSequenceToFASTA, which is very similar, the only >>> difference is that it takes a GenericSequence object, instead >>> of a collection of GenericSequence objects. >>> >>> I have attached a workflow and an input document, >>> >>> Any idea why I can't get a parser for >>> fromGenericSequenceCollectionToFASTA service ? >>> >>> Thanks >>> Arnaud >>> >>> >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > > -- > Stian Soiland, myGrid team > School of Computer Science > The University of Manchester > http://www.cs.man.ac.uk/~ssoiland/ > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Taverna-users mailing list > Taverna-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/taverna-users > Documentation: http://www.mygrid.org.uk/usermanual1.6/ > FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq > Biological Services: http://www.mygrid.org.uk/wiki/Mygrid/ > BiologicalWebServices > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From ivanp at mmb.pcb.ub.es Fri Nov 9 11:42:29 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Fri, 09 Nov 2007 17:42:29 +0100 Subject: [MOBY-dev] Changes in method MobyService.toXML() broke my services Message-ID: <47348DF5.5030201@mmb.pcb.ub.es> Hi, I've realized that all my jMoby-MoSeS services were producing server (Tomcat) errors and answering non-moby messages in the case when a MobyException had to be launched. Looking into the server logs, I find this line: ... java.lang.NoSuchMethodError: org.biomoby.shared.parser.ServiceException.toXML()Ljava/lang/String; ... I decided to have a look to the CVS in this class of Moby and I've seen that the class (and this method) has been modified in the last revisions... Perhaps I'm doing something bad, but I think it is a big coincidence that just these parts of the code are modified. Should I regenerate skeletons? I guess this is not the right approach... Thanks, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From martin.senger at gmail.com Fri Nov 9 12:28:38 2007 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 9 Nov 2007 17:28:38 +0000 Subject: [MOBY-dev] Changes in method MobyService.toXML() broke my services In-Reply-To: <47348DF5.5030201@mmb.pcb.ub.es> References: <47348DF5.5030201@mmb.pcb.ub.es> Message-ID: <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> > I decided to have a look to the CVS in this class of Moby and I've seen > that the class (and this method) has been modified in the last > revisions... Please look in the older moby-dev messages - the issue was discussed there a while ago. The problem was that Paul changed the method without changing all its uses. After a brief discussion (I mean I was shouting in anger) he fixed it promptly. Do you think that your today observation means that the same/similar situation happened again? No, I do not see any recent change in the CVS. The last was four months ago, and Paul put there exactly the comment I was referring to above: " Changed exception printing to toXMLString() so as not to collide with Martin's toXML(), which returns a DOM object Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Fri Nov 9 12:57:19 2007 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 9 Nov 2007 09:57:19 -0800 Subject: [MOBY-dev] [Taverna-users] Add BioMOBY Parser functionality in taverna (1.6.2) In-Reply-To: References: <472B7A68.70804@imim.es> <004d01c81d8f$5a27b660$6400a8c0@notebook> <43abb4040711050251j440001cdj25de307728fd4f44@mail.gmail.com> Message-ID: Hi Pieter, I will look into it and hopefully fix it shortly. Not sure why its failing ... I bet the base case for the parser is incorrect and thats why you get the stack overflow. Eddie On Nov 9, 2007 8:50 AM, Pieter Neerincx wrote: > Hi Eddie, > > I'm not sure if this is related, but recently I'm having problems > with the BioMOBY Parsers as well. For example try to decompose the > base64_encoded_svgz object to get to the SVGZ out... doesn't work. It > gives me an "empty list". > > Simple Objects without childs (primitives) work fine, but > decomposition of more complex objects either doesn't work or > sometimes I can not even add the parser. If the latter happens it > takes a long time and my local test Central is hammered with queries, > but if I leave it overnight there is no parser the next morning. I do > get java errors on the commandline though. See below for the details. > For an example try to decompose the collection "GI_Clusters" produced > by the service GeneIlluminator_Disambiguate. For an example workflow > for this service (without decomposition so far) have a look at > https://www.bioinformatics.nl/phenolink/home/ -> Gene Illuminator > services -> GeneIlluminator_Disambiguate. > > Could you please look into this? > > Cheers, > > Pi > > ---------------------------------------------- > > exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError > at java.lang.ClassLoader.findBootstrapClass(Native Method) > at java.lang.ClassLoader.findBootstrapClass0 > (ClassLoader.java:891) > at java.lang.ClassLoader.loadClass(ClassLoader.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java: > 268) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.loadClass( > LocalArtifactClassLoader.java:224) > at > net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.findClass( > LocalArtifactClassLoader.java:184) > at > net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.findClass( > LocalArtifactClassLoader.java:154) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java: > 319) > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) > at java.lang.Class.getDeclaredMethod(Class.java:1907) > at > org.apache.commons.discovery.tools.ClassUtils.findPublicStaticMethod > (ClassUtils.java:116) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor > y(EngineConfigurationFactoryFinder.java:178) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder.access > $200(EngineConfigurationFactoryFinder.java:46) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run > (EngineConfigurationFactoryFinder.java:128) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor > y(EngineConfigurationFactoryFinder.java:113) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor > y(EngineConfigurationFactoryFinder.java:160) > at org.apache.axis.client.Service.getEngineConfiguration > (Service.java:813) > at org.apache.axis.client.Service.getAxisClient(Service.java: > 104) > at org.apache.axis.client.Service.(Service.java:113) > at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:192) > at org.biomoby.client.CentralImpl.getDataTypeAsXML > (CentralImpl.java:1045) > at org.biomoby.client.CentralImpl.getDataType > (CentralImpl.java:1038) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil > dType(MobyParseDatatypeProcessor.java:271) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.processData > type(MobyParseDatatypeProcessor.java:211) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil > dType(MobyParseDatatypeProcessor.java:283) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.processData > type(MobyParseDatatypeProcessor.java:211) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil > dType(MobyParseDatatypeProcessor.java:283) > ... last two messages repeated many times ... > > ---------------------------------------------- > > > > On 5-nov-2007, at 11:51, Stian Soiland wrote: > > > Eddie, who's one of the BioMoby developers, will have a look at > > this bug. > > > > > On 11/2/07, Edward Kawas wrote: > >> Hi Arnaud, > >> > >> That must be a bug. I will try to track it down and fix it. > >> > >> Thanks for the thorough report! > >> > >> Eddie > >> > >>> -----Original Message----- > >>> From: moby-dev-bounces at lists.open-bio.org > >>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > >>> Arnaud Kerhornou > >>> Sent: Friday, November 02, 2007 12:29 PM > >>> To: taverna-users mailing list; Core developer announcements > >>> Subject: [MOBY-dev] Add BioMOBY Parser functionality in > >>> taverna (1.6.2) > >>> > >>> Hi everyone, > >>> > >>> I can not get a BioMOBY Parser for a Moby service called > >>> fromGenericSequenceCollectionToFASTA. > >>> I have no problem getting a parser with > >>> fromGenericSequenceToFASTA, which is very similar, the only > >>> difference is that it takes a GenericSequence object, instead > >>> of a collection of GenericSequence objects. > >>> > >>> I have attached a workflow and an input document, > >>> > >>> Any idea why I can't get a parser for > >>> fromGenericSequenceCollectionToFASTA service ? > >>> > >>> Thanks > >>> Arnaud > >>> > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at lists.open-bio.org > >> http://lists.open-bio.org/mailman/listinfo/moby-dev > >> > > > > > > -- > > Stian Soiland, myGrid team > > School of Computer Science > > The University of Manchester > > http://www.cs.man.ac.uk/~ssoiland/ > > > > ---------------------------------------------------------------------- > > --- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a > > browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Taverna-users mailing list > > Taverna-users at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/taverna-users > > Documentation: http://www.mygrid.org.uk/usermanual1.6/ > > FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq > > Biological Services: http://www.mygrid.org.uk/wiki/Mygrid/ > > BiologicalWebServices > > > > ------------------------------------------------------------- > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > > phone: 0317-483 039 > fax: 0317-483 584 > mobile: 06-143 66 783 > mail: pieter.neerincx at wur.nl > skype: pieter.online > ------------------------------------------------------------ > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From markw at illuminae.com Fri Nov 9 16:30:27 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 09 Nov 2007 13:30:27 -0800 Subject: [MOBY-dev] Manuscript submitted to BiB Message-ID: Hi all, Just letting you know that I have re-formatted the manuscript appropriately and submitted it to Briefings in Bioinformatics. It would actually be nice "bookends" for the project if it were to be published there, since they published the "vapourware" paper back in 2002 :-) Best wishes all! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From ivanp at mmb.pcb.ub.es Fri Nov 9 16:37:06 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Fri, 09 Nov 2007 22:37:06 +0100 Subject: [MOBY-dev] Changes in method MobyService.toXML() broke myservices In-Reply-To: <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> References: <47348DF5.5030201@mmb.pcb.ub.es> <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> Message-ID: <4734D302.4060704@mmb.pcb.ub.es> Hi Martin, You're right. I remember this now. I've discovered this problem in the recent days but perhaps the problem is that I have some inconsistences with the deployed libraries (although I've checked it, it seems quite likely that I forgot something). I cannot do it now, but I'll check it asap. I'm quite sure that I've deployed latest version of jmoby.jar in the server (perhaps should I recreate datatypes.jar also?). Well, I'm sorry if it is my fault (it seems the more likely) I'll keep you all informed. Cheers, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> I decided to have a look to the CVS in this class of Moby and I've seen >> that the class (and this method) has been modified in the last >> revisions... >> > > > Please look in the older moby-dev messages - the issue was discussed there a > while ago. The problem was that Paul changed the method without changing all > its uses. After a brief discussion (I mean I was shouting in anger) he fixed > it promptly. Do you think that your today observation means that the > same/similar situation happened again? > > No, I do not see any recent change in the CVS. The last was four months ago, > and Paul put there exactly the comment I was referring to above: " > > Changed exception printing to toXMLString() so as not to collide with > Martin's toXML(), which returns a DOM object > > > Cheers, > Martin > > From ivanp at mmb.pcb.ub.es Mon Nov 12 09:16:27 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Mon, 12 Nov 2007 15:16:27 +0100 Subject: [MOBY-dev] Changes in method MobyService.toXML() broke myservices In-Reply-To: <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> References: <47348DF5.5030201@mmb.pcb.ub.es> <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> Message-ID: <4738603B.8010009@mmb.pcb.ub.es> Hi, I don't know exactly how, but my JBoss server had a cached version of jMoby and even removing it and deploying it again it kept going using the old version... I modified my local version of jMoby code to introduce some logging and then it magically worked :-S The funny thing is that then I decided to compile the CVS version again and it worked also... I don't know exactly what has happened but well, it's ok now. I'm sorry, as I suspected the problem was "mine". Thanks, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> I decided to have a look to the CVS in this class of Moby and I've seen >> that the class (and this method) has been modified in the last >> revisions... >> > > > Please look in the older moby-dev messages - the issue was discussed there a > while ago. The problem was that Paul changed the method without changing all > its uses. After a brief discussion (I mean I was shouting in anger) he fixed > it promptly. Do you think that your today observation means that the > same/similar situation happened again? > > No, I do not see any recent change in the CVS. The last was four months ago, > and Paul put there exactly the comment I was referring to above: " > > Changed exception printing to toXMLString() so as not to collide with > Martin's toXML(), which returns a DOM object > > > Cheers, > Martin > > From groscurt at mpiz-koeln.mpg.de Tue Nov 13 05:52:00 2007 From: groscurt at mpiz-koeln.mpg.de (groscurt at mpiz-koeln.mpg.de) Date: Tue, 13 Nov 2007 11:52:00 +0100 (CET) Subject: [MOBY-dev] MobyServices and Taverna workflow problems In-Reply-To: <472F253A.6030004@bsc.es> References: <472F253A.6030004@bsc.es> Message-ID: <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> Hi all, we have a problem concerning BioMoby webservices in taverna and we hope one can help us out. We have two Webservices which e.g. one returns an object with the articlename 'sequence', the other has this object as input with the articlename 'seq' (as simple example). Now we tried to connect this services into a workflow and taverna returned a NullPointerException apparently in the skeleton class of the second service, because it looks for 'seq' in the xml, but we only have 'sequence'. I'm not quite sure if this is the problem, but how is it possible to connect arbitrary services without taking care of the articlename ? What do we have to take into account when using a Biomoby webservice for taverna ? the solution of having always the same articlename is working, but i guess this is not intended... thanks in advance andreas From edward.kawas at gmail.com Tue Nov 13 09:30:40 2007 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue, 13 Nov 2007 06:30:40 -0800 Subject: [MOBY-dev] MobyServices and Taverna workflow problems In-Reply-To: <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> References: <472F253A.6030004@bsc.es> <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: Hi Andreas, Can you send me an example workflow? Thanks, Eddie On Nov 13, 2007 2:52 AM, wrote: > Hi all, > > we have a problem concerning BioMoby webservices in taverna and we hope > one can help us out. > > We have two Webservices which e.g. one returns an object with the > articlename 'sequence', the other has this object as input with the > articlename 'seq' (as simple example). > > Now we tried to connect this services into a workflow and taverna returned > a NullPointerException apparently in the skeleton class of the second > service, because it looks for 'seq' in the xml, but we only have > 'sequence'. > > I'm not quite sure if this is the problem, but how is it possible to > connect arbitrary services without taking care of the articlename ? > > What do we have to take into account when using a Biomoby webservice for > taverna ? > > the solution of having always the same articlename is working, but i guess > this is not intended... > > thanks in advance > andreas > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From edward.kawas at gmail.com Tue Nov 13 11:19:44 2007 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue, 13 Nov 2007 08:19:44 -0800 Subject: [MOBY-dev] MobyServices and Taverna workflow problems In-Reply-To: References: <472F253A.6030004@bsc.es> <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: Hi Andreas, >From the first reading, I thought that you had a workflow that didnt work... From reading it again, it sounds like you are asking whether or not you have to worry about the article names in Taverna. Article names are automatically discovered and the correct one is used in Taverna. If you have a case where this might not be the case, then please let me know. The only things that a user of Taverna needs to take into account when using moby is to make sure that they supply the correct namespace and data for any particular service. Articlenames are taken care of, even though if you look in the intermediate input/output browser and the articlename is not what it's supposed to be. Does this answer your question? Thanks, Eddie On Nov 13, 2007 6:30 AM, Eddie Kawas wrote: > Hi Andreas, > > Can you send me an example workflow? > > Thanks, > > Eddie > > > On Nov 13, 2007 2:52 AM, wrote: > > Hi all, > > > > we have a problem concerning BioMoby webservices in taverna and we hope > > one can help us out. > > > > We have two Webservices which e.g. one returns an object with the > > articlename 'sequence', the other has this object as input with the > > articlename 'seq' (as simple example). > > > > Now we tried to connect this services into a workflow and taverna returned > > a NullPointerException apparently in the skeleton class of the second > > service, because it looks for 'seq' in the xml, but we only have > > 'sequence'. > > > > I'm not quite sure if this is the problem, but how is it possible to > > connect arbitrary services without taking care of the articlename ? > > > > What do we have to take into account when using a Biomoby webservice for > > taverna ? > > > > the solution of having always the same articlename is working, but i guess > > this is not intended... > > > > thanks in advance > > andreas > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From markw at illuminae.com Tue Nov 13 16:51:23 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Nov 2007 13:51:23 -0800 Subject: [MOBY-dev] Invitation to submit Message-ID: Hi all, In the wake of the PLoS ONE Gong Show[1], this weekend I was invited to submit the Moby 1.0 paper to Briefings in Bioinformatics. Hopefully it will find its target audience there :-) I submitted it this morning. Best wishes all! Mark [1] http://en.wikipedia.org/wiki/Gong_show -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Tue Nov 13 17:45:50 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Nov 2007 14:45:50 -0800 Subject: [MOBY-dev] INB services with questionable registrations... Message-ID: Hi INB folks! Looks like some of your services have been registered as consuming "anything and everything" again :-) Go to Gbrowse_moby (http://mobycentral.icapture.ubc.ca), select namespace DragonDB_Allele and use "cho" as the ID. 6 of your services claim to consume DragonDB Alleles... and I suspect that isn't the case, right? Cheers! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Wed Nov 14 21:09:50 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 14 Nov 2007 18:09:50 -0800 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? Message-ID: Hell, why not?! :-) I had an hour free this afternoon, and this is what I did with it: It takes about 15 minutes to auto-generate them from the registry so I could put th escript on a cron... This is purely first-pass, just-trying-an-idea stuff, so it isn't "pretty", but... very very cool :-) Cheers all! Mark From markw at illuminae.com Tue Nov 13 21:29:01 2007 From: markw at illuminae.com (mark wilkinson) Date: Wed, 14 Nov 2007 02:29:01 +0000 GMT Subject: [MOBY-dev] Just realized... Message-ID: <1533480739-1195007449-cardhu_blackberry.rim.net-19272-@engine02-cell01> ...It would be much more appropriate to group the services by the namespace they operate under so that all services that work on a particular type of ID could be added to iGoogle as a unit! That's tomorrow's homework. It's suppertime now :-) M -- Mark Wilkinson ...on the road! From groscurt at mpiz-koeln.mpg.de Wed Nov 14 03:28:25 2007 From: groscurt at mpiz-koeln.mpg.de (groscurt at mpiz-koeln.mpg.de) Date: Wed, 14 Nov 2007 09:28:25 +0100 (CET) Subject: [MOBY-dev] MobyServices and Taverna workflow problems In-Reply-To: References: <472F253A.6030004@bsc.es> <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: <45402.195.37.46.22.1195028905.squirrel@mpizmail.mpiz-koeln.mpg.de> Hi Eddie, thanks for your answer. Unfortunately we cant send you currently an example because we *fixed* our problem... but we try to recreate the error and then send you a copy. I think your answer covers my problem, but then the questions is why does the error occurred. The problem is that one service returns an object with a specific articlename and the next service consumes the same object type with a different articlename. Like "I give you an AminoAcidSequence which is named sequence" - the other response "I want an AminoAcidSequence which is named seq." The second webservice then looks in the XML for something called seq and does not find that because we have sequence -> nullpointerexception thrown by the second webservice. When I understand you correctly this should be handled by taverna - so either there is a bug, or the problem is a total different one. We try to recreate the situation and send you the workflow. thanks andreas PS: we *fixed* this by naming all in- and outputs the same and then it worked..... > Hi Andreas, > >>From the first reading, I thought that you had a workflow that didnt > work... From reading it again, it sounds like you are asking whether > or not you have to worry about the article names in Taverna. Article > names are automatically discovered and the correct one is used in > Taverna. If you have a case where this might not be the case, then > please let me know. > > The only things that a user of Taverna needs to take into account when > using moby is to make sure that they supply the correct namespace and > data for any particular service. Articlenames are taken care of, even > though if you look in the intermediate input/output browser and the > articlename is not what it's supposed to be. > > Does this answer your question? > > Thanks, > > Eddie > > On Nov 13, 2007 6:30 AM, Eddie Kawas wrote: >> Hi Andreas, >> >> Can you send me an example workflow? >> >> Thanks, >> >> Eddie >> >> >> On Nov 13, 2007 2:52 AM, wrote: >> > Hi all, >> > >> > we have a problem concerning BioMoby webservices in taverna and we >> hope >> > one can help us out. >> > >> > We have two Webservices which e.g. one returns an object with the >> > articlename 'sequence', the other has this object as input with the >> > articlename 'seq' (as simple example). >> > >> > Now we tried to connect this services into a workflow and taverna >> returned >> > a NullPointerException apparently in the skeleton class of the second >> > service, because it looks for 'seq' in the xml, but we only have >> > 'sequence'. >> > >> > I'm not quite sure if this is the problem, but how is it possible to >> > connect arbitrary services without taking care of the articlename ? >> > >> > What do we have to take into account when using a Biomoby webservice >> for >> > taverna ? >> > >> > the solution of having always the same articlename is working, but i >> guess >> > this is not intended... >> > >> > thanks in advance >> > andreas >> > >> > _______________________________________________ >> > MOBY-dev mailing list >> > MOBY-dev at lists.open-bio.org >> > http://lists.open-bio.org/mailman/listinfo/moby-dev >> > >> > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From Pieter.Neerincx at wur.nl Wed Nov 14 08:57:14 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 14 Nov 2007 14:57:14 +0100 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? In-Reply-To: References: Message-ID: Hi Mark, Like the idea! Several colleagues showed me their personalised Google pages, but I never bothered to signup for an account, because I didn't see any content worth the effort. That changed today :). Just give it try and I'm getting "404 - Service returned no response. This indicates that this service is currently unavailable. Try again later." for several gadgets... Work in progress I guess :). Will try again later. Cheers, Pi On 15-nov-2007, at 3:09, Mark Wilkinson wrote: > Hell, why not?! :-) > > I had an hour free this afternoon, and this is what I did with it: > > > > It takes about 15 minutes to auto-generate them from the registry so I > could put th escript on a cron... This is purely first-pass, > just-trying-an-idea stuff, so it isn't "pretty", but... very very > cool :-) > > Cheers all! > > Mark > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From markw at illuminae.com Thu Nov 15 09:38:39 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 15 Nov 2007 06:38:39 -0800 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? In-Reply-To: References: Message-ID: Services may well be down... I am not currently filtering for "alive" services... M On Wed, 14 Nov 2007 05:57:14 -0800, Pieter Neerincx wrote: > Hi Mark, > > Like the idea! Several colleagues showed me their personalised Google > pages, but I never bothered to signup for an account, because I > didn't see any content worth the effort. That changed today :). > > Just give it try and I'm getting "404 - Service returned no response. > This indicates that this service is currently unavailable. Try again > later." for several gadgets... Work in progress I guess :). Will try > again later. > > Cheers, > > Pi > > On 15-nov-2007, at 3:09, Mark Wilkinson wrote: > >> Hell, why not?! :-) >> >> I had an hour free this afternoon, and this is what I did with it: >> >> >> >> It takes about 15 minutes to auto-generate them from the registry so I >> could put th escript on a cron... This is purely first-pass, >> just-trying-an-idea stuff, so it isn't "pretty", but... very very >> cool :-) >> >> Cheers all! >> >> Mark >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > ------------------------------------------------------------- > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > > phone: 0317-483 039 > fax: 0317-483 584 > mobile: 06-143 66 783 > mail: pieter.neerincx at wur.nl > skype: pieter.online > ------------------------------------------------------------ > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Wed Nov 14 11:14:56 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 14 Nov 2007 17:14:56 +0100 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? In-Reply-To: References: Message-ID: <7C6BBD26-D489-440A-9194-5538B269574C@wur.nl> On 15-nov-2007, at 15:38, Mark Wilkinson wrote: > Services may well be down... I am not currently filtering for "alive" > services... Fair enough :), but I tried one of my own services for which I know 100% it's up and I tried the getGoTerm service from bioinfo.icapture.ubc.ca. That latter one is one of yours right? Also gave my a 404 error with several GO terms with and without the GO: prefix in front of the GO ID... Weird, but I tried again and my own service works now. Didn't change anything and checked the server logs: it's been up all the time. getGoTerm still fails on me though. Cheers, Pi > > M > > > > On Wed, 14 Nov 2007 05:57:14 -0800, Pieter Neerincx > wrote: > >> Hi Mark, >> >> Like the idea! Several colleagues showed me their personalised Google >> pages, but I never bothered to signup for an account, because I >> didn't see any content worth the effort. That changed today :). >> >> Just give it try and I'm getting "404 - Service returned no response. >> This indicates that this service is currently unavailable. Try again >> later." for several gadgets... Work in progress I guess :). Will try >> again later. >> >> Cheers, >> >> Pi >> >> On 15-nov-2007, at 3:09, Mark Wilkinson wrote: >> >>> Hell, why not?! :-) >>> >>> I had an hour free this afternoon, and this is what I did with it: >>> >>> >>> >>> It takes about 15 minutes to auto-generate them from the registry >>> so I >>> could put th escript on a cron... This is purely first-pass, >>> just-trying-an-idea stuff, so it isn't "pretty", but... very very >>> cool :-) >>> >>> Cheers all! >>> >>> Mark >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> >> ------------------------------------------------------------- >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> >> phone: 0317-483 039 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> mail: pieter.neerincx at wur.nl >> skype: pieter.online >> ------------------------------------------------------------ >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From dgonzalez at cnio.es Wed Nov 14 11:15:45 2007 From: dgonzalez at cnio.es (David G. Pisano) Date: Wed, 14 Nov 2007 17:15:45 +0100 Subject: [MOBY-dev] INB services with questionable registrations... In-Reply-To: References: Message-ID: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> Umm, I see just one INB service there... getCodonTableFromEmboss provided by: www.cnb.uam.es Natalia will take a look into it Can you tell us the rest of the "questionable" services? On 13 Nov 2007, at 23:45, Mark Wilkinson wrote: > Hi INB folks! > > Looks like some of your services have been registered as consuming > "anything and everything" again :-) > > Go to Gbrowse_moby (http://mobycentral.icapture.ubc.ca), select > namespace > DragonDB_Allele and use "cho" as the ID. 6 of your services claim to > consume DragonDB Alleles... and I suspect that isn't the case, right? > > Cheers! > > Mark > > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > Tel: 604 682 2344 x62129 > Fax: 604 806 9274 > > ***CONFIDENTIALITY NOTICE*** > This electronic message is intended only for the use of the > addressee and > may contain information that is privileged and confidential. Any > dissemination, distribution or copying of this communication by > unauthorized individuals is strictly prohibited. If you have > received this > communication in error, please notify the sender immediately by reply > e-mail and delete the original and all copies from your system. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev --- David G. Pisano Bioinformatics Unit Structural Biology and Biocomputing Programme Spanish National Cancer Research Centre (CNIO) Melchor Fdez. Almagro, 3 E-28029 Madrid, Spain +34 91 7328000 (ext. 2161) Skype: dgpisano dgpisano at cnio.es **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From markw at illuminae.com Wed Nov 14 11:41:15 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 14 Nov 2007 08:41:15 -0800 Subject: [MOBY-dev] INB services with questionable registrations... In-Reply-To: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> References: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> Message-ID: Hi David, Yes, there is only one there now. How strange?!? Yesterday there were six! Maybe I am going crazy ;-) Anyway, best wishes! Mark On Wed, 14 Nov 2007 08:15:45 -0800, David G. Pisano wrote: > Umm, I see just one INB service there... getCodonTableFromEmboss > provided by: www.cnb.uam.es > Natalia will take a look into it > > Can you tell us the rest of the "questionable" services? > > On 13 Nov 2007, at 23:45, Mark Wilkinson wrote: > >> Hi INB folks! >> >> Looks like some of your services have been registered as consuming >> "anything and everything" again :-) >> >> Go to Gbrowse_moby (http://mobycentral.icapture.ubc.ca), select >> namespace >> DragonDB_Allele and use "cho" as the ID. 6 of your services claim to >> consume DragonDB Alleles... and I suspect that isn't the case, right? >> >> Cheers! >> >> Mark >> >> >> >> -- >> -- >> Mark Wilkinson >> Assistant Professor, Dept. Medical Genetics >> University of British Columbia >> PI Bioinformatics >> iCAPTURE Centre, St. Paul's Hospital >> Tel: 604 682 2344 x62129 >> Fax: 604 806 9274 >> >> ***CONFIDENTIALITY NOTICE*** >> This electronic message is intended only for the use of the >> addressee and >> may contain information that is privileged and confidential. Any >> dissemination, distribution or copying of this communication by >> unauthorized individuals is strictly prohibited. If you have >> received this >> communication in error, please notify the sender immediately by reply >> e-mail and delete the original and all copies from your system. >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > --- > David G. Pisano > Bioinformatics Unit > Structural Biology and Biocomputing Programme > Spanish National Cancer Research Centre (CNIO) > > Melchor Fdez. Almagro, 3 > E-28029 Madrid, Spain > +34 91 7328000 (ext. 2161) > Skype: dgpisano > dgpisano at cnio.es > > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea > el destinatario. Si usted recibe por error este correo, se ruega > comunicarlo al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments > may contain confidential and privileged information for the sole use of > the designated recipient named above. Distribution, reproduction or any > other use of this transmission by any party other than the intended > recipient is prohibited. If you are not the intended recipient please > contact the sender and delete all copies. > -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Wed Nov 14 11:44:14 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 14 Nov 2007 08:44:14 -0800 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? In-Reply-To: <7C6BBD26-D489-440A-9194-5538B269574C@wur.nl> References: <7C6BBD26-D489-440A-9194-5538B269574C@wur.nl> Message-ID: All of my GO services are currently dead. they were coded to access a database at UBC that was taken offline when our university (in their esteemed brilliance) closed the UBC Bioinformatics Centre :-P I'm looking at other options now. Apparently there's an open GO database at EMBL, so I'm going to try to hit that one and see if it works for me. I'm not anxious to host and maintain the full GO database here locally, so if I can't find an open mysql interface somewhere else then I'll have to take those services offline. M On Wed, 14 Nov 2007 08:14:56 -0800, Pieter Neerincx wrote: > > On 15-nov-2007, at 15:38, Mark Wilkinson wrote: > >> Services may well be down... I am not currently filtering for "alive" >> services... > > Fair enough :), but I tried one of my own services for which I know > 100% it's up and I tried the getGoTerm service from > bioinfo.icapture.ubc.ca. That latter one is one of yours right? Also > gave my a 404 error with several GO terms with and without the GO: > prefix in front of the GO ID... > > Weird, but I tried again and my own service works now. Didn't change > anything and checked the server logs: it's been up all the time. > getGoTerm still fails on me though. > > Cheers, > > Pi > >> >> M >> >> >> >> On Wed, 14 Nov 2007 05:57:14 -0800, Pieter Neerincx >> wrote: >> >>> Hi Mark, >>> >>> Like the idea! Several colleagues showed me their personalised Google >>> pages, but I never bothered to signup for an account, because I >>> didn't see any content worth the effort. That changed today :). >>> >>> Just give it try and I'm getting "404 - Service returned no response. >>> This indicates that this service is currently unavailable. Try again >>> later." for several gadgets... Work in progress I guess :). Will try >>> again later. >>> >>> Cheers, >>> >>> Pi >>> >>> On 15-nov-2007, at 3:09, Mark Wilkinson wrote: >>> >>>> Hell, why not?! :-) >>>> >>>> I had an hour free this afternoon, and this is what I did with it: >>>> >>>> >>>> >>>> It takes about 15 minutes to auto-generate them from the registry >>>> so I >>>> could put th escript on a cron... This is purely first-pass, >>>> just-trying-an-idea stuff, so it isn't "pretty", but... very very >>>> cool :-) >>>> >>>> Cheers all! >>>> >>>> Mark >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>> >>> >>> ------------------------------------------------------------- >>> Wageningen University and Research centre (WUR) >>> Laboratory of Bioinformatics >>> Transitorium (building 312) room 1034 >>> >>> Dreijenlaan 3 >>> 6703 HA Wageningen >>> The Netherlands >>> >>> phone: 0317-483 039 >>> fax: 0317-483 584 >>> mobile: 06-143 66 783 >>> mail: pieter.neerincx at wur.nl >>> skype: pieter.online >>> ------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > ------------------------------------------------------------- > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > > phone: 0317-483 039 > fax: 0317-483 584 > mobile: 06-143 66 783 > mail: pieter.neerincx at wur.nl > skype: pieter.online > ------------------------------------------------------------ > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From rroyo at lsi.upc.edu Wed Nov 14 11:35:16 2007 From: rroyo at lsi.upc.edu (Romina Royo) Date: Wed, 14 Nov 2007 17:35:16 +0100 Subject: [MOBY-dev] INB services with questionable registrations... In-Reply-To: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> References: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> Message-ID: <473B23C4.707@lsi.upc.edu> Hello, Sorry! There were some services from our node that have already been fixed. I'm sorry we didn't reply sooner to let you know about it Romina David G. Pisano wrote: > Umm, I see just one INB service there... getCodonTableFromEmboss > provided by: www.cnb.uam.es > Natalia will take a look into it > > Can you tell us the rest of the "questionable" services? > > On 13 Nov 2007, at 23:45, Mark Wilkinson wrote: > >> Hi INB folks! >> >> Looks like some of your services have been registered as consuming >> "anything and everything" again :-) >> >> Go to Gbrowse_moby (http://mobycentral.icapture.ubc.ca), select >> namespace >> DragonDB_Allele and use "cho" as the ID. 6 of your services claim to >> consume DragonDB Alleles... and I suspect that isn't the case, right? >> >> Cheers! >> >> Mark >> >> >> >> ---- >> Mark Wilkinson >> Assistant Professor, Dept. Medical Genetics >> University of British Columbia >> PI Bioinformatics >> iCAPTURE Centre, St. Paul's Hospital >> Tel: 604 682 2344 x62129 >> Fax: 604 806 9274 >> >> ***CONFIDENTIALITY NOTICE*** >> This electronic message is intended only for the use of the addressee >> and >> may contain information that is privileged and confidential. Any >> dissemination, distribution or copying of this communication by >> unauthorized individuals is strictly prohibited. If you have received >> this >> communication in error, please notify the sender immediately by reply >> e-mail and delete the original and all copies from your system. >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > --- > David G. Pisano > Bioinformatics Unit > Structural Biology and Biocomputing Programme > Spanish National Cancer Research Centre (CNIO) > > Melchor Fdez. Almagro, 3 > E-28029 Madrid, Spain > +34 91 7328000 (ext. 2161) > Skype: dgpisano > dgpisano at cnio.es > > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n > o cualquier otro tipo de transmisi?n por parte de otra persona que no > sea el destinatario. Si usted recibe por error este correo, se ruega > comunicarlo al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any > attachments may contain confidential and privileged information for > the sole use of the designated recipient named above. Distribution, > reproduction or any other use of this transmission by any party other > than the intended recipient is prohibited. If you are not the intended > recipient please contact the sender and delete all copies. > > ------------------------------------------------------------------------ > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From igoldsmid at semanticdiscoverysystems.com Wed Nov 14 20:43:45 2007 From: igoldsmid at semanticdiscoverysystems.com (Ian Goldsmid) Date: Thu, 15 Nov 2007 14:43:45 +1300 Subject: [MOBY-dev] beginning to seriously tackle legacy data integration and querying issues in OWL/RDF (Semantic Web)? Message-ID: <005201c82728$f6d5a1f0$e480e5d0$@com> Hi This is a once only posting. I think some of you may find this useful: What is this about in one (rather long J ) sentence? Semantic Discovery Systems software that now enables non technical end users ??? through a familiar end-user-friendly Concept Map/Topic Map + Faceted Browser GUI representation of OWL Ontologies: to map, view, navigate and query; distributed, heterogeneous, corporate/legacy data sources and web services, with significantly automated mapping between data sources and OWL, and distributed query optimization to ensure optimal performance. -------- The first of its kind to go fully beyond a research prototype to truly Enterprise Scalable Deployment: Martin O???Connor, one of the Prot??g?? Staff at Stanford we collaborate with: [1]http://protege.stanford.edu/aboutus/aboutus.html, and, [2]http://bmir.stanford.edu/people/view.php/martin_j_oconnor -- recently said to us: ???but people are only beginning to seriously tackle legacy data integration and querying issues in OWL. The existing data querying/integration solutions that are out there are mostly research prototypes??????. We are one of the very few Semantic application software developers with a comprehensive product offering, with foundations that are fully mature and commercially proven too, that delivers optimized legacy data integration with W3C RDF/OWL/SPARQL. --------- A few additional summary points: There is extensive information at [3]www.SemanticDiscoverySystems.com, although [4]SDS_Quick_View.ppt is intended summarily elaborate on the following points: * The Semantic Discovery System generates mappings between Ontologies (created in W3C OWL) and distributed, heterogeneous data sources (oracle, any rdbms, any files (Excel for example), AND internal/external Web Services ??? (e.g. NCBI, Kegg, etc) ??? such that an end-user, a Pharmaceutical Researcher, Clinical Scientist, Fraud Investigator, Financial Analyst for example, can NOW: * View and navigate all the underlying distributed data -- all the objects or concepts ??? e.g. genes, proteins, compounds etc - AND their relationships -- in a familiar, user-friendly Concept Map/Network Diagram graphical user interface, and/or a faceted browser (see [5]SDS_Quick_View.ppt) * AND most importantly ??? the functionality to query that underlying distributed, heterogeneous data using that same user-friendly Concept Map GUI (W3C SPARQL is auto-generated to do that) ??? i.e. the Concept Map is also the Query Builder. The Semantic Discovery System has a built in distributed Query Optimizer (this optimization technology has a ten year track record) ??? this is effective for optimizing queries across distributed databases. The underlying data sources are Federated ??? i.e. queried in place ??? NOT pushed up to the client as they are in a few other existing systems of a similar kind, which causes an untenable bottleneck for anything but a small experimental prototype. The Semantic Discovery System is architecturally appropriate for Large Scale Enterprise deployments ??? AND we also supply a fully functional desktop version for individual users too. As an extended introduction ??? please navigate to [6]www.semanticdiscoverysystems.com ??? and start by reading the bullet points in the right hand panel with the heading - Why SDS? A key outcome from using SDS, is that end users can now map, view, navigate, work with, and query distributed, heterogeneous data without further programming intervention ??? using a graphical interface paradigm they are already familiar with, and find entirely natural to use. I hope that helps clarify one way or the other, whether this may, or will not be of some interest. If this is of interest to you, we offer an Early Access Program you may want to take a look at: [7]SDS_V7_EAP_Plan.ppt Thanks and looking forward to the possibility of hearing from you. Kind Regards, Ian Ian Goldsmid UK: +44 (208) 816 8379 US West Coast: +1 (415) 691 6097 US East Coast: +1 (617) 314 6330 Asia Pacific: +64 9 889 0269 Skype: igoldsmid: [8]cid:image001.png at 01C826A4.75B38350 JahJah FreePhone: [9]cid:image002.png at 01C826A4.75B38350 [10]igoldsmid at semanticdiscoverysystems.com [11]www.insilicodiscovery.com [12]www.semanticdiscoverysystems.com cid:image005.jpg at 01C826A9.B1B27410 0 [IMAGE]-Submit References 1. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.ebdofkjsn2c9mk.ReadNotify.com/tg/ebdofkjsn2c9mlhttp/protege.stanford.edu/aboutus/aboutus.html 2. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.ebdofkjsn2c9mk.ReadNotify.com/tg/ebdofkjsn2c9mlhttp/bmir.stanford.edu/people/view.php/martin_j_oconnor 3. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.SemanticDiscoverySystems.com 4. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.insilicodiscovery.com/v2/Emails/SDS_Quick_View.ppt 5. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.insilicodiscovery.com/v2/Emails/SDS_Quick_View.ppt 6. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.semanticdiscoverysystems.com 7. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.insilicodiscovery.com/v2/Emails/SDS_V7_EAP_Plan.ppt 8. skype:igoldsmid?call 9. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.jajah.com/IanGoldsmid 10. blocked::mailto:igoldsmid at insilicodiscovery.com 11. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.insilicodiscovery.com 12. blocked::http://www.insilicodiscovery.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1389 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20071115/aaa59069/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 4217 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20071115/aaa59069/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 6381 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20071115/aaa59069/attachment-0001.jpe From markw at illuminae.com Thu Nov 15 21:39:08 2007 From: markw at illuminae.com (mark wilkinson) Date: Fri, 16 Nov 2007 02:39:08 +0000 GMT Subject: [MOBY-dev] BiB submission Message-ID: <698615207-1195180861-cardhu_blackberry.rim.net-27173-@engine18-cell01> So BiB has "gently" rejected the manuscript due to it's length, but have re-offered their invitation if we cut it down (significantly), and they are completely happy with us submitting large portions of the details as "Supplementary Information". I've cut-out 30% of the manuscript and created a supplementary appendix where I make the more detailed arguments. It's still slightly over-length, but the editor indicated some compassion and may allow the submission at it's current length. To be honest, I think the paper is more "punchy" now, and reads better than it did with the full discussion in the main text :-) as soon as I get the OK from the editor I'll up this modified copy to the CVS. More than anything I'm really excited to have it as an invited submission to such a high-impact journal after the painful process that we just went through with PLoS ONE (a low-impact journal)... Having said that, I worry that we're not necessarily reaching the full breadth of audience that we really want to reach. Is there anyone in the community who wants to take-up the task of writing a more biologically-oriented manuscript for e.g. Genome Biology? I'm really not in a position to do this myself since (oddly enough) I don't actually *use* Moby to solve any biological problems... But I know there are lot of you on the list who do!! Just an idea... M -- Mark Wilkinson ...on the road! From markw at illuminae.com Thu Nov 15 21:49:27 2007 From: markw at illuminae.com (mark wilkinson) Date: Fri, 16 Nov 2007 02:49:27 +0000 GMT Subject: [MOBY-dev] An update on moby Central Message-ID: <1937583103-1195181482-cardhu_blackberry.rim.net-30769-@engine20-cell01> As you know, we're trying to move Moby Central to a new (faster!!) server at the SUN Centre of Excellence in Calgary (headed by Christoph Sensen, Paul Gordon's PhD supervisor). The migration is turning out to be extremely troublesome, largely due to our dependence on the libxml2 libraries. This is unfortunate... It likely means that moby central will be difficult to install for many people... But I'm sure it will be worth the trouble, since it will be on a dedicated 64bit server with high connectivity, compared to the server it is on now which seems to have terrible connectivity problems for everyone except me ;-) Eddie s well along in making a CPAN release of Moby, and Wendy is well along in working on the multi-lingual problem (we're trying to be compatible with every mysql down to Mysql version 3) So there is progress on the milestones from the last developers meeting! I believe that Eddie has also completed a pure-perl implementation of all Moby Central code, so we won't have the urrent chaotic mixture of Tomcat and Apache dependencies. Progress! M -- Mark Wilkinson ...on the road! From Pieter.Neerincx at wur.nl Fri Nov 16 07:47:57 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 16 Nov 2007 13:47:57 +0100 Subject: [MOBY-dev] An update on moby Central In-Reply-To: <1937583103-1195181482-cardhu_blackberry.rim.net-30769-@engine20-cell01> References: <1937583103-1195181482-cardhu_blackberry.rim.net-30769-@engine20-cell01> Message-ID: Hi, On 16-nov-2007, at 3:49, mark wilkinson wrote: > As you know, we're trying to move Moby Central to a new (faster!!) > server at the SUN Centre of Excellence in Calgary (headed by > Christoph Sensen, Paul Gordon's PhD supervisor). The migration is > turning out to be extremely troublesome, largely due to our > dependence on the libxml2 libraries. This is unfortunate... It > likely means that moby central will be difficult to install for > many people... I do install test Centrals on a more or less regular basis :) and yes the procedure can be... challenging :). Especially since we try to keep the OS and other software separated. So we never install stuff in the "default" place. I have no experience with the latest pure Perl version of BioMOBY Central, but libxml2 should be fine as long as you have a relative recent version. Not sure if this helps, but from my own experience: * For older versions there is a list describing which version of XML::LibXML works with which version of libxml2. Apparently you can not randomly mix versions! Even minor differences in the version number can break things. * If libxml2 is not in the default path or you have an OS supplied older version in the default path and want to link some Perl stuff to a newer version in an alternative location, please make sure the xml2- config binary is pointing to the libxml2 version you want to use and xml2-config is in your PATH both for yourself and for the apache user. If you are having other problems just put them on the mailinglist; maybe one of us has seen them before... > But I'm sure it will be worth the trouble, since it will be on a > dedicated 64bit server with high connectivity, compared to the > server it is on now which seems to have terrible connectivity > problems for everyone except me ;-) > > Eddie s well along in making a CPAN release of Moby, and Wendy is > well along in working on the multi-lingual problem (we're trying to > be compatible with every mysql down to Mysql version 3) > > So there is progress on the milestones from the last developers > meeting! > > I believe that Eddie has also completed a pure-perl implementation > of all Moby Central code, so we won't have the urrent chaotic > mixture of Tomcat and Apache dependencies. I'd love to give that one a try, so if you are looking for a "guinea pig" let me know :)... Cheers, Pi > Progress! > > M > > > -- > Mark Wilkinson > ...on the road! > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From Pieter.Neerincx at wur.nl Wed Nov 21 11:40:17 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 21 Nov 2007 17:40:17 +0100 Subject: [MOBY-dev] Authorities In-Reply-To: <005201c82728$f6d5a1f0$e480e5d0$@com> References: <005201c82728$f6d5a1f0$e480e5d0$@com> Message-ID: <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> Hi, I compiled a page with some extra information about BioMOBY authorities, because I thought this was lacking. The page at ~moby- live/Docs/MOBY-S_API/Authorities.html reflects what I found using Google and after browsing the mailinglist archive. So in case their are things outdated, plain wrong or missing, please correct me... (It might take some time for this page to pop-up on the BioMOBY site, but it should get there eventually thanks to cron.) Cheers, Pi ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From groscurt at mpiz-koeln.mpg.de Thu Nov 22 06:54:13 2007 From: groscurt at mpiz-koeln.mpg.de (groscurt at mpiz-koeln.mpg.de) Date: Thu, 22 Nov 2007 12:54:13 +0100 (CET) Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> Message-ID: <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> Hiho, at the EU-Sol meeting in Rome we discussed the usability of Moby for the project. One main issue was if it is possible to secure the data send via WebServices and to ensure that only specific people are able to use specific webservices. This is because the EU-Sol is a closed consortium with industry partners and they, but also the "normal" biologists, demand to have a solution which guarantees such requirements. So what I was wondering if this issue already came up in Moby ? I'm currently getting started to understand the current principles of securing WebServices, but i was wondering if someone has somehow experiences with that ? So any comments and hints are welcome :-) Best andreas From gordonp at ucalgary.ca Thu Nov 22 08:43:56 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 22 Nov 2007 06:43:56 -0700 Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: <4745879C.9090805@ucalgary.ca> I think generally we agreed that this could and should be done at the HTTP transport level rather than within MOBY itself. That's one of the advantages of having a layered architecture :-) groscurt at mpiz-koeln.mpg.de wrote: > Hiho, > > at the EU-Sol meeting in Rome we discussed the usability of Moby for the > project. One main issue was if it is possible to secure the data send via > WebServices and to ensure that only specific people are able to use > specific webservices. This is because the EU-Sol is a closed consortium > with industry partners and they, but also the "normal" biologists, demand > to have a solution which guarantees such requirements. > > So what I was wondering if this issue already came up in Moby ? I'm > currently getting started to understand the current principles of securing > WebServices, but i was wondering if someone has somehow experiences with > that ? > > So any comments and hints are welcome :-) > > Best > andreas > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From Pieter.Neerincx at wur.nl Thu Nov 22 09:16:06 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 22 Nov 2007 15:16:06 +0100 Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: <61EAB8F5-4A8B-4F8A-B7C9-96390913428A@wur.nl> Hi Andreas, On 22-nov-2007, at 12:54, groscurt at mpiz-koeln.mpg.de wrote: > Hiho, > > at the EU-Sol meeting in Rome we discussed the usability of Moby > for the > project. One main issue was if it is possible to secure the data > send via > WebServices and to ensure that only specific people are able to use > specific webservices. This is because the EU-Sol is a closed > consortium > with industry partners and they, but also the "normal" biologists, > demand > to have a solution which guarantees such requirements. In one of our collaborations I'm in a similar situation with a combined public / private consortium. There are several ways to secure your services, that can already work with the current state of the BioMOBY art. The thing is that as far as I know there is not really a standard ... yet. So probably several people already have different mechanisms in place. I'm using HTTPS to secure the connection. Next I do authentication on the web service level: in addition to other data I'm sending a BioMOBY object called "User" around. This contains a user ID, a password and an e-mail address. If necessary I validate those against an LDAP server. Instead of doing authentication on the web service level, you could also do authentication on the level of the web server or on the level of the transport layer. The reason I'm not doing this is that it would require extra logic for a workflow builder or client to handle this and not all of them do. Putting the user credentials inside the BioMOBY payload of the SOAP message makes sure this way of handling authentication works with any BioMOBY client :). If anyone has a more elegant solution I'd love the hear about it! Cheers, Pi > So what I was wondering if this issue already came up in Moby ? I'm > currently getting started to understand the current principles of > securing > WebServices, but i was wondering if someone has somehow experiences > with > that ? > > So any comments and hints are welcome :-) > > Best > andreas > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From gordonp at ucalgary.ca Thu Nov 22 10:14:29 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 22 Nov 2007 08:14:29 -0700 Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <61EAB8F5-4A8B-4F8A-B7C9-96390913428A@wur.nl> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> <61EAB8F5-4A8B-4F8A-B7C9-96390913428A@wur.nl> Message-ID: <47459CD5.7010709@ucalgary.ca> Hi Pieter, While your approach definitely works, I am loathe to incorporate authentication within Moby itself, as I mentioned in my previous message. I think a more elegant solution would be for the community to suggest the use of enveloped XML signatures in the MOBY payload. In that way, the authentication is built right into the message (e.g. public-key based), rather than relying on a username/password database. This would also promote one authentication amongst all service providers. It would also be backward compatible, as parsers should ignore the signature tag, as it's not in the MOBY namespace. My $0.02, Paul Pieter Neerincx wrote: > Hi Andreas, > > On 22-nov-2007, at 12:54, groscurt at mpiz-koeln.mpg.de wrote: > > >> Hiho, >> >> at the EU-Sol meeting in Rome we discussed the usability of Moby >> for the >> project. One main issue was if it is possible to secure the data >> send via >> WebServices and to ensure that only specific people are able to use >> specific webservices. This is because the EU-Sol is a closed >> consortium >> with industry partners and they, but also the "normal" biologists, >> demand >> to have a solution which guarantees such requirements. >> > > In one of our collaborations I'm in a similar situation with a > combined public / private consortium. > There are several ways to secure your services, that can already work > with the current state of the BioMOBY art. The thing is that as far > as I know there is not really a standard ... yet. So probably several > people already have different mechanisms in place. > > I'm using HTTPS to secure the connection. Next I do authentication on > the web service level: in addition to other data I'm sending a > BioMOBY object called "User" around. This contains a user ID, a > password and an e-mail address. If necessary I validate those against > an LDAP server. Instead of doing authentication on the web service > level, you could also do authentication on the level of the web > server or on the level of the transport layer. The reason I'm not > doing this is that it would require extra logic for a workflow > builder or client to handle this and not all of them do. Putting the > user credentials inside the BioMOBY payload of the SOAP message makes > sure this way of handling authentication works with any BioMOBY > client :). > > If anyone has a more elegant solution I'd love the hear about it! > > Cheers, > > Pi > > > >> So what I was wondering if this issue already came up in Moby ? I'm >> currently getting started to understand the current principles of >> securing >> WebServices, but i was wondering if someone has somehow experiences >> with >> that ? >> >> So any comments and hints are welcome :-) >> >> Best >> andreas >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> > > ------------------------------------------------------------- > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > > phone: 0317-483 039 > fax: 0317-483 584 > mobile: 06-143 66 783 > mail: pieter.neerincx at wur.nl > skype: pieter.online > ------------------------------------------------------------ > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,47458d42260162341231610! > > > > From Pieter.Neerincx at wur.nl Thu Nov 22 12:01:16 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 22 Nov 2007 18:01:16 +0100 Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <47459CD5.7010709@ucalgary.ca> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> <61EAB8F5-4A8B-4F8A-B7C9-96390913428A@wur.nl> <47459CD5.7010709@ucalgary.ca> Message-ID: Hi Paul, I agree that would be more elegant. Basically I don't care too much about how authentication is handled as long as it works :) and the most important thing would be having something standardised! But for those who want something that has been working already for the past two years, a simple User object is a pragmatic solution for the time being. I had that implemented in a split second. This in contrast to making the secure connection over HTTPS work. Fiddling with SLL certificates and Java keystores isn't always fun :). Cheers, Pi On 22-nov-2007, at 16:14, Paul Gordon wrote: > Hi Pieter, > > While your approach definitely works, I am loathe to incorporate > authentication within Moby itself, as I mentioned in my previous > message. I think a more elegant solution would be for the > community to > suggest the use of enveloped XML signatures in the MOBY payload. In > that way, the authentication is built right into the message (e.g. > public-key based), rather than relying on a username/password > database. > This would also promote one authentication amongst all service > providers. It would also be backward compatible, as parsers should > ignore the signature tag, as it's not in the MOBY namespace. > > My $0.02, > > Paul > > Pieter Neerincx wrote: >> Hi Andreas, >> >> On 22-nov-2007, at 12:54, groscurt at mpiz-koeln.mpg.de wrote: >> >> >>> Hiho, >>> >>> at the EU-Sol meeting in Rome we discussed the usability of Moby >>> for the >>> project. One main issue was if it is possible to secure the data >>> send via >>> WebServices and to ensure that only specific people are able to use >>> specific webservices. This is because the EU-Sol is a closed >>> consortium >>> with industry partners and they, but also the "normal" biologists, >>> demand >>> to have a solution which guarantees such requirements. >>> >> >> In one of our collaborations I'm in a similar situation with a >> combined public / private consortium. >> There are several ways to secure your services, that can already work >> with the current state of the BioMOBY art. The thing is that as far >> as I know there is not really a standard ... yet. So probably several >> people already have different mechanisms in place. >> >> I'm using HTTPS to secure the connection. Next I do authentication on >> the web service level: in addition to other data I'm sending a >> BioMOBY object called "User" around. This contains a user ID, a >> password and an e-mail address. If necessary I validate those against >> an LDAP server. Instead of doing authentication on the web service >> level, you could also do authentication on the level of the web >> server or on the level of the transport layer. The reason I'm not >> doing this is that it would require extra logic for a workflow >> builder or client to handle this and not all of them do. Putting the >> user credentials inside the BioMOBY payload of the SOAP message makes >> sure this way of handling authentication works with any BioMOBY >> client :). >> >> If anyone has a more elegant solution I'd love the hear about it! >> >> Cheers, >> >> Pi >> >> >> >>> So what I was wondering if this issue already came up in Moby ? I'm >>> currently getting started to understand the current principles of >>> securing >>> WebServices, but i was wondering if someone has somehow experiences >>> with >>> that ? >>> >>> So any comments and hints are welcome :-) >>> >>> Best >>> andreas >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >>> >> >> ------------------------------------------------------------- >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> >> phone: 0317-483 039 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> mail: pieter.neerincx at wur.nl >> skype: pieter.online >> ------------------------------------------------------------ >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> !DSPAM:60005,47458d42260162341231610! >> >> >> >> > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From markw at illuminae.com Fri Nov 23 16:52:57 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 23 Nov 2007 13:52:57 -0800 Subject: [MOBY-dev] Question about LSID/RDF resolution preferences Message-ID: Hi all, For anyone who is using the RDF metadata, I have a quick question for you: When we resolve an LSID, we return metadata about that entity. At the moment, however, we change the URI of that entity in our returned metadata. e.g. when we resolve this LSID: urn:lsid:biomoby.org:serviceinstance:bioinfo.icapture.ubc.ca,FASTA2HighestGenericSequenceObject:2006-04-12T18-27-15Z we return an RDF graph about: http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances#bioinfo.icapture.ubc.ca,FASTA2HighestGenericSequenceObject This strikes me as being quite a nasty thing to do to people! However, it does break fewer tools that are not capable of parsing URIs other than URLs. Opinions? Mark From markw at illuminae.com Fri Nov 23 14:16:12 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 23 Nov 2007 11:16:12 -0800 Subject: [MOBY-dev] New method for discovering location of Moby Central Message-ID: Hi all, Since we will be moving Moby Central in the next few days (it now passes all tests!) I thought it would also be a good time to design a more reliable way to discover the location of the registry than to hard-code it into the Perl and Java libraries. I've set-up some redirects on http://biomoby.org as follows: http://biomoby.org/mobycentral http://biomoby.org/ontologyserver these will give you a "301 Permamently Moved" with the "Location" header directing you to the default registry and ontology server respectively. You can use this Perl code to get the locations if you need them, but I'll be adding this into the Perl client code (and asking eddie/martin to do the same for the Java stack) so probably you wont need to know the exact locations in most cases. ============================ #!perl -w use LWP::UserAgent; use HTTP::Request::Common qw(HEAD); my $ua = LWP::UserAgent->new; my $req = HEAD 'http://biomoby.org/mobycentral'; my $res = $ua->simple_request($req); my $mobycentral = $res->header('location'); print "Default Moby Central is at: $mobycentral\n"; $req = HEAD 'http://biomoby.org/ontologyserver'; $res = $ua->simple_request($req); my $ontologyserver = $res->header('location'); print "Default Moby Ontology Server is at: $ontologyserver\n"; ================================ b.t.w. if you are going to write code like this for yourself, PLEASE use the "simple_request" method, rather than the "request" method of LWP, since a simple_request does not automatically follow the 301 redirect (which then results in a 411 error in the registry error log) This strikes me as being a more stable way of locating the registry in the long-term. Any objections/comments? b.t.w. if anyone wants to try the new Moby Central please use these new addresses, but DON'T use the new registry to do any production work yet, since I'll be wiping out and re-cloning the registry database when we "go live" next week. The new registry currently is a clone of Moby Central as of 3 days ago. Best wishes! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Sun Nov 25 02:18:53 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:18:53 -0800 Subject: [MOBY-dev] Tentative plan for the MOBY Central move Message-ID: Hi again everyone! It looks like the new Moby Central is working correctly and all accessories (RESOURCES script, LSID resolver, etc.) are working on the new machine. All we need now is a plan to deal with 24 hours of chaos when we shut-down the old server and switch to the new one. I've been trying to find a way to make Apache redirect POST data to an alternate location but it apparently cannot be done in any "sensible" way (a bug or a feature?? I'm not sure...). Anyway, it means that we'll have to all switch at ~the same time. My plan for the moment is this: 1) Announce the date/time when the switch will happen - the old server will be *switched off* at this time to ensure that we don't get out of sync. 2) I have re-coded the Perl stack (but haven't yet committed it... probably this weekend when I'm really really sure!). It now calls http://biomoby.org/mobycentral and scrapes the 302 Location header from that to determine where MOBY Central really is. This will help ensure that any future move (if necessary) is not so painful. 3) The Perl stack still uses environment variables as its default if they are available, so it will be possible to update your code without forcing the switch to the new server. Just set the MOBY_SERVER and MOBY_ONTOLOGYSERVER environment variables to point to the old MOBY Central until the switch happens. (hopefully the Java code will also do something similar?) 4) On that date/time, I will make a clone of the current MOBY Central database from mobycentral.icapture.ubc.ca and move it to moby.ucalgary.ca, then shut down the old server completely. Basically, a CVS Update is all that should be necessary to make the switch from old to new registries. After more than a month of struggling, we were unable to get MOBY Central to run in 64-bit (combinations of libxml.c problems and mod-perl problems), so the wonderful and patient sysadmins in Calgary spent a lot of time and effort in re-compiling everything in 32 bit so that it all works for us! I sincerely appreciate their commitment!!!! Thanks to them (and I owe them a couple of bottles of scotch, apparently...) In any case, the server in Calgary should have much better connectivity for everyone, so it should all run much faster after the move! The only exception is RDF generation (i.e. the RESOURCES script) since everything in MOBY Central is now pure-perl, and the RDF::Core libraries are significantly slower than their Java counterparts. Eddie is working on a caching mechanism for the RDF, so hopefully it wont be *unusably* slow (apparently it took 15 minutes for Dashboard to load the RDF today without caching... UGH!) Just as an aside, I was playing with the LSID resolver a couple of days ago and I have working code that merges the RDF from all possible metadata endpoints into a single graph. I'll post it to the list if anyone is interested (or just go to my blog: semanticmusings.blogspot.com since I also posted the code there for the sake of the HCLS community). The point of that excercise was that we want service providers to be able to give example input/output to their services in their RDF Signatures, but until now we never had the code that could retrieve metadata from anywhere other than MOBY Central. Now we do! If anyone has any questions or concerns about this plan (e.g. if you are holding a workshop in the next week, and want to be sure that MOBY Central is not "dead" when you try to reach it!) please say so and we'll schedule the move around your event. If it is going to be extremely troublesome we can delay the move until Christmas. Best wishes everyone! Mark From markw at illuminae.com Sun Nov 25 02:37:21 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:37:21 -0800 Subject: [MOBY-dev] other additions Message-ID: Hello again! In the background I have been trying to make various aspects of Moby more "standards compliant" (hey! Stop laughing! Cheeky!!!) Here are the additions I have made: 1) One request that I got repeatedly from all over the place was that the WSDL for a service should be available through a GET, since that's how all *other* Web Services work. This is now possible, and I think we should add it into the API as a legitimate way of getting the WSDL that does not use SOAP calls to the Registry. The URL pattern is: http://biomoby.org/services/wsdl/AUTH_URI/SERVICE_NAME e.g. http://biomoby.org/services/wsdl/antirrhinum.net/getDragonAlleleDescription I intend to ensure that this mechanism is stable forever, so please feel free to write code around it. It likely doesn't affect the Java users as much as the Perl users, since the Java stack doesn't use the retrieveService call on MOBY Central anyway, it creates its SOAP endpoint stubs using the output from a findService call... (right? or am I misunderstanding?) 2) The same WSDL document is now also available when you resolve a Service Instance LSID through a getData call. So, there are now THREE ways to get the WSDL: (a) The Moby Central API retrieveService call; (b) a URL; (c) LSID getData resolution. Hopefully one of these three solutions should please everyone! I know that Martin is going to spank me for this... but I have been spanked by Martin before, and survived! ;-) LOL! Mark From markw at illuminae.com Sun Nov 25 02:45:52 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:45:52 -0800 Subject: [MOBY-dev] Oh! One last thing... Message-ID: The myGrid/myExperiment team wanted a web page where we list all of the Moby Services and their WSDL's. http://biomoby.org/cgi-bin/serviceList This is NOT part of the API, it's just FYI. That page is auto-generated from the registry so it is always up-to-date, but I do NOT promise that it will always exist. I just put it up as a favour to the myGrid team. Still, it might be useful to someone else for some reason. M From markw at illuminae.com Sun Nov 25 02:57:06 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:57:06 -0800 Subject: [MOBY-dev] other additions In-Reply-To: References: Message-ID: Hmmmm... no sooner do I hit "send" than I have a re-think about something that I said... > The URL pattern is: > http://biomoby.org/services/wsdl/AUTH_URI/SERVICE_NAME Perhaps that URL should be: http://biomoby.org/services/wsdl/REGISTRY_URI/AUTH_URI/SERVICE_NAME and that would allow us to support multiple registries with the same URL syntax... That *would* be quite useful, na? I guess this should maybe be an RFC before I claim it as an addition to the API!! What are your thoughts? M From markw at illuminae.com Sun Nov 25 02:57:06 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:57:06 -0800 Subject: [MOBY-dev] other additions In-Reply-To: References: Message-ID: Hmmmm... no sooner do I hit "send" than I have a re-think about something that I said... > The URL pattern is: > http://biomoby.org/services/wsdl/AUTH_URI/SERVICE_NAME Perhaps that URL should be: http://biomoby.org/services/wsdl/REGISTRY_URI/AUTH_URI/SERVICE_NAME and that would allow us to support multiple registries with the same URL syntax... That *would* be quite useful, na? I guess this should maybe be an RFC before I claim it as an addition to the API!! What are your thoughts? M From martin.senger at gmail.com Sat Nov 24 03:55:55 2007 From: martin.senger at gmail.com (Martin Senger) Date: Sat, 24 Nov 2007 08:55:55 +0000 Subject: [MOBY-dev] Tentative plan for the MOBY Central move In-Reply-To: References: Message-ID: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> > All we need now is a plan to deal with 24 hours of chaos No, we don't. But perhaps I missed something. I understand that the problem is that our software (our libraries) do not have (yet) the ability to redirect to the default moby central automatically when its location changes. You already have prepared this ability to the Perl libraries and it is a question of few hours to add it to the jMoby library. So why not to do these changes now, almost silently, but let the libraries point to the old moby center. Then we can announce that in some reasonably time, such as a month or several weeks, everybody is advised to update their installation in order to get new libraries to their machines. Finally, after an announcement period we can switch. Just my 2c's, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Sun Nov 25 04:14:08 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 25 Nov 2007 01:14:08 -0800 Subject: [MOBY-dev] Tentative plan for the MOBY Central move In-Reply-To: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> References: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> Message-ID: The problem is that i cannot find a way to automatically redirect SOAP calls from the old MOBY Central to the new MOBY Central. This is possibly because I do not fully understand the Apache redirect mechanism, but my Google searches have told me that redirecting a POST (as we would need to do with MOBY Central) is not trivial, and is not supported by any native Apache configuration directive. So... I don't think this change can be "silent". I think we all need to update at the same time. I wish it could be silent! If you know a way to do it, please tell me, because I haven't found a way in my own exploration of the problem... M On Sat, 24 Nov 2007 00:55:55 -0800, Martin Senger wrote: >> All we need now is a plan to deal with 24 hours of chaos > > > No, we don't. But perhaps I missed something. > > I understand that the problem is that our software (our libraries) do not > have (yet) the ability to redirect to the default moby central > automatically > when its location changes. You already have prepared this ability to the > Perl libraries and it is a question of few hours to add it to the jMoby > library. So why not to do these changes now, almost silently, but let the > libraries point to the old moby center. Then we can announce that in some > reasonably time, such as a month or several weeks, everybody is advised > to > update their installation in order to get new libraries to their > machines. > Finally, after an announcement period we can switch. > > Just my 2c's, > Martin > From martin.senger at gmail.com Sat Nov 24 09:36:11 2007 From: martin.senger at gmail.com (Martin Senger) Date: Sat, 24 Nov 2007 14:36:11 +0000 Subject: [MOBY-dev] Tentative plan for the MOBY Central move In-Reply-To: References: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> Message-ID: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> > The problem is that i cannot find a way to automatically redirect SOAP > calls from the old MOBY Central to the new MOBY Central No, that is not what I have suggested. I wish it could be silent! If you know a way to do it, please tell me, Actually the way I am suggesting is the one you suggested and you already did :-) You created a stable URL (which is not a URL of a default biomoby central, and which is not a URL that is going to change). This URL is able to give back a URL and URI of a default registry. This URL is not supposed to be widely used directly but it is supposed to be consulted by Perl and Java libraries. The library then uses the obtained result as the default URL and URI. In our current case, we can silently include this ability into our libraries (as you already did for Perl) and tell people that they have a month (or whatever) to update their software (the best way by taking the new versions of our Perl and Java libraries - just by 'cvs update'). At the moment, the "stable URL" I mentioned above will be still pointing to the icapture moby server. After a month (or whatever) we change the result coming from the stable URL to point to Calgary server. Nobody notices anything (unless they are using their own libraries and they did not develop into them the same mechanism in time). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Sun Nov 25 11:42:56 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 25 Nov 2007 08:42:56 -0800 Subject: [MOBY-dev] Tentative plan for the MOBY Central move In-Reply-To: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> References: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> Message-ID: Ah, I see! The same solution, but with the http://biomoby.org/mobycentral pointing to the old server rather than the new server for ~a month! Okay, that's more gentle than what I had suggested :-) Good idea! M On Sat, 24 Nov 2007 06:36:11 -0800, Martin Senger wrote: >> The problem is that i cannot find a way to automatically redirect SOAP >> calls from the old MOBY Central to the new MOBY Central > > > No, that is not what I have suggested. > > I wish it could be silent! If you know a way to do it, please tell me, > > > Actually the way I am suggesting is the one you suggested and you already > did :-) You created a stable URL (which is not a URL of a default biomoby > central, and which is not a URL that is going to change). This URL is > able > to give back a URL and URI of a default registry. This URL is not > supposed > to be widely used directly but it is supposed to be consulted by Perl and > Java libraries. The library then uses the obtained result as the default > URL > and URI. > > In our current case, we can silently include this ability into our > libraries > (as you already did for Perl) and tell people that they have a month (or > whatever) to update their software (the best way by taking the new > versions > of our Perl and Java libraries - just by 'cvs update'). At the moment, > the > "stable URL" I mentioned above will be still pointing to the icapture > moby > server. After a month (or whatever) we change the result coming from the > stable URL to point to Calgary server. Nobody notices anything (unless > they > are using their own libraries and they did not develop into them the same > mechanism in time). > > Cheers, > Martin > From groscurt at mpiz-koeln.mpg.de Mon Nov 26 09:04:56 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Mon, 26 Nov 2007 15:04:56 +0100 Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects In-Reply-To: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> References: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> Message-ID: <200711261504.56503.groscurt@mpiz-koeln.mpg.de> Hi, I'm using CentralCachedCallsImpl to send calls to the Central. The first time i'm calling it it collects the service types from the url http://biomoby.org/RESOURCES/MOBY-S/Objects For the last months this worked fine, but as I tried to today i receive error by error: Cannot parse MOBY Service Type Ontology: com.hp.hpl.jena.shared.JenaException: rethrew: ARP interrupted 15:00:48,230 ERROR [STDERR] java.io.InterruptedIOException: ARP interrupted 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.WrappedException.throwMe(WrappedException.java:74) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.ARPFilter.parse(ARPFilter.java:316) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:221) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:209) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:239) 15:00:48,231 ERROR [STDERR] at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:161) or Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException 15:00:02,396 ERROR [STDERR] java.lang.NullPointerException 15:00:02,396 ERROR [STDERR] at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:182) is this a current or general error ? Does the moving of MobyCentral requires an cvs update ? thanks andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From edward.kawas at gmail.com Mon Nov 26 09:22:29 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 26 Nov 2007 06:22:29 -0800 Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects In-Reply-To: <200711261504.56503.groscurt@mpiz-koeln.mpg.de> References: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> <200711261504.56503.groscurt@mpiz-koeln.mpg.de> Message-ID: <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> Hi Andreas, I cannot reproduce this error. I have tried running the 'main' for each of the classes in the package org.biomoby.shared.extended and each of them worked ... Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Andreas Groscurth Sent: November-26-07 6:05 AM To: Core developer announcements Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects Hi, I'm using CentralCachedCallsImpl to send calls to the Central. The first time i'm calling it it collects the service types from the url http://biomoby.org/RESOURCES/MOBY-S/Objects For the last months this worked fine, but as I tried to today i receive error by error: Cannot parse MOBY Service Type Ontology: com.hp.hpl.jena.shared.JenaException: rethrew: ARP interrupted 15:00:48,230 ERROR [STDERR] java.io.InterruptedIOException: ARP interrupted 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.WrappedException.throwMe(WrappedException.java:74) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.ARPFilter.parse(ARPFilter.java:316) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:221) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:209) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:239) 15:00:48,231 ERROR [STDERR] at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:161) or Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException 15:00:02,396 ERROR [STDERR] java.lang.NullPointerException 15:00:02,396 ERROR [STDERR] at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) is this a current or general error ? Does the moving of MobyCentral requires an cvs update ? thanks andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From groscurt at mpiz-koeln.mpg.de Mon Nov 26 10:25:25 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Mon, 26 Nov 2007 16:25:25 +0100 Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects In-Reply-To: <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> References: <200711261504.56503.groscurt@mpiz-koeln.mpg.de> <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> Message-ID: <200711261625.25954.groscurt@mpiz-koeln.mpg.de> hi, mhm... running it from the parser it also works for me... the following not: public class TestMoby { public static void main( String[] args ) throws Exception { Central central = new CentralCachedCallsImpl( ); MobyService mobyService = new MobyService(); mobyService.setCategory(""); mobyService.setAuthority("arabidopsis.info"); mobyService.setName("NASCArraysGeneswingerByAGI"); mobyService = central.findService(mobyService)[0]; MobyRequest request = new MobyRequest( central ); request.setService( mobyService ); request.setInput( new MobyDataObject( "AGI_LocusCode", "At2g21050" ) ); MobyContentInstance contentInstance = request.invokeService(); } } First it takes a eternity to get the data types - maybe this is just a current (and also a local) issue, but thats the feeling i get, compared to the calles some weeks ago. Second - this is the output I get: Fetching data type ontology from http://biomoby.org/RESOURCES/MOBY-S/Objects Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:182) at org.biomoby.shared.MobyDataType.loadDataTypes(MobyDataType.java:103) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:144) at org.biomoby.shared.data.MobyDataObject.(MobyDataObject.java:78) at org.biomoby.shared.data.MobyDataObject.(MobyDataObject.java:73) at test.TestMoby.main(TestMoby.java:28) Fetching namespace ontology from http://biomoby.org/RESOURCES/MOBY-S/Namespaces There are 1 collections in response 1 Fetching data type ontology from http://biomoby.org/RESOURCES/MOBY-S/Objects So - the namespaces are apparently ok - but it keeps trying to get the data types.... and always ends up in the Nullpointer. Any ideas? thanks andreas On Monday 26 November 2007 15:22, Edward Kawas wrote: > Hi Andreas, > > I cannot reproduce this error. I have tried running the 'main' for each of > the classes in the package org.biomoby.shared.extended and each of them > worked ... > > Eddie > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Andreas Groscurth > Sent: November-26-07 6:05 AM > To: Core developer announcements > Subject: [MOBY-dev] Problems with > http://biomoby.org/RESOURCES/MOBY-S/Objects > > Hi, > > I'm using CentralCachedCallsImpl to send calls to the Central. > > The first time i'm calling it it collects the service types from the url > http://biomoby.org/RESOURCES/MOBY-S/Objects > > For the last months this worked fine, but as I tried to today i receive > error > by error: > > Cannot parse MOBY Service Type Ontology: > com.hp.hpl.jena.shared.JenaException: > rethrew: ARP interrupted > 15:00:48,230 ERROR [STDERR] java.io.InterruptedIOException: ARP interrupted > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.WrappedException.throwMe(WrappedException.java:74) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.ARPFilter.parse(ARPFilter.java:316) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:221) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:209) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:239) > 15:00:48,231 ERROR [STDERR] at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataType >P arser.java:161) > > or > > Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException > 15:00:02,396 ERROR [STDERR] java.lang.NullPointerException > 15:00:02,396 ERROR [STDERR] at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataType >P arser.java:182) > > is this a current or general error ? > > Does the moving of MobyCentral requires an cvs update ? > > thanks > andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From arnaud at ebi.ac.uk Mon Nov 26 06:26:46 2007 From: arnaud at ebi.ac.uk (Arnaud Kerhornou) Date: Mon, 26 Nov 2007 11:26:46 +0000 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Message-ID: <474AAD76.3000101@ebi.ac.uk> Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca47cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstanceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(BiomobyScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.java:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(BiomobyScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerHelperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject.java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject.java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstance.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java:125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMobyXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDatatypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenerateTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocationWithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(ProcessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithoutIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(ProcessorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(ProcessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) -------------- next part -------------- A non-text attachment was scrubbed... Name: geneid_exercise1.xml Type: text/xml Size: 3091 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20071126/050d5129/attachment-0001.xml -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: HS307871.fa Url: http://lists.open-bio.org/pipermail/moby-dev/attachments/20071126/050d5129/attachment-0001.pl From edward.kawas at gmail.com Mon Nov 26 18:34:15 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 26 Nov 2007 15:34:15 -0800 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <474AAD76.3000101@ebi.ac.uk> References: <474AAD76.3000101@ebi.ac.uk> Message-ID: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Hi Arnaud, It seems to be working now. Not sure what the problem was, but I just ran your workflow with your inputs and it worked for me. Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou Sent: November-26-07 3:27 AM To: 'Core developer announcements' Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan ceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby ScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j ava:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby ScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH elperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan ce.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: 125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo byXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat atypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera teTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation WithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P rocessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou tIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce ssorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr ocessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) From edward.kawas at gmail.com Mon Nov 26 18:34:15 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 26 Nov 2007 15:34:15 -0800 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <474AAD76.3000101@ebi.ac.uk> References: <474AAD76.3000101@ebi.ac.uk> Message-ID: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Hi Arnaud, It seems to be working now. Not sure what the problem was, but I just ran your workflow with your inputs and it worked for me. Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou Sent: November-26-07 3:27 AM To: 'Core developer announcements' Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan ceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby ScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j ava:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby ScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH elperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan ce.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: 125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo byXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat atypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera teTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation WithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P rocessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou tIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce ssorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr ocessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) From arnaud at ebi.ac.uk Mon Nov 26 08:09:32 2007 From: arnaud at ebi.ac.uk (Arnaud Kerhornou) Date: Mon, 26 Nov 2007 13:09:32 +0000 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Message-ID: <474AC58C.2090206@ebi.ac.uk> Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into this, please ? Thanks Arnaud PS: Taverna Exception stack: WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca47cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstanceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(BiomobyScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.java:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(BiomobyScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerHelperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject.java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject.java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstance.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java:125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMobyXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDatatypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenerateTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocationWithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(ProcessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithoutIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(ProcessorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(ProcessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) -------------- next part -------------- A non-text attachment was scrubbed... Name: geneid_exercise1.xml Type: text/xml Size: 3092 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20071126/491752a6/attachment.xml -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: HS307871.fa Url: http://lists.open-bio.org/pipermail/moby-dev/attachments/20071126/491752a6/attachment.pl From markw at illuminae.com Mon Nov 26 18:35:19 2007 From: markw at illuminae.com (mark wilkinson) Date: Mon, 26 Nov 2007 23:35:19 +0000 GMT Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> References: <474AAD76.3000101@ebi.ac.uk> <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Message-ID: <63848754-1196120332-cardhu_blackberry.rim.net-15230-@engine10-cell01> Hi all, I have a feeling that these problems were largely rooted in the fact that the LSID resolver caches its WSDL. When I was testing things against the new code against the new endpoint this weekend I was using the LSID resolver on MobyCentral, and it seems that it cached the results and then when the non-updated code tried to access the same resources it was unable to hit the endpoint. I have deleted the lsid cache and that seems to have solved many of the problems we all experienced the past few days. Sorry about that! It took a while to track down that arcane problem... Mark -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Mon, 26 Nov 2007 15:34:15 To:"'Arnaud Kerhornou'" , "'Core developer announcements'" , "'Core developer announcements'" Subject: Re: [MOBY-dev] Parse_moby_data processor in taverna fails Hi Arnaud, It seems to be working now. Not sure what the problem was, but I just ran your workflow with your inputs and it worked for me. Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou Sent: November-26-07 3:27 AM To: 'Core developer announcements' Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan ceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby ScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j ava:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby ScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH elperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan ce.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: 125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo byXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat atypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera teTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation WithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P rocessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou tIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce ssorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr ocessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Nov 26 18:35:19 2007 From: markw at illuminae.com (mark wilkinson) Date: Mon, 26 Nov 2007 23:35:19 +0000 GMT Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> References: <474AAD76.3000101@ebi.ac.uk> <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Message-ID: <63848754-1196120332-cardhu_blackberry.rim.net-15230-@engine10-cell01> Hi all, I have a feeling that these problems were largely rooted in the fact that the LSID resolver caches its WSDL. When I was testing things against the new code against the new endpoint this weekend I was using the LSID resolver on MobyCentral, and it seems that it cached the results and then when the non-updated code tried to access the same resources it was unable to hit the endpoint. I have deleted the lsid cache and that seems to have solved many of the problems we all experienced the past few days. Sorry about that! It took a while to track down that arcane problem... Mark -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Mon, 26 Nov 2007 15:34:15 To:"'Arnaud Kerhornou'" , "'Core developer announcements'" , "'Core developer announcements'" Subject: Re: [MOBY-dev] Parse_moby_data processor in taverna fails Hi Arnaud, It seems to be working now. Not sure what the problem was, but I just ran your workflow with your inputs and it worked for me. Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou Sent: November-26-07 3:27 AM To: 'Core developer announcements' Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan ceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby ScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j ava:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby ScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH elperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan ce.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: 125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo byXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat atypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera teTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation WithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P rocessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou tIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce ssorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr ocessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Nov 26 20:48:28 2007 From: markw at illuminae.com (mark wilkinson) Date: Tue, 27 Nov 2007 01:48:28 +0000 GMT Subject: [MOBY-dev] CVS updated Message-ID: <510644021-1196128322-cardhu_blackberry.rim.net-7890-@engine11-cell01> Hi all, So as per Martin's suggestion, the 301 redirect points to the CURRENT moby central, and will continue to point there until we have as many people updated as possible. Perl users, please CVS update your code and let me know if you find errors. Sorry again about the chaos over the weekend. LSID caching catches me by surprise all the time, and it did so again this time... I didn't expect that simply running new code on the mobycentral machine, without updating mobycentral itself, would cause a problem! Live and learn... M -- Mark Wilkinson ...on the road! From markw at illuminae.com Mon Nov 26 21:16:17 2007 From: markw at illuminae.com (mark wilkinson) Date: Tue, 27 Nov 2007 02:16:17 +0000 GMT Subject: [MOBY-dev] The moby URI Message-ID: <1961185115-1196129989-cardhu_blackberry.rim.net-27939-@engine25-cell01> A couple of people have asked me about the Moby URI that is required by the SOAP Lite libraries. The URI takes the form: http://some.authority/MOBY/Central In my experience, what you put into the some.authority component is completely meaningless. What matters is the MOBY/Central component, which represents the Perl path to the MOBY::Central.pm library. So... Whatever you have it set to now should always work for you regardless of where we move mobycentral to. M -- Mark Wilkinson ...on the road! From groscurt at mpiz-koeln.mpg.de Tue Nov 27 05:05:16 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Tue, 27 Nov 2007 11:05:16 +0100 Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects In-Reply-To: <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> References: <200711261504.56503.groscurt@mpiz-koeln.mpg.de> <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> Message-ID: <200711271105.16413.groscurt@mpiz-koeln.mpg.de> Hi, problem fixed... I checked out the source again and added dome libs which I havent had added before (but it worked ...) and now it works as intended. Thanks andreas On Monday 26 November 2007 15:22, Edward Kawas wrote: > Hi Andreas, > > I cannot reproduce this error. I have tried running the 'main' for each of > the classes in the package org.biomoby.shared.extended and each of them > worked ... > > Eddie > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Andreas Groscurth > Sent: November-26-07 6:05 AM > To: Core developer announcements > Subject: [MOBY-dev] Problems with > http://biomoby.org/RESOURCES/MOBY-S/Objects > > Hi, > > I'm using CentralCachedCallsImpl to send calls to the Central. > > The first time i'm calling it it collects the service types from the url > http://biomoby.org/RESOURCES/MOBY-S/Objects > > For the last months this worked fine, but as I tried to today i receive > error > by error: > > Cannot parse MOBY Service Type Ontology: > com.hp.hpl.jena.shared.JenaException: > rethrew: ARP interrupted > 15:00:48,230 ERROR [STDERR] java.io.InterruptedIOException: ARP interrupted > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.WrappedException.throwMe(WrappedException.java:74) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.ARPFilter.parse(ARPFilter.java:316) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:221) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:209) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:239) > 15:00:48,231 ERROR [STDERR] at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataType >P arser.java:161) > > or > > Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException > 15:00:02,396 ERROR [STDERR] java.lang.NullPointerException > 15:00:02,396 ERROR [STDERR] at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataType >P arser.java:182) > > is this a current or general error ? > > Does the moving of MobyCentral requires an cvs update ? > > thanks > andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From arnaud at ebi.ac.uk Tue Nov 27 05:08:08 2007 From: arnaud at ebi.ac.uk (Arnaud Kerhornou) Date: Tue, 27 Nov 2007 10:08:08 +0000 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> References: <474AAD76.3000101@ebi.ac.uk> <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Message-ID: <474BEC88.9010205@ebi.ac.uk> hi Eddie, Actually the taverna workflow worked but I still get an Exception at the moby parsing stage. Should I clean my local cache ? Arnaud PS: Exception stack org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca47cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 502 for URL: http://mobycentral.icapture.ubc.ca/authority/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstanceCache(BiomobyScavengerWorker.java:709) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(BiomobyScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.java:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(BiomobyScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerHelperThread.run(ScavengerHelperThreadPool.java:123) Edward Kawas wrote: > Hi Arnaud, > > It seems to be working now. Not sure what the problem was, but I just ran > your workflow with your inputs and it worked for me. > > Eddie > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou > Sent: November-26-07 3:27 AM > To: 'Core developer announcements' > Subject: [MOBY-dev] Parse_moby_data processor in taverna fails > > Hi, > > I just tried a workflow that was working fine last week with taverna > 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the > exception stack below), > > (I have attached the workflow, it takes a fasta sequence) > > Can someone look into it, please ? > > Thanks > Arnaud > > WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: > org.biomoby.shared.MobyException: Cannot write to > '/Users/axk/Library/Application > Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 > 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. > java.io.IOException: Server returned HTTP response code: 500 for URL: > http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances > at > org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) > at > org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan > ceCache(BiomobyScavengerWorker.java:742) > at > org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby > ScavengerWorker.java:392) > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j > ava:50) > at > org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby > ScavengerHelper.java:140) > at > org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH > elperThread.run(ScavengerHelperThreadPool.java:123) > Cannot parse MOBY Object Ontology: java.lang.NullPointerException > java.lang.NullPointerException > at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP > arser.java:182) > at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) > at > org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) > at > org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. > java:186) > at > org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. > java:152) > at > org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan > ce.java:240) > at > org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: > 125) > at > org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) > at > org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) > at > org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo > byXML.java:75) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat > atypeTask.java:100) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera > teTemplates(ProcessorTask.java:576) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation > WithRetryLogic(ProcessorTask.java:517) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P > rocessorTask.java:436) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou > tIteration(ProcessorTask.java:642) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce > ssorTask.java:353) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr > ocessorTask.java:280) > at > uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) > > > > ___________________________________________________________________________ Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire. http://fr.mail.yahoo.com From dmitry.repchevski at bsc.es Tue Nov 27 14:59:44 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Tue, 27 Nov 2007 20:59:44 +0100 Subject: [MOBY-dev] Moby Java JAXB API Message-ID: <474C7730.9010801@bsc.es> Hello everybody, I would like to get your opinion about the demo I made. The demo is actually a simple Moby client which is connected to our repository (http://moby-dev.inab.org/cgi-bin/MOBY-Central.pl) obtain the list of "simple" services (those that accepts MobyObject as input) from our url (inb.bsc.es) and give a possibility to call them. The interesting thing is that the client uses its own API based on JAXB. There are four jars you can download: http://inb.bsc.es/java/MobyCore.jar http://inb.bsc.es/java/MobyRegistry.jar http://inb.bsc.es/java/MobyGenerator.jar http://inb.bsc.es/java/MobyDemoClient.jar with source code in: http://inb.bsc.es/java/MobyCore-src.zip http://inb.bsc.es/java/MobyRegistry-src.zip http://inb.bsc.es/java/MobyGenerator-src.zip http://inb.bsc.es/java/MobyDemoClient-src.zip MobyCore.jar contains the API to marshall/unmarshall moby messages as well as call moby services. Actually there is almost no API at all, because most of the classes are JAXB annotated java classes with get/set methods. MobyCore can work without any pregenerated datatypes in this case all moby objects are converted to AnyMobyObject class by unmarshaller. There is also a simple ontology generator - MobyGenerator. It connects to moby-central and generates JAXB annotated datatype classes with proper get/set methods using java inheritance for "IS" and java properties for HASA/HAS (in latter case List<>) As I mentioned before there is no need to generate the ontology to work with API so one can use AnyMobyObject o = AnyMobyObject("PDB-Text"); o.setMobyId(""); o.setNamespace(""); o.setArticleName(""); o.putAttribute("context", new MobyString("some text")); or PDB_Text o = new PDB_Text(); o.setMobyId(""); o.setNamespace(""); o.setArticleName(""); o.setContent(new MobyString("some text"); MobyRegistry is as you can guess JAXB classes to work with Registry API. The package is still clumsy even with help from Edward Kawas, there are just too many classes may times duplicated... So what it the typical use case? Something like: ******************************************************************************** MobyData mobyData = new MobyData("sip_1"); AminoAcidSequence sequence = new AminoAcidSequence(); sequence.setSequenceString(new MobyString("MKELNDLEKKYNAHIGVYALDTKSGKEVKFNSDKRFAYASTSKAINSAILLEQVPYNKLNKKVHINKDDIVAYSPILEKY" + "VGKDITLKALIEASMTYSDNTANNKIIKEIGGIKKVKQRLKELGDKVTNPVRYEIELNYYSPKSKKDTSTPAAFGKTLNK" + "LIANGKLSKENKKFLLDLMLNNKSGDTLIKDGVPKDYKVADKSGQSTYASRNDVAFVYPKGQSEPIVLVIFTNKDNKSDK" + "PNDKLISETAKSVMKEF")); sequence.setLength(new MobyInteger(257)); mobyData.addMobyDataElement(new MobySimple(sequence, "sequence")); mobyData.addParameter(new MobyParameter("scores", "25")); mobyData.addParameter(new MobyParameter("alignments", "2")); MobyMessage message = new MobyMessage(mobyData); MobyServiceEndpoint service = new MobyServiceEndpoint("http://inb.bsc.es/cgi-bin/mobyServices/dispatchers/asyncDispatcher.cgi", "runNCBITBlastn"); MobyMessage m = service.call(message); if (m.hasExceptions()) { List exceptions = m.getExceptions(); for (MobyException ex : exceptions) { System.out.print(ex.getSeverity().name()); System.out.print(" "); System.out.print(ex.getRefQueryID()); System.out.print(" "); System.out.println(ex.getRefElement()); System.out.print("---- code = "); System.out.print(ex.getExceptionCode()); System.out.println("---->"); System.out.println(ex.getExceptionMessage()); } } else { List mobyDataList = m.getMobyDataList(); for (MobyData md : mobyDataList) { MobySimple simple = md.getData(""); // article name BLAST_Text blast = simple.getObject(); System.out.println("=============>\n" + blast.getContent().getString()); } } ******************************************************************************** Finally I would like to notice that API NEED JAX-WS 2.1. AND (at least MobyGenerator) Java6. So to test it someone has to install jax-ws into endorsed directory (in jre/lib/ create a directory named "endorsed" and put all jax-ws packages into it). JAX-WS you can download from https://jax-ws.dev.java.net/ri-download.html Again this is the version of JAX-WS which is included in next Java 6 update (in a few months) and what is important with update N (https://jdk6.dev.java.net/6uNea.html) The demo itself is pretty simple, but I hope you will like it :-) Just forgot - both Demo and MobyGenerator need MobyCore and MobyRegistry jars :-) MobyGenerator needs JDK 6 to be able to compile generated classes (otherwise it creates zipped sources). Cheers, Dmitry From markw at illuminae.com Thu Nov 29 17:59:58 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 29 Nov 2007 14:59:58 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central Message-ID: Hi again all, The new Moby Central is available at: http://moby.ucalgary.ca/moby/MOBY-Central.pl http://moby.ucalgary.ca/moby/OntologyServer.cgi It would be great for people to give it a test run before we make the move permanent. It loads much faster into tools like Taverna because it caches its RDF(thanks Eddie!) Please don't use it for registering services, only for service discovery. It synchronizes with the registry at mobycentral.icapture.ubc.ca at 3:45AM Mountain Standard Time every night, so any services that you register in it will be lost! M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From groscurt at mpiz-koeln.mpg.de Fri Nov 30 03:57:33 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 09:57:33 +0100 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: Message-ID: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> Hi do I understand it correctly: URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi However, the first works, but the second seems not to work. In the browser I get 500 Internal Server Error and in the dashboard ===ERROR=== Fault details: [stackTrace: null] [hostname: null] Fault string: Failed to access class (moby::OntologyServer.cgi) at /opt/coolstack/lib/perl5/site_perl/5.8.8/SOAP/Lite.pm line 2473, line 159. Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client Fault actor: null When calling: http://moby.ucalgary.ca/moby/MOBY-Central.pl =========== Any solutions ? thx On Thursday 29 November 2007 23:59, Mark Wilkinson wrote: > Hi again all, > > The new Moby Central is available at: > > http://moby.ucalgary.ca/moby/MOBY-Central.pl > http://moby.ucalgary.ca/moby/OntologyServer.cgi > > It would be great for people to give it a test run before we make the move > permanent. It loads much faster into tools like Taverna because it caches > its RDF(thanks Eddie!) > > Please don't use it for registering services, only for service discovery. > It synchronizes with the registry at mobycentral.icapture.ubc.ca at 3:45AM > Mountain Standard Time every night, so any services that you register in > it will be lost! > > M -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From groscurt at mpiz-koeln.mpg.de Fri Nov 30 03:58:36 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 09:58:36 +0100 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: Message-ID: <200711300958.37078.groscurt@mpiz-koeln.mpg.de> And I forgot. the default "old" central is apparently not accessible... at least I do always get a timeout. best andreas Hi do I understand it correctly: URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi However, the first works, but the second seems not to work. In the browser I get 500 Internal Server Error and in the dashboard ===ERROR=== Fault details: [stackTrace: null] [hostname: null] Fault string: Failed to access class (moby::OntologyServer.cgi) at /opt/coolstack/lib/perl5/site_perl/5.8.8/SOAP/Lite.pm line 2473, line 159. Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client Fault actor: null When calling: http://moby.ucalgary.ca/moby/MOBY-Central.pl =========== Any solutions ? thx On Thursday 29 November 2007 23:59, Mark Wilkinson wrote: > Hi again all, > > The new Moby Central is available at: > > http://moby.ucalgary.ca/moby/MOBY-Central.pl > http://moby.ucalgary.ca/moby/OntologyServer.cgi > > It would be great for people to give it a test run before we make the move > permanent. It loads much faster into tools like Taverna because it caches > its RDF(thanks Eddie!) > > Please don't use it for registering services, only for service discovery. > It synchronizes with the registry at mobycentral.icapture.ubc.ca at 3:45AM > Mountain Standard Time every night, so any services that you register in > it will be lost! > > M -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From markw at illuminae.com Fri Nov 30 04:02:02 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:02:02 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> References: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> Message-ID: On Fri, 30 Nov 2007 00:57:33 -0800, Andreas Groscurth wrote: > do I understand it correctly: > > URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl > URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi No. MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl MOBY_URI = http://whatever.you.want/MOBY/Central MOBY_ONTOLOGYSERVER= http://moby.ucalgary.ca/moby/OntologyServer.cgi (Taverna wont need the latter, but the Perl clients do) From markw at illuminae.com Fri Nov 30 04:06:57 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:06:57 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: <200711300958.37078.groscurt@mpiz-koeln.mpg.de> References: <200711300958.37078.groscurt@mpiz-koeln.mpg.de> Message-ID: Yeah, it looks like the server has crashed. I can't even SSH into it. I've sent a message to the sysadmins, but they wont get it for another 6 hours at best, so... >>sigh<< Sorry! Mark On Fri, 30 Nov 2007 00:58:36 -0800, Andreas Groscurth wrote: > And I forgot. > > the default "old" central is apparently not accessible... at least I do > always > get a timeout. > > best > andreas > > > Hi > > do I understand it correctly: > > URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl > URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi > > However, the first works, but the second seems not to work. In the > browser I > get 500 Internal Server Error and in the dashboard > > ===ERROR=== > Fault details: > [stackTrace: null] > [hostname: null] > Fault string: Failed to access class (moby::OntologyServer.cgi) > at /opt/coolstack/lib/perl5/site_perl/5.8.8/SOAP/Lite.pm line 2473, > line > 159. > > Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client > Fault actor: null > When calling: > http://moby.ucalgary.ca/moby/MOBY-Central.pl > =========== > > Any solutions ? > thx > > On Thursday 29 November 2007 23:59, Mark Wilkinson wrote: >> Hi again all, >> >> The new Moby Central is available at: >> >> http://moby.ucalgary.ca/moby/MOBY-Central.pl >> http://moby.ucalgary.ca/moby/OntologyServer.cgi >> >> It would be great for people to give it a test run before we make the >> move >> permanent. It loads much faster into tools like Taverna because it >> caches >> its RDF(thanks Eddie!) >> >> Please don't use it for registering services, only for service >> discovery. >> It synchronizes with the registry at mobycentral.icapture.ubc.ca at >> 3:45AM >> Mountain Standard Time every night, so any services that you register in >> it will be lost! >> >> M > From groscurt at mpiz-koeln.mpg.de Fri Nov 30 04:11:33 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 10:11:33 +0100 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> Message-ID: <200711301011.33675.groscurt@mpiz-koeln.mpg.de> Thanks mark, nice time to answer my mail :-) /bow On Friday 30 November 2007 10:02, Mark Wilkinson wrote: > On Fri, 30 Nov 2007 00:57:33 -0800, Andreas Groscurth > > wrote: > > do I understand it correctly: > > > > URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl > > URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi > > No. > > MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl > MOBY_URI = http://whatever.you.want/MOBY/Central > > MOBY_ONTOLOGYSERVER= http://moby.ucalgary.ca/moby/OntologyServer.cgi > > (Taverna wont need the latter, but the Perl clients do) > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From markw at illuminae.com Fri Nov 30 04:16:53 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:16:53 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: <200711301011.33675.groscurt@mpiz-koeln.mpg.de> References: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> <200711301011.33675.groscurt@mpiz-koeln.mpg.de> Message-ID: On Fri, 30 Nov 2007 01:11:33 -0800, Andreas Groscurth wrote: > Thanks mark, > > nice time to answer my mail :-) The benefits of a segmented sleep pattern :-) http://en.wikipedia.org/wiki/Segmented_sleep Mark From markw at illuminae.com Fri Nov 30 04:20:56 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:20:56 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> Message-ID: > MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl > MOBY_URI = http://whatever.you.want/MOBY/Central I'm not sure if the Java libraries are sensitive to the content of the "whatever.you.want" section (or if they need a URI at all??) M From groscurt at mpiz-koeln.mpg.de Fri Nov 30 04:37:36 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 10:37:36 +0100 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: Message-ID: <200711301037.36999.groscurt@mpiz-koeln.mpg.de> Apparently they are ok with that.. at least dashboard is loading from the url and uri.... But currently i use http://moby.ucalgary.ca/moby/MOBY-Central.pl and http://moby.ucalgary.ca/MOBY/Central On Friday 30 November 2007 10:20, Mark Wilkinson wrote: > > MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl > > MOBY_URI = http://whatever.you.want/MOBY/Central > > I'm not sure if the Java libraries are sensitive to the content of the > "whatever.you.want" section (or if they need a URI at all??) > > M > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From markw at illuminae.com Fri Nov 30 04:40:38 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:40:38 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: <200711301037.36999.groscurt@mpiz-koeln.mpg.de> References: <200711301037.36999.groscurt@mpiz-koeln.mpg.de> Message-ID: Okay, thanks for the confirmation. Mark On Fri, 30 Nov 2007 01:37:36 -0800, Andreas Groscurth wrote: > Apparently they are ok with that.. at least dashboard is loading from > the url > and uri.... > > But currently i use > > http://moby.ucalgary.ca/moby/MOBY-Central.pl > and > http://moby.ucalgary.ca/MOBY/Central > > On Friday 30 November 2007 10:20, Mark Wilkinson wrote: >> > MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl >> > MOBY_URI = http://whatever.you.want/MOBY/Central >> >> I'm not sure if the Java libraries are sensitive to the content of the >> "whatever.you.want" section (or if they need a URI at all??) >> >> M >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > From groscurt at mpiz-koeln.mpg.de Fri Nov 30 06:23:06 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 12:23:06 +0100 Subject: [MOBY-dev] Using CentralDigestCachedImpl.... In-Reply-To: <47267E18.4010509@ucalgary.ca> References: <91C40642-83C2-4ECC-92C7-BB150BD700CA@farmbio.uu.se> <77B231CC-2BE8-4121-90A5-A6899C336C7D@farmbio.uu.se> <47267E18.4010509@ucalgary.ca> Message-ID: <200711301223.07171.groscurt@mpiz-koeln.mpg.de> Hi, I'm using CentralDigestCachedImpl for caching the datatypes and namespaces locally. CentralDigestCachedImpl cachedImpl = new CentralDigestCachedImpl("http://moby.ucalgary.ca/moby/MOBY-Central.pl","http://moby.ucalgary.ca/MOBY/Central", file.getAbsolutePath() ); cachedImpl.updateCache( CentralDigestCachedImpl.CACHE_PART_DATATYPES ); cachedImpl.updateCache( CentralDigestCachedImpl.CACHE_PART_NAMESPACES ); This works fine and re-calls use the local cache. But when I create a new MobyDataObject, it starts again to fetch the datatypes Fetching data type ontology from http://moby.ucalgary.ca/RESOURCES/MOBY-S/Objects So how do I tell it, that its already has these information ? the MobyDataObject can also have a Registry Object - so i guess that can help - but how to I link my CachedCentral with a Registry object ? Or is this otherwise solveable ? thx andreas From groscurt at mpiz-koeln.mpg.de Fri Nov 30 09:20:55 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 15:20:55 +0100 Subject: [MOBY-dev] Movement of Moby and Java Code In-Reply-To: <200711301223.07171.groscurt@mpiz-koeln.mpg.de> References: <91C40642-83C2-4ECC-92C7-BB150BD700CA@farmbio.uu.se> <47267E18.4010509@ucalgary.ca> <200711301223.07171.groscurt@mpiz-koeln.mpg.de> Message-ID: <200711301520.55828.groscurt@mpiz-koeln.mpg.de> HI, and another question.... In the CentralImpl class the two final variables DEFAULT_ENDPOINT and DEFAULT_NAMESPACE are defined and point to the 'old' MobyCentral. As this is currently not available some calls fail. A general question is: will this code be changed to point to the new central ? will the old URL be available and redirect to the new central ? Best andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From martin.senger at gmail.com Fri Nov 30 10:03:46 2007 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 30 Nov 2007 15:03:46 +0000 Subject: [MOBY-dev] Movement of Moby and Java Code In-Reply-To: <200711301520.55828.groscurt@mpiz-koeln.mpg.de> References: <91C40642-83C2-4ECC-92C7-BB150BD700CA@farmbio.uu.se> <47267E18.4010509@ucalgary.ca> <200711301223.07171.groscurt@mpiz-koeln.mpg.de> <200711301520.55828.groscurt@mpiz-koeln.mpg.de> Message-ID: <4d93f07c0711300703g114c03a0mefad3ec08c780352@mail.gmail.com> > A general question is: will this code be changed to point to the new > central ? Yes, it will be changed (I will do it next week). No, it will not point to a new central :-) Instead, it will be dynamically filled from the data provided by a URL Mark gave us. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Nov 30 12:07:36 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 09:07:36 -0800 Subject: [MOBY-dev] It's worse than that... she's dead, Jim! Message-ID: Well, Moby Central is dead dead dead! We're not sure if it is a hard drive crash or a motherboard problem, but regardless, it doesn't look promising. I'm waiting on the definitive word from our sysadmin for how long it will take to fix. If it's more than a day or two, then I guess this makes the migration decision for us! I'm swiching the redirect on biomoby.org to point to the server in Calgary right now. If you have CVS updated your Perl libraries you will immediately start using the new registry when that happens. To migrate Taverna, edit the taverna/conf/mygrid.properties file to point to the new MOBY Central: http://moby.ucalgary.ca/moby/MOBY-Central.pl Gbrowse-moby is also running on the new server: http://moby.ucalgary.ca/gbrowse_moby There will be a variety of things that *don't* work - e.g. the registry encyclopedia, etc. but I think most of the core functionality is available on the new machine already. Of course, almost all of *my* services are going to be dead, since they were running on that machine. I'll try to get them running again ASAP. I'll keep you all updated throughout the day, and hopefully we'll know enough to make a final decision tonight. Best wishes! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Fri Nov 30 12:39:42 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 09:39:42 -0800 Subject: [MOBY-dev] Things that don't work at the moment Message-ID: Hi, So, anything that relies on LSID resolution is broken (including Gbrowse-moby), since the LSID SRV record in the DNS is pointing to the old server. I've just contacted Chris D. at Open-Bio and asked him if he could update their DNS. Might take a while... M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From gordonp at ucalgary.ca Fri Nov 30 13:01:56 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 30 Nov 2007 11:01:56 -0700 Subject: [MOBY-dev] Movement of Moby and Java Code In-Reply-To: <4d93f07c0711300703g114c03a0mefad3ec08c780352@mail.gmail.com> References: <91C40642-83C2-4ECC-92C7-BB150BD700CA@farmbio.uu.se> <47267E18.4010509@ucalgary.ca> <200711301223.07171.groscurt@mpiz-koeln.mpg.de> <200711301520.55828.groscurt@mpiz-koeln.mpg.de> <4d93f07c0711300703g114c03a0mefad3ec08c780352@mail.gmail.com> Message-ID: <47505014.2080606@ucalgary.ca> In the interim, if you are using the org.biomoby.shared.data packages, you'll need to explicitly use the Calgary registry, e.g. Registry registry = new Registry("calgary", "http://moby.ucalgary.ca/moby/MOBY-Central.pl", "http://useless.domain.com/MOBY/Central"); MobyContentInstance contents = MobyDataUtils.fromXMLDocument(stream, registry); Martin Senger wrote: >> A general question is: will this code be changed to point to the new >> central ? >> > > > Yes, it will be changed (I will do it next week). > No, it will not point to a new central :-) Instead, it will be dynamically > filled from the data provided by a URL Mark gave us. > > Cheers, > Martin > > From markw at illuminae.com Thu Nov 1 00:09:23 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 31 Oct 2007 17:09:23 -0700 Subject: [MOBY-dev] findService question In-Reply-To: <4729046A.3070205@bsc.es> References: <4729046A.3070205@bsc.es> Message-ID: Sorry for adding to the confusion :-) LOL! I really should just let Eddie handle these questions, but sometimes I feel inclined to participate :-) I should know better... M On Wed, 31 Oct 2007 15:40:42 -0700, Dmitry Repchevsky wrote: > >The answer is no! > > Could not be more clear :-) > > Thanx, > > Dmitry > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ola.spjuth at farmbio.uu.se Thu Nov 1 21:51:46 2007 From: ola.spjuth at farmbio.uu.se (Ola Spjuth) Date: Thu, 1 Nov 2007 22:51:46 +0100 Subject: [MOBY-dev] Service inputs: Required or optional? Message-ID: <698036CE-995F-491F-A1F9-AF177F61CB8C@farmbio.uu.se> Hi, I have a general question regarding what information is required and which is optional for different services. When trying to validatate primary inputs for the service GeneticMap2GFF , which only takes a GeneticMap as input, I have some questions how the following should be interpreted: From Dashboard for reference: GeneticMap A genetic map contains mapped loci. The length component should indicate the length of the map in map units, but does NOT have to be zero-based; i.e. the length is simply the distance from the most proximal to the most distal marker on the map, regardless of whether or not the proximal marker is at position '0' on the map. It is likely that, in many cases, the namespace and id of this GeneticMap will be identical to the namespace and id of the 'chromosome' component of the MappedLoci's MapPosition, but this isn't required if the various Loci are more sensibly associated with another map. HAS: MappedLocus [MappedLocus] HASA: Length [Float] MappedLocus A locus that is mapped to a genetic map. the Locus component should hold a Locus (with the associated namespace and id as appropriate), while the MapPosition component should hold the chromosome, start, and end position for that Locus. Start and end may be the same to indicate point maps rather than range maps. HASA: Locus [Locus] HASA: MapPosition Locus Descr: A lightweight object representing a Locus. The namespace and id should indicate the specific Locus being described. The contained Allele objects may be used to indicate a series of Alleles for that locus, if appropriate. If there is no Allele information, or if specification of an Allele is not appropriate (e.g. in the case of a MappedLocus object), then a single Allele object with blank namespace, id, and description would be appropriate. HAS: Allele[Allele] Allele Descr: A lightweight object representing an Allele. The namespace and id should indicate the specific Allele being described. The contained String object is a human-readable description of the Allele in whatever form is most appropriate (e.g. the phenotype). HASA: description [String] MapPosition Descr: A position on a genetic map. HASA: chromosome [String] HASA: start [Float] HASA: end [Float] Please correct me if I'm wrong with the following statements: 1) Primitive MobyObjects cannot have ID and NAMESPACE but must have a VALUE. 2) A GeneticMap must have at least one (but could have many) MappedLocus and must have a Length. It must also have an ID and a Namespace, even though the description says something that it is not a requirement 3) A MappedLocus must have a Locus and a MapPosition. Judging from the Descrition it seems that no ID and no NAMESPACE is required. Is this true, and how can this information be extracted from the DataType? 4) A Locus must have at least one Allele. It seems that it also needs an ID and a NAMESPACE. 5) A HASA relationship indicates that this object is required, for example it is not a valid MapPosition if it does not have a chromosome string-value, and start and end float-values. I guess my questions boil down to: How can I tell what parameters are required and which can be omitted when invoking a service? Can service providers specify that ID and NAMESPACE are required or optional for a PrimaryInput or is the only way of knowing this to read the Description (or sometimes comment)? For simple services (like retrieval from a DB) this is trivial, but for complex cases (like above) it is still a bit unclear for me. Hope you can help me out! Cheers, .../Ola From akerhornou at imim.es Fri Nov 2 19:28:40 2007 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri, 02 Nov 2007 19:28:40 +0000 Subject: [MOBY-dev] Add BioMOBY Parser functionality in taverna (1.6.2) Message-ID: <472B7A68.70804@imim.es> Hi everyone, I can not get a BioMOBY Parser for a Moby service called fromGenericSequenceCollectionToFASTA. I have no problem getting a parser with fromGenericSequenceToFASTA, which is very similar, the only difference is that it takes a GenericSequence object, instead of a collection of GenericSequence objects. I have attached a workflow and an input document, Any idea why I can't get a parser for fromGenericSequenceCollectionToFASTA service ? Thanks Arnaud -------------- next part -------------- A non-text attachment was scrubbed... Name: FASTA_parsing_Test.xml Type: text/xml Size: 3467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: identifier_input_example.xml Type: text/xml Size: 1008 bytes Desc: not available URL: From edward.kawas at gmail.com Fri Nov 2 20:14:50 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 2 Nov 2007 13:14:50 -0700 Subject: [MOBY-dev] Service inputs: Required or optional? In-Reply-To: <698036CE-995F-491F-A1F9-AF177F61CB8C@farmbio.uu.se> References: <698036CE-995F-491F-A1F9-AF177F61CB8C@farmbio.uu.se> Message-ID: <004a01c81d8d$073cf9d0$6400a8c0@notebook> Hi Ola, Most of your assertions are correct. The one assertion that you made that is false is about ns/id for primitive datatypes. All datatypes have a ns/id attribute associated with them. Sometimes they are filled in and mean something, and in other cases they are left blank. Usually if I create a retrieval type service, like getFASTAById, I fill in the ns/id with id for the sequence and the ns being the database that the sequence came from. To answer your last question, take a look at the following url: http://biomoby.open-bio.org/index.php/2007/06/02/do-all-contained-objects-ha ve-to-be-there/ Hope that this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Ola Spjuth > Sent: Thursday, November 01, 2007 2:52 PM > To: Core developer announcements > Subject: [MOBY-dev] Service inputs: Required or optional? > > Hi, > > I have a general question regarding what information is > required and which is optional for different services. > > When trying to validatate primary inputs for the service > GeneticMap2GFF , which only takes a GeneticMap as input, I > have some questions how the following should be interpreted: > > From Dashboard for reference: > > GeneticMap > A genetic map contains mapped loci. The length component > should indicate the length of the map in map units, but does > NOT have to be zero-based; i.e. the length is simply the > distance from the most proximal to the most distal marker on > the map, regardless of whether or not the proximal marker is > at position '0' on the map. It is likely that, in many > cases, the namespace and id of this GeneticMap will be > identical to the namespace and id of the 'chromosome' > component of the MappedLoci's MapPosition, but this isn't > required if the various Loci are more sensibly associated > with another map. > HAS: MappedLocus [MappedLocus] > HASA: Length [Float] > > MappedLocus > A locus that is mapped to a genetic map. the Locus component > should hold a Locus (with the associated namespace and id as > appropriate), while the MapPosition component should hold the > chromosome, start, and end position for that Locus. Start > and end may be the same to indicate point maps rather than range maps. > HASA: Locus [Locus] > HASA: MapPosition > > Locus > Descr: A lightweight object representing a Locus. The > namespace and id should indicate the specific Locus being > described. The contained Allele objects may be used to > indicate a series of Alleles for that locus, if appropriate. > If there is no Allele information, or if specification of an > Allele is not appropriate (e.g. in the case of a MappedLocus > object), then a single Allele object with blank namespace, > id, and description would be appropriate. > HAS: Allele[Allele] > > Allele > Descr: A lightweight object representing an Allele. The > namespace and id should indicate the specific Allele being > described. The contained String object is a human-readable > description of the Allele in whatever form is most > appropriate (e.g. the phenotype). > HASA: description [String] > > MapPosition > Descr: A position on a genetic map. > HASA: chromosome [String] > HASA: start [Float] > HASA: end [Float] > > > Please correct me if I'm wrong with the following statements: > > 1) Primitive MobyObjects cannot have ID and NAMESPACE but > must have a VALUE. > > 2) A GeneticMap must have at least one (but could have many) > MappedLocus and must have a Length. It must also have an ID > and a Namespace, even though the description says something > that it is not a requirement > > 3) A MappedLocus must have a Locus and a MapPosition. Judging > from the Descrition it seems that no ID and no NAMESPACE is > required. Is this true, and how can this information be > extracted from the DataType? > > 4) A Locus must have at least one Allele. It seems that it > also needs an ID and a NAMESPACE. > > 5) A HASA relationship indicates that this object is > required, for example it is not a valid MapPosition if it > does not have a chromosome string-value, and start and end > float-values. > > I guess my questions boil down to: > How can I tell what parameters are required and which can be > omitted when invoking a service? Can service providers > specify that ID and NAMESPACE are required or optional for a > PrimaryInput or is the only way of knowing this to read the > Description (or sometimes comment)? > For simple services (like retrieval from a DB) this is > trivial, but for complex cases (like above) it is still a bit > unclear for me. Hope you can help me out! > > Cheers, > > .../Ola > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Fri Nov 2 20:31:30 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 2 Nov 2007 13:31:30 -0700 Subject: [MOBY-dev] Add BioMOBY Parser functionality in taverna (1.6.2) In-Reply-To: <472B7A68.70804@imim.es> References: <472B7A68.70804@imim.es> Message-ID: <004d01c81d8f$5a27b660$6400a8c0@notebook> Hi Arnaud, That must be a bug. I will try to track it down and fix it. Thanks for the thorough report! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Arnaud Kerhornou > Sent: Friday, November 02, 2007 12:29 PM > To: taverna-users mailing list; Core developer announcements > Subject: [MOBY-dev] Add BioMOBY Parser functionality in > taverna (1.6.2) > > Hi everyone, > > I can not get a BioMOBY Parser for a Moby service called > fromGenericSequenceCollectionToFASTA. > I have no problem getting a parser with > fromGenericSequenceToFASTA, which is very similar, the only > difference is that it takes a GenericSequence object, instead > of a collection of GenericSequence objects. > > I have attached a workflow and an input document, > > Any idea why I can't get a parser for > fromGenericSequenceCollectionToFASTA service ? > > Thanks > Arnaud > > > > > From dmitry.repchevski at bsc.es Mon Nov 5 11:40:11 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 05 Nov 2007 12:40:11 +0100 Subject: [MOBY-dev] Secondary Parameters "min" "max" datatype Message-ID: <472F011B.4000707@bsc.es> Hello! I'm little confused about min, max values in Secondary Parameters... according the schema: is it the String? Cheers, Dmitry From dmitry.repchevski at bsc.es Mon Nov 5 14:14:18 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 05 Nov 2007 15:14:18 +0100 Subject: [MOBY-dev] Secondary Parameters question. Message-ID: <472F253A.6030004@bsc.es> Hello! I have another question about Secondary Parameters. using findService operation I can obtain the list of Secondary Parameters, for example; ***************************************************************** Integer ***************************************************************** The problem I have is that they are specified outside the tag, right? So there could be only one list of parameters per request, right? So in case of having two tags (two mobyData) in which one I should to put those parameters? Imagine the situation where I have two Simple inputs (with two corresponding mobyData) and one list of parameters. In the service description there could be only one (?) list of parameters, but in moby message there could be as many, as mobyData. Could anyone illuminate me, please? Sincerely, Dmitry From martin.senger at gmail.com Mon Nov 5 14:28:51 2007 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 5 Nov 2007 14:28:51 +0000 Subject: [MOBY-dev] Secondary Parameters question. In-Reply-To: <472F253A.6030004@bsc.es> References: <472F253A.6030004@bsc.es> Message-ID: <4d93f07c0711050628y723e83d4n26ce3f2ff0986e4a@mail.gmail.com> Dmitry, Can I suggest you the following please? [Just my personal suggestion.] You are doing a good job by comparing the latest XSD of the registry with the official BioMoby API, as documented on the BioMoby pages. I suggest that you take the API as the primary source, and point out where the XSD differs. Eddie then can update the XSD (if he agrees that there is a difference). If you find, during your trip through the BioMoby API pages, that there is something ambiguous or missing in the pages, you can point it out, as well, and somebody (Wendy?) will correct the documentation. This way we can all benefit from your research in a more persistent way (meaning: the clarified things will be kept in the docs and XSD) than just by emails. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Mon Nov 5 17:08:19 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 5 Nov 2007 09:08:19 -0800 Subject: [MOBY-dev] Secondary Parameters question. In-Reply-To: <472F253A.6030004@bsc.es> References: <472F253A.6030004@bsc.es> Message-ID: <000401c81fce$7850bba0$2766a8c0@notebook> Hi Dmitry, The secondary parameters are one per request, i.e. for a single request, 10 and for multiple requests: 10 10 Secondary parameters are optional parameters and usually a service provider will choose defaults for them. If you want to specify parameters for both inputs (mobyData) blocks, then you will have to specify them twice. Does this clarify the situation? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Dmitry Repchevsky > Sent: Monday, November 05, 2007 6:14 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] Secondary Parameters question. > > Hello! > > I have another question about Secondary Parameters. > > using findService operation I can obtain the list of > Secondary Parameters, for example; > ***************************************************************** > > > Integer > > > > > > > > ***************************************************************** > The problem I have is that they are specified outside the > tag, right? > So there could be only one list of parameters per request, right? > So in case of having two tags (two mobyData) in which > one I should to put those parameters? > Imagine the situation where I have two Simple inputs (with > two corresponding mobyData) and one list of parameters. > In the service description there could be only one (?) list > of parameters, but in moby message there could be as many, as > mobyData. > > Could anyone illuminate me, please? > > Sincerely, > > Dmitry > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Mon Nov 5 17:09:52 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 5 Nov 2007 09:09:52 -0800 Subject: [MOBY-dev] Secondary Parameters "min" "max" datatype In-Reply-To: <472F011B.4000707@bsc.es> References: <472F011B.4000707@bsc.es> Message-ID: <000501c81fce$aefbf110$2766a8c0@notebook> Hi Dmitry, The type is a 'string' of text, but in reality its a float, integer, DateTime, etc. I should fix that later. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Dmitry Repchevsky > Sent: Monday, November 05, 2007 3:40 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] Secondary Parameters "min" "max" datatype > > Hello! > > I'm little confused about min, max values in Secondary Parameters... > > according the schema: > type="xs:string" /> is it the String? > > Cheers, > > Dmitry > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From dmitry.repchevski at bsc.es Mon Nov 5 17:50:47 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Mon, 05 Nov 2007 18:50:47 +0100 Subject: [MOBY-dev] Secondary Parameters question. References: 472F253A.6030004@bsc.es Message-ID: <472F57F7.2070204@bsc.es> Hello Edward, Yeah got it. I just didn't get that the mobyData is the same format... I mean that they are actually 2 requests to the same service... I mistakenly thought that I could specify the service with two mobyData inputs. Thank you very much, Dmitry From Pieter.Neerincx at wur.nl Fri Nov 9 16:50:09 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 9 Nov 2007 17:50:09 +0100 Subject: [MOBY-dev] [Taverna-users] Add BioMOBY Parser functionality in taverna (1.6.2) In-Reply-To: <43abb4040711050251j440001cdj25de307728fd4f44@mail.gmail.com> References: <472B7A68.70804@imim.es> <004d01c81d8f$5a27b660$6400a8c0@notebook> <43abb4040711050251j440001cdj25de307728fd4f44@mail.gmail.com> Message-ID: Hi Eddie, I'm not sure if this is related, but recently I'm having problems with the BioMOBY Parsers as well. For example try to decompose the base64_encoded_svgz object to get to the SVGZ out... doesn't work. It gives me an "empty list". Simple Objects without childs (primitives) work fine, but decomposition of more complex objects either doesn't work or sometimes I can not even add the parser. If the latter happens it takes a long time and my local test Central is hammered with queries, but if I leave it overnight there is no parser the next morning. I do get java errors on the commandline though. See below for the details. For an example try to decompose the collection "GI_Clusters" produced by the service GeneIlluminator_Disambiguate. For an example workflow for this service (without decomposition so far) have a look at https://www.bioinformatics.nl/phenolink/home/ -> Gene Illuminator services -> GeneIlluminator_Disambiguate. Could you please look into this? Cheers, Pi ---------------------------------------------- exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError at java.lang.ClassLoader.findBootstrapClass(Native Method) at java.lang.ClassLoader.findBootstrapClass0 (ClassLoader.java:891) at java.lang.ClassLoader.loadClass(ClassLoader.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java: 268) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.loadClass( LocalArtifactClassLoader.java:224) at net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.findClass( LocalArtifactClassLoader.java:184) at net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.findClass( LocalArtifactClassLoader.java:154) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java: 319) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) at java.lang.Class.getDeclaredMethod(Class.java:1907) at org.apache.commons.discovery.tools.ClassUtils.findPublicStaticMethod (ClassUtils.java:116) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor y(EngineConfigurationFactoryFinder.java:178) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.access $200(EngineConfigurationFactoryFinder.java:46) at org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run (EngineConfigurationFactoryFinder.java:128) at java.security.AccessController.doPrivileged(Native Method) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor y(EngineConfigurationFactoryFinder.java:113) at org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor y(EngineConfigurationFactoryFinder.java:160) at org.apache.axis.client.Service.getEngineConfiguration (Service.java:813) at org.apache.axis.client.Service.getAxisClient(Service.java: 104) at org.apache.axis.client.Service.(Service.java:113) at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:192) at org.biomoby.client.CentralImpl.getDataTypeAsXML (CentralImpl.java:1045) at org.biomoby.client.CentralImpl.getDataType (CentralImpl.java:1038) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil dType(MobyParseDatatypeProcessor.java:271) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.processData type(MobyParseDatatypeProcessor.java:211) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil dType(MobyParseDatatypeProcessor.java:283) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.processData type(MobyParseDatatypeProcessor.java:211) at org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil dType(MobyParseDatatypeProcessor.java:283) ... last two messages repeated many times ... ---------------------------------------------- On 5-nov-2007, at 11:51, Stian Soiland wrote: > Eddie, who's one of the BioMoby developers, will have a look at > this bug. > > On 11/2/07, Edward Kawas wrote: >> Hi Arnaud, >> >> That must be a bug. I will try to track it down and fix it. >> >> Thanks for the thorough report! >> >> Eddie >> >>> -----Original Message----- >>> From: moby-dev-bounces at lists.open-bio.org >>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of >>> Arnaud Kerhornou >>> Sent: Friday, November 02, 2007 12:29 PM >>> To: taverna-users mailing list; Core developer announcements >>> Subject: [MOBY-dev] Add BioMOBY Parser functionality in >>> taverna (1.6.2) >>> >>> Hi everyone, >>> >>> I can not get a BioMOBY Parser for a Moby service called >>> fromGenericSequenceCollectionToFASTA. >>> I have no problem getting a parser with >>> fromGenericSequenceToFASTA, which is very similar, the only >>> difference is that it takes a GenericSequence object, instead >>> of a collection of GenericSequence objects. >>> >>> I have attached a workflow and an input document, >>> >>> Any idea why I can't get a parser for >>> fromGenericSequenceCollectionToFASTA service ? >>> >>> Thanks >>> Arnaud >>> >>> >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > > -- > Stian Soiland, myGrid team > School of Computer Science > The University of Manchester > http://www.cs.man.ac.uk/~ssoiland/ > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Taverna-users mailing list > Taverna-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/taverna-users > Documentation: http://www.mygrid.org.uk/usermanual1.6/ > FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq > Biological Services: http://www.mygrid.org.uk/wiki/Mygrid/ > BiologicalWebServices > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From ivanp at mmb.pcb.ub.es Fri Nov 9 16:42:29 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Fri, 09 Nov 2007 17:42:29 +0100 Subject: [MOBY-dev] Changes in method MobyService.toXML() broke my services Message-ID: <47348DF5.5030201@mmb.pcb.ub.es> Hi, I've realized that all my jMoby-MoSeS services were producing server (Tomcat) errors and answering non-moby messages in the case when a MobyException had to be launched. Looking into the server logs, I find this line: ... java.lang.NoSuchMethodError: org.biomoby.shared.parser.ServiceException.toXML()Ljava/lang/String; ... I decided to have a look to the CVS in this class of Moby and I've seen that the class (and this method) has been modified in the last revisions... Perhaps I'm doing something bad, but I think it is a big coincidence that just these parts of the code are modified. Should I regenerate skeletons? I guess this is not the right approach... Thanks, -- ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ From martin.senger at gmail.com Fri Nov 9 17:28:38 2007 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 9 Nov 2007 17:28:38 +0000 Subject: [MOBY-dev] Changes in method MobyService.toXML() broke my services In-Reply-To: <47348DF5.5030201@mmb.pcb.ub.es> References: <47348DF5.5030201@mmb.pcb.ub.es> Message-ID: <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> > I decided to have a look to the CVS in this class of Moby and I've seen > that the class (and this method) has been modified in the last > revisions... Please look in the older moby-dev messages - the issue was discussed there a while ago. The problem was that Paul changed the method without changing all its uses. After a brief discussion (I mean I was shouting in anger) he fixed it promptly. Do you think that your today observation means that the same/similar situation happened again? No, I do not see any recent change in the CVS. The last was four months ago, and Paul put there exactly the comment I was referring to above: " Changed exception printing to toXMLString() so as not to collide with Martin's toXML(), which returns a DOM object Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Fri Nov 9 17:57:19 2007 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 9 Nov 2007 09:57:19 -0800 Subject: [MOBY-dev] [Taverna-users] Add BioMOBY Parser functionality in taverna (1.6.2) In-Reply-To: References: <472B7A68.70804@imim.es> <004d01c81d8f$5a27b660$6400a8c0@notebook> <43abb4040711050251j440001cdj25de307728fd4f44@mail.gmail.com> Message-ID: Hi Pieter, I will look into it and hopefully fix it shortly. Not sure why its failing ... I bet the base case for the parser is incorrect and thats why you get the stack overflow. Eddie On Nov 9, 2007 8:50 AM, Pieter Neerincx wrote: > Hi Eddie, > > I'm not sure if this is related, but recently I'm having problems > with the BioMOBY Parsers as well. For example try to decompose the > base64_encoded_svgz object to get to the SVGZ out... doesn't work. It > gives me an "empty list". > > Simple Objects without childs (primitives) work fine, but > decomposition of more complex objects either doesn't work or > sometimes I can not even add the parser. If the latter happens it > takes a long time and my local test Central is hammered with queries, > but if I leave it overnight there is no parser the next morning. I do > get java errors on the commandline though. See below for the details. > For an example try to decompose the collection "GI_Clusters" produced > by the service GeneIlluminator_Disambiguate. For an example workflow > for this service (without decomposition so far) have a look at > https://www.bioinformatics.nl/phenolink/home/ -> Gene Illuminator > services -> GeneIlluminator_Disambiguate. > > Could you please look into this? > > Cheers, > > Pi > > ---------------------------------------------- > > exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError > at java.lang.ClassLoader.findBootstrapClass(Native Method) > at java.lang.ClassLoader.findBootstrapClass0 > (ClassLoader.java:891) > at java.lang.ClassLoader.loadClass(ClassLoader.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java: > 268) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.loadClass( > LocalArtifactClassLoader.java:224) > at > net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.findClass( > LocalArtifactClassLoader.java:184) > at > net.sf.taverna.raven.repository.impl.LocalArtifactClassLoader.findClass( > LocalArtifactClassLoader.java:154) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java: > 319) > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) > at java.lang.Class.getDeclaredMethod(Class.java:1907) > at > org.apache.commons.discovery.tools.ClassUtils.findPublicStaticMethod > (ClassUtils.java:116) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor > y(EngineConfigurationFactoryFinder.java:178) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder.access > $200(EngineConfigurationFactoryFinder.java:46) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run > (EngineConfigurationFactoryFinder.java:128) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor > y(EngineConfigurationFactoryFinder.java:113) > at > org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor > y(EngineConfigurationFactoryFinder.java:160) > at org.apache.axis.client.Service.getEngineConfiguration > (Service.java:813) > at org.apache.axis.client.Service.getAxisClient(Service.java: > 104) > at org.apache.axis.client.Service.(Service.java:113) > at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:192) > at org.biomoby.client.CentralImpl.getDataTypeAsXML > (CentralImpl.java:1045) > at org.biomoby.client.CentralImpl.getDataType > (CentralImpl.java:1038) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil > dType(MobyParseDatatypeProcessor.java:271) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.processData > type(MobyParseDatatypeProcessor.java:211) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil > dType(MobyParseDatatypeProcessor.java:283) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.processData > type(MobyParseDatatypeProcessor.java:211) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeProcessor.flattenChil > dType(MobyParseDatatypeProcessor.java:283) > ... last two messages repeated many times ... > > ---------------------------------------------- > > > > On 5-nov-2007, at 11:51, Stian Soiland wrote: > > > Eddie, who's one of the BioMoby developers, will have a look at > > this bug. > > > > > On 11/2/07, Edward Kawas wrote: > >> Hi Arnaud, > >> > >> That must be a bug. I will try to track it down and fix it. > >> > >> Thanks for the thorough report! > >> > >> Eddie > >> > >>> -----Original Message----- > >>> From: moby-dev-bounces at lists.open-bio.org > >>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > >>> Arnaud Kerhornou > >>> Sent: Friday, November 02, 2007 12:29 PM > >>> To: taverna-users mailing list; Core developer announcements > >>> Subject: [MOBY-dev] Add BioMOBY Parser functionality in > >>> taverna (1.6.2) > >>> > >>> Hi everyone, > >>> > >>> I can not get a BioMOBY Parser for a Moby service called > >>> fromGenericSequenceCollectionToFASTA. > >>> I have no problem getting a parser with > >>> fromGenericSequenceToFASTA, which is very similar, the only > >>> difference is that it takes a GenericSequence object, instead > >>> of a collection of GenericSequence objects. > >>> > >>> I have attached a workflow and an input document, > >>> > >>> Any idea why I can't get a parser for > >>> fromGenericSequenceCollectionToFASTA service ? > >>> > >>> Thanks > >>> Arnaud > >>> > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at lists.open-bio.org > >> http://lists.open-bio.org/mailman/listinfo/moby-dev > >> > > > > > > -- > > Stian Soiland, myGrid team > > School of Computer Science > > The University of Manchester > > http://www.cs.man.ac.uk/~ssoiland/ > > > > ---------------------------------------------------------------------- > > --- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a > > browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Taverna-users mailing list > > Taverna-users at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/taverna-users > > Documentation: http://www.mygrid.org.uk/usermanual1.6/ > > FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq > > Biological Services: http://www.mygrid.org.uk/wiki/Mygrid/ > > BiologicalWebServices > > > > ------------------------------------------------------------- > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > > phone: 0317-483 039 > fax: 0317-483 584 > mobile: 06-143 66 783 > mail: pieter.neerincx at wur.nl > skype: pieter.online > ------------------------------------------------------------ > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From markw at illuminae.com Fri Nov 9 21:30:27 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 09 Nov 2007 13:30:27 -0800 Subject: [MOBY-dev] Manuscript submitted to BiB Message-ID: Hi all, Just letting you know that I have re-formatted the manuscript appropriately and submitted it to Briefings in Bioinformatics. It would actually be nice "bookends" for the project if it were to be published there, since they published the "vapourware" paper back in 2002 :-) Best wishes all! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From ivanp at mmb.pcb.ub.es Fri Nov 9 21:37:06 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Fri, 09 Nov 2007 22:37:06 +0100 Subject: [MOBY-dev] Changes in method MobyService.toXML() broke myservices In-Reply-To: <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> References: <47348DF5.5030201@mmb.pcb.ub.es> <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> Message-ID: <4734D302.4060704@mmb.pcb.ub.es> Hi Martin, You're right. I remember this now. I've discovered this problem in the recent days but perhaps the problem is that I have some inconsistences with the deployed libraries (although I've checked it, it seems quite likely that I forgot something). I cannot do it now, but I'll check it asap. I'm quite sure that I've deployed latest version of jmoby.jar in the server (perhaps should I recreate datatypes.jar also?). Well, I'm sorry if it is my fault (it seems the more likely) I'll keep you all informed. Cheers, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> I decided to have a look to the CVS in this class of Moby and I've seen >> that the class (and this method) has been modified in the last >> revisions... >> > > > Please look in the older moby-dev messages - the issue was discussed there a > while ago. The problem was that Paul changed the method without changing all > its uses. After a brief discussion (I mean I was shouting in anger) he fixed > it promptly. Do you think that your today observation means that the > same/similar situation happened again? > > No, I do not see any recent change in the CVS. The last was four months ago, > and Paul put there exactly the comment I was referring to above: " > > Changed exception printing to toXMLString() so as not to collide with > Martin's toXML(), which returns a DOM object > > > Cheers, > Martin > > From ivanp at mmb.pcb.ub.es Mon Nov 12 14:16:27 2007 From: ivanp at mmb.pcb.ub.es (=?ISO-8859-1?Q?Iv=E1n_P=E1rraga_Garc=EDa?=) Date: Mon, 12 Nov 2007 15:16:27 +0100 Subject: [MOBY-dev] Changes in method MobyService.toXML() broke myservices In-Reply-To: <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> References: <47348DF5.5030201@mmb.pcb.ub.es> <4d93f07c0711090928r4354dc96y220fe39036d78de5@mail.gmail.com> Message-ID: <4738603B.8010009@mmb.pcb.ub.es> Hi, I don't know exactly how, but my JBoss server had a cached version of jMoby and even removing it and deploying it again it kept going using the old version... I modified my local version of jMoby code to introduce some logging and then it magically worked :-S The funny thing is that then I decided to compile the CVS version again and it worked also... I don't know exactly what has happened but well, it's ok now. I'm sorry, as I suspected the problem was "mine". Thanks, ------------------------------------------------ Iv?n P?rraga Garc?a Computer Scientist Molecular Modelling & Bioinformatics Unit INB - Instituto Nacional de Bioinform?tica Josep Samitier 1-5 08028 Barcelona Spain tel.: +34 93 403 71 55 fax.: +34 93 403 71 57 e-mail: ivanp at mmb.pcb.ub.es group page: http://mmb.pcb.ub.es pgp key: http://mmb.pcb.ub.es/~ivanp/pubkey.asc ------------------------------------------------ Martin Senger escribi?: >> I decided to have a look to the CVS in this class of Moby and I've seen >> that the class (and this method) has been modified in the last >> revisions... >> > > > Please look in the older moby-dev messages - the issue was discussed there a > while ago. The problem was that Paul changed the method without changing all > its uses. After a brief discussion (I mean I was shouting in anger) he fixed > it promptly. Do you think that your today observation means that the > same/similar situation happened again? > > No, I do not see any recent change in the CVS. The last was four months ago, > and Paul put there exactly the comment I was referring to above: " > > Changed exception printing to toXMLString() so as not to collide with > Martin's toXML(), which returns a DOM object > > > Cheers, > Martin > > From groscurt at mpiz-koeln.mpg.de Tue Nov 13 10:52:00 2007 From: groscurt at mpiz-koeln.mpg.de (groscurt at mpiz-koeln.mpg.de) Date: Tue, 13 Nov 2007 11:52:00 +0100 (CET) Subject: [MOBY-dev] MobyServices and Taverna workflow problems In-Reply-To: <472F253A.6030004@bsc.es> References: <472F253A.6030004@bsc.es> Message-ID: <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> Hi all, we have a problem concerning BioMoby webservices in taverna and we hope one can help us out. We have two Webservices which e.g. one returns an object with the articlename 'sequence', the other has this object as input with the articlename 'seq' (as simple example). Now we tried to connect this services into a workflow and taverna returned a NullPointerException apparently in the skeleton class of the second service, because it looks for 'seq' in the xml, but we only have 'sequence'. I'm not quite sure if this is the problem, but how is it possible to connect arbitrary services without taking care of the articlename ? What do we have to take into account when using a Biomoby webservice for taverna ? the solution of having always the same articlename is working, but i guess this is not intended... thanks in advance andreas From edward.kawas at gmail.com Tue Nov 13 14:30:40 2007 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue, 13 Nov 2007 06:30:40 -0800 Subject: [MOBY-dev] MobyServices and Taverna workflow problems In-Reply-To: <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> References: <472F253A.6030004@bsc.es> <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: Hi Andreas, Can you send me an example workflow? Thanks, Eddie On Nov 13, 2007 2:52 AM, wrote: > Hi all, > > we have a problem concerning BioMoby webservices in taverna and we hope > one can help us out. > > We have two Webservices which e.g. one returns an object with the > articlename 'sequence', the other has this object as input with the > articlename 'seq' (as simple example). > > Now we tried to connect this services into a workflow and taverna returned > a NullPointerException apparently in the skeleton class of the second > service, because it looks for 'seq' in the xml, but we only have > 'sequence'. > > I'm not quite sure if this is the problem, but how is it possible to > connect arbitrary services without taking care of the articlename ? > > What do we have to take into account when using a Biomoby webservice for > taverna ? > > the solution of having always the same articlename is working, but i guess > this is not intended... > > thanks in advance > andreas > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From edward.kawas at gmail.com Tue Nov 13 16:19:44 2007 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue, 13 Nov 2007 08:19:44 -0800 Subject: [MOBY-dev] MobyServices and Taverna workflow problems In-Reply-To: References: <472F253A.6030004@bsc.es> <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: Hi Andreas, >From the first reading, I thought that you had a workflow that didnt work... From reading it again, it sounds like you are asking whether or not you have to worry about the article names in Taverna. Article names are automatically discovered and the correct one is used in Taverna. If you have a case where this might not be the case, then please let me know. The only things that a user of Taverna needs to take into account when using moby is to make sure that they supply the correct namespace and data for any particular service. Articlenames are taken care of, even though if you look in the intermediate input/output browser and the articlename is not what it's supposed to be. Does this answer your question? Thanks, Eddie On Nov 13, 2007 6:30 AM, Eddie Kawas wrote: > Hi Andreas, > > Can you send me an example workflow? > > Thanks, > > Eddie > > > On Nov 13, 2007 2:52 AM, wrote: > > Hi all, > > > > we have a problem concerning BioMoby webservices in taverna and we hope > > one can help us out. > > > > We have two Webservices which e.g. one returns an object with the > > articlename 'sequence', the other has this object as input with the > > articlename 'seq' (as simple example). > > > > Now we tried to connect this services into a workflow and taverna returned > > a NullPointerException apparently in the skeleton class of the second > > service, because it looks for 'seq' in the xml, but we only have > > 'sequence'. > > > > I'm not quite sure if this is the problem, but how is it possible to > > connect arbitrary services without taking care of the articlename ? > > > > What do we have to take into account when using a Biomoby webservice for > > taverna ? > > > > the solution of having always the same articlename is working, but i guess > > this is not intended... > > > > thanks in advance > > andreas > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From markw at illuminae.com Tue Nov 13 21:51:23 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Nov 2007 13:51:23 -0800 Subject: [MOBY-dev] Invitation to submit Message-ID: Hi all, In the wake of the PLoS ONE Gong Show[1], this weekend I was invited to submit the Moby 1.0 paper to Briefings in Bioinformatics. Hopefully it will find its target audience there :-) I submitted it this morning. Best wishes all! Mark [1] http://en.wikipedia.org/wiki/Gong_show -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Tue Nov 13 22:45:50 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Nov 2007 14:45:50 -0800 Subject: [MOBY-dev] INB services with questionable registrations... Message-ID: Hi INB folks! Looks like some of your services have been registered as consuming "anything and everything" again :-) Go to Gbrowse_moby (http://mobycentral.icapture.ubc.ca), select namespace DragonDB_Allele and use "cho" as the ID. 6 of your services claim to consume DragonDB Alleles... and I suspect that isn't the case, right? Cheers! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Thu Nov 15 02:09:50 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 14 Nov 2007 18:09:50 -0800 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? Message-ID: Hell, why not?! :-) I had an hour free this afternoon, and this is what I did with it: It takes about 15 minutes to auto-generate them from the registry so I could put th escript on a cron... This is purely first-pass, just-trying-an-idea stuff, so it isn't "pretty", but... very very cool :-) Cheers all! Mark From markw at illuminae.com Wed Nov 14 02:29:01 2007 From: markw at illuminae.com (mark wilkinson) Date: Wed, 14 Nov 2007 02:29:01 +0000 GMT Subject: [MOBY-dev] Just realized... Message-ID: <1533480739-1195007449-cardhu_blackberry.rim.net-19272-@engine02-cell01> ...It would be much more appropriate to group the services by the namespace they operate under so that all services that work on a particular type of ID could be added to iGoogle as a unit! That's tomorrow's homework. It's suppertime now :-) M -- Mark Wilkinson ...on the road! From groscurt at mpiz-koeln.mpg.de Wed Nov 14 08:28:25 2007 From: groscurt at mpiz-koeln.mpg.de (groscurt at mpiz-koeln.mpg.de) Date: Wed, 14 Nov 2007 09:28:25 +0100 (CET) Subject: [MOBY-dev] MobyServices and Taverna workflow problems In-Reply-To: References: <472F253A.6030004@bsc.es> <38281.195.37.46.22.1194951120.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: <45402.195.37.46.22.1195028905.squirrel@mpizmail.mpiz-koeln.mpg.de> Hi Eddie, thanks for your answer. Unfortunately we cant send you currently an example because we *fixed* our problem... but we try to recreate the error and then send you a copy. I think your answer covers my problem, but then the questions is why does the error occurred. The problem is that one service returns an object with a specific articlename and the next service consumes the same object type with a different articlename. Like "I give you an AminoAcidSequence which is named sequence" - the other response "I want an AminoAcidSequence which is named seq." The second webservice then looks in the XML for something called seq and does not find that because we have sequence -> nullpointerexception thrown by the second webservice. When I understand you correctly this should be handled by taverna - so either there is a bug, or the problem is a total different one. We try to recreate the situation and send you the workflow. thanks andreas PS: we *fixed* this by naming all in- and outputs the same and then it worked..... > Hi Andreas, > >>From the first reading, I thought that you had a workflow that didnt > work... From reading it again, it sounds like you are asking whether > or not you have to worry about the article names in Taverna. Article > names are automatically discovered and the correct one is used in > Taverna. If you have a case where this might not be the case, then > please let me know. > > The only things that a user of Taverna needs to take into account when > using moby is to make sure that they supply the correct namespace and > data for any particular service. Articlenames are taken care of, even > though if you look in the intermediate input/output browser and the > articlename is not what it's supposed to be. > > Does this answer your question? > > Thanks, > > Eddie > > On Nov 13, 2007 6:30 AM, Eddie Kawas wrote: >> Hi Andreas, >> >> Can you send me an example workflow? >> >> Thanks, >> >> Eddie >> >> >> On Nov 13, 2007 2:52 AM, wrote: >> > Hi all, >> > >> > we have a problem concerning BioMoby webservices in taverna and we >> hope >> > one can help us out. >> > >> > We have two Webservices which e.g. one returns an object with the >> > articlename 'sequence', the other has this object as input with the >> > articlename 'seq' (as simple example). >> > >> > Now we tried to connect this services into a workflow and taverna >> returned >> > a NullPointerException apparently in the skeleton class of the second >> > service, because it looks for 'seq' in the xml, but we only have >> > 'sequence'. >> > >> > I'm not quite sure if this is the problem, but how is it possible to >> > connect arbitrary services without taking care of the articlename ? >> > >> > What do we have to take into account when using a Biomoby webservice >> for >> > taverna ? >> > >> > the solution of having always the same articlename is working, but i >> guess >> > this is not intended... >> > >> > thanks in advance >> > andreas >> > >> > _______________________________________________ >> > MOBY-dev mailing list >> > MOBY-dev at lists.open-bio.org >> > http://lists.open-bio.org/mailman/listinfo/moby-dev >> > >> > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From Pieter.Neerincx at wur.nl Wed Nov 14 13:57:14 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 14 Nov 2007 14:57:14 +0100 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? In-Reply-To: References: Message-ID: Hi Mark, Like the idea! Several colleagues showed me their personalised Google pages, but I never bothered to signup for an account, because I didn't see any content worth the effort. That changed today :). Just give it try and I'm getting "404 - Service returned no response. This indicates that this service is currently unavailable. Try again later." for several gadgets... Work in progress I guess :). Will try again later. Cheers, Pi On 15-nov-2007, at 3:09, Mark Wilkinson wrote: > Hell, why not?! :-) > > I had an hour free this afternoon, and this is what I did with it: > > > > It takes about 15 minutes to auto-generate them from the registry so I > could put th escript on a cron... This is purely first-pass, > just-trying-an-idea stuff, so it isn't "pretty", but... very very > cool :-) > > Cheers all! > > Mark > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From markw at illuminae.com Thu Nov 15 14:38:39 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 15 Nov 2007 06:38:39 -0800 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? In-Reply-To: References: Message-ID: Services may well be down... I am not currently filtering for "alive" services... M On Wed, 14 Nov 2007 05:57:14 -0800, Pieter Neerincx wrote: > Hi Mark, > > Like the idea! Several colleagues showed me their personalised Google > pages, but I never bothered to signup for an account, because I > didn't see any content worth the effort. That changed today :). > > Just give it try and I'm getting "404 - Service returned no response. > This indicates that this service is currently unavailable. Try again > later." for several gadgets... Work in progress I guess :). Will try > again later. > > Cheers, > > Pi > > On 15-nov-2007, at 3:09, Mark Wilkinson wrote: > >> Hell, why not?! :-) >> >> I had an hour free this afternoon, and this is what I did with it: >> >> >> >> It takes about 15 minutes to auto-generate them from the registry so I >> could put th escript on a cron... This is purely first-pass, >> just-trying-an-idea stuff, so it isn't "pretty", but... very very >> cool :-) >> >> Cheers all! >> >> Mark >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > ------------------------------------------------------------- > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > > phone: 0317-483 039 > fax: 0317-483 584 > mobile: 06-143 66 783 > mail: pieter.neerincx at wur.nl > skype: pieter.online > ------------------------------------------------------------ > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Wed Nov 14 16:14:56 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 14 Nov 2007 17:14:56 +0100 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? In-Reply-To: References: Message-ID: <7C6BBD26-D489-440A-9194-5538B269574C@wur.nl> On 15-nov-2007, at 15:38, Mark Wilkinson wrote: > Services may well be down... I am not currently filtering for "alive" > services... Fair enough :), but I tried one of my own services for which I know 100% it's up and I tried the getGoTerm service from bioinfo.icapture.ubc.ca. That latter one is one of yours right? Also gave my a 404 error with several GO terms with and without the GO: prefix in front of the GO ID... Weird, but I tried again and my own service works now. Didn't change anything and checked the server logs: it's been up all the time. getGoTerm still fails on me though. Cheers, Pi > > M > > > > On Wed, 14 Nov 2007 05:57:14 -0800, Pieter Neerincx > wrote: > >> Hi Mark, >> >> Like the idea! Several colleagues showed me their personalised Google >> pages, but I never bothered to signup for an account, because I >> didn't see any content worth the effort. That changed today :). >> >> Just give it try and I'm getting "404 - Service returned no response. >> This indicates that this service is currently unavailable. Try again >> later." for several gadgets... Work in progress I guess :). Will try >> again later. >> >> Cheers, >> >> Pi >> >> On 15-nov-2007, at 3:09, Mark Wilkinson wrote: >> >>> Hell, why not?! :-) >>> >>> I had an hour free this afternoon, and this is what I did with it: >>> >>> >>> >>> It takes about 15 minutes to auto-generate them from the registry >>> so I >>> could put th escript on a cron... This is purely first-pass, >>> just-trying-an-idea stuff, so it isn't "pretty", but... very very >>> cool :-) >>> >>> Cheers all! >>> >>> Mark >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> >> ------------------------------------------------------------- >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> >> phone: 0317-483 039 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> mail: pieter.neerincx at wur.nl >> skype: pieter.online >> ------------------------------------------------------------ >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From dgonzalez at cnio.es Wed Nov 14 16:15:45 2007 From: dgonzalez at cnio.es (David G. Pisano) Date: Wed, 14 Nov 2007 17:15:45 +0100 Subject: [MOBY-dev] INB services with questionable registrations... In-Reply-To: References: Message-ID: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> Umm, I see just one INB service there... getCodonTableFromEmboss provided by: www.cnb.uam.es Natalia will take a look into it Can you tell us the rest of the "questionable" services? On 13 Nov 2007, at 23:45, Mark Wilkinson wrote: > Hi INB folks! > > Looks like some of your services have been registered as consuming > "anything and everything" again :-) > > Go to Gbrowse_moby (http://mobycentral.icapture.ubc.ca), select > namespace > DragonDB_Allele and use "cho" as the ID. 6 of your services claim to > consume DragonDB Alleles... and I suspect that isn't the case, right? > > Cheers! > > Mark > > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > Tel: 604 682 2344 x62129 > Fax: 604 806 9274 > > ***CONFIDENTIALITY NOTICE*** > This electronic message is intended only for the use of the > addressee and > may contain information that is privileged and confidential. Any > dissemination, distribution or copying of this communication by > unauthorized individuals is strictly prohibited. If you have > received this > communication in error, please notify the sender immediately by reply > e-mail and delete the original and all copies from your system. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev --- David G. Pisano Bioinformatics Unit Structural Biology and Biocomputing Programme Spanish National Cancer Research Centre (CNIO) Melchor Fdez. Almagro, 3 E-28029 Madrid, Spain +34 91 7328000 (ext. 2161) Skype: dgpisano dgpisano at cnio.es **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From markw at illuminae.com Wed Nov 14 16:41:15 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 14 Nov 2007 08:41:15 -0800 Subject: [MOBY-dev] INB services with questionable registrations... In-Reply-To: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> References: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> Message-ID: Hi David, Yes, there is only one there now. How strange?!? Yesterday there were six! Maybe I am going crazy ;-) Anyway, best wishes! Mark On Wed, 14 Nov 2007 08:15:45 -0800, David G. Pisano wrote: > Umm, I see just one INB service there... getCodonTableFromEmboss > provided by: www.cnb.uam.es > Natalia will take a look into it > > Can you tell us the rest of the "questionable" services? > > On 13 Nov 2007, at 23:45, Mark Wilkinson wrote: > >> Hi INB folks! >> >> Looks like some of your services have been registered as consuming >> "anything and everything" again :-) >> >> Go to Gbrowse_moby (http://mobycentral.icapture.ubc.ca), select >> namespace >> DragonDB_Allele and use "cho" as the ID. 6 of your services claim to >> consume DragonDB Alleles... and I suspect that isn't the case, right? >> >> Cheers! >> >> Mark >> >> >> >> -- >> -- >> Mark Wilkinson >> Assistant Professor, Dept. Medical Genetics >> University of British Columbia >> PI Bioinformatics >> iCAPTURE Centre, St. Paul's Hospital >> Tel: 604 682 2344 x62129 >> Fax: 604 806 9274 >> >> ***CONFIDENTIALITY NOTICE*** >> This electronic message is intended only for the use of the >> addressee and >> may contain information that is privileged and confidential. Any >> dissemination, distribution or copying of this communication by >> unauthorized individuals is strictly prohibited. If you have >> received this >> communication in error, please notify the sender immediately by reply >> e-mail and delete the original and all copies from your system. >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > --- > David G. Pisano > Bioinformatics Unit > Structural Biology and Biocomputing Programme > Spanish National Cancer Research Centre (CNIO) > > Melchor Fdez. Almagro, 3 > E-28029 Madrid, Spain > +34 91 7328000 (ext. 2161) > Skype: dgpisano > dgpisano at cnio.es > > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea > el destinatario. Si usted recibe por error este correo, se ruega > comunicarlo al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments > may contain confidential and privileged information for the sole use of > the designated recipient named above. Distribution, reproduction or any > other use of this transmission by any party other than the intended > recipient is prohibited. If you are not the intended recipient please > contact the sender and delete all copies. > -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Wed Nov 14 16:44:14 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 14 Nov 2007 08:44:14 -0800 Subject: [MOBY-dev] iGoogle as a cusomizable Moby Mashup? In-Reply-To: <7C6BBD26-D489-440A-9194-5538B269574C@wur.nl> References: <7C6BBD26-D489-440A-9194-5538B269574C@wur.nl> Message-ID: All of my GO services are currently dead. they were coded to access a database at UBC that was taken offline when our university (in their esteemed brilliance) closed the UBC Bioinformatics Centre :-P I'm looking at other options now. Apparently there's an open GO database at EMBL, so I'm going to try to hit that one and see if it works for me. I'm not anxious to host and maintain the full GO database here locally, so if I can't find an open mysql interface somewhere else then I'll have to take those services offline. M On Wed, 14 Nov 2007 08:14:56 -0800, Pieter Neerincx wrote: > > On 15-nov-2007, at 15:38, Mark Wilkinson wrote: > >> Services may well be down... I am not currently filtering for "alive" >> services... > > Fair enough :), but I tried one of my own services for which I know > 100% it's up and I tried the getGoTerm service from > bioinfo.icapture.ubc.ca. That latter one is one of yours right? Also > gave my a 404 error with several GO terms with and without the GO: > prefix in front of the GO ID... > > Weird, but I tried again and my own service works now. Didn't change > anything and checked the server logs: it's been up all the time. > getGoTerm still fails on me though. > > Cheers, > > Pi > >> >> M >> >> >> >> On Wed, 14 Nov 2007 05:57:14 -0800, Pieter Neerincx >> wrote: >> >>> Hi Mark, >>> >>> Like the idea! Several colleagues showed me their personalised Google >>> pages, but I never bothered to signup for an account, because I >>> didn't see any content worth the effort. That changed today :). >>> >>> Just give it try and I'm getting "404 - Service returned no response. >>> This indicates that this service is currently unavailable. Try again >>> later." for several gadgets... Work in progress I guess :). Will try >>> again later. >>> >>> Cheers, >>> >>> Pi >>> >>> On 15-nov-2007, at 3:09, Mark Wilkinson wrote: >>> >>>> Hell, why not?! :-) >>>> >>>> I had an hour free this afternoon, and this is what I did with it: >>>> >>>> >>>> >>>> It takes about 15 minutes to auto-generate them from the registry >>>> so I >>>> could put th escript on a cron... This is purely first-pass, >>>> just-trying-an-idea stuff, so it isn't "pretty", but... very very >>>> cool :-) >>>> >>>> Cheers all! >>>> >>>> Mark >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>> >>> >>> ------------------------------------------------------------- >>> Wageningen University and Research centre (WUR) >>> Laboratory of Bioinformatics >>> Transitorium (building 312) room 1034 >>> >>> Dreijenlaan 3 >>> 6703 HA Wageningen >>> The Netherlands >>> >>> phone: 0317-483 039 >>> fax: 0317-483 584 >>> mobile: 06-143 66 783 >>> mail: pieter.neerincx at wur.nl >>> skype: pieter.online >>> ------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > ------------------------------------------------------------- > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > > phone: 0317-483 039 > fax: 0317-483 584 > mobile: 06-143 66 783 > mail: pieter.neerincx at wur.nl > skype: pieter.online > ------------------------------------------------------------ > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From rroyo at lsi.upc.edu Wed Nov 14 16:35:16 2007 From: rroyo at lsi.upc.edu (Romina Royo) Date: Wed, 14 Nov 2007 17:35:16 +0100 Subject: [MOBY-dev] INB services with questionable registrations... In-Reply-To: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> References: <0C2F076D-D2AF-4E9D-9540-1FBC21F4DFD0@cnio.es> Message-ID: <473B23C4.707@lsi.upc.edu> Hello, Sorry! There were some services from our node that have already been fixed. I'm sorry we didn't reply sooner to let you know about it Romina David G. Pisano wrote: > Umm, I see just one INB service there... getCodonTableFromEmboss > provided by: www.cnb.uam.es > Natalia will take a look into it > > Can you tell us the rest of the "questionable" services? > > On 13 Nov 2007, at 23:45, Mark Wilkinson wrote: > >> Hi INB folks! >> >> Looks like some of your services have been registered as consuming >> "anything and everything" again :-) >> >> Go to Gbrowse_moby (http://mobycentral.icapture.ubc.ca), select >> namespace >> DragonDB_Allele and use "cho" as the ID. 6 of your services claim to >> consume DragonDB Alleles... and I suspect that isn't the case, right? >> >> Cheers! >> >> Mark >> >> >> >> ---- >> Mark Wilkinson >> Assistant Professor, Dept. Medical Genetics >> University of British Columbia >> PI Bioinformatics >> iCAPTURE Centre, St. Paul's Hospital >> Tel: 604 682 2344 x62129 >> Fax: 604 806 9274 >> >> ***CONFIDENTIALITY NOTICE*** >> This electronic message is intended only for the use of the addressee >> and >> may contain information that is privileged and confidential. Any >> dissemination, distribution or copying of this communication by >> unauthorized individuals is strictly prohibited. If you have received >> this >> communication in error, please notify the sender immediately by reply >> e-mail and delete the original and all copies from your system. >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > --- > David G. Pisano > Bioinformatics Unit > Structural Biology and Biocomputing Programme > Spanish National Cancer Research Centre (CNIO) > > Melchor Fdez. Almagro, 3 > E-28029 Madrid, Spain > +34 91 7328000 (ext. 2161) > Skype: dgpisano > dgpisano at cnio.es > > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n > o cualquier otro tipo de transmisi?n por parte de otra persona que no > sea el destinatario. Si usted recibe por error este correo, se ruega > comunicarlo al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any > attachments may contain confidential and privileged information for > the sole use of the designated recipient named above. Distribution, > reproduction or any other use of this transmission by any party other > than the intended recipient is prohibited. If you are not the intended > recipient please contact the sender and delete all copies. > > ------------------------------------------------------------------------ > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From igoldsmid at semanticdiscoverysystems.com Thu Nov 15 01:43:45 2007 From: igoldsmid at semanticdiscoverysystems.com (Ian Goldsmid) Date: Thu, 15 Nov 2007 14:43:45 +1300 Subject: [MOBY-dev] beginning to seriously tackle legacy data integration and querying issues in OWL/RDF (Semantic Web)? Message-ID: <005201c82728$f6d5a1f0$e480e5d0$@com> Hi This is a once only posting. I think some of you may find this useful: What is this about in one (rather long J ) sentence? Semantic Discovery Systems software that now enables non technical end users ??? through a familiar end-user-friendly Concept Map/Topic Map + Faceted Browser GUI representation of OWL Ontologies: to map, view, navigate and query; distributed, heterogeneous, corporate/legacy data sources and web services, with significantly automated mapping between data sources and OWL, and distributed query optimization to ensure optimal performance. -------- The first of its kind to go fully beyond a research prototype to truly Enterprise Scalable Deployment: Martin O???Connor, one of the Prot??g?? Staff at Stanford we collaborate with: [1]http://protege.stanford.edu/aboutus/aboutus.html, and, [2]http://bmir.stanford.edu/people/view.php/martin_j_oconnor -- recently said to us: ???but people are only beginning to seriously tackle legacy data integration and querying issues in OWL. The existing data querying/integration solutions that are out there are mostly research prototypes??????. We are one of the very few Semantic application software developers with a comprehensive product offering, with foundations that are fully mature and commercially proven too, that delivers optimized legacy data integration with W3C RDF/OWL/SPARQL. --------- A few additional summary points: There is extensive information at [3]www.SemanticDiscoverySystems.com, although [4]SDS_Quick_View.ppt is intended summarily elaborate on the following points: * The Semantic Discovery System generates mappings between Ontologies (created in W3C OWL) and distributed, heterogeneous data sources (oracle, any rdbms, any files (Excel for example), AND internal/external Web Services ??? (e.g. NCBI, Kegg, etc) ??? such that an end-user, a Pharmaceutical Researcher, Clinical Scientist, Fraud Investigator, Financial Analyst for example, can NOW: * View and navigate all the underlying distributed data -- all the objects or concepts ??? e.g. genes, proteins, compounds etc - AND their relationships -- in a familiar, user-friendly Concept Map/Network Diagram graphical user interface, and/or a faceted browser (see [5]SDS_Quick_View.ppt) * AND most importantly ??? the functionality to query that underlying distributed, heterogeneous data using that same user-friendly Concept Map GUI (W3C SPARQL is auto-generated to do that) ??? i.e. the Concept Map is also the Query Builder. The Semantic Discovery System has a built in distributed Query Optimizer (this optimization technology has a ten year track record) ??? this is effective for optimizing queries across distributed databases. The underlying data sources are Federated ??? i.e. queried in place ??? NOT pushed up to the client as they are in a few other existing systems of a similar kind, which causes an untenable bottleneck for anything but a small experimental prototype. The Semantic Discovery System is architecturally appropriate for Large Scale Enterprise deployments ??? AND we also supply a fully functional desktop version for individual users too. As an extended introduction ??? please navigate to [6]www.semanticdiscoverysystems.com ??? and start by reading the bullet points in the right hand panel with the heading - Why SDS? A key outcome from using SDS, is that end users can now map, view, navigate, work with, and query distributed, heterogeneous data without further programming intervention ??? using a graphical interface paradigm they are already familiar with, and find entirely natural to use. I hope that helps clarify one way or the other, whether this may, or will not be of some interest. If this is of interest to you, we offer an Early Access Program you may want to take a look at: [7]SDS_V7_EAP_Plan.ppt Thanks and looking forward to the possibility of hearing from you. Kind Regards, Ian Ian Goldsmid UK: +44 (208) 816 8379 US West Coast: +1 (415) 691 6097 US East Coast: +1 (617) 314 6330 Asia Pacific: +64 9 889 0269 Skype: igoldsmid: [8]cid:image001.png at 01C826A4.75B38350 JahJah FreePhone: [9]cid:image002.png at 01C826A4.75B38350 [10]igoldsmid at semanticdiscoverysystems.com [11]www.insilicodiscovery.com [12]www.semanticdiscoverysystems.com cid:image005.jpg at 01C826A9.B1B27410 0 [IMAGE]-Submit References 1. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.ebdofkjsn2c9mk.ReadNotify.com/tg/ebdofkjsn2c9mlhttp/protege.stanford.edu/aboutus/aboutus.html 2. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.ebdofkjsn2c9mk.ReadNotify.com/tg/ebdofkjsn2c9mlhttp/bmir.stanford.edu/people/view.php/martin_j_oconnor 3. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.SemanticDiscoverySystems.com 4. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.insilicodiscovery.com/v2/Emails/SDS_Quick_View.ppt 5. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.insilicodiscovery.com/v2/Emails/SDS_Quick_View.ppt 6. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.semanticdiscoverysystems.com 7. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.insilicodiscovery.com/v2/Emails/SDS_V7_EAP_Plan.ppt 8. skype:igoldsmid?call 9. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.jajah.com/IanGoldsmid 10. blocked::mailto:igoldsmid at insilicodiscovery.com 11. http://www.qsplk9d5bz8czk.ReadNotify.com/tg/qsplk9d5bz8czlhttp/www.insilicodiscovery.com 12. blocked::http://www.insilicodiscovery.com -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 4217 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 6381 bytes Desc: not available URL: From markw at illuminae.com Fri Nov 16 02:39:08 2007 From: markw at illuminae.com (mark wilkinson) Date: Fri, 16 Nov 2007 02:39:08 +0000 GMT Subject: [MOBY-dev] BiB submission Message-ID: <698615207-1195180861-cardhu_blackberry.rim.net-27173-@engine18-cell01> So BiB has "gently" rejected the manuscript due to it's length, but have re-offered their invitation if we cut it down (significantly), and they are completely happy with us submitting large portions of the details as "Supplementary Information". I've cut-out 30% of the manuscript and created a supplementary appendix where I make the more detailed arguments. It's still slightly over-length, but the editor indicated some compassion and may allow the submission at it's current length. To be honest, I think the paper is more "punchy" now, and reads better than it did with the full discussion in the main text :-) as soon as I get the OK from the editor I'll up this modified copy to the CVS. More than anything I'm really excited to have it as an invited submission to such a high-impact journal after the painful process that we just went through with PLoS ONE (a low-impact journal)... Having said that, I worry that we're not necessarily reaching the full breadth of audience that we really want to reach. Is there anyone in the community who wants to take-up the task of writing a more biologically-oriented manuscript for e.g. Genome Biology? I'm really not in a position to do this myself since (oddly enough) I don't actually *use* Moby to solve any biological problems... But I know there are lot of you on the list who do!! Just an idea... M -- Mark Wilkinson ...on the road! From markw at illuminae.com Fri Nov 16 02:49:27 2007 From: markw at illuminae.com (mark wilkinson) Date: Fri, 16 Nov 2007 02:49:27 +0000 GMT Subject: [MOBY-dev] An update on moby Central Message-ID: <1937583103-1195181482-cardhu_blackberry.rim.net-30769-@engine20-cell01> As you know, we're trying to move Moby Central to a new (faster!!) server at the SUN Centre of Excellence in Calgary (headed by Christoph Sensen, Paul Gordon's PhD supervisor). The migration is turning out to be extremely troublesome, largely due to our dependence on the libxml2 libraries. This is unfortunate... It likely means that moby central will be difficult to install for many people... But I'm sure it will be worth the trouble, since it will be on a dedicated 64bit server with high connectivity, compared to the server it is on now which seems to have terrible connectivity problems for everyone except me ;-) Eddie s well along in making a CPAN release of Moby, and Wendy is well along in working on the multi-lingual problem (we're trying to be compatible with every mysql down to Mysql version 3) So there is progress on the milestones from the last developers meeting! I believe that Eddie has also completed a pure-perl implementation of all Moby Central code, so we won't have the urrent chaotic mixture of Tomcat and Apache dependencies. Progress! M -- Mark Wilkinson ...on the road! From Pieter.Neerincx at wur.nl Fri Nov 16 12:47:57 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 16 Nov 2007 13:47:57 +0100 Subject: [MOBY-dev] An update on moby Central In-Reply-To: <1937583103-1195181482-cardhu_blackberry.rim.net-30769-@engine20-cell01> References: <1937583103-1195181482-cardhu_blackberry.rim.net-30769-@engine20-cell01> Message-ID: Hi, On 16-nov-2007, at 3:49, mark wilkinson wrote: > As you know, we're trying to move Moby Central to a new (faster!!) > server at the SUN Centre of Excellence in Calgary (headed by > Christoph Sensen, Paul Gordon's PhD supervisor). The migration is > turning out to be extremely troublesome, largely due to our > dependence on the libxml2 libraries. This is unfortunate... It > likely means that moby central will be difficult to install for > many people... I do install test Centrals on a more or less regular basis :) and yes the procedure can be... challenging :). Especially since we try to keep the OS and other software separated. So we never install stuff in the "default" place. I have no experience with the latest pure Perl version of BioMOBY Central, but libxml2 should be fine as long as you have a relative recent version. Not sure if this helps, but from my own experience: * For older versions there is a list describing which version of XML::LibXML works with which version of libxml2. Apparently you can not randomly mix versions! Even minor differences in the version number can break things. * If libxml2 is not in the default path or you have an OS supplied older version in the default path and want to link some Perl stuff to a newer version in an alternative location, please make sure the xml2- config binary is pointing to the libxml2 version you want to use and xml2-config is in your PATH both for yourself and for the apache user. If you are having other problems just put them on the mailinglist; maybe one of us has seen them before... > But I'm sure it will be worth the trouble, since it will be on a > dedicated 64bit server with high connectivity, compared to the > server it is on now which seems to have terrible connectivity > problems for everyone except me ;-) > > Eddie s well along in making a CPAN release of Moby, and Wendy is > well along in working on the multi-lingual problem (we're trying to > be compatible with every mysql down to Mysql version 3) > > So there is progress on the milestones from the last developers > meeting! > > I believe that Eddie has also completed a pure-perl implementation > of all Moby Central code, so we won't have the urrent chaotic > mixture of Tomcat and Apache dependencies. I'd love to give that one a try, so if you are looking for a "guinea pig" let me know :)... Cheers, Pi > Progress! > > M > > > -- > Mark Wilkinson > ...on the road! > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From Pieter.Neerincx at wur.nl Wed Nov 21 16:40:17 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 21 Nov 2007 17:40:17 +0100 Subject: [MOBY-dev] Authorities In-Reply-To: <005201c82728$f6d5a1f0$e480e5d0$@com> References: <005201c82728$f6d5a1f0$e480e5d0$@com> Message-ID: <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> Hi, I compiled a page with some extra information about BioMOBY authorities, because I thought this was lacking. The page at ~moby- live/Docs/MOBY-S_API/Authorities.html reflects what I found using Google and after browsing the mailinglist archive. So in case their are things outdated, plain wrong or missing, please correct me... (It might take some time for this page to pop-up on the BioMOBY site, but it should get there eventually thanks to cron.) Cheers, Pi ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From groscurt at mpiz-koeln.mpg.de Thu Nov 22 11:54:13 2007 From: groscurt at mpiz-koeln.mpg.de (groscurt at mpiz-koeln.mpg.de) Date: Thu, 22 Nov 2007 12:54:13 +0100 (CET) Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> Message-ID: <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> Hiho, at the EU-Sol meeting in Rome we discussed the usability of Moby for the project. One main issue was if it is possible to secure the data send via WebServices and to ensure that only specific people are able to use specific webservices. This is because the EU-Sol is a closed consortium with industry partners and they, but also the "normal" biologists, demand to have a solution which guarantees such requirements. So what I was wondering if this issue already came up in Moby ? I'm currently getting started to understand the current principles of securing WebServices, but i was wondering if someone has somehow experiences with that ? So any comments and hints are welcome :-) Best andreas From gordonp at ucalgary.ca Thu Nov 22 13:43:56 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 22 Nov 2007 06:43:56 -0700 Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: <4745879C.9090805@ucalgary.ca> I think generally we agreed that this could and should be done at the HTTP transport level rather than within MOBY itself. That's one of the advantages of having a layered architecture :-) groscurt at mpiz-koeln.mpg.de wrote: > Hiho, > > at the EU-Sol meeting in Rome we discussed the usability of Moby for the > project. One main issue was if it is possible to secure the data send via > WebServices and to ensure that only specific people are able to use > specific webservices. This is because the EU-Sol is a closed consortium > with industry partners and they, but also the "normal" biologists, demand > to have a solution which guarantees such requirements. > > So what I was wondering if this issue already came up in Moby ? I'm > currently getting started to understand the current principles of securing > WebServices, but i was wondering if someone has somehow experiences with > that ? > > So any comments and hints are welcome :-) > > Best > andreas > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From Pieter.Neerincx at wur.nl Thu Nov 22 14:16:06 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 22 Nov 2007 15:16:06 +0100 Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> Message-ID: <61EAB8F5-4A8B-4F8A-B7C9-96390913428A@wur.nl> Hi Andreas, On 22-nov-2007, at 12:54, groscurt at mpiz-koeln.mpg.de wrote: > Hiho, > > at the EU-Sol meeting in Rome we discussed the usability of Moby > for the > project. One main issue was if it is possible to secure the data > send via > WebServices and to ensure that only specific people are able to use > specific webservices. This is because the EU-Sol is a closed > consortium > with industry partners and they, but also the "normal" biologists, > demand > to have a solution which guarantees such requirements. In one of our collaborations I'm in a similar situation with a combined public / private consortium. There are several ways to secure your services, that can already work with the current state of the BioMOBY art. The thing is that as far as I know there is not really a standard ... yet. So probably several people already have different mechanisms in place. I'm using HTTPS to secure the connection. Next I do authentication on the web service level: in addition to other data I'm sending a BioMOBY object called "User" around. This contains a user ID, a password and an e-mail address. If necessary I validate those against an LDAP server. Instead of doing authentication on the web service level, you could also do authentication on the level of the web server or on the level of the transport layer. The reason I'm not doing this is that it would require extra logic for a workflow builder or client to handle this and not all of them do. Putting the user credentials inside the BioMOBY payload of the SOAP message makes sure this way of handling authentication works with any BioMOBY client :). If anyone has a more elegant solution I'd love the hear about it! Cheers, Pi > So what I was wondering if this issue already came up in Moby ? I'm > currently getting started to understand the current principles of > securing > WebServices, but i was wondering if someone has somehow experiences > with > that ? > > So any comments and hints are welcome :-) > > Best > andreas > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From gordonp at ucalgary.ca Thu Nov 22 15:14:29 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 22 Nov 2007 08:14:29 -0700 Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <61EAB8F5-4A8B-4F8A-B7C9-96390913428A@wur.nl> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> <61EAB8F5-4A8B-4F8A-B7C9-96390913428A@wur.nl> Message-ID: <47459CD5.7010709@ucalgary.ca> Hi Pieter, While your approach definitely works, I am loathe to incorporate authentication within Moby itself, as I mentioned in my previous message. I think a more elegant solution would be for the community to suggest the use of enveloped XML signatures in the MOBY payload. In that way, the authentication is built right into the message (e.g. public-key based), rather than relying on a username/password database. This would also promote one authentication amongst all service providers. It would also be backward compatible, as parsers should ignore the signature tag, as it's not in the MOBY namespace. My $0.02, Paul Pieter Neerincx wrote: > Hi Andreas, > > On 22-nov-2007, at 12:54, groscurt at mpiz-koeln.mpg.de wrote: > > >> Hiho, >> >> at the EU-Sol meeting in Rome we discussed the usability of Moby >> for the >> project. One main issue was if it is possible to secure the data >> send via >> WebServices and to ensure that only specific people are able to use >> specific webservices. This is because the EU-Sol is a closed >> consortium >> with industry partners and they, but also the "normal" biologists, >> demand >> to have a solution which guarantees such requirements. >> > > In one of our collaborations I'm in a similar situation with a > combined public / private consortium. > There are several ways to secure your services, that can already work > with the current state of the BioMOBY art. The thing is that as far > as I know there is not really a standard ... yet. So probably several > people already have different mechanisms in place. > > I'm using HTTPS to secure the connection. Next I do authentication on > the web service level: in addition to other data I'm sending a > BioMOBY object called "User" around. This contains a user ID, a > password and an e-mail address. If necessary I validate those against > an LDAP server. Instead of doing authentication on the web service > level, you could also do authentication on the level of the web > server or on the level of the transport layer. The reason I'm not > doing this is that it would require extra logic for a workflow > builder or client to handle this and not all of them do. Putting the > user credentials inside the BioMOBY payload of the SOAP message makes > sure this way of handling authentication works with any BioMOBY > client :). > > If anyone has a more elegant solution I'd love the hear about it! > > Cheers, > > Pi > > > >> So what I was wondering if this issue already came up in Moby ? I'm >> currently getting started to understand the current principles of >> securing >> WebServices, but i was wondering if someone has somehow experiences >> with >> that ? >> >> So any comments and hints are welcome :-) >> >> Best >> andreas >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> > > ------------------------------------------------------------- > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > > phone: 0317-483 039 > fax: 0317-483 584 > mobile: 06-143 66 783 > mail: pieter.neerincx at wur.nl > skype: pieter.online > ------------------------------------------------------------ > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > !DSPAM:60005,47458d42260162341231610! > > > > From Pieter.Neerincx at wur.nl Thu Nov 22 17:01:16 2007 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 22 Nov 2007 18:01:16 +0100 Subject: [MOBY-dev] Moby in a secure world In-Reply-To: <47459CD5.7010709@ucalgary.ca> References: <005201c82728$f6d5a1f0$e480e5d0$@com> <98BD4F68-EEAE-47D9-906E-0E28CE5AC24D@wur.nl> <58460.195.37.46.17.1195732453.squirrel@mpizmail.mpiz-koeln.mpg.de> <61EAB8F5-4A8B-4F8A-B7C9-96390913428A@wur.nl> <47459CD5.7010709@ucalgary.ca> Message-ID: Hi Paul, I agree that would be more elegant. Basically I don't care too much about how authentication is handled as long as it works :) and the most important thing would be having something standardised! But for those who want something that has been working already for the past two years, a simple User object is a pragmatic solution for the time being. I had that implemented in a split second. This in contrast to making the secure connection over HTTPS work. Fiddling with SLL certificates and Java keystores isn't always fun :). Cheers, Pi On 22-nov-2007, at 16:14, Paul Gordon wrote: > Hi Pieter, > > While your approach definitely works, I am loathe to incorporate > authentication within Moby itself, as I mentioned in my previous > message. I think a more elegant solution would be for the > community to > suggest the use of enveloped XML signatures in the MOBY payload. In > that way, the authentication is built right into the message (e.g. > public-key based), rather than relying on a username/password > database. > This would also promote one authentication amongst all service > providers. It would also be backward compatible, as parsers should > ignore the signature tag, as it's not in the MOBY namespace. > > My $0.02, > > Paul > > Pieter Neerincx wrote: >> Hi Andreas, >> >> On 22-nov-2007, at 12:54, groscurt at mpiz-koeln.mpg.de wrote: >> >> >>> Hiho, >>> >>> at the EU-Sol meeting in Rome we discussed the usability of Moby >>> for the >>> project. One main issue was if it is possible to secure the data >>> send via >>> WebServices and to ensure that only specific people are able to use >>> specific webservices. This is because the EU-Sol is a closed >>> consortium >>> with industry partners and they, but also the "normal" biologists, >>> demand >>> to have a solution which guarantees such requirements. >>> >> >> In one of our collaborations I'm in a similar situation with a >> combined public / private consortium. >> There are several ways to secure your services, that can already work >> with the current state of the BioMOBY art. The thing is that as far >> as I know there is not really a standard ... yet. So probably several >> people already have different mechanisms in place. >> >> I'm using HTTPS to secure the connection. Next I do authentication on >> the web service level: in addition to other data I'm sending a >> BioMOBY object called "User" around. This contains a user ID, a >> password and an e-mail address. If necessary I validate those against >> an LDAP server. Instead of doing authentication on the web service >> level, you could also do authentication on the level of the web >> server or on the level of the transport layer. The reason I'm not >> doing this is that it would require extra logic for a workflow >> builder or client to handle this and not all of them do. Putting the >> user credentials inside the BioMOBY payload of the SOAP message makes >> sure this way of handling authentication works with any BioMOBY >> client :). >> >> If anyone has a more elegant solution I'd love the hear about it! >> >> Cheers, >> >> Pi >> >> >> >>> So what I was wondering if this issue already came up in Moby ? I'm >>> currently getting started to understand the current principles of >>> securing >>> WebServices, but i was wondering if someone has somehow experiences >>> with >>> that ? >>> >>> So any comments and hints are welcome :-) >>> >>> Best >>> andreas >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >>> >> >> ------------------------------------------------------------- >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> >> phone: 0317-483 039 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> mail: pieter.neerincx at wur.nl >> skype: pieter.online >> ------------------------------------------------------------ >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> !DSPAM:60005,47458d42260162341231610! >> >> >> >> > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > ------------------------------------------------------------- Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 039 fax: 0317-483 584 mobile: 06-143 66 783 mail: pieter.neerincx at wur.nl skype: pieter.online ------------------------------------------------------------ From markw at illuminae.com Fri Nov 23 21:52:57 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 23 Nov 2007 13:52:57 -0800 Subject: [MOBY-dev] Question about LSID/RDF resolution preferences Message-ID: Hi all, For anyone who is using the RDF metadata, I have a quick question for you: When we resolve an LSID, we return metadata about that entity. At the moment, however, we change the URI of that entity in our returned metadata. e.g. when we resolve this LSID: urn:lsid:biomoby.org:serviceinstance:bioinfo.icapture.ubc.ca,FASTA2HighestGenericSequenceObject:2006-04-12T18-27-15Z we return an RDF graph about: http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances#bioinfo.icapture.ubc.ca,FASTA2HighestGenericSequenceObject This strikes me as being quite a nasty thing to do to people! However, it does break fewer tools that are not capable of parsing URIs other than URLs. Opinions? Mark From markw at illuminae.com Fri Nov 23 19:16:12 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 23 Nov 2007 11:16:12 -0800 Subject: [MOBY-dev] New method for discovering location of Moby Central Message-ID: Hi all, Since we will be moving Moby Central in the next few days (it now passes all tests!) I thought it would also be a good time to design a more reliable way to discover the location of the registry than to hard-code it into the Perl and Java libraries. I've set-up some redirects on http://biomoby.org as follows: http://biomoby.org/mobycentral http://biomoby.org/ontologyserver these will give you a "301 Permamently Moved" with the "Location" header directing you to the default registry and ontology server respectively. You can use this Perl code to get the locations if you need them, but I'll be adding this into the Perl client code (and asking eddie/martin to do the same for the Java stack) so probably you wont need to know the exact locations in most cases. ============================ #!perl -w use LWP::UserAgent; use HTTP::Request::Common qw(HEAD); my $ua = LWP::UserAgent->new; my $req = HEAD 'http://biomoby.org/mobycentral'; my $res = $ua->simple_request($req); my $mobycentral = $res->header('location'); print "Default Moby Central is at: $mobycentral\n"; $req = HEAD 'http://biomoby.org/ontologyserver'; $res = $ua->simple_request($req); my $ontologyserver = $res->header('location'); print "Default Moby Ontology Server is at: $ontologyserver\n"; ================================ b.t.w. if you are going to write code like this for yourself, PLEASE use the "simple_request" method, rather than the "request" method of LWP, since a simple_request does not automatically follow the 301 redirect (which then results in a 411 error in the registry error log) This strikes me as being a more stable way of locating the registry in the long-term. Any objections/comments? b.t.w. if anyone wants to try the new Moby Central please use these new addresses, but DON'T use the new registry to do any production work yet, since I'll be wiping out and re-cloning the registry database when we "go live" next week. The new registry currently is a clone of Moby Central as of 3 days ago. Best wishes! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Sun Nov 25 07:18:53 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:18:53 -0800 Subject: [MOBY-dev] Tentative plan for the MOBY Central move Message-ID: Hi again everyone! It looks like the new Moby Central is working correctly and all accessories (RESOURCES script, LSID resolver, etc.) are working on the new machine. All we need now is a plan to deal with 24 hours of chaos when we shut-down the old server and switch to the new one. I've been trying to find a way to make Apache redirect POST data to an alternate location but it apparently cannot be done in any "sensible" way (a bug or a feature?? I'm not sure...). Anyway, it means that we'll have to all switch at ~the same time. My plan for the moment is this: 1) Announce the date/time when the switch will happen - the old server will be *switched off* at this time to ensure that we don't get out of sync. 2) I have re-coded the Perl stack (but haven't yet committed it... probably this weekend when I'm really really sure!). It now calls http://biomoby.org/mobycentral and scrapes the 302 Location header from that to determine where MOBY Central really is. This will help ensure that any future move (if necessary) is not so painful. 3) The Perl stack still uses environment variables as its default if they are available, so it will be possible to update your code without forcing the switch to the new server. Just set the MOBY_SERVER and MOBY_ONTOLOGYSERVER environment variables to point to the old MOBY Central until the switch happens. (hopefully the Java code will also do something similar?) 4) On that date/time, I will make a clone of the current MOBY Central database from mobycentral.icapture.ubc.ca and move it to moby.ucalgary.ca, then shut down the old server completely. Basically, a CVS Update is all that should be necessary to make the switch from old to new registries. After more than a month of struggling, we were unable to get MOBY Central to run in 64-bit (combinations of libxml.c problems and mod-perl problems), so the wonderful and patient sysadmins in Calgary spent a lot of time and effort in re-compiling everything in 32 bit so that it all works for us! I sincerely appreciate their commitment!!!! Thanks to them (and I owe them a couple of bottles of scotch, apparently...) In any case, the server in Calgary should have much better connectivity for everyone, so it should all run much faster after the move! The only exception is RDF generation (i.e. the RESOURCES script) since everything in MOBY Central is now pure-perl, and the RDF::Core libraries are significantly slower than their Java counterparts. Eddie is working on a caching mechanism for the RDF, so hopefully it wont be *unusably* slow (apparently it took 15 minutes for Dashboard to load the RDF today without caching... UGH!) Just as an aside, I was playing with the LSID resolver a couple of days ago and I have working code that merges the RDF from all possible metadata endpoints into a single graph. I'll post it to the list if anyone is interested (or just go to my blog: semanticmusings.blogspot.com since I also posted the code there for the sake of the HCLS community). The point of that excercise was that we want service providers to be able to give example input/output to their services in their RDF Signatures, but until now we never had the code that could retrieve metadata from anywhere other than MOBY Central. Now we do! If anyone has any questions or concerns about this plan (e.g. if you are holding a workshop in the next week, and want to be sure that MOBY Central is not "dead" when you try to reach it!) please say so and we'll schedule the move around your event. If it is going to be extremely troublesome we can delay the move until Christmas. Best wishes everyone! Mark From markw at illuminae.com Sun Nov 25 07:37:21 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:37:21 -0800 Subject: [MOBY-dev] other additions Message-ID: Hello again! In the background I have been trying to make various aspects of Moby more "standards compliant" (hey! Stop laughing! Cheeky!!!) Here are the additions I have made: 1) One request that I got repeatedly from all over the place was that the WSDL for a service should be available through a GET, since that's how all *other* Web Services work. This is now possible, and I think we should add it into the API as a legitimate way of getting the WSDL that does not use SOAP calls to the Registry. The URL pattern is: http://biomoby.org/services/wsdl/AUTH_URI/SERVICE_NAME e.g. http://biomoby.org/services/wsdl/antirrhinum.net/getDragonAlleleDescription I intend to ensure that this mechanism is stable forever, so please feel free to write code around it. It likely doesn't affect the Java users as much as the Perl users, since the Java stack doesn't use the retrieveService call on MOBY Central anyway, it creates its SOAP endpoint stubs using the output from a findService call... (right? or am I misunderstanding?) 2) The same WSDL document is now also available when you resolve a Service Instance LSID through a getData call. So, there are now THREE ways to get the WSDL: (a) The Moby Central API retrieveService call; (b) a URL; (c) LSID getData resolution. Hopefully one of these three solutions should please everyone! I know that Martin is going to spank me for this... but I have been spanked by Martin before, and survived! ;-) LOL! Mark From markw at illuminae.com Sun Nov 25 07:45:52 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:45:52 -0800 Subject: [MOBY-dev] Oh! One last thing... Message-ID: The myGrid/myExperiment team wanted a web page where we list all of the Moby Services and their WSDL's. http://biomoby.org/cgi-bin/serviceList This is NOT part of the API, it's just FYI. That page is auto-generated from the registry so it is always up-to-date, but I do NOT promise that it will always exist. I just put it up as a favour to the myGrid team. Still, it might be useful to someone else for some reason. M From markw at illuminae.com Sun Nov 25 07:57:06 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:57:06 -0800 Subject: [MOBY-dev] other additions In-Reply-To: References: Message-ID: Hmmmm... no sooner do I hit "send" than I have a re-think about something that I said... > The URL pattern is: > http://biomoby.org/services/wsdl/AUTH_URI/SERVICE_NAME Perhaps that URL should be: http://biomoby.org/services/wsdl/REGISTRY_URI/AUTH_URI/SERVICE_NAME and that would allow us to support multiple registries with the same URL syntax... That *would* be quite useful, na? I guess this should maybe be an RFC before I claim it as an addition to the API!! What are your thoughts? M From markw at illuminae.com Sun Nov 25 07:57:06 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 24 Nov 2007 23:57:06 -0800 Subject: [MOBY-dev] other additions In-Reply-To: References: Message-ID: Hmmmm... no sooner do I hit "send" than I have a re-think about something that I said... > The URL pattern is: > http://biomoby.org/services/wsdl/AUTH_URI/SERVICE_NAME Perhaps that URL should be: http://biomoby.org/services/wsdl/REGISTRY_URI/AUTH_URI/SERVICE_NAME and that would allow us to support multiple registries with the same URL syntax... That *would* be quite useful, na? I guess this should maybe be an RFC before I claim it as an addition to the API!! What are your thoughts? M From martin.senger at gmail.com Sat Nov 24 08:55:55 2007 From: martin.senger at gmail.com (Martin Senger) Date: Sat, 24 Nov 2007 08:55:55 +0000 Subject: [MOBY-dev] Tentative plan for the MOBY Central move In-Reply-To: References: Message-ID: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> > All we need now is a plan to deal with 24 hours of chaos No, we don't. But perhaps I missed something. I understand that the problem is that our software (our libraries) do not have (yet) the ability to redirect to the default moby central automatically when its location changes. You already have prepared this ability to the Perl libraries and it is a question of few hours to add it to the jMoby library. So why not to do these changes now, almost silently, but let the libraries point to the old moby center. Then we can announce that in some reasonably time, such as a month or several weeks, everybody is advised to update their installation in order to get new libraries to their machines. Finally, after an announcement period we can switch. Just my 2c's, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Sun Nov 25 09:14:08 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 25 Nov 2007 01:14:08 -0800 Subject: [MOBY-dev] Tentative plan for the MOBY Central move In-Reply-To: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> References: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> Message-ID: The problem is that i cannot find a way to automatically redirect SOAP calls from the old MOBY Central to the new MOBY Central. This is possibly because I do not fully understand the Apache redirect mechanism, but my Google searches have told me that redirecting a POST (as we would need to do with MOBY Central) is not trivial, and is not supported by any native Apache configuration directive. So... I don't think this change can be "silent". I think we all need to update at the same time. I wish it could be silent! If you know a way to do it, please tell me, because I haven't found a way in my own exploration of the problem... M On Sat, 24 Nov 2007 00:55:55 -0800, Martin Senger wrote: >> All we need now is a plan to deal with 24 hours of chaos > > > No, we don't. But perhaps I missed something. > > I understand that the problem is that our software (our libraries) do not > have (yet) the ability to redirect to the default moby central > automatically > when its location changes. You already have prepared this ability to the > Perl libraries and it is a question of few hours to add it to the jMoby > library. So why not to do these changes now, almost silently, but let the > libraries point to the old moby center. Then we can announce that in some > reasonably time, such as a month or several weeks, everybody is advised > to > update their installation in order to get new libraries to their > machines. > Finally, after an announcement period we can switch. > > Just my 2c's, > Martin > From martin.senger at gmail.com Sat Nov 24 14:36:11 2007 From: martin.senger at gmail.com (Martin Senger) Date: Sat, 24 Nov 2007 14:36:11 +0000 Subject: [MOBY-dev] Tentative plan for the MOBY Central move In-Reply-To: References: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> Message-ID: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> > The problem is that i cannot find a way to automatically redirect SOAP > calls from the old MOBY Central to the new MOBY Central No, that is not what I have suggested. I wish it could be silent! If you know a way to do it, please tell me, Actually the way I am suggesting is the one you suggested and you already did :-) You created a stable URL (which is not a URL of a default biomoby central, and which is not a URL that is going to change). This URL is able to give back a URL and URI of a default registry. This URL is not supposed to be widely used directly but it is supposed to be consulted by Perl and Java libraries. The library then uses the obtained result as the default URL and URI. In our current case, we can silently include this ability into our libraries (as you already did for Perl) and tell people that they have a month (or whatever) to update their software (the best way by taking the new versions of our Perl and Java libraries - just by 'cvs update'). At the moment, the "stable URL" I mentioned above will be still pointing to the icapture moby server. After a month (or whatever) we change the result coming from the stable URL to point to Calgary server. Nobody notices anything (unless they are using their own libraries and they did not develop into them the same mechanism in time). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Sun Nov 25 16:42:56 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 25 Nov 2007 08:42:56 -0800 Subject: [MOBY-dev] Tentative plan for the MOBY Central move In-Reply-To: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> References: <4d93f07c0711240055g7ca64fd5l2072cf80a1278c40@mail.gmail.com> <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> Message-ID: Ah, I see! The same solution, but with the http://biomoby.org/mobycentral pointing to the old server rather than the new server for ~a month! Okay, that's more gentle than what I had suggested :-) Good idea! M On Sat, 24 Nov 2007 06:36:11 -0800, Martin Senger wrote: >> The problem is that i cannot find a way to automatically redirect SOAP >> calls from the old MOBY Central to the new MOBY Central > > > No, that is not what I have suggested. > > I wish it could be silent! If you know a way to do it, please tell me, > > > Actually the way I am suggesting is the one you suggested and you already > did :-) You created a stable URL (which is not a URL of a default biomoby > central, and which is not a URL that is going to change). This URL is > able > to give back a URL and URI of a default registry. This URL is not > supposed > to be widely used directly but it is supposed to be consulted by Perl and > Java libraries. The library then uses the obtained result as the default > URL > and URI. > > In our current case, we can silently include this ability into our > libraries > (as you already did for Perl) and tell people that they have a month (or > whatever) to update their software (the best way by taking the new > versions > of our Perl and Java libraries - just by 'cvs update'). At the moment, > the > "stable URL" I mentioned above will be still pointing to the icapture > moby > server. After a month (or whatever) we change the result coming from the > stable URL to point to Calgary server. Nobody notices anything (unless > they > are using their own libraries and they did not develop into them the same > mechanism in time). > > Cheers, > Martin > From groscurt at mpiz-koeln.mpg.de Mon Nov 26 14:04:56 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Mon, 26 Nov 2007 15:04:56 +0100 Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects In-Reply-To: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> References: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> Message-ID: <200711261504.56503.groscurt@mpiz-koeln.mpg.de> Hi, I'm using CentralCachedCallsImpl to send calls to the Central. The first time i'm calling it it collects the service types from the url http://biomoby.org/RESOURCES/MOBY-S/Objects For the last months this worked fine, but as I tried to today i receive error by error: Cannot parse MOBY Service Type Ontology: com.hp.hpl.jena.shared.JenaException: rethrew: ARP interrupted 15:00:48,230 ERROR [STDERR] java.io.InterruptedIOException: ARP interrupted 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.WrappedException.throwMe(WrappedException.java:74) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.ARPFilter.parse(ARPFilter.java:316) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:221) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:209) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:239) 15:00:48,231 ERROR [STDERR] at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:161) or Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException 15:00:02,396 ERROR [STDERR] java.lang.NullPointerException 15:00:02,396 ERROR [STDERR] at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:182) is this a current or general error ? Does the moving of MobyCentral requires an cvs update ? thanks andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From edward.kawas at gmail.com Mon Nov 26 14:22:29 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 26 Nov 2007 06:22:29 -0800 Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects In-Reply-To: <200711261504.56503.groscurt@mpiz-koeln.mpg.de> References: <4d93f07c0711240636u1fa18ccbw1bb56414f817a19f@mail.gmail.com> <200711261504.56503.groscurt@mpiz-koeln.mpg.de> Message-ID: <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> Hi Andreas, I cannot reproduce this error. I have tried running the 'main' for each of the classes in the package org.biomoby.shared.extended and each of them worked ... Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Andreas Groscurth Sent: November-26-07 6:05 AM To: Core developer announcements Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects Hi, I'm using CentralCachedCallsImpl to send calls to the Central. The first time i'm calling it it collects the service types from the url http://biomoby.org/RESOURCES/MOBY-S/Objects For the last months this worked fine, but as I tried to today i receive error by error: Cannot parse MOBY Service Type Ontology: com.hp.hpl.jena.shared.JenaException: rethrew: ARP interrupted 15:00:48,230 ERROR [STDERR] java.io.InterruptedIOException: ARP interrupted 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.WrappedException.throwMe(WrappedException.java:74) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.ARPFilter.parse(ARPFilter.java:316) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:221) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:209) 15:00:48,231 ERROR [STDERR] at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:239) 15:00:48,231 ERROR [STDERR] at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:161) or Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException 15:00:02,396 ERROR [STDERR] java.lang.NullPointerException 15:00:02,396 ERROR [STDERR] at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) is this a current or general error ? Does the moving of MobyCentral requires an cvs update ? thanks andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From groscurt at mpiz-koeln.mpg.de Mon Nov 26 15:25:25 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Mon, 26 Nov 2007 16:25:25 +0100 Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects In-Reply-To: <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> References: <200711261504.56503.groscurt@mpiz-koeln.mpg.de> <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> Message-ID: <200711261625.25954.groscurt@mpiz-koeln.mpg.de> hi, mhm... running it from the parser it also works for me... the following not: public class TestMoby { public static void main( String[] args ) throws Exception { Central central = new CentralCachedCallsImpl( ); MobyService mobyService = new MobyService(); mobyService.setCategory(""); mobyService.setAuthority("arabidopsis.info"); mobyService.setName("NASCArraysGeneswingerByAGI"); mobyService = central.findService(mobyService)[0]; MobyRequest request = new MobyRequest( central ); request.setService( mobyService ); request.setInput( new MobyDataObject( "AGI_LocusCode", "At2g21050" ) ); MobyContentInstance contentInstance = request.invokeService(); } } First it takes a eternity to get the data types - maybe this is just a current (and also a local) issue, but thats the feeling i get, compared to the calles some weeks ago. Second - this is the output I get: Fetching data type ontology from http://biomoby.org/RESOURCES/MOBY-S/Objects Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:182) at org.biomoby.shared.MobyDataType.loadDataTypes(MobyDataType.java:103) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:144) at org.biomoby.shared.data.MobyDataObject.(MobyDataObject.java:78) at org.biomoby.shared.data.MobyDataObject.(MobyDataObject.java:73) at test.TestMoby.main(TestMoby.java:28) Fetching namespace ontology from http://biomoby.org/RESOURCES/MOBY-S/Namespaces There are 1 collections in response 1 Fetching data type ontology from http://biomoby.org/RESOURCES/MOBY-S/Objects So - the namespaces are apparently ok - but it keeps trying to get the data types.... and always ends up in the Nullpointer. Any ideas? thanks andreas On Monday 26 November 2007 15:22, Edward Kawas wrote: > Hi Andreas, > > I cannot reproduce this error. I have tried running the 'main' for each of > the classes in the package org.biomoby.shared.extended and each of them > worked ... > > Eddie > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Andreas Groscurth > Sent: November-26-07 6:05 AM > To: Core developer announcements > Subject: [MOBY-dev] Problems with > http://biomoby.org/RESOURCES/MOBY-S/Objects > > Hi, > > I'm using CentralCachedCallsImpl to send calls to the Central. > > The first time i'm calling it it collects the service types from the url > http://biomoby.org/RESOURCES/MOBY-S/Objects > > For the last months this worked fine, but as I tried to today i receive > error > by error: > > Cannot parse MOBY Service Type Ontology: > com.hp.hpl.jena.shared.JenaException: > rethrew: ARP interrupted > 15:00:48,230 ERROR [STDERR] java.io.InterruptedIOException: ARP interrupted > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.WrappedException.throwMe(WrappedException.java:74) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.ARPFilter.parse(ARPFilter.java:316) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:221) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:209) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:239) > 15:00:48,231 ERROR [STDERR] at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataType >P arser.java:161) > > or > > Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException > 15:00:02,396 ERROR [STDERR] java.lang.NullPointerException > 15:00:02,396 ERROR [STDERR] at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataType >P arser.java:182) > > is this a current or general error ? > > Does the moving of MobyCentral requires an cvs update ? > > thanks > andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From arnaud at ebi.ac.uk Mon Nov 26 11:26:46 2007 From: arnaud at ebi.ac.uk (Arnaud Kerhornou) Date: Mon, 26 Nov 2007 11:26:46 +0000 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Message-ID: <474AAD76.3000101@ebi.ac.uk> Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca47cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstanceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(BiomobyScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.java:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(BiomobyScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerHelperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject.java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject.java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstance.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java:125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMobyXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDatatypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenerateTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocationWithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(ProcessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithoutIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(ProcessorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(ProcessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) -------------- next part -------------- A non-text attachment was scrubbed... Name: geneid_exercise1.xml Type: text/xml Size: 3091 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: HS307871.fa URL: From edward.kawas at gmail.com Mon Nov 26 23:34:15 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 26 Nov 2007 15:34:15 -0800 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <474AAD76.3000101@ebi.ac.uk> References: <474AAD76.3000101@ebi.ac.uk> Message-ID: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Hi Arnaud, It seems to be working now. Not sure what the problem was, but I just ran your workflow with your inputs and it worked for me. Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou Sent: November-26-07 3:27 AM To: 'Core developer announcements' Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan ceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby ScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j ava:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby ScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH elperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan ce.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: 125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo byXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat atypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera teTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation WithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P rocessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou tIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce ssorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr ocessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) From edward.kawas at gmail.com Mon Nov 26 23:34:15 2007 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 26 Nov 2007 15:34:15 -0800 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <474AAD76.3000101@ebi.ac.uk> References: <474AAD76.3000101@ebi.ac.uk> Message-ID: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Hi Arnaud, It seems to be working now. Not sure what the problem was, but I just ran your workflow with your inputs and it worked for me. Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou Sent: November-26-07 3:27 AM To: 'Core developer announcements' Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan ceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby ScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j ava:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby ScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH elperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan ce.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: 125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo byXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat atypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera teTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation WithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P rocessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou tIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce ssorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr ocessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) From arnaud at ebi.ac.uk Mon Nov 26 13:09:32 2007 From: arnaud at ebi.ac.uk (Arnaud Kerhornou) Date: Mon, 26 Nov 2007 13:09:32 +0000 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Message-ID: <474AC58C.2090206@ebi.ac.uk> Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into this, please ? Thanks Arnaud PS: Taverna Exception stack: WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca47cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstanceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(BiomobyScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.java:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(BiomobyScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerHelperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeParser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject.java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject.java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstance.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java:125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMobyXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDatatypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenerateTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocationWithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(ProcessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithoutIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(ProcessorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(ProcessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) -------------- next part -------------- A non-text attachment was scrubbed... Name: geneid_exercise1.xml Type: text/xml Size: 3092 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: HS307871.fa URL: From markw at illuminae.com Mon Nov 26 23:35:19 2007 From: markw at illuminae.com (mark wilkinson) Date: Mon, 26 Nov 2007 23:35:19 +0000 GMT Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> References: <474AAD76.3000101@ebi.ac.uk> <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Message-ID: <63848754-1196120332-cardhu_blackberry.rim.net-15230-@engine10-cell01> Hi all, I have a feeling that these problems were largely rooted in the fact that the LSID resolver caches its WSDL. When I was testing things against the new code against the new endpoint this weekend I was using the LSID resolver on MobyCentral, and it seems that it cached the results and then when the non-updated code tried to access the same resources it was unable to hit the endpoint. I have deleted the lsid cache and that seems to have solved many of the problems we all experienced the past few days. Sorry about that! It took a while to track down that arcane problem... Mark -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Mon, 26 Nov 2007 15:34:15 To:"'Arnaud Kerhornou'" , "'Core developer announcements'" , "'Core developer announcements'" Subject: Re: [MOBY-dev] Parse_moby_data processor in taverna fails Hi Arnaud, It seems to be working now. Not sure what the problem was, but I just ran your workflow with your inputs and it worked for me. Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou Sent: November-26-07 3:27 AM To: 'Core developer announcements' Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan ceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby ScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j ava:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby ScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH elperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan ce.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: 125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo byXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat atypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera teTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation WithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P rocessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou tIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce ssorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr ocessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Nov 26 23:35:19 2007 From: markw at illuminae.com (mark wilkinson) Date: Mon, 26 Nov 2007 23:35:19 +0000 GMT Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> References: <474AAD76.3000101@ebi.ac.uk> <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Message-ID: <63848754-1196120332-cardhu_blackberry.rim.net-15230-@engine10-cell01> Hi all, I have a feeling that these problems were largely rooted in the fact that the LSID resolver caches its WSDL. When I was testing things against the new code against the new endpoint this weekend I was using the LSID resolver on MobyCentral, and it seems that it cached the results and then when the non-updated code tried to access the same resources it was unable to hit the endpoint. I have deleted the lsid cache and that seems to have solved many of the problems we all experienced the past few days. Sorry about that! It took a while to track down that arcane problem... Mark -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Mon, 26 Nov 2007 15:34:15 To:"'Arnaud Kerhornou'" , "'Core developer announcements'" , "'Core developer announcements'" Subject: Re: [MOBY-dev] Parse_moby_data processor in taverna fails Hi Arnaud, It seems to be working now. Not sure what the problem was, but I just ran your workflow with your inputs and it worked for me. Eddie -----Original Message----- From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou Sent: November-26-07 3:27 AM To: 'Core developer announcements' Subject: [MOBY-dev] Parse_moby_data processor in taverna fails Hi, I just tried a workflow that was working fine last week with taverna 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the exception stack below), (I have attached the workflow, it takes a fasta sequence) Can someone look into it, please ? Thanks Arnaud WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 500 for URL: http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan ceCache(BiomobyScavengerWorker.java:742) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby ScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j ava:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby ScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH elperThread.run(ScavengerHelperThreadPool.java:123) Cannot parse MOBY Object Ontology: java.lang.NullPointerException java.lang.NullPointerException at org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP arser.java:182) at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) at org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:186) at org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. java:152) at org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan ce.java:240) at org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: 125) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) at org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) at org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo byXML.java:75) at org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat atypeTask.java:100) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera teTemplates(ProcessorTask.java:576) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation WithRetryLogic(ProcessorTask.java:517) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P rocessorTask.java:436) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou tIteration(ProcessorTask.java:642) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce ssorTask.java:353) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr ocessorTask.java:280) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Nov 27 01:48:28 2007 From: markw at illuminae.com (mark wilkinson) Date: Tue, 27 Nov 2007 01:48:28 +0000 GMT Subject: [MOBY-dev] CVS updated Message-ID: <510644021-1196128322-cardhu_blackberry.rim.net-7890-@engine11-cell01> Hi all, So as per Martin's suggestion, the 301 redirect points to the CURRENT moby central, and will continue to point there until we have as many people updated as possible. Perl users, please CVS update your code and let me know if you find errors. Sorry again about the chaos over the weekend. LSID caching catches me by surprise all the time, and it did so again this time... I didn't expect that simply running new code on the mobycentral machine, without updating mobycentral itself, would cause a problem! Live and learn... M -- Mark Wilkinson ...on the road! From markw at illuminae.com Tue Nov 27 02:16:17 2007 From: markw at illuminae.com (mark wilkinson) Date: Tue, 27 Nov 2007 02:16:17 +0000 GMT Subject: [MOBY-dev] The moby URI Message-ID: <1961185115-1196129989-cardhu_blackberry.rim.net-27939-@engine25-cell01> A couple of people have asked me about the Moby URI that is required by the SOAP Lite libraries. The URI takes the form: http://some.authority/MOBY/Central In my experience, what you put into the some.authority component is completely meaningless. What matters is the MOBY/Central component, which represents the Perl path to the MOBY::Central.pm library. So... Whatever you have it set to now should always work for you regardless of where we move mobycentral to. M -- Mark Wilkinson ...on the road! From groscurt at mpiz-koeln.mpg.de Tue Nov 27 10:05:16 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Tue, 27 Nov 2007 11:05:16 +0100 Subject: [MOBY-dev] Problems with http://biomoby.org/RESOURCES/MOBY-S/Objects In-Reply-To: <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> References: <200711261504.56503.groscurt@mpiz-koeln.mpg.de> <448C04CC1E864F5C8B76AFE17A3EF6D5@OfficePC> Message-ID: <200711271105.16413.groscurt@mpiz-koeln.mpg.de> Hi, problem fixed... I checked out the source again and added dome libs which I havent had added before (but it worked ...) and now it works as intended. Thanks andreas On Monday 26 November 2007 15:22, Edward Kawas wrote: > Hi Andreas, > > I cannot reproduce this error. I have tried running the 'main' for each of > the classes in the package org.biomoby.shared.extended and each of them > worked ... > > Eddie > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Andreas Groscurth > Sent: November-26-07 6:05 AM > To: Core developer announcements > Subject: [MOBY-dev] Problems with > http://biomoby.org/RESOURCES/MOBY-S/Objects > > Hi, > > I'm using CentralCachedCallsImpl to send calls to the Central. > > The first time i'm calling it it collects the service types from the url > http://biomoby.org/RESOURCES/MOBY-S/Objects > > For the last months this worked fine, but as I tried to today i receive > error > by error: > > Cannot parse MOBY Service Type Ontology: > com.hp.hpl.jena.shared.JenaException: > rethrew: ARP interrupted > 15:00:48,230 ERROR [STDERR] java.io.InterruptedIOException: ARP interrupted > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.WrappedException.throwMe(WrappedException.java:74) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.ARPFilter.parse(ARPFilter.java:316) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:221) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:209) > 15:00:48,231 ERROR [STDERR] at > com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:239) > 15:00:48,231 ERROR [STDERR] at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataType >P arser.java:161) > > or > > Cannot parse MOBY Service Type Ontology: java.lang.NullPointerException > 15:00:02,396 ERROR [STDERR] java.lang.NullPointerException > 15:00:02,396 ERROR [STDERR] at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataType >P arser.java:182) > > is this a current or general error ? > > Does the moving of MobyCentral requires an cvs update ? > > thanks > andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From arnaud at ebi.ac.uk Tue Nov 27 10:08:08 2007 From: arnaud at ebi.ac.uk (Arnaud Kerhornou) Date: Tue, 27 Nov 2007 10:08:08 +0000 Subject: [MOBY-dev] Parse_moby_data processor in taverna fails In-Reply-To: <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> References: <474AAD76.3000101@ebi.ac.uk> <639FC32707B64DBDAC2295DDE4EC7C38@OfficePC> Message-ID: <474BEC88.9010205@ebi.ac.uk> hi Eddie, Actually the taverna workflow worked but I still get an Exception at the moby parsing stage. Should I clean my local cache ? Arnaud PS: Exception stack org.biomoby.shared.MobyException: Cannot write to '/Users/axk/Library/Application Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca47cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. java.io.IOException: Server returned HTTP response code: 502 for URL: http://mobycentral.icapture.ubc.ca/authority/RESOURCES/MOBY-S/ServiceInstances at org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstanceCache(BiomobyScavengerWorker.java:709) at org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(BiomobyScavengerWorker.java:392) at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.java:50) at org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(BiomobyScavengerHelper.java:140) at org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerHelperThread.run(ScavengerHelperThreadPool.java:123) Edward Kawas wrote: > Hi Arnaud, > > It seems to be working now. Not sure what the problem was, but I just ran > your workflow with your inputs and it worked for me. > > Eddie > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Arnaud Kerhornou > Sent: November-26-07 3:27 AM > To: 'Core developer announcements' > Subject: [MOBY-dev] Parse_moby_data processor in taverna fails > > Hi, > > I just tried a workflow that was working fine last week with taverna > 1.6.2.1, and it gets stuck on the parse_moby_data stage (See the > exception stack below), > > (I have attached the workflow, it takes a fasta sequence) > > Can someone look into it, please ? > > Thanks > Arnaud > > WARN 2007-11-26 11:19:51,714 There was a problem writing to the cache: > org.biomoby.shared.MobyException: Cannot write to > '/Users/axk/Library/Application > Support/Taverna-1.6.2/moby-cache/http58.47.47mobycentral46icapture46ubc46ca4 > 7cgi45bin47MOBY0547mobycentral46pl/service_rdf/SERVICE_INSTANCE.rdf'. > java.io.IOException: Server returned HTTP response code: 500 for URL: > http://moby.ucalgary.ca/RESOURCES/MOBY-S/ServiceInstances > at > org.biomoby.client.taverna.plugin.CacheImpl.storeURL(CacheImpl.java:363) > at > org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.updateServiceInstan > ceCache(BiomobyScavengerWorker.java:742) > at > org.biomoby.client.taverna.plugin.BiomobyScavengerWorker.getServices(Biomoby > ScavengerWorker.java:392) > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScavenger.j > ava:50) > at > org.biomoby.client.taverna.plugin.BiomobyScavengerHelper.getDefaults(Biomoby > ScavengerHelper.java:140) > at > org.embl.ebi.escience.scuflui.workbench.ScavengerHelperThreadPool$ScavengerH > elperThread.run(ScavengerHelperThreadPool.java:123) > Cannot parse MOBY Object Ontology: java.lang.NullPointerException > java.lang.NullPointerException > at > org.biomoby.shared.extended.DataTypeParser.getMobyDataTypesFromRDF(DataTypeP > arser.java:182) > at org.biomoby.shared.MobyDataType.getDataType(MobyDataType.java:88) > at > org.biomoby.shared.data.MobyDataComposite.(MobyDataComposite.java:35) > at > org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. > java:186) > at > org.biomoby.shared.data.MobyDataObject.createInstanceFromDOM(MobyDataObject. > java:152) > at > org.biomoby.shared.data.MobyContentInstance.parseDataGroup(MobyContentInstan > ce.java:240) > at > org.biomoby.shared.data.MobyContentInstance.(MobyContentInstance.java: > 125) > at > org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:93) > at > org.biomoby.shared.data.MobyDataUtils.fromXMLDocument(MobyDataUtils.java:48) > at > org.biomoby.client.taverna.plugin.ParseMobyXML.getContentForDataType(ParseMo > byXML.java:75) > at > org.biomoby.client.taverna.plugin.MobyParseDatatypeTask.execute(MobyParseDat > atypeTask.java:100) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenera > teTemplates(ProcessorTask.java:576) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocation > WithRetryLogic(ProcessorTask.java:517) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(P > rocessorTask.java:436) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithou > tIteration(ProcessorTask.java:642) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(Proce > ssorTask.java:353) > at > uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(Pr > ocessorTask.java:280) > at > uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) > > > > ___________________________________________________________________________ Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire. http://fr.mail.yahoo.com From dmitry.repchevski at bsc.es Tue Nov 27 19:59:44 2007 From: dmitry.repchevski at bsc.es (Dmitry Repchevsky) Date: Tue, 27 Nov 2007 20:59:44 +0100 Subject: [MOBY-dev] Moby Java JAXB API Message-ID: <474C7730.9010801@bsc.es> Hello everybody, I would like to get your opinion about the demo I made. The demo is actually a simple Moby client which is connected to our repository (http://moby-dev.inab.org/cgi-bin/MOBY-Central.pl) obtain the list of "simple" services (those that accepts MobyObject as input) from our url (inb.bsc.es) and give a possibility to call them. The interesting thing is that the client uses its own API based on JAXB. There are four jars you can download: http://inb.bsc.es/java/MobyCore.jar http://inb.bsc.es/java/MobyRegistry.jar http://inb.bsc.es/java/MobyGenerator.jar http://inb.bsc.es/java/MobyDemoClient.jar with source code in: http://inb.bsc.es/java/MobyCore-src.zip http://inb.bsc.es/java/MobyRegistry-src.zip http://inb.bsc.es/java/MobyGenerator-src.zip http://inb.bsc.es/java/MobyDemoClient-src.zip MobyCore.jar contains the API to marshall/unmarshall moby messages as well as call moby services. Actually there is almost no API at all, because most of the classes are JAXB annotated java classes with get/set methods. MobyCore can work without any pregenerated datatypes in this case all moby objects are converted to AnyMobyObject class by unmarshaller. There is also a simple ontology generator - MobyGenerator. It connects to moby-central and generates JAXB annotated datatype classes with proper get/set methods using java inheritance for "IS" and java properties for HASA/HAS (in latter case List<>) As I mentioned before there is no need to generate the ontology to work with API so one can use AnyMobyObject o = AnyMobyObject("PDB-Text"); o.setMobyId(""); o.setNamespace(""); o.setArticleName(""); o.putAttribute("context", new MobyString("some text")); or PDB_Text o = new PDB_Text(); o.setMobyId(""); o.setNamespace(""); o.setArticleName(""); o.setContent(new MobyString("some text"); MobyRegistry is as you can guess JAXB classes to work with Registry API. The package is still clumsy even with help from Edward Kawas, there are just too many classes may times duplicated... So what it the typical use case? Something like: ******************************************************************************** MobyData mobyData = new MobyData("sip_1"); AminoAcidSequence sequence = new AminoAcidSequence(); sequence.setSequenceString(new MobyString("MKELNDLEKKYNAHIGVYALDTKSGKEVKFNSDKRFAYASTSKAINSAILLEQVPYNKLNKKVHINKDDIVAYSPILEKY" + "VGKDITLKALIEASMTYSDNTANNKIIKEIGGIKKVKQRLKELGDKVTNPVRYEIELNYYSPKSKKDTSTPAAFGKTLNK" + "LIANGKLSKENKKFLLDLMLNNKSGDTLIKDGVPKDYKVADKSGQSTYASRNDVAFVYPKGQSEPIVLVIFTNKDNKSDK" + "PNDKLISETAKSVMKEF")); sequence.setLength(new MobyInteger(257)); mobyData.addMobyDataElement(new MobySimple(sequence, "sequence")); mobyData.addParameter(new MobyParameter("scores", "25")); mobyData.addParameter(new MobyParameter("alignments", "2")); MobyMessage message = new MobyMessage(mobyData); MobyServiceEndpoint service = new MobyServiceEndpoint("http://inb.bsc.es/cgi-bin/mobyServices/dispatchers/asyncDispatcher.cgi", "runNCBITBlastn"); MobyMessage m = service.call(message); if (m.hasExceptions()) { List exceptions = m.getExceptions(); for (MobyException ex : exceptions) { System.out.print(ex.getSeverity().name()); System.out.print(" "); System.out.print(ex.getRefQueryID()); System.out.print(" "); System.out.println(ex.getRefElement()); System.out.print("---- code = "); System.out.print(ex.getExceptionCode()); System.out.println("---->"); System.out.println(ex.getExceptionMessage()); } } else { List mobyDataList = m.getMobyDataList(); for (MobyData md : mobyDataList) { MobySimple simple = md.getData(""); // article name BLAST_Text blast = simple.getObject(); System.out.println("=============>\n" + blast.getContent().getString()); } } ******************************************************************************** Finally I would like to notice that API NEED JAX-WS 2.1. AND (at least MobyGenerator) Java6. So to test it someone has to install jax-ws into endorsed directory (in jre/lib/ create a directory named "endorsed" and put all jax-ws packages into it). JAX-WS you can download from https://jax-ws.dev.java.net/ri-download.html Again this is the version of JAX-WS which is included in next Java 6 update (in a few months) and what is important with update N (https://jdk6.dev.java.net/6uNea.html) The demo itself is pretty simple, but I hope you will like it :-) Just forgot - both Demo and MobyGenerator need MobyCore and MobyRegistry jars :-) MobyGenerator needs JDK 6 to be able to compile generated classes (otherwise it creates zipped sources). Cheers, Dmitry From markw at illuminae.com Thu Nov 29 22:59:58 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 29 Nov 2007 14:59:58 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central Message-ID: Hi again all, The new Moby Central is available at: http://moby.ucalgary.ca/moby/MOBY-Central.pl http://moby.ucalgary.ca/moby/OntologyServer.cgi It would be great for people to give it a test run before we make the move permanent. It loads much faster into tools like Taverna because it caches its RDF(thanks Eddie!) Please don't use it for registering services, only for service discovery. It synchronizes with the registry at mobycentral.icapture.ubc.ca at 3:45AM Mountain Standard Time every night, so any services that you register in it will be lost! M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From groscurt at mpiz-koeln.mpg.de Fri Nov 30 08:57:33 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 09:57:33 +0100 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: Message-ID: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> Hi do I understand it correctly: URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi However, the first works, but the second seems not to work. In the browser I get 500 Internal Server Error and in the dashboard ===ERROR=== Fault details: [stackTrace: null] [hostname: null] Fault string: Failed to access class (moby::OntologyServer.cgi) at /opt/coolstack/lib/perl5/site_perl/5.8.8/SOAP/Lite.pm line 2473, line 159. Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client Fault actor: null When calling: http://moby.ucalgary.ca/moby/MOBY-Central.pl =========== Any solutions ? thx On Thursday 29 November 2007 23:59, Mark Wilkinson wrote: > Hi again all, > > The new Moby Central is available at: > > http://moby.ucalgary.ca/moby/MOBY-Central.pl > http://moby.ucalgary.ca/moby/OntologyServer.cgi > > It would be great for people to give it a test run before we make the move > permanent. It loads much faster into tools like Taverna because it caches > its RDF(thanks Eddie!) > > Please don't use it for registering services, only for service discovery. > It synchronizes with the registry at mobycentral.icapture.ubc.ca at 3:45AM > Mountain Standard Time every night, so any services that you register in > it will be lost! > > M -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From groscurt at mpiz-koeln.mpg.de Fri Nov 30 08:58:36 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 09:58:36 +0100 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: Message-ID: <200711300958.37078.groscurt@mpiz-koeln.mpg.de> And I forgot. the default "old" central is apparently not accessible... at least I do always get a timeout. best andreas Hi do I understand it correctly: URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi However, the first works, but the second seems not to work. In the browser I get 500 Internal Server Error and in the dashboard ===ERROR=== Fault details: [stackTrace: null] [hostname: null] Fault string: Failed to access class (moby::OntologyServer.cgi) at /opt/coolstack/lib/perl5/site_perl/5.8.8/SOAP/Lite.pm line 2473, line 159. Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client Fault actor: null When calling: http://moby.ucalgary.ca/moby/MOBY-Central.pl =========== Any solutions ? thx On Thursday 29 November 2007 23:59, Mark Wilkinson wrote: > Hi again all, > > The new Moby Central is available at: > > http://moby.ucalgary.ca/moby/MOBY-Central.pl > http://moby.ucalgary.ca/moby/OntologyServer.cgi > > It would be great for people to give it a test run before we make the move > permanent. It loads much faster into tools like Taverna because it caches > its RDF(thanks Eddie!) > > Please don't use it for registering services, only for service discovery. > It synchronizes with the registry at mobycentral.icapture.ubc.ca at 3:45AM > Mountain Standard Time every night, so any services that you register in > it will be lost! > > M -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From markw at illuminae.com Fri Nov 30 09:02:02 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:02:02 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> References: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> Message-ID: On Fri, 30 Nov 2007 00:57:33 -0800, Andreas Groscurth wrote: > do I understand it correctly: > > URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl > URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi No. MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl MOBY_URI = http://whatever.you.want/MOBY/Central MOBY_ONTOLOGYSERVER= http://moby.ucalgary.ca/moby/OntologyServer.cgi (Taverna wont need the latter, but the Perl clients do) From markw at illuminae.com Fri Nov 30 09:06:57 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:06:57 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: <200711300958.37078.groscurt@mpiz-koeln.mpg.de> References: <200711300958.37078.groscurt@mpiz-koeln.mpg.de> Message-ID: Yeah, it looks like the server has crashed. I can't even SSH into it. I've sent a message to the sysadmins, but they wont get it for another 6 hours at best, so... >>sigh<< Sorry! Mark On Fri, 30 Nov 2007 00:58:36 -0800, Andreas Groscurth wrote: > And I forgot. > > the default "old" central is apparently not accessible... at least I do > always > get a timeout. > > best > andreas > > > Hi > > do I understand it correctly: > > URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl > URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi > > However, the first works, but the second seems not to work. In the > browser I > get 500 Internal Server Error and in the dashboard > > ===ERROR=== > Fault details: > [stackTrace: null] > [hostname: null] > Fault string: Failed to access class (moby::OntologyServer.cgi) > at /opt/coolstack/lib/perl5/site_perl/5.8.8/SOAP/Lite.pm line 2473, > line > 159. > > Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client > Fault actor: null > When calling: > http://moby.ucalgary.ca/moby/MOBY-Central.pl > =========== > > Any solutions ? > thx > > On Thursday 29 November 2007 23:59, Mark Wilkinson wrote: >> Hi again all, >> >> The new Moby Central is available at: >> >> http://moby.ucalgary.ca/moby/MOBY-Central.pl >> http://moby.ucalgary.ca/moby/OntologyServer.cgi >> >> It would be great for people to give it a test run before we make the >> move >> permanent. It loads much faster into tools like Taverna because it >> caches >> its RDF(thanks Eddie!) >> >> Please don't use it for registering services, only for service >> discovery. >> It synchronizes with the registry at mobycentral.icapture.ubc.ca at >> 3:45AM >> Mountain Standard Time every night, so any services that you register in >> it will be lost! >> >> M > From groscurt at mpiz-koeln.mpg.de Fri Nov 30 09:11:33 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 10:11:33 +0100 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> Message-ID: <200711301011.33675.groscurt@mpiz-koeln.mpg.de> Thanks mark, nice time to answer my mail :-) /bow On Friday 30 November 2007 10:02, Mark Wilkinson wrote: > On Fri, 30 Nov 2007 00:57:33 -0800, Andreas Groscurth > > wrote: > > do I understand it correctly: > > > > URL = http://moby.ucalgary.ca/moby/MOBY-Central.pl > > URI = http://moby.ucalgary.ca/moby/OntologyServer.cgi > > No. > > MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl > MOBY_URI = http://whatever.you.want/MOBY/Central > > MOBY_ONTOLOGYSERVER= http://moby.ucalgary.ca/moby/OntologyServer.cgi > > (Taverna wont need the latter, but the Perl clients do) > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From markw at illuminae.com Fri Nov 30 09:16:53 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:16:53 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: <200711301011.33675.groscurt@mpiz-koeln.mpg.de> References: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> <200711301011.33675.groscurt@mpiz-koeln.mpg.de> Message-ID: On Fri, 30 Nov 2007 01:11:33 -0800, Andreas Groscurth wrote: > Thanks mark, > > nice time to answer my mail :-) The benefits of a segmented sleep pattern :-) http://en.wikipedia.org/wiki/Segmented_sleep Mark From markw at illuminae.com Fri Nov 30 09:20:56 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:20:56 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: <200711300957.33406.groscurt@mpiz-koeln.mpg.de> Message-ID: > MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl > MOBY_URI = http://whatever.you.want/MOBY/Central I'm not sure if the Java libraries are sensitive to the content of the "whatever.you.want" section (or if they need a URI at all??) M From groscurt at mpiz-koeln.mpg.de Fri Nov 30 09:37:36 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 10:37:36 +0100 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: References: Message-ID: <200711301037.36999.groscurt@mpiz-koeln.mpg.de> Apparently they are ok with that.. at least dashboard is loading from the url and uri.... But currently i use http://moby.ucalgary.ca/moby/MOBY-Central.pl and http://moby.ucalgary.ca/MOBY/Central On Friday 30 November 2007 10:20, Mark Wilkinson wrote: > > MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl > > MOBY_URI = http://whatever.you.want/MOBY/Central > > I'm not sure if the Java libraries are sensitive to the content of the > "whatever.you.want" section (or if they need a URI at all??) > > M > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From markw at illuminae.com Fri Nov 30 09:40:38 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 01:40:38 -0800 Subject: [MOBY-dev] For those who want to use the new Moby Central In-Reply-To: <200711301037.36999.groscurt@mpiz-koeln.mpg.de> References: <200711301037.36999.groscurt@mpiz-koeln.mpg.de> Message-ID: Okay, thanks for the confirmation. Mark On Fri, 30 Nov 2007 01:37:36 -0800, Andreas Groscurth wrote: > Apparently they are ok with that.. at least dashboard is loading from > the url > and uri.... > > But currently i use > > http://moby.ucalgary.ca/moby/MOBY-Central.pl > and > http://moby.ucalgary.ca/MOBY/Central > > On Friday 30 November 2007 10:20, Mark Wilkinson wrote: >> > MOBY_SERVER = http://moby.ucalgary.ca/moby/MOBY-Central.pl >> > MOBY_URI = http://whatever.you.want/MOBY/Central >> >> I'm not sure if the Java libraries are sensitive to the content of the >> "whatever.you.want" section (or if they need a URI at all??) >> >> M >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > From groscurt at mpiz-koeln.mpg.de Fri Nov 30 11:23:06 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 12:23:06 +0100 Subject: [MOBY-dev] Using CentralDigestCachedImpl.... In-Reply-To: <47267E18.4010509@ucalgary.ca> References: <91C40642-83C2-4ECC-92C7-BB150BD700CA@farmbio.uu.se> <77B231CC-2BE8-4121-90A5-A6899C336C7D@farmbio.uu.se> <47267E18.4010509@ucalgary.ca> Message-ID: <200711301223.07171.groscurt@mpiz-koeln.mpg.de> Hi, I'm using CentralDigestCachedImpl for caching the datatypes and namespaces locally. CentralDigestCachedImpl cachedImpl = new CentralDigestCachedImpl("http://moby.ucalgary.ca/moby/MOBY-Central.pl","http://moby.ucalgary.ca/MOBY/Central", file.getAbsolutePath() ); cachedImpl.updateCache( CentralDigestCachedImpl.CACHE_PART_DATATYPES ); cachedImpl.updateCache( CentralDigestCachedImpl.CACHE_PART_NAMESPACES ); This works fine and re-calls use the local cache. But when I create a new MobyDataObject, it starts again to fetch the datatypes Fetching data type ontology from http://moby.ucalgary.ca/RESOURCES/MOBY-S/Objects So how do I tell it, that its already has these information ? the MobyDataObject can also have a Registry Object - so i guess that can help - but how to I link my CachedCentral with a Registry object ? Or is this otherwise solveable ? thx andreas From groscurt at mpiz-koeln.mpg.de Fri Nov 30 14:20:55 2007 From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth) Date: Fri, 30 Nov 2007 15:20:55 +0100 Subject: [MOBY-dev] Movement of Moby and Java Code In-Reply-To: <200711301223.07171.groscurt@mpiz-koeln.mpg.de> References: <91C40642-83C2-4ECC-92C7-BB150BD700CA@farmbio.uu.se> <47267E18.4010509@ucalgary.ca> <200711301223.07171.groscurt@mpiz-koeln.mpg.de> Message-ID: <200711301520.55828.groscurt@mpiz-koeln.mpg.de> HI, and another question.... In the CentralImpl class the two final variables DEFAULT_ENDPOINT and DEFAULT_NAMESPACE are defined and point to the 'old' MobyCentral. As this is currently not available some calls fail. A general question is: will this code be changed to point to the new central ? will the old URL be available and redirect to the new central ? Best andreas -- Andreas Groscurth Bioinformatics Developer Max Planck Institute for Plant Breeding Research Carl-von-Linn?-Weg 10 50829 Cologne Germany E-mail: ? ?groscurt at mpiz-koeln.mpg.de Phone: ? ?+49(0)221-5062-449 From martin.senger at gmail.com Fri Nov 30 15:03:46 2007 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 30 Nov 2007 15:03:46 +0000 Subject: [MOBY-dev] Movement of Moby and Java Code In-Reply-To: <200711301520.55828.groscurt@mpiz-koeln.mpg.de> References: <91C40642-83C2-4ECC-92C7-BB150BD700CA@farmbio.uu.se> <47267E18.4010509@ucalgary.ca> <200711301223.07171.groscurt@mpiz-koeln.mpg.de> <200711301520.55828.groscurt@mpiz-koeln.mpg.de> Message-ID: <4d93f07c0711300703g114c03a0mefad3ec08c780352@mail.gmail.com> > A general question is: will this code be changed to point to the new > central ? Yes, it will be changed (I will do it next week). No, it will not point to a new central :-) Instead, it will be dynamically filled from the data provided by a URL Mark gave us. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Nov 30 17:07:36 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 09:07:36 -0800 Subject: [MOBY-dev] It's worse than that... she's dead, Jim! Message-ID: Well, Moby Central is dead dead dead! We're not sure if it is a hard drive crash or a motherboard problem, but regardless, it doesn't look promising. I'm waiting on the definitive word from our sysadmin for how long it will take to fix. If it's more than a day or two, then I guess this makes the migration decision for us! I'm swiching the redirect on biomoby.org to point to the server in Calgary right now. If you have CVS updated your Perl libraries you will immediately start using the new registry when that happens. To migrate Taverna, edit the taverna/conf/mygrid.properties file to point to the new MOBY Central: http://moby.ucalgary.ca/moby/MOBY-Central.pl Gbrowse-moby is also running on the new server: http://moby.ucalgary.ca/gbrowse_moby There will be a variety of things that *don't* work - e.g. the registry encyclopedia, etc. but I think most of the core functionality is available on the new machine already. Of course, almost all of *my* services are going to be dead, since they were running on that machine. I'll try to get them running again ASAP. I'll keep you all updated throughout the day, and hopefully we'll know enough to make a final decision tonight. Best wishes! Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From markw at illuminae.com Fri Nov 30 17:39:42 2007 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 30 Nov 2007 09:39:42 -0800 Subject: [MOBY-dev] Things that don't work at the moment Message-ID: Hi, So, anything that relies on LSID resolution is broken (including Gbrowse-moby), since the LSID SRV record in the DNS is pointing to the old server. I've just contacted Chris D. at Open-Bio and asked him if he could update their DNS. Might take a while... M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital Tel: 604 682 2344 x62129 Fax: 604 806 9274 ***CONFIDENTIALITY NOTICE*** This electronic message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any dissemination, distribution or copying of this communication by unauthorized individuals is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and delete the original and all copies from your system. From gordonp at ucalgary.ca Fri Nov 30 18:01:56 2007 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 30 Nov 2007 11:01:56 -0700 Subject: [MOBY-dev] Movement of Moby and Java Code In-Reply-To: <4d93f07c0711300703g114c03a0mefad3ec08c780352@mail.gmail.com> References: <91C40642-83C2-4ECC-92C7-BB150BD700CA@farmbio.uu.se> <47267E18.4010509@ucalgary.ca> <200711301223.07171.groscurt@mpiz-koeln.mpg.de> <200711301520.55828.groscurt@mpiz-koeln.mpg.de> <4d93f07c0711300703g114c03a0mefad3ec08c780352@mail.gmail.com> Message-ID: <47505014.2080606@ucalgary.ca> In the interim, if you are using the org.biomoby.shared.data packages, you'll need to explicitly use the Calgary registry, e.g. Registry registry = new Registry("calgary", "http://moby.ucalgary.ca/moby/MOBY-Central.pl", "http://useless.domain.com/MOBY/Central"); MobyContentInstance contents = MobyDataUtils.fromXMLDocument(stream, registry); Martin Senger wrote: >> A general question is: will this code be changed to point to the new >> central ? >> > > > Yes, it will be changed (I will do it next week). > No, it will not point to a new central :-) Instead, it will be dynamically > filled from the data provided by a URL Mark gave us. > > Cheers, > Martin > >