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:
1010
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:
1010
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: