From duncan.hull at cs.man.ac.uk  Tue Feb  8 06:56:20 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue Feb  8 06:53:06 2005
Subject: [MOBY-dev] mobycentral down?
Message-ID: <4208A8E4.4040603@cs.man.ac.uk>

Dear moby-devvers

Is anyone else having a problem getting to 
http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl

???

Duncan
From senger at ebi.ac.uk  Tue Feb  8 07:04:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Feb  8 07:00:34 2005
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208A8E4.4040603@cs.man.ac.uk>
Message-ID: <Pine.LNX.4.44.0502081204260.5027-100000@bagheera.ebi.ac.uk>

> Is anyone else having a problem getting to 
> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
   Works fine for me (Tue Feb  8 12:04:42 GMT 2005).
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From sophie.durand at infobiogen.fr  Tue Feb  8 05:41:34 2005
From: sophie.durand at infobiogen.fr (Sophie Durand)
Date: Tue Feb  8 10:59:23 2005
Subject: [MOBY-dev] bug in MOBY::CommunSubs:getCrossReferences
Message-ID: <4208975E.6050201@infobiogen.fr>

Hello,

I have a problem while parsing the following moby output:

<?xml version='1.0' encoding='UTF-8'?><moby:MOBY
xmlns:moby='http://www.biomoby.org/moby'><moby:mobyContent
moby:authority='genoplante-info.infobiogen.fr'><moby:serviceNotes>GENOPLANTE 

PHYTOPROT. IDDN.FR.001.250004.000.S.P.2003.000.10300. This database, its
constitutive components and its documentation, are the intellectual
property of GENOPLANTE-VALOR.</moby:serviceNotes><moby:mobyData
moby:queryID='1'><moby:Collection
moby:articleName=''><moby:Simple><moby:Object
moby:namespace='AGI_LocusCode' moby:id='AT3G23130'
 ><CrossReference><moby:Object moby:namespace='PHYTOPROT_CLUSTER_Id' 
moby:id='148'
/></CrossReference></moby:Object></moby:Simple></moby:Collection></moby:mobyData></moby:mobyContent></moby:MOBY>

I'm using the Perl API with a genericServiceInputParser call and then a 
getCrossReferences call to obtain the cross reference. But in this case, 
I don't get any cross reference. If I delete the "moby:" namespaces like 
this :
<CrossReference><moby:Object namespace='PHYTOPROT_CLUSTER_Id'  id='148' 
/></CrossReference>
it works well.

So I looked in the code, and I modified the following function in 
MOBY::CommunSubs.pm, and then it works:

sub _makeObjectType {
     my ($xref) = @_;
     my $ns = $xref->getAttributeNode('namespace');
     $ns = $xref->getAttributeNode('moby:namespace') unless $ns;
     return undef unless $ns;
     my $id = $xref->getAttributeNode('id');
     $id = $xref->getAttributeNode('moby:id') unless $id;  # INSTEAD OF $ns
     return undef unless $id;
     my $XREF = MOBY::CrossReference->new(
         type => "object",
         namespace => $ns->getValue,
         id => $id->getValue,
      );
}

-- 
Sophie Durand
Ing?nieure en Bioinformatique
INRA / URGI chez Infobiogen
523, place des Terrasses de l'Agora
91000 Evry - FRANCE
From mwilkinson at mrl.ubc.ca  Tue Feb  8 12:21:46 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue Feb  8 11:38:29 2005
Subject: [moby] [MOBY-dev] bug in MOBY::CommunSubs:getCrossReferences
In-Reply-To: <4208975E.6050201@infobiogen.fr>
References: <4208975E.6050201@infobiogen.fr>
Message-ID: <1107883306.8689.75.camel@mobycentral.icapture.ubc.ca>

thanks!  Bug squashed.

M


On Tue, 2005-02-08 at 02:41, Sophie Durand wrote:
> Hello,
> 
> I have a problem while parsing the following moby output:
> 
> <?xml version='1.0' encoding='UTF-8'?><moby:MOBY
> xmlns:moby='http://www.biomoby.org/moby'><moby:mobyContent
> moby:authority='genoplante-info.infobiogen.fr'><moby:serviceNotes>GENOPLANTE 
> 
> PHYTOPROT. IDDN.FR.001.250004.000.S.P.2003.000.10300. This database, its
> constitutive components and its documentation, are the intellectual
> property of GENOPLANTE-VALOR.</moby:serviceNotes><moby:mobyData
> moby:queryID='1'><moby:Collection
> moby:articleName=''><moby:Simple><moby:Object
> moby:namespace='AGI_LocusCode' moby:id='AT3G23130'
>  ><CrossReference><moby:Object moby:namespace='PHYTOPROT_CLUSTER_Id' 
> moby:id='148'
> /></CrossReference></moby:Object></moby:Simple></moby:Collection></moby:mobyData></moby:mobyContent></moby:MOBY>
> 
> I'm using the Perl API with a genericServiceInputParser call and then a 
> getCrossReferences call to obtain the cross reference. But in this case, 
> I don't get any cross reference. If I delete the "moby:" namespaces like 
> this :
> <CrossReference><moby:Object namespace='PHYTOPROT_CLUSTER_Id'  id='148' 
> /></CrossReference>
> it works well.
> 
> So I looked in the code, and I modified the following function in 
> MOBY::CommunSubs.pm, and then it works:
> 
> sub _makeObjectType {
>      my ($xref) = @_;
>      my $ns = $xref->getAttributeNode('namespace');
>      $ns = $xref->getAttributeNode('moby:namespace') unless $ns;
>      return undef unless $ns;
>      my $id = $xref->getAttributeNode('id');
>      $id = $xref->getAttributeNode('moby:id') unless $id;  # INSTEAD OF $ns
>      return undef unless $id;
>      my $XREF = MOBY::CrossReference->new(
>          type => "object",
>          namespace => $ns->getValue,
>          id => $id->getValue,
>       );
> }
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada

From gss at ncgr.org  Tue Feb  8 12:35:46 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue Feb  8 12:31:26 2005
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208A8E4.4040603@cs.man.ac.uk>
References: <4208A8E4.4040603@cs.man.ac.uk>
Message-ID: <4208F872.3000105@ncgr.org>

Something indeed seems to be awry:

wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl

--10:30:24--  http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
           => `-'
Resolving mobycentral.cbr.nrc.ca... 198.166.4.151
Connecting to mobycentral.cbr.nrc.ca[198.166.4.151]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 411 Length Required
 2 Date: Tue, 08 Feb 2005 17:30:25 GMT
 3 Server: Apache/1.3.29 (Unix) mod_perl/1.29
 4 Connection: close
 5 Content-Type: text/plain
10:30:25 ERROR 411: Length Required.

// Gary

Duncan Hull wrote:

> Dear moby-devvers
>
> Is anyone else having a problem getting to 
> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
> ???
>
> Duncan
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
From senger at ebi.ac.uk  Tue Feb  8 12:47:26 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Feb  8 12:42:56 2005
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208F872.3000105@ncgr.org>
Message-ID: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>

> Something indeed seems to be awry:
> 
> wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
   Let me claim again: according my test client contacting moby central,
everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
that wget should work properly? Moby central responses may not be good if
you contact it withour any SOAP message.

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger@EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger

From edward.kawas at gmail.com  Tue Feb  8 12:49:40 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue Feb  8 12:45:20 2005
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
Message-ID: <4208fbb5.7748301d.273c.55f3@smtp.gmail.com>

I second Martins' claim.

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Tuesday, February 08, 2005 9:47 AM
> To: Core developer announcements
> Cc: Mark Wilkinson
> Subject: Re: [MOBY-dev] mobycentral down?
> 
> > Something indeed seems to be awry:
> >
> > wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-
> bin/MOBY05/mobycentral.pl
> >
>    Let me claim again: according my test client contacting
> moby central,
> everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why
> do you expect
> that wget should work properly? Moby central responses may
> not be good if
> you contact it withour any SOAP message.
> 
>    Martin
> 
> --
> Martin Senger
> 
> EMBL Outstation - Hinxton                Senger@EBI.ac.uk
> European Bioinformatics Institute        Phone: (+44) 1223
> 494636
> Wellcome Trust Genome Campus             (Switchboard:
> 494444)
> Hinxton                                  Fax  : (+44) 1223
> 494468
> Cambridge CB10 1SD
> United Kingdom
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From mwilkinson at mrl.ubc.ca  Tue Feb  8 13:32:08 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue Feb  8 12:48:22 2005
Subject: [moby] Re: [MOBY-dev] mobycentral down?
In-Reply-To: <4208F872.3000105@ncgr.org>
References: <4208A8E4.4040603@cs.man.ac.uk>  <4208F872.3000105@ncgr.org>
Message-ID: <1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>

Strange... I am having no problems with it today.  It passes all tests
both on the development and production server from a remote connection
to mobycentral.pl, and the CGI browser is working properly (local
connection).  

I do notice, however, that the services that rely on SeqHound are...
errr... not working properly is a mild way to say it ;-)  but that isn't
a MOBYCentral problem and I'm sure the SeqHound staff are already aware
of the problem.

...????  i dunno

I'll keep my eye on it for the rest of the day to see if i notice
anything unusual.  I wonder if it the same problem we have seen a few
times in the past few months with connections from Europe being
blocked??  We can't seem to track that one down - it is not happening on
our machines, we know that for sure... it is something elsewhere.

M



On Tue, 2005-02-08 at 09:35, Gary Schiltz wrote:
> Something indeed seems to be awry:
> 
> wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> 
> --10:30:24--  http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>            => `-'
> Resolving mobycentral.cbr.nrc.ca... 198.166.4.151
> Connecting to mobycentral.cbr.nrc.ca[198.166.4.151]:80... connected.
> HTTP request sent, awaiting response...
>  1 HTTP/1.1 411 Length Required
>  2 Date: Tue, 08 Feb 2005 17:30:25 GMT
>  3 Server: Apache/1.3.29 (Unix) mod_perl/1.29
>  4 Connection: close
>  5 Content-Type: text/plain
> 10:30:25 ERROR 411: Length Required.
> 
> // Gary
> 
> Duncan Hull wrote:
> 
> > Dear moby-devvers
> >
> > Is anyone else having a problem getting to 
> > http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> >
> > ???
> >
> > Duncan
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev@biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> >
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada

From gss at ncgr.org  Tue Feb  8 12:56:25 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue Feb  8 12:51:52 2005
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
Message-ID: <4208FD49.1080508@ncgr.org>

As someone famous must have said, "What was I thinking?", or "Never 
mind", or even more succinctly, "Duh" :-) I suppose I was thinking of 
the URL for the gbrowse interface to MOBY.

// Gary

Martin Senger wrote:

>>Something indeed seems to be awry:
>>
>>wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>>
>>
>   Let me claim again: according my test client contacting moby central,
>everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
>that wget should work properly? Moby central responses may not be good if
>you contact it withour any SOAP message.
>
>   Martin
>
>
From duncan.hull at cs.man.ac.uk  Tue Feb  8 13:18:49 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue Feb  8 13:17:58 2005
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>
References: <4208A8E4.4040603@cs.man.ac.uk> <4208F872.3000105@ncgr.org>
	<1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42090289.8010001@cs.man.ac.uk>

dear moby-devvers

re: my original message. For the record, mobycentral was temporarily 
unavailable from within Taverna, which may have been a local 
(Manchester) problem.

Its accessible again now...


Duncan

http://taverna.sourceforge.net/


From mwilkinson at mrl.ubc.ca  Tue Feb  8 14:06:41 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue Feb  8 13:22:57 2005
Subject: [moby] Re: [MOBY-dev] mobycentral down?
In-Reply-To: <4208FD49.1080508@ncgr.org>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
	<4208FD49.1080508@ncgr.org>
Message-ID: <1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>

I think the correct quote is:

"Doh!"

	H.J.Simpson




On Tue, 2005-02-08 at 09:56, Gary Schiltz wrote:
> As someone famous must have said, "What was I thinking?", or "Never 
> mind", or even more succinctly, "Duh" :-) I suppose I was thinking of 
> the URL for the gbrowse interface to MOBY.
> 
> // Gary
> 
> Martin Senger wrote:
> 
> >>Something indeed seems to be awry:
> >>
> >>wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> >>
> >>
> >   Let me claim again: according my test client contacting moby central,
> >everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
> >that wget should work properly? Moby central responses may not be good if
> >you contact it withour any SOAP message.
> >
> >   Martin
> >
> >
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada

From duncan.hull at cs.man.ac.uk  Tue Feb  8 14:01:02 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue Feb  8 13:56:42 2005
Subject: [MOBY-dev] Mobycentral D'oh?
In-Reply-To: <1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>	<4208FD49.1080508@ncgr.org>
	<1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42090C6E.8090902@cs.man.ac.uk>

Mark

Mark Wilkinson wrote:

>I think the correct quote is: "Doh!" 	H.J.Simpson
>  
>
Can't find it in Pubmed
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=pubmed&cmd=search&term=Simpson+HJ

Do you have the year/journal of publication? :)


Duncan
From mwilkinson at mrl.ubc.ca  Wed Feb  9 14:54:38 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Feb  9 14:10:52 2005
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>

Hi MOBYers!

It's getting to that time again - time for the next (but hopefully not
last... touch wood!) BioMOBY developers meeting!

Due to overwhelming requests I am happy to host it here in Vancouver
again.  Alternately, and at higher cost, we could host it in a more
exotic location such as the spectacular Whistler Ski Resort (site of the
2010 winter olympics - about 1.5 hours north of Vancouver).

The dates are pretty limited.  It appears that the first weekend of May
(7th and 8th) is clear of other conferences that people might want to
attend.

Keeping with tradition, I will be using my Genome Canada grant to pay
for as much of the local expenses as I can afford, so hopefully the
charge to each of you will be primarily for travel, with only a little
bit to cover room and board.

So... a few questions:

1)  Are the dates (May 7-8) going to work for the majority of you core
developers?

2)  Do you want to meet in Vancouver, or should we make our potentially
last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
Rebecca, we can play hackeysac in either location ;-) )

3)  *** Can people please contact me ASAP indicating their interest in
attending so that I can ballpark the expenses and work out how much I
can afford to supplement from my grant ***

4)  Is there now sufficient interest in MOBY that it is worth having
back-to-back developers and implementers meetings?  If you are not a
"core developer", but would be interested in attending a one-day
hands-on meeting with people who have experience in building MOBY
Services please let me know.  If there is sufficient interest I'll see
if I can arrange something like this.


Looking forward to seeing you all again soon!

Mark


-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada

From simont at mcw.edu  Mon Feb 14 23:03:15 2005
From: simont at mcw.edu (Twigger Simon)
Date: Mon Feb 14 22:58:39 2005
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
In-Reply-To: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>
References: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>
Message-ID: <849AE9B6-7F06-11D9-83B7-000A959D1D82@mcw.edu>

Hi Mark,

Sign me up, the 7/8th of May look good and Im willing to go to a blow 
out meeting or a normal one. :) We are working on some java axis 
libraries to make Java services easier to create. We have prototype 
code in place at the moment but have just brought on board a java guru 
so Im having him look things over and give his blessing before we 
inflict them on the world. If we have an agenda for the potential 
implementers meeting I'd like to see if I can interest a few more 
people. We see a lot of promise in web services in general and MOBY in 
particular and Im hoping I can get some more of our teams to buy in, 
particularly when they see that their data can be made available via 
Taverna, etc. for free. Any guesstimates of the costs when you have 
some idea would be welcome so I can see who I can afford to bring 
along.

There is an increasing interest in developing ontologies, addressing 
datasharing, etc. in the cardiovascular arena here in the US and I 
would also be interested in chatting with you some more about your 
plans for CardioSHARE and how we might align our work at MCW to achieve 
this common goal.

Cheers,

	Simon.


On Feb 9, 2005, at 1:54 PM, Mark Wilkinson wrote:

> Hi MOBYers!
>
> It's getting to that time again - time for the next (but hopefully not
> last... touch wood!) BioMOBY developers meeting!
>
> Due to overwhelming requests I am happy to host it here in Vancouver
> again.  Alternately, and at higher cost, we could host it in a more
> exotic location such as the spectacular Whistler Ski Resort (site of 
> the
> 2010 winter olympics - about 1.5 hours north of Vancouver).
>
> The dates are pretty limited.  It appears that the first weekend of May
> (7th and 8th) is clear of other conferences that people might want to
> attend.
>
> Keeping with tradition, I will be using my Genome Canada grant to pay
> for as much of the local expenses as I can afford, so hopefully the
> charge to each of you will be primarily for travel, with only a little
> bit to cover room and board.
>
> So... a few questions:
>
> 1)  Are the dates (May 7-8) going to work for the majority of you core
> developers?
>
> 2)  Do you want to meet in Vancouver, or should we make our potentially
> last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
> Rebecca, we can play hackeysac in either location ;-) )
>
> 3)  *** Can people please contact me ASAP indicating their interest in
> attending so that I can ballpark the expenses and work out how much I
> can afford to supplement from my grant ***
>
> 4)  Is there now sufficient interest in MOBY that it is worth having
> back-to-back developers and implementers meetings?  If you are not a
> "core developer", but would be interested in attending a one-day
> hands-on meeting with people who have experience in building MOBY
> Services please let me know.  If there is sufficient interest I'll see
> if I can arrange something like this.
>
>
> Looking forward to seeing you all again soon!
>
> Mark
>
>
> -- 
> Mark Wilkinson
> Assistant Professor (Bioinformatics)
> Dept. Medical Genetics, UBC, Canada
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw

From mwilkinson at mobile.rogers.com  Mon Feb 14 23:04:05 2005
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Mon Feb 14 23:01:58 2005
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <200502150401.j1F41oKr013946@portal.open-bio.org>

Hey Simon,

Please post to the mailing list with your moby java activities since I have several people doing similar things - no point in duplicating effort if we can split the work :-)

I'll be posting the URL for the registration page before weeks end - I'm just waiting for a quote on the room rate.

Cheers!

M

-----Original Message-----
From: Twigger Simon <simont@mcw.edu>
Date: Mon, 14 Feb 2005 22:03:15 
To:Core developer announcements <moby-dev@portal.open-bio.org>
Subject: Re: [MOBY-dev] BioMOBY developers meeting pre-announcement

Hi Mark,

Sign me up, the 7/8th of May look good and Im willing to go to a blow 
out meeting or a normal one. :) We are working on some java axis 
libraries to make Java services easier to create. We have prototype 
code in place at the moment but have just brought on board a java guru 
so Im having him look things over and give his blessing before we 
inflict them on the world. If we have an agenda for the potential 
implementers meeting I'd like to see if I can interest a few more 
people. We see a lot of promise in web services in general and MOBY in 
particular and Im hoping I can get some more of our teams to buy in, 
particularly when they see that their data can be made available via 
Taverna, etc. for free. Any guesstimates of the costs when you have 
some idea would be welcome so I can see who I can afford to bring 
along.

There is an increasing interest in developing ontologies, addressing 
datasharing, etc. in the cardiovascular arena here in the US and I 
would also be interested in chatting with you some more about your 
plans for CardioSHARE and how we might align our work at MCW to achieve 
this common goal.

Cheers,

	Simon.


On Feb 9, 2005, at 1:54 PM, Mark Wilkinson wrote:

> Hi MOBYers!
>
> It's getting to that time again - time for the next (but hopefully not
> last... touch wood!) BioMOBY developers meeting!
>
> Due to overwhelming requests I am happy to host it here in Vancouver
> again.  Alternately, and at higher cost, we could host it in a more
> exotic location such as the spectacular Whistler Ski Resort (site of 
> the
> 2010 winter olympics - about 1.5 hours north of Vancouver).
>
> The dates are pretty limited.  It appears that the first weekend of May
> (7th and 8th) is clear of other conferences that people might want to
> attend.
>
> Keeping with tradition, I will be using my Genome Canada grant to pay
> for as much of the local expenses as I can afford, so hopefully the
> charge to each of you will be primarily for travel, with only a little
> bit to cover room and board.
>
> So... a few questions:
>
> 1)  Are the dates (May 7-8) going to work for the majority of you core
> developers?
>
> 2)  Do you want to meet in Vancouver, or should we make our potentially
> last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
> Rebecca, we can play hackeysac in either location ;-) )
>
> 3)  *** Can people please contact me ASAP indicating their interest in
> attending so that I can ballpark the expenses and work out how much I
> can afford to supplement from my grant ***
>
> 4)  Is there now sufficient interest in MOBY that it is worth having
> back-to-back developers and implementers meetings?  If you are not a
> "core developer", but would be interested in attending a one-day
> hands-on meeting with people who have experience in building MOBY
> Services please let me know.  If there is sufficient interest I'll see
> if I can arrange something like this.
>
>
> Looking forward to seeing you all again soon!
>
> Mark
>
>
> -- 
> Mark Wilkinson
> Assistant Professor (Bioinformatics)
> Dept. Medical Genetics, UBC, Canada
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw

_______________________________________________
MOBY-dev mailing list
MOBY-dev@biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
From simont at mcw.edu  Tue Feb 15 00:18:58 2005
From: simont at mcw.edu (Twigger Simon)
Date: Tue Feb 15 00:14:20 2005
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
In-Reply-To: <200502150401.j1F41oKr013946@portal.open-bio.org>
References: <200502150401.j1F41oKr013946@portal.open-bio.org>
Message-ID: <186E1ACA-7F11-11D9-83B7-000A959D1D82@mcw.edu>

Hi Mark,

I'll see how things are looking and get the documentation together. The 
basic goal was to create some basic classes to simplify access to the 
MOBY payload of a webservice call so that we could concentrate on 
getting the services up rather than parsing the MOBY XML and rewriting 
the XML prior to returning the result. We've been using Axis to handle 
the webservice part of the equation, we've created some core classes 
and have a simple test service prototype that we are gearing up to do 
something meaningful with. If you have people doing similar things it 
would be great to get an overview of what you are working on too so we 
can divide and conquer where possible.

Simon.


On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:

> Hey Simon,
>
> Please post to the mailing list with your moby java activities since I 
> have several people doing similar things - no point in duplicating 
> effort if we can split the work :-)
>
> I'll be posting the URL for the registration page before weeks end - 
> I'm just waiting for a quote on the room rate.
>
> Cheers!
>
> M
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw


--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw

From ywong at infobiogen.fr  Tue Feb 15 03:18:47 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Tue Feb 15 03:15:40 2005
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <32818.195.221.101.193.1108455527.squirrel@195.221.101.193>

Hi,
  I know that someone at mips (Octave Noubibou) is also working on that
field, on my side, I have an API in Java (based on the Python API) that
helps me to build moby webservices (with axis or j2ee)

> Hi Mark,
>
> I'll see how things are looking and get the documentation together. The
> basic goal was to create some basic classes to simplify access to the
> MOBY payload of a webservice call so that we could concentrate on
> getting the services up rather than parsing the MOBY XML and rewriting
> the XML prior to returning the result. We've been using Axis to handle
> the webservice part of the equation, we've created some core classes
> and have a simple test service prototype that we are gearing up to do
> something meaningful with. If you have people doing similar things it
> would be great to get an overview of what you are working on too so we
> can divide and conquer where possible.
>
> Simon.
>
>
> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>
>> Hey Simon,
>>
>> Please post to the mailing list with your moby java activities since I
>> have several people doing similar things - no point in duplicating
>> effort if we can split the work :-)
>>
>> I'll be posting the URL for the registration page before weeks end -
>> I'm just waiting for a quote on the room rate.
>>
>> Cheers!
>>
>> M
> --
>
> Simon N. Twigger, Ph.D.
> Assistant Professor, Department of Physiology
> Medical College of Wisconsin
> 8701 Watertown Plank Road,
> Milwaukee, WI, USA
> tel: 414-456-8802
> fax: 414-456-6595
> AIM/iChat: simontatmcw
>
>
> --
>
> Simon N. Twigger, Ph.D.
> Assistant Professor, Department of Physiology
> Medical College of Wisconsin
> 8701 Watertown Plank Road,
> Milwaukee, WI, USA
> tel: 414-456-8802
> fax: 414-456-6595
> AIM/iChat: simontatmcw
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


From mwilkinson at mrl.ubc.ca  Tue Feb 15 10:01:50 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue Feb 15 08:57:49 2005
Subject: [MOBY-dev] MOBY Service code developments
Message-ID: <1108479710.24515.22.camel@mobycentral.icapture.ubc.ca>

I think both Ben and Eddie are working on things like this as well.  Ben
is at a course doing "wet" work (ugh!) this week, but Eddie should be
on-line somewhere.

Xref'ing with each other early on would probably be worthwhile - divide
and conquer :-)

I found in Perl that the code used by services was often identical to
that used by clients, so I ended up putting these kinds of routines into
a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
considering that rather than coding service/client specific modules...
if you haven't already.

M


-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
-------------- next part --------------
An embedded message was scrubbed...
From: ywong@infobiogen.fr
Subject: [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
Date: Tue, 15 Feb 2005 09:18:47 +0100 (CET)
Size: 4684
Url: http://biomoby.org/pipermail/moby-dev/attachments/20050215/0c9de6b1/attachment-0001.eml
From bmg at sfu.ca  Tue Feb 15 11:16:16 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Tue Feb 15 11:13:12 2005
Subject: [MOBY-dev] java api
Message-ID: <42122050.400@sfu.ca>

Hi moby-dev,

 I think this from Simon sums up something that would be handy for 
everyone in the jMoby group - both client and service providers -(that 
hasn't written their own version already).

The
> basic goal was to create some basic classes to simplify access to the
> MOBY payload of a webservice call so that we could concentrate on
> getting the services up rather than parsing the MOBY XML and rewriting
> the XML prior to returning the result.

I don't really know the protocol here, but perhaps someone could post an 
Interface that others could check out, comment on, and code to?  Or 
perhaps some one already has a good solution?

-Ben


------------------------------------------------------------------------

Subject:
MOBY Service code developments
From:
Mark Wilkinson <mwilkinson@mrl.ubc.ca>
Date:
Tue, 15 Feb 2005 07:01:50 -0800

To:
Ben Good <bgood@mrl.ubc.ca>, Eddie Kawas <ed.kawas@gmail.com>, mobydev 
<moby-dev@biomoby.org>


I think both Ben and Eddie are working on things like this as well.  Ben
is at a course doing "wet" work (ugh!) this week, but Eddie should be
on-line somewhere.

Xref'ing with each other early on would probably be worthwhile - divide
and conquer  :-) 

I found in Perl that the code used by services was often identical to
that used by clients, so I ended up putting these kinds of routines into
a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
considering that rather than coding service/client specific modules...
if you haven't already.

M


-- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical 
Genetics, UBC, Canada


------------------------------------------------------------------------

Subject:
[moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
From:
ywong@infobiogen.fr
Date:
Tue, 15 Feb 2005 09:18:47 +0100 (CET)

To:
"Core developer announcements" <moby-dev@portal.open-bio.org>


Hi,
  I know that someone at mips (Octave Noubibou) is also working on that
field, on my side, I have an API in Java (based on the Python API) that
helps me to build moby webservices (with axis or j2ee)


>> Hi Mark,
>>
>> I'll see how things are looking and get the documentation together. The
>> basic goal was to create some basic classes to simplify access to the
>> MOBY payload of a webservice call so that we could concentrate on
>> getting the services up rather than parsing the MOBY XML and rewriting
>> the XML prior to returning the result. We've been using Axis to handle
>> the webservice part of the equation, we've created some core classes
>> and have a simple test service prototype that we are gearing up to do
>> something meaningful with. If you have people doing similar things it
>> would be great to get an overview of what you are working on too so we
>> can divide and conquer where possible.
>>
>> Simon.
>>
>>
>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>
>  
>
>>>> Hey Simon,
>>>>
>>>> Please post to the mailing list with your moby java activities since I
>>>> have several people doing similar things - no point in duplicating
>>>> effort if we can split the work  :-) 
>>>>
>>>> I'll be posting the URL for the registration page before weeks end -
>>>> I'm just waiting for a quote on the room rate.
>>>>
>>>> Cheers!
>>>>
>>>> M
>>    
>>
>> --
>>
>> Simon N. Twigger, Ph.D.
>> Assistant Professor, Department of Physiology
>> Medical College of Wisconsin
>> 8701 Watertown Plank Road,
>> Milwaukee, WI, USA
>> tel: 414-456-8802
>> fax: 414-456-6595
>> AIM/iChat: simontatmcw
>>
>>
>> --
>>
>> Simon N. Twigger, Ph.D.
>> Assistant Professor, Department of Physiology
>> Medical College of Wisconsin
>> 8701 Watertown Plank Road,
>> Milwaukee, WI, USA
>> tel: 414-456-8802
>> fax: 414-456-6595
>> AIM/iChat: simontatmcw
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>  
>


_______________________________________________
MOBY-dev mailing list
MOBY-dev@biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

From edward.kawas at gmail.com  Tue Feb 15 11:35:14 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue Feb 15 12:22:22 2005
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
Message-ID: <421224c7.7ea94a2b.4fa7.0513@smtp.gmail.com>

Hi,

Ben and I just coded some methods that given certain inputs
create DOM elements, parse them, etc for Moby Objects. I
attached the javadoc for them to this message (ignore the
package name and we probably will rethink the method names,
but just as an example take a look). 

Is this something similar to what people would like for
services? I think that Ben is right and that we should
create some interfaces containing methods that people would
find useful and then we could code them. Right now I think
that there is an awful lot of code duplication.

Eddie

> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Benjamin
> Good
> Sent: Tuesday, February 15, 2005 8:16 AM
> To: moby-dev@biomoby.org
> Subject: [MOBY-dev] java api
> 
> Hi moby-dev,
> 
>  I think this from Simon sums up something that would be
> handy for
> everyone in the jMoby group - both client and service
> providers -(that
> hasn't written their own version already).
> 
> The
> > basic goal was to create some basic classes to simplify
> access to the
> > MOBY payload of a webservice call so that we could
> concentrate on
> > getting the services up rather than parsing the MOBY XML
> and rewriting
> > the XML prior to returning the result.
> 
> I don't really know the protocol here, but perhaps someone
> could post an
> Interface that others could check out, comment on, and
> code to?  Or
> perhaps some one already has a good solution?
> 
> -Ben
> 
> 
> ----------------------------------------------------------
> --------------
> 
> Subject:
> MOBY Service code developments
> From:
> Mark Wilkinson <mwilkinson@mrl.ubc.ca>
> Date:
> Tue, 15 Feb 2005 07:01:50 -0800
> 
> To:
> Ben Good <bgood@mrl.ubc.ca>, Eddie Kawas
> <ed.kawas@gmail.com>, mobydev
> <moby-dev@biomoby.org>
> 
> 
> I think both Ben and Eddie are working on things like this
> as well.  Ben
> is at a course doing "wet" work (ugh!) this week, but
> Eddie should be
> on-line somewhere.
> 
> Xref'ing with each other early on would probably be
> worthwhile - divide
> and conquer  :-)
> 
> I found in Perl that the code used by services was often
> identical to
> that used by clients, so I ended up putting these kinds of
> routines into
> a "neutral" location (MOBY::CommonSubs).  It's probably
> worthwhile
> considering that rather than coding service/client
> specific modules...
> if you haven't already.
> 
> M
> 
> 
> -- Mark Wilkinson Assistant Professor (Bioinformatics)
> Dept. Medical
> Genetics, UBC, Canada
> 
> 
> ----------------------------------------------------------
> --------------
> 
> Subject:
> [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-
> announcement
> From:
> ywong@infobiogen.fr
> Date:
> Tue, 15 Feb 2005 09:18:47 +0100 (CET)
> 
> To:
> "Core developer announcements" <moby-dev@portal.open-
> bio.org>
> 
> 
> Hi,
>   I know that someone at mips (Octave Noubibou) is also
> working on that
> field, on my side, I have an API in Java (based on the
> Python API) that
> helps me to build moby webservices (with axis or j2ee)
> 
> 
> >> Hi Mark,
> >>
> >> I'll see how things are looking and get the
> documentation together. The
> >> basic goal was to create some basic classes to simplify
> access to the
> >> MOBY payload of a webservice call so that we could
> concentrate on
> >> getting the services up rather than parsing the MOBY
> XML and rewriting
> >> the XML prior to returning the result. We've been using
> Axis to handle
> >> the webservice part of the equation, we've created some
> core classes
> >> and have a simple test service prototype that we are
> gearing up to do
> >> something meaningful with. If you have people doing
> similar things it
> >> would be great to get an overview of what you are
> working on too so we
> >> can divide and conquer where possible.
> >>
> >> Simon.
> >>
> >>
> >> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
> >>
> >
> >
> >>>> Hey Simon,
> >>>>
> >>>> Please post to the mailing list with your moby java
> activities since I
> >>>> have several people doing similar things - no point
> in duplicating
> >>>> effort if we can split the work  :-)
> >>>>
> >>>> I'll be posting the URL for the registration page
> before weeks end -
> >>>> I'm just waiting for a quote on the room rate.
> >>>>
> >>>> Cheers!
> >>>>
> >>>> M
> >>
> >>
> >> --
> >>
> >> Simon N. Twigger, Ph.D.
> >> Assistant Professor, Department of Physiology
> >> Medical College of Wisconsin
> >> 8701 Watertown Plank Road,
> >> Milwaukee, WI, USA
> >> tel: 414-456-8802
> >> fax: 414-456-6595
> >> AIM/iChat: simontatmcw
> >>
> >>
> >> --
> >>
> >> Simon N. Twigger, Ph.D.
> >> Assistant Professor, Department of Physiology
> >> Medical College of Wisconsin
> >> 8701 Watertown Plank Road,
> >> Milwaukee, WI, USA
> >> tel: 414-456-8802
> >> fax: 414-456-6595
> >> AIM/iChat: simontatmcw
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev@biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> >
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-------------- next part --------------

-------------- next part --------------

From gordonp at ucalgary.ca  Tue Feb 15 12:37:21 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue Feb 15 12:32:40 2005
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
References: <42122050.400@sfu.ca>
Message-ID: <42123351.6090206@ucalgary.ca>

Hi all,

    I'm replying directly to you since the mailing list gets confused 
over my various e-mail addresses and bounces messages (I'm trying to fix 
this).  We should definitely open a dialog even before the May meeting 
because it seems that a lot of people are trying to acheive the same 
goals, and I think  most of the code to do these things are already in 
place.  For parsing and outputting data, org.biomoby.client.MobyRequest 
should be able to act as both the client and server code as MOBY 
messages are the same from a formatting point of view.  MobyRequest is 
nice and robust too, because it uses namespace-aware XPath to grab the 
relevant payload data.

In principle you should also not need to touch the XML directly, and we 
are almost to that stage.  Martin created the base type classes for when 
he started the registration side of things in Java:

org.biomoby.shared.MobyData 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyData.html>
org.biomoby.shared.MobyPrimaryDataSimple 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyPrimaryDataSimple.html>
org.biomoby.shared.MobyPrimaryDataSet 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyPrimaryDataSet.html>

I then extended these classes for actual instances of MOBY data (so they 
can conveniently be used for querying MOBY central and running services):

*org.biomoby.shared.MobyDataSetInstance*
org.biomoby.shared.MobyDataSimpleInstance 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyDataSimpleInstance.html>*
**org.biomoby.shared.MobyDataFloat (arbitrary precision)*
*org.biomoby.shared.MobyDataInt (arbitrary precision)*
*org.biomoby.shared.MobyDataString

*And a convenience class for otherwise painful to parse data (ISO 8601):*

**org.biomoby.shared.MobyDataDateTime*

Since an object is always made up fundamentally of the base classes 
object, string, int and float, there should be no need to generate any 
more classes to hold the data.  The only thing that remains is defining 
the methods in MobyDataSimpleInstance to set the data members for 
composite objects (maybe addMember(MobyDataSimpleInstance)?) and perhaps 
do a run-time check against MOBY Central that the data type given in 
setDataType is fullfilled before to XML() is called.

I was thinking something like this (PDGJOB is probably the most complex 
objects registered right now):

MobyDataSimpleInstance mdsi = new MobyDataSimpleInstance(new MobyDataType("PDGJOB"), "random object name", "some object id");
mdsi.addMember(new MobyDataString("answerService", "put your favorite answer service name here"));
mdsi.addMember(new MobyDataString("authURI", "http://my.great.domain.org/"));

GregorianCalendar gc = new GregorianCalendar();
gc.add(Calendar.MINUTE, 10); // Time out in 10 minutes
mdsi.addMember(new MobyDataDateTime("timeout", gc);

mdsi.addMember(new MobyDataString("killcode", "12345");
mdsi.addMember(new MobyDataString("killService", "put your favorite kill service name here");


As  service provider, to get the MOBY enveloped required to send this 
back to a client we call:

Central worker = new CentralImpl ();
MobyRequest mr = new MobyRequest(worker);
String responseXML = mr.convertMOBYDataToMOBYRequest(mdsis);
/* proceed to send this response back through the SOAP call you've 
received to start this code execution*/

If we are the client and we were SENDING this data instead, we can 
simply use the MobyRequest built-in SOAP handling:

mr.setInput(mdsi);
Vector output = mr.invokeService();


My CDN$0.02 :-)

Paul


Benjamin Good wrote:

> Hi moby-dev,
>
> I think this from Simon sums up something that would be handy for 
> everyone in the jMoby group - both client and service providers -(that 
> hasn't written their own version already).
>
> The
>
>> basic goal was to create some basic classes to simplify access to the
>> MOBY payload of a webservice call so that we could concentrate on
>> getting the services up rather than parsing the MOBY XML and rewriting
>> the XML prior to returning the result.
>
>
> I don't really know the protocol here, but perhaps someone could post 
> an Interface that others could check out, comment on, and code to?  Or 
> perhaps some one already has a good solution?
>
> -Ben
>
>
> ------------------------------------------------------------------------
>
> Subject:
> MOBY Service code developments
> From:
> Mark Wilkinson <mwilkinson@mrl.ubc.ca>
> Date:
> Tue, 15 Feb 2005 07:01:50 -0800
>
> To:
> Ben Good <bgood@mrl.ubc.ca>, Eddie Kawas <ed.kawas@gmail.com>, mobydev 
> <moby-dev@biomoby.org>
>
>
> I think both Ben and Eddie are working on things like this as well.  Ben
> is at a course doing "wet" work (ugh!) this week, but Eddie should be
> on-line somewhere.
>
> Xref'ing with each other early on would probably be worthwhile - divide
> and conquer  :-)
> I found in Perl that the code used by services was often identical to
> that used by clients, so I ended up putting these kinds of routines into
> a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
> considering that rather than coding service/client specific modules...
> if you haven't already.
>
> M
>
>
> -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical 
> Genetics, UBC, Canada
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
> From:
> ywong@infobiogen.fr
> Date:
> Tue, 15 Feb 2005 09:18:47 +0100 (CET)
>
> To:
> "Core developer announcements" <moby-dev@portal.open-bio.org>
>
>
> Hi,
>  I know that someone at mips (Octave Noubibou) is also working on that
> field, on my side, I have an API in Java (based on the Python API) that
> helps me to build moby webservices (with axis or j2ee)
>
>
>>> Hi Mark,
>>>
>>> I'll see how things are looking and get the documentation together. The
>>> basic goal was to create some basic classes to simplify access to the
>>> MOBY payload of a webservice call so that we could concentrate on
>>> getting the services up rather than parsing the MOBY XML and rewriting
>>> the XML prior to returning the result. We've been using Axis to handle
>>> the webservice part of the equation, we've created some core classes
>>> and have a simple test service prototype that we are gearing up to do
>>> something meaningful with. If you have people doing similar things it
>>> would be great to get an overview of what you are working on too so we
>>> can divide and conquer where possible.
>>>
>>> Simon.
>>>
>>>
>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>
>>  
>>
>>>>> Hey Simon,
>>>>>
>>>>> Please post to the mailing list with your moby java activities 
>>>>> since I
>>>>> have several people doing similar things - no point in duplicating
>>>>> effort if we can split the work  :-)
>>>>> I'll be posting the URL for the registration page before weeks end -
>>>>> I'm just waiting for a quote on the room rate.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> M
>>>>
>>>   
>>> -- 
>>>
>>> Simon N. Twigger, Ph.D.
>>> Assistant Professor, Department of Physiology
>>> Medical College of Wisconsin
>>> 8701 Watertown Plank Road,
>>> Milwaukee, WI, USA
>>> tel: 414-456-8802
>>> fax: 414-456-6595
>>> AIM/iChat: simontatmcw
>>>
>>>
>>> -- 
>>>
>>> Simon N. Twigger, Ph.D.
>>> Assistant Professor, Department of Physiology
>>> Medical College of Wisconsin
>>> 8701 Watertown Plank Road,
>>> Milwaukee, WI, USA
>>> tel: 414-456-8802
>>> fax: 414-456-6595
>>> AIM/iChat: simontatmcw
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev@biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>  
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>

From gordonp at ucalgary.ca  Tue Feb 15 12:53:11 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue Feb 15 12:48:25 2005
Subject: [MOBY-dev] java api
In-Reply-To: <42123351.6090206@ucalgary.ca>
References: <42122050.400@sfu.ca> <42123351.6090206@ucalgary.ca>
Message-ID: <42123707.7060504@ucalgary.ca>

Hi Eddie,

    The attchment was blank for we, can you resend it directly?  Perhaps 
we could integrate this code into MobyDataSimpleInstance.getMembers() 
and MobyDataSimpleInstance.getMember(String name) methods?  Also, there 
was a typo in my example, it should have read:

String responseXML = mr.convertMOBYDataToMOBYRequest(mdsi, null);

Cheers!

Paul


From edward.kawas at gmail.com  Tue Feb 15 13:01:52 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue Feb 15 12:57:10 2005
Subject: [MOBY-dev] java api
In-Reply-To: <42123707.7060504@ucalgary.ca>
Message-ID: <42123912.362bff4b.58cb.30c8@smtp.gmail.com>

Try: 
http://mobycentral.cbr.nrc.ca/applets/MobyObjectPrimitiveExt
ractor.html

and

http://mobycentral.cbr.nrc.ca/applets/Triples.html

Probably integrating this into MobyDataSimpleInstance would
be a good idea.

Eddie
> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Paul Gordon
> Sent: Tuesday, February 15, 2005 9:53 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] java api
> 
> Hi Eddie,
> 
>     The attchment was blank for we, can you resend it
> directly?  Perhaps
> we could integrate this code into
> MobyDataSimpleInstance.getMembers()
> and MobyDataSimpleInstance.getMember(String name) methods?
> Also, there
> was a typo in my example, it should have read:
> 
> String responseXML = mr.convertMOBYDataToMOBYRequest(mdsi,
> null);
> 
> Cheers!
> 
> Paul
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev

From octave.noubibou at gsf.de  Wed Feb 16 06:19:09 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Wed Feb 16 06:11:27 2005
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
References: <42122050.400@sfu.ca>
Message-ID: <42132C2D.4010200@gsf.de>

Hi all,

as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since  
3  months  now. 
one of my first tasks was to provide a generic API to  simplify access 
to the pameters (queryID, namespace, id)
one needs from the moby input xml to run the services and also methods 
to generate moby conform xml result.

I have used DOM4J and XPATH to implement concrete classes for this purpose.
At the moment all you need to get your parameters is to use the method 
"allParsedData(inputxml)" no matter how complex the inputxml is.
This method return a vector of the form e.g.:

(((queryID1,ns,id))) for a simple type

or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a 
collection
 
or 
(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))  
for an input with 2 invocations, the first been a collection and the 
second a simple type.

currently i do not handle secondary articles, but this should not be 
difficult.

we habe tried in our java services and everything seems to be ok.

i am commenting the code now. once it is finished, i will like to share 
it with you for comment or rectification and of course use.
Is there any possibility to upload this in central repository?

best regards

octave

>
>
> Hi,
>  I know that someone at mips (Octave Noubibou) is also working on that
> field, on my side, I have an API in Java (based on the Python API) that
> helps me to build moby webservices (with axis or j2ee)
>
>
>>> Hi Mark,
>>>
>>> I'll see how things are looking and get the documentation together. The
>>> basic goal was to create some basic classes to simplify access to the
>>> MOBY payload of a webservice call so that we could concentrate on
>>> getting the services up rather than parsing the MOBY XML and rewriting
>>> the XML prior to returning the result. We've been using Axis to handle
>>> the webservice part of the equation, we've created some core classes
>>> and have a simple test service prototype that we are gearing up to do
>>> something meaningful with. If you have people doing similar things it
>>> would be great to get an overview of what you are working on too so we
>>> can divide and conquer where possible.
>>>
>>> Simon.
>>>
>>>
>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>

From ywong at infobiogen.fr  Wed Feb 16 08:02:14 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Wed Feb 16 07:57:34 2005
Subject: [MOBY-dev] java api
In-Reply-To: <42132C2D.4010200@gsf.de>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
Message-ID: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>

Hi,
  My API was based on my Python API and uses Xerces library (but can use
any DOM API compatible library) and as for the Python library, was
intended to be generic:

  XML Moby String <-> Java Objects

  People should only use java object and serialize their results in moby
XML .

  The only thing it doesn't support (yet) is the PIB. It is also intended
to ease the building of java webservices without being tied to any
webservice's API (j2ee or axis or anything else)

  It can also execute moby webservices (client interface) but doesn't
support registration of objects/services to the bioMoby directory.

  For instance, the documentation of the API is just in plain javadoc  and
there are just two examples (client querying a bioMoby webservice and a
server serving moby contents)

  The client API can query the bioMoby directory (find a service)

  I can send the source and documentation to whom it may concern but
consider the code to be beta quality code :p ...

one example of usage:

    public String aHelloWorld(String mobyContent) throws
MobyParserException {
        MobyContent mobyInput=new MobyContent();
        MobyContent mobyOutput=new MobyContent(this.authority, this.notes);

        mobyInput.fromXML(mobyContent);

        /*browse all the queries */
        Iterator iterator=mobyInput.keys().iterator();

        while (iterator.hasNext()) {
            String queryID=(String)iterator.next();

            MobyQuery mq=mobyInput.getQuery(queryID);
            MobyQuery queryResult=new MobyQuery(queryID);

            if (mq.getObjects().size()>0) {
                MobyObject o=(MobyObject)mq.getObjects().elementAt(0);

                queryResult.addObject(o);
                queryResult.addObject(new MobyObject(o.getArticleName(),
"Global_Keyword", "hello world"));

                mobyOutput.setQuery(queryResult);
            }
        }

        return mobyOutput.toXML();
    }


Don't know if it is easy enough...

> Hi all,
>
> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since
> 3  months  now.
> one of my first tasks was to provide a generic API to  simplify access
> to the pameters (queryID, namespace, id)
> one needs from the moby input xml to run the services and also methods
> to generate moby conform xml result.
>
> I have used DOM4J and XPATH to implement concrete classes for this
> purpose.
> At the moment all you need to get your parameters is to use the method
> "allParsedData(inputxml)" no matter how complex the inputxml is.
> This method return a vector of the form e.g.:
>
> (((queryID1,ns,id))) for a simple type
>
> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
> collection
>
> or
> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
> for an input with 2 invocations, the first been a collection and the
> second a simple type.
>
> currently i do not handle secondary articles, but this should not be
> difficult.
>
> we habe tried in our java services and everything seems to be ok.
>
> i am commenting the code now. once it is finished, i will like to share
> it with you for comment or rectification and of course use.
> Is there any possibility to upload this in central repository?
>
> best regards
>
> octave
>
>>
>>
>> Hi,
>>  I know that someone at mips (Octave Noubibou) is also working on that
>> field, on my side, I have an API in Java (based on the Python API) that
>> helps me to build moby webservices (with axis or j2ee)
>>
>>
>>>> Hi Mark,
>>>>
>>>> I'll see how things are looking and get the documentation together.
>>>> The
>>>> basic goal was to create some basic classes to simplify access to the
>>>> MOBY payload of a webservice call so that we could concentrate on
>>>> getting the services up rather than parsing the MOBY XML and rewriting
>>>> the XML prior to returning the result. We've been using Axis to handle
>>>> the webservice part of the equation, we've created some core classes
>>>> and have a simple test service prototype that we are gearing up to do
>>>> something meaningful with. If you have people doing similar things it
>>>> would be great to get an overview of what you are working on too so we
>>>> can divide and conquer where possible.
>>>>
>>>> Simon.
>>>>
>>>>
>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


From ywong at infobiogen.fr  Wed Feb 16 09:30:43 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Wed Feb 16 09:26:06 2005
Subject: [MOBY-dev] java api
In-Reply-To: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
Message-ID: <34006.195.221.101.193.1108564243.squirrel@195.221.101.193>

PS: I've put the sources at this url:
    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2

    you'll need a login and password:
    login: Invite
    password: invite

    Documentation of the API is in <wsGenoplante_src_dir>/dist/
    a compiled jar is also in this directory

    You'll find the two examples in the <jws_src_dir>/src/ directory
    To setup the webservice (in the case of axis) just copy the
MobyWebService.java to the axis directory as a jws file:

   cp <jws_src_dir>/src/MobyWebService.java
<jakarta_instance_directory>/webapps/axis/

  and use Perl, Python Java API to query the service :p

  A more exhaustive documentation of the API will be produced but I lack
some time doing it... (maybe just look at the examples to have an idea)

  The two projects were written using netbeans 4.0 but the ant file should
work without it:

 build from source:
 $ant
 the resulting jar will be found in the dist directory
<wsGenoplante_src_dir>/dist/wsGenoplante.jar

> Hi,
>   My API was based on my Python API and uses Xerces library (but can use
> any DOM API compatible library) and as for the Python library, was
> intended to be generic:
>
>   XML Moby String <-> Java Objects
>
>   People should only use java object and serialize their results in moby
> XML .
>
>   The only thing it doesn't support (yet) is the PIB. It is also intended
> to ease the building of java webservices without being tied to any
> webservice's API (j2ee or axis or anything else)
>
>   It can also execute moby webservices (client interface) but doesn't
> support registration of objects/services to the bioMoby directory.
>
>   For instance, the documentation of the API is just in plain javadoc  and
> there are just two examples (client querying a bioMoby webservice and a
> server serving moby contents)
>
>   The client API can query the bioMoby directory (find a service)
>
>   I can send the source and documentation to whom it may concern but
> consider the code to be beta quality code :p ...
>
> one example of usage:
>
>     public String aHelloWorld(String mobyContent) throws
> MobyParserException {
>         MobyContent mobyInput=new MobyContent();
>         MobyContent mobyOutput=new MobyContent(this.authority,
> this.notes);
>
>         mobyInput.fromXML(mobyContent);
>
>         /*browse all the queries */
>         Iterator iterator=mobyInput.keys().iterator();
>
>         while (iterator.hasNext()) {
>             String queryID=(String)iterator.next();
>
>             MobyQuery mq=mobyInput.getQuery(queryID);
>             MobyQuery queryResult=new MobyQuery(queryID);
>
>             if (mq.getObjects().size()>0) {
>                 MobyObject o=(MobyObject)mq.getObjects().elementAt(0);
>
>                 queryResult.addObject(o);
>                 queryResult.addObject(new MobyObject(o.getArticleName(),
> "Global_Keyword", "hello world"));
>
>                 mobyOutput.setQuery(queryResult);
>             }
>         }
>
>         return mobyOutput.toXML();
>     }
>
>
> Don't know if it is easy enough...
>
>> Hi all,
>>
>> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since
>> 3  months  now.
>> one of my first tasks was to provide a generic API to  simplify access
>> to the pameters (queryID, namespace, id)
>> one needs from the moby input xml to run the services and also methods
>> to generate moby conform xml result.
>>
>> I have used DOM4J and XPATH to implement concrete classes for this
>> purpose.
>> At the moment all you need to get your parameters is to use the method
>> "allParsedData(inputxml)" no matter how complex the inputxml is.
>> This method return a vector of the form e.g.:
>>
>> (((queryID1,ns,id))) for a simple type
>>
>> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>> collection
>>
>> or
>> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>> for an input with 2 invocations, the first been a collection and the
>> second a simple type.
>>
>> currently i do not handle secondary articles, but this should not be
>> difficult.
>>
>> we habe tried in our java services and everything seems to be ok.
>>
>> i am commenting the code now. once it is finished, i will like to share
>> it with you for comment or rectification and of course use.
>> Is there any possibility to upload this in central repository?
>>
>> best regards
>>
>> octave
>>
>>>
>>>
>>> Hi,
>>>  I know that someone at mips (Octave Noubibou) is also working on that
>>> field, on my side, I have an API in Java (based on the Python API) that
>>> helps me to build moby webservices (with axis or j2ee)
>>>
>>>
>>>>> Hi Mark,
>>>>>
>>>>> I'll see how things are looking and get the documentation together.
>>>>> The
>>>>> basic goal was to create some basic classes to simplify access to the
>>>>> MOBY payload of a webservice call so that we could concentrate on
>>>>> getting the services up rather than parsing the MOBY XML and
>>>>> rewriting
>>>>> the XML prior to returning the result. We've been using Axis to
>>>>> handle
>>>>> the webservice part of the equation, we've created some core classes
>>>>> and have a simple test service prototype that we are gearing up to do
>>>>> something meaningful with. If you have people doing similar things it
>>>>> would be great to get an overview of what you are working on too so
>>>>> we
>>>>> can divide and conquer where possible.
>>>>>
>>>>> Simon.
>>>>>
>>>>>
>>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


From bmg at sfu.ca  Wed Feb 16 20:20:44 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed Feb 16 20:19:21 2005
Subject: [MOBY-dev] java api
In-Reply-To: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
Message-ID: <4213F16C.5030302@sfu.ca>

ywong@infobiogen.fr wrote:

>Hi,
>  My API was based on my Python API and uses Xerces library (but can use
>any DOM API compatible library) and as for the Python library, was
>intended to be generic:
>
>  XML Moby String <-> Java Objects
>  
>
Does this mean that you have a Java object for each Moby data-type 
(Object, DNASequence...) ?

-Ben

From bmg at sfu.ca  Wed Feb 16 20:23:01 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed Feb 16 20:20:09 2005
Subject: [MOBY-dev] java api
In-Reply-To: <42132C2D.4010200@gsf.de>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
Message-ID: <4213F1F5.4020202@sfu.ca>

What about accessing the rest of the contents of the data in a MobyData 
block (ie the primitive values)?

-Ben

Octave Noubibou wrote:

> Hi all,
>
> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS 
> since  3  months  now. one of my first tasks was to provide a generic 
> API to  simplify access to the pameters (queryID, namespace, id)
> one needs from the moby input xml to run the services and also methods 
> to generate moby conform xml result.
>
> I have used DOM4J and XPATH to implement concrete classes for this 
> purpose.
> At the moment all you need to get your parameters is to use the method 
> "allParsedData(inputxml)" no matter how complex the inputxml is.
> This method return a vector of the form e.g.:
>
> (((queryID1,ns,id))) for a simple type
>
> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a 
> collection
>
> or 
> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))  
> for an input with 2 invocations, the first been a collection and the 
> second a simple type.
>
> currently i do not handle secondary articles, but this should not be 
> difficult.
>
> we habe tried in our java services and everything seems to be ok.
>
> i am commenting the code now. once it is finished, i will like to 
> share it with you for comment or rectification and of course use.
> Is there any possibility to upload this in central repository?
>
> best regards
>
> octave
>
>>
>>
>> Hi,
>>  I know that someone at mips (Octave Noubibou) is also working on that
>> field, on my side, I have an API in Java (based on the Python API) that
>> helps me to build moby webservices (with axis or j2ee)
>>
>>
>>>> Hi Mark,
>>>>
>>>> I'll see how things are looking and get the documentation together. 
>>>> The
>>>> basic goal was to create some basic classes to simplify access to the
>>>> MOBY payload of a webservice call so that we could concentrate on
>>>> getting the services up rather than parsing the MOBY XML and rewriting
>>>> the XML prior to returning the result. We've been using Axis to handle
>>>> the webservice part of the equation, we've created some core classes
>>>> and have a simple test service prototype that we are gearing up to do
>>>> something meaningful with. If you have people doing similar things it
>>>> would be great to get an overview of what you are working on too so we
>>>> can divide and conquer where possible.
>>>>
>>>> Simon.
>>>>
>>>>
>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>

From ywong at infobiogen.fr  Thu Feb 17 03:39:18 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Thu Feb 17 03:34:38 2005
Subject: [MOBY-dev] java api
In-Reply-To: <4213F1F5.4020202@sfu.ca>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<4213F1F5.4020202@sfu.ca>
Message-ID: <32888.195.221.101.193.1108629558.squirrel@195.221.101.193>

Hi,
  No, unlike Python, I can't generate on the fly classes so the MobyObject
class is generic, it describes an Moby XML object as a class with
attributes:

  -prefix (default is moby, for XML serialization)
  -tag (for the XML serialization and specify what kind of Moby object it is)
  -namespace (Moby namespace eg AGI_LocusCode)
  -id (object identifier)
  -articleName (name of this object)
  -other moby objects (described in the ontology)
  -a raw content (the serializer only require this object to have a
toString method)

To determine what kind of object it is, I just look at the tag property
with a getTag method.

It is possible to build a specific object from this one using inheritance.

This structure should be enough exhaustive to describe all possible Moby
objects:

    <Object1 namespace="aNamespace" id="anId">
        <Object2 articleName="something">
            <Object3 articleName="A">
                   <Xref .../>
                   <Xref ...>Description</Xref>
                   RAW CONTENT for Object with article Name A
            </Object3>
        </Object2>
        <Object4 namespace="aNamespace" id="anId"/>
        RAW Content for Object 1
    </Object1>

Just have a look at the MobyObject class and the example MobyWebservice
(the method getRandomDNASequence return a DNA sequence object).

Yan

> What about accessing the rest of the contents of the data in a MobyData
> block (ie the primitive values)?
>
> -Ben
>
> Octave Noubibou wrote:
>
>> Hi all,
>>
>> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>> since  3  months  now. one of my first tasks was to provide a generic
>> API to  simplify access to the pameters (queryID, namespace, id)
>> one needs from the moby input xml to run the services and also methods
>> to generate moby conform xml result.
>>
>> I have used DOM4J and XPATH to implement concrete classes for this
>> purpose.
>> At the moment all you need to get your parameters is to use the method
>> "allParsedData(inputxml)" no matter how complex the inputxml is.
>> This method return a vector of the form e.g.:
>>
>> (((queryID1,ns,id))) for a simple type
>>
>> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>> collection
>>
>> or
>> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>> for an input with 2 invocations, the first been a collection and the
>> second a simple type.
>>
>> currently i do not handle secondary articles, but this should not be
>> difficult.
>>
>> we habe tried in our java services and everything seems to be ok.
>>
>> i am commenting the code now. once it is finished, i will like to
>> share it with you for comment or rectification and of course use.
>> Is there any possibility to upload this in central repository?
>>
>> best regards
>>
>> octave
>>
>>>
>>>
>>> Hi,
>>>  I know that someone at mips (Octave Noubibou) is also working on that
>>> field, on my side, I have an API in Java (based on the Python API) that
>>> helps me to build moby webservices (with axis or j2ee)
>>>
>>>
>>>>> Hi Mark,
>>>>>
>>>>> I'll see how things are looking and get the documentation together.
>>>>> The
>>>>> basic goal was to create some basic classes to simplify access to the
>>>>> MOBY payload of a webservice call so that we could concentrate on
>>>>> getting the services up rather than parsing the MOBY XML and
>>>>> rewriting
>>>>> the XML prior to returning the result. We've been using Axis to
>>>>> handle
>>>>> the webservice part of the equation, we've created some core classes
>>>>> and have a simple test service prototype that we are gearing up to do
>>>>> something meaningful with. If you have people doing similar things it
>>>>> would be great to get an overview of what you are working on too so
>>>>> we
>>>>> can divide and conquer where possible.
>>>>>
>>>>> Simon.
>>>>>
>>>>>
>>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


From gordonp at ucalgary.ca  Thu Feb 17 10:21:41 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Thu Feb 17 10:16:57 2005
Subject: [MOBY-dev] java api
In-Reply-To: <32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<4213F1F5.4020202@sfu.ca>
	<32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
Message-ID: <4214B685.6090105@ucalgary.ca>

It's great to see all of this code coming out, who new there were so 
many Java MOBY developers! :-)

We should really think about how to consolidate the best parts of the 
everyone's code into a cohesive object hierarchy.  This can be a bit 
tricky, since it's easy to feel insulted because some great code you 
wrote doesn't make it into the amalgam.  In practice, current coders 
will probably continue to use the classes they have already developed, 
since they've build other code around it, so the amalgam is more for the 
benefit of new Java coders.  I'm volunteering myself to take some of Ben 
and Eddie's PIB and RDF type-checking code and fold it into the existing 
MobyDataSimpleInstance. 

Yan, I haven't looked thoroughly, does your Java code use Jython to 
access your underlying Python implementation of the API?

Simon, what data instance classes are you planning on using for the Axis 
streamlining?

>Hi,
>  No, unlike Python, I can't generate on the fly classes so the MobyObject
>class is generic, it describes an Moby XML object as a class with
>attributes:
>
>  -prefix (default is moby, for XML serialization)
>  -tag (for the XML serialization and specify what kind of Moby object it is)
>  -namespace (Moby namespace eg AGI_LocusCode)
>  -id (object identifier)
>  -articleName (name of this object)
>  -other moby objects (described in the ontology)
>  -a raw content (the serializer only require this object to have a
>toString method)
>
>To determine what kind of object it is, I just look at the tag property
>with a getTag method.
>
>It is possible to build a specific object from this one using inheritance.
>
>This structure should be enough exhaustive to describe all possible Moby
>objects:
>
>    <Object1 namespace="aNamespace" id="anId">
>        <Object2 articleName="something">
>            <Object3 articleName="A">
>                   <Xref .../>
>                   <Xref ...>Description</Xref>
>                   RAW CONTENT for Object with article Name A
>            </Object3>
>        </Object2>
>        <Object4 namespace="aNamespace" id="anId"/>
>        RAW Content for Object 1
>    </Object1>
>
>Just have a look at the MobyObject class and the example MobyWebservice
>(the method getRandomDNASequence return a DNA sequence object).
>
>Yan
>
>  
>
>>What about accessing the rest of the contents of the data in a MobyData
>>block (ie the primitive values)?
>>
>>-Ben
>>
>>Octave Noubibou wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>since  3  months  now. one of my first tasks was to provide a generic
>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>one needs from the moby input xml to run the services and also methods
>>>to generate moby conform xml result.
>>>
>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>purpose.
>>>At the moment all you need to get your parameters is to use the method
>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>This method return a vector of the form e.g.:
>>>
>>>(((queryID1,ns,id))) for a simple type
>>>
>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>collection
>>>
>>>or
>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>for an input with 2 invocations, the first been a collection and the
>>>second a simple type.
>>>
>>>currently i do not handle secondary articles, but this should not be
>>>difficult.
>>>
>>>we habe tried in our java services and everything seems to be ok.
>>>
>>>i am commenting the code now. once it is finished, i will like to
>>>share it with you for comment or rectification and of course use.
>>>Is there any possibility to upload this in central repository?
>>>
>>>best regards
>>>
>>>octave
>>>
>>>      
>>>
>>>>Hi,
>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>field, on my side, I have an API in Java (based on the Python API) that
>>>>helps me to build moby webservices (with axis or j2ee)
>>>>
>>>>
>>>>        
>>>>
>>>>>>Hi Mark,
>>>>>>
>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>The
>>>>>>basic goal was to create some basic classes to simplify access to the
>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>rewriting
>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>handle
>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>and have a simple test service prototype that we are gearing up to do
>>>>>>something meaningful with. If you have people doing similar things it
>>>>>>would be great to get an overview of what you are working on too so
>>>>>>we
>>>>>>can divide and conquer where possible.
>>>>>>
>>>>>>Simon.
>>>>>>
>>>>>>
>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev@biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev@biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>    
>>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>  
>

From ywong at infobiogen.fr  Thu Feb 17 10:34:50 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Thu Feb 17 10:30:01 2005
Subject: [MOBY-dev] java api
In-Reply-To: <4214B685.6090105@ucalgary.ca>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<4213F1F5.4020202@sfu.ca>
	<32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
	<4214B685.6090105@ucalgary.ca>
Message-ID: <34198.195.221.101.193.1108654490.squirrel@195.221.101.193>

No, the API I wrote is 100% java :p, the Python API was the model on which
I based the development.


> It's great to see all of this code coming out, who new there were so
> many Java MOBY developers! :-)
>
> We should really think about how to consolidate the best parts of the
> everyone's code into a cohesive object hierarchy.  This can be a bit
> tricky, since it's easy to feel insulted because some great code you
> wrote doesn't make it into the amalgam.  In practice, current coders
> will probably continue to use the classes they have already developed,
> since they've build other code around it, so the amalgam is more for the
> benefit of new Java coders.  I'm volunteering myself to take some of Ben
> and Eddie's PIB and RDF type-checking code and fold it into the existing
> MobyDataSimpleInstance.
>
> Yan, I haven't looked thoroughly, does your Java code use Jython to
> access your underlying Python implementation of the API?
>
> Simon, what data instance classes are you planning on using for the Axis
> streamlining?
>
>>Hi,
>>  No, unlike Python, I can't generate on the fly classes so the
>> MobyObject
>>class is generic, it describes an Moby XML object as a class with
>>attributes:
>>
>>  -prefix (default is moby, for XML serialization)
>>  -tag (for the XML serialization and specify what kind of Moby object it
>> is)
>>  -namespace (Moby namespace eg AGI_LocusCode)
>>  -id (object identifier)
>>  -articleName (name of this object)
>>  -other moby objects (described in the ontology)
>>  -a raw content (the serializer only require this object to have a
>>toString method)
>>
>>To determine what kind of object it is, I just look at the tag property
>>with a getTag method.
>>
>>It is possible to build a specific object from this one using
>> inheritance.
>>
>>This structure should be enough exhaustive to describe all possible Moby
>>objects:
>>
>>    <Object1 namespace="aNamespace" id="anId">
>>        <Object2 articleName="something">
>>            <Object3 articleName="A">
>>                   <Xref .../>
>>                   <Xref ...>Description</Xref>
>>                   RAW CONTENT for Object with article Name A
>>            </Object3>
>>        </Object2>
>>        <Object4 namespace="aNamespace" id="anId"/>
>>        RAW Content for Object 1
>>    </Object1>
>>
>>Just have a look at the MobyObject class and the example MobyWebservice
>>(the method getRandomDNASequence return a DNA sequence object).
>>
>>Yan
>>
>>
>>
>>>What about accessing the rest of the contents of the data in a MobyData
>>>block (ie the primitive values)?
>>>
>>>-Ben
>>>
>>>Octave Noubibou wrote:
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>>since  3  months  now. one of my first tasks was to provide a generic
>>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>>one needs from the moby input xml to run the services and also methods
>>>>to generate moby conform xml result.
>>>>
>>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>>purpose.
>>>>At the moment all you need to get your parameters is to use the method
>>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>>This method return a vector of the form e.g.:
>>>>
>>>>(((queryID1,ns,id))) for a simple type
>>>>
>>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>>collection
>>>>
>>>>or
>>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>>for an input with 2 invocations, the first been a collection and the
>>>>second a simple type.
>>>>
>>>>currently i do not handle secondary articles, but this should not be
>>>>difficult.
>>>>
>>>>we habe tried in our java services and everything seems to be ok.
>>>>
>>>>i am commenting the code now. once it is finished, i will like to
>>>>share it with you for comment or rectification and of course use.
>>>>Is there any possibility to upload this in central repository?
>>>>
>>>>best regards
>>>>
>>>>octave
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>>field, on my side, I have an API in Java (based on the Python API)
>>>>> that
>>>>>helps me to build moby webservices (with axis or j2ee)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Hi Mark,
>>>>>>>
>>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>>The
>>>>>>>basic goal was to create some basic classes to simplify access to
>>>>>>> the
>>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>>rewriting
>>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>>handle
>>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>>and have a simple test service prototype that we are gearing up to
>>>>>>> do
>>>>>>>something meaningful with. If you have people doing similar things
>>>>>>> it
>>>>>>>would be great to get an overview of what you are working on too so
>>>>>>>we
>>>>>>>can divide and conquer where possible.
>>>>>>>
>>>>>>>Simon.
>>>>>>>
>>>>>>>
>>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev@biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev@biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>>
>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev@biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>


From mwilkinson at mobile.rogers.com  Sat Feb 19 02:38:30 2005
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Sat Feb 19 02:36:33 2005
Subject: [MOBY-dev] java api
Message-ID: <200502190736.j1J7aPKr002666@portal.open-bio.org>

Hi Paul, Aloha from Honolulu! (just a stopover on the way to Sydney, unfortunately...)


Thanks for the offer of your time in doing some java code merging!

I had planned to write a message to the group shortly in this regard, so now seems a good moment to do so :-). It seems to me that Eddie is a good choice for the person who makes the final decisions for the moby java codebase structure if only because he is currently employed to do java moby 100% of his time.  This doesn't mean that he wouldn't discuss it with everyone else, just that he would take the time (and responsibility) for taking the "best of the best" code and consolidating it into a unified API.

I was thinking that the next moby meeting (May) would be a good time to talk about this face-to-face and make sure everyone knows the strengths and limitations of each others code.

Na?  Opinions?

M


-----Original Message-----
From: Paul Gordon <gordonp@ucalgary.ca>
Date: Thu, 17 Feb 2005 08:21:41 
To:Core developer announcements <moby-dev@portal.open-bio.org>
Subject: Re: [MOBY-dev] java api

It's great to see all of this code coming out, who new there were so 
many Java MOBY developers! :-)

We should really think about how to consolidate the best parts of the 
everyone's code into a cohesive object hierarchy.  This can be a bit 
tricky, since it's easy to feel insulted because some great code you 
wrote doesn't make it into the amalgam.  In practice, current coders 
will probably continue to use the classes they have already developed, 
since they've build other code around it, so the amalgam is more for the 
benefit of new Java coders.  I'm volunteering myself to take some of Ben 
and Eddie's PIB and RDF type-checking code and fold it into the existing 
MobyDataSimpleInstance. 

Yan, I haven't looked thoroughly, does your Java code use Jython to 
access your underlying Python implementation of the API?

Simon, what data instance classes are you planning on using for the Axis 
streamlining?

>Hi,
>  No, unlike Python, I can't generate on the fly classes so the MobyObject
>class is generic, it describes an Moby XML object as a class with
>attributes:
>
>  -prefix (default is moby, for XML serialization)
>  -tag (for the XML serialization and specify what kind of Moby object it is)
>  -namespace (Moby namespace eg AGI_LocusCode)
>  -id (object identifier)
>  -articleName (name of this object)
>  -other moby objects (described in the ontology)
>  -a raw content (the serializer only require this object to have a
>toString method)
>
>To determine what kind of object it is, I just look at the tag property
>with a getTag method.
>
>It is possible to build a specific object from this one using inheritance.
>
>This structure should be enough exhaustive to describe all possible Moby
>objects:
>
>    <Object1 namespace="aNamespace" id="anId">
>        <Object2 articleName="something">
>            <Object3 articleName="A">
>                   <Xref .../>
>                   <Xref ...>Description</Xref>
>                   RAW CONTENT for Object with article Name A
>            </Object3>
>        </Object2>
>        <Object4 namespace="aNamespace" id="anId"/>
>        RAW Content for Object 1
>    </Object1>
>
>Just have a look at the MobyObject class and the example MobyWebservice
>(the method getRandomDNASequence return a DNA sequence object).
>
>Yan
>
>  
>
>>What about accessing the rest of the contents of the data in a MobyData
>>block (ie the primitive values)?
>>
>>-Ben
>>
>>Octave Noubibou wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>since  3  months  now. one of my first tasks was to provide a generic
>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>one needs from the moby input xml to run the services and also methods
>>>to generate moby conform xml result.
>>>
>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>purpose.
>>>At the moment all you need to get your parameters is to use the method
>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>This method return a vector of the form e.g.:
>>>
>>>(((queryID1,ns,id))) for a simple type
>>>
>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>collection
>>>
>>>or
>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>for an input with 2 invocations, the first been a collection and the
>>>second a simple type.
>>>
>>>currently i do not handle secondary articles, but this should not be
>>>difficult.
>>>
>>>we habe tried in our java services and everything seems to be ok.
>>>
>>>i am commenting the code now. once it is finished, i will like to
>>>share it with you for comment or rectification and of course use.
>>>Is there any possibility to upload this in central repository?
>>>
>>>best regards
>>>
>>>octave
>>>
>>>      
>>>
>>>>Hi,
>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>field, on my side, I have an API in Java (based on the Python API) that
>>>>helps me to build moby webservices (with axis or j2ee)
>>>>
>>>>
>>>>        
>>>>
>>>>>>Hi Mark,
>>>>>>
>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>The
>>>>>>basic goal was to create some basic classes to simplify access to the
>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>rewriting
>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>handle
>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>and have a simple test service prototype that we are gearing up to do
>>>>>>something meaningful with. If you have people doing similar things it
>>>>>>would be great to get an overview of what you are working on too so
>>>>>>we
>>>>>>can divide and conquer where possible.
>>>>>>
>>>>>>Simon.
>>>>>>
>>>>>>
>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev@biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev@biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>    
>>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>  
>

_______________________________________________
MOBY-dev mailing list
MOBY-dev@biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
From edward.kawas at gmail.com  Wed Feb 23 01:02:47 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Wed Feb 23 00:57:51 2005
Subject: [MOBY-dev] java api
Message-ID: <421c1c8d.080cc2c8.5369.1953@smtp.gmail.com>

Hello Moby,

  I have been tasked with organizing and extending the jMoby
code.  My goal is to maximize the usefulness of what has
already been written and to provide a solid structure upon
which the next generations of jMoby can be based.  In
seeking to accomplish these goals I would like to start with
a discussion of what jMoby does well at the moment and what
it does not so well or does not do at all.  I'd like to use
this discussion to set some specific goals for the next
version of the API. 
 
Once these goals are clarified I would like to use them to
create a conceptually meaningful package hierarchy, slot the
existing classes into it, and to produce the interfaces for
the classes that need to be written. For instance, the
package "shared" could usefully be decomposed into a set of
more meaningful package names which would facilitate the use
of the code by newbies, reducing code duplication and
allowing us developers to be more efficient. The help and
participation from all the jMoby developers will be vital
for this revision to succeed.

Here are some questions I have about jMoby2005:
   Will we be supporting automatic generation of service
templates?  How (axis?)?  Will the library allow for the
addition of real wsdl descriptions of the services so that
client developers outside of the Moby community can use
their .NET/Axis tools to make use of Moby services?  How
will jMoby deal with service ontologies?  Is there interest
in providing GUI development support?

So, let's hear what you think about the future of jMoby!

Eddie Kawas

-B

From ed.kawas at gmail.com  Wed Feb 23 00:54:53 2005
From: ed.kawas at gmail.com (Eddie Kawas)
Date: Wed Feb 23 14:16:01 2005
Subject: [MOBY-dev] java api
Message-ID: <421c1ab0.13628b9a.6ca6.2fdf@smtp.gmail.com>

Hello Moby,

  I have been tasked with organizing and extending the jMoby
code.  My goal is to maximize the usefulness of what has
already been written and to provide a solid structure upon
which the next generations of jMoby can be based.  In
seeking to accomplish these goals I would like to start with
a discussion of what jMoby does well at the moment and what
it does not so well or does not do at all.  I'd like to use
this discussion to set some specific goals for the next
version of the API. 
 
Once these goals are clarified I would like to use them to
create a conceptually meaningful package hierarchy, slot the
existing classes into it, and to produce the interfaces for
the classes that need to be written. For instance, the
package "shared" could usefully be decomposed into a set of
more meaningful package names which would facilitate the use
of the code by newbies, reducing code duplication and
allowing us developers to be more efficient. The help and
participation from all the jMoby developers will be vital
for this revision to succeed.

Here are some questions I have about jMoby2005:
   Will we be supporting automatic generation of service
templates?  How (axis?)?  Will the library allow for the
addition of real wsdl descriptions of the services so that
client developers outside of the Moby community can use
their .NET/Axis tools to make use of Moby services?  How
will jMoby deal with service ontologies?  Is there interest
in providing GUI development support?

So, let's hear what you think about the future of jMoby!

Eddie Kawas

-B

From bmg at sfu.ca  Wed Feb 23 21:27:09 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed Feb 23 21:24:21 2005
Subject: [MOBY-dev] java api
In-Reply-To: <34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
	<34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
Message-ID: <421D3B7D.4040805@sfu.ca>

Hi Yan,

 I couldn't log in to check out your code, is it still there with Invite 
Invite ?

thanks
-Ben

regarding

PS: I've put the sources at this url:
    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2


From ywong at infobiogen.fr  Thu Feb 24 03:22:49 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Mon Mar  7 20:24:50 2005
Subject: [MOBY-dev] java api
In-Reply-To: <421D3B7D.4040805@sfu.ca>
References: <42122050.400@sfu.ca>	<42132C2D.4010200@gsf.de>	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>	<34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
	<421D3B7D.4040805@sfu.ca>
Message-ID: <421D8ED9.9030509@infobiogen.fr>

Benjamin Good wrote:

> Hi Yan,
>
> I couldn't log in to check out your code, is it still there with 
> Invite Invite ?
>
> thanks
> -Ben
>
> regarding
>
> PS: I've put the sources at this url:
>    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
>    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
It should be
login: Invite (first letter in caps)
password: invite (no caps at all)

I send you the two files... wsGenoplante.tar.bz2 contains the API and 
jws.tar.bz2 the examples of how to use it
they were developed with netbeans 4 but has a ant file (build.xml). A  
javadoc and a ready to use binary is also  provided in the  package
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wsGenoplante.tar.bz2
Type: application/octet-stream
Size: 33088 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050224/014f211d/wsGenoplante.tar-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jws.tar.bz2
Type: application/octet-stream
Size: 12818 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050224/014f211d/jws.tar-0001.obj
From duncan.hull at cs.man.ac.uk  Tue Feb  8 06:56:20 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue, 08 Feb 2005 11:56:20 +0000
Subject: [MOBY-dev] mobycentral down?
Message-ID: <4208A8E4.4040603@cs.man.ac.uk>

Dear moby-devvers

Is anyone else having a problem getting to 
http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl

???

Duncan


From senger at ebi.ac.uk  Tue Feb  8 07:04:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 8 Feb 2005 12:04:57 +0000 (GMT)
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208A8E4.4040603@cs.man.ac.uk>
Message-ID: <Pine.LNX.4.44.0502081204260.5027-100000@bagheera.ebi.ac.uk>

> Is anyone else having a problem getting to 
> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
   Works fine for me (Tue Feb  8 12:04:42 GMT 2005).
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From sophie.durand at infobiogen.fr  Tue Feb  8 05:41:34 2005
From: sophie.durand at infobiogen.fr (Sophie Durand)
Date: Tue, 08 Feb 2005 11:41:34 +0100
Subject: [MOBY-dev] bug in MOBY::CommunSubs:getCrossReferences
Message-ID: <4208975E.6050201@infobiogen.fr>

Hello,

I have a problem while parsing the following moby output:

<?xml version='1.0' encoding='UTF-8'?><moby:MOBY
xmlns:moby='http://www.biomoby.org/moby'><moby:mobyContent
moby:authority='genoplante-info.infobiogen.fr'><moby:serviceNotes>GENOPLANTE 

PHYTOPROT. IDDN.FR.001.250004.000.S.P.2003.000.10300. This database, its
constitutive components and its documentation, are the intellectual
property of GENOPLANTE-VALOR.</moby:serviceNotes><moby:mobyData
moby:queryID='1'><moby:Collection
moby:articleName=''><moby:Simple><moby:Object
moby:namespace='AGI_LocusCode' moby:id='AT3G23130'
 ><CrossReference><moby:Object moby:namespace='PHYTOPROT_CLUSTER_Id' 
moby:id='148'
/></CrossReference></moby:Object></moby:Simple></moby:Collection></moby:mobyData></moby:mobyContent></moby:MOBY>

I'm using the Perl API with a genericServiceInputParser call and then a 
getCrossReferences call to obtain the cross reference. But in this case, 
I don't get any cross reference. If I delete the "moby:" namespaces like 
this :
<CrossReference><moby:Object namespace='PHYTOPROT_CLUSTER_Id'  id='148' 
/></CrossReference>
it works well.

So I looked in the code, and I modified the following function in 
MOBY::CommunSubs.pm, and then it works:

sub _makeObjectType {
     my ($xref) = @_;
     my $ns = $xref->getAttributeNode('namespace');
     $ns = $xref->getAttributeNode('moby:namespace') unless $ns;
     return undef unless $ns;
     my $id = $xref->getAttributeNode('id');
     $id = $xref->getAttributeNode('moby:id') unless $id;  # INSTEAD OF $ns
     return undef unless $id;
     my $XREF = MOBY::CrossReference->new(
         type => "object",
         namespace => $ns->getValue,
         id => $id->getValue,
      );
}

-- 
Sophie Durand
Ing?nieure en Bioinformatique
INRA / URGI chez Infobiogen
523, place des Terrasses de l'Agora
91000 Evry - FRANCE


From mwilkinson at mrl.ubc.ca  Tue Feb  8 12:21:46 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 08 Feb 2005 09:21:46 -0800
Subject: [moby] [MOBY-dev] bug in MOBY::CommunSubs:getCrossReferences
In-Reply-To: <4208975E.6050201@infobiogen.fr>
References: <4208975E.6050201@infobiogen.fr>
Message-ID: <1107883306.8689.75.camel@mobycentral.icapture.ubc.ca>

thanks!  Bug squashed.

M


On Tue, 2005-02-08 at 02:41, Sophie Durand wrote:
> Hello,
> 
> I have a problem while parsing the following moby output:
> 
> <?xml version='1.0' encoding='UTF-8'?><moby:MOBY
> xmlns:moby='http://www.biomoby.org/moby'><moby:mobyContent
> moby:authority='genoplante-info.infobiogen.fr'><moby:serviceNotes>GENOPLANTE 
> 
> PHYTOPROT. IDDN.FR.001.250004.000.S.P.2003.000.10300. This database, its
> constitutive components and its documentation, are the intellectual
> property of GENOPLANTE-VALOR.</moby:serviceNotes><moby:mobyData
> moby:queryID='1'><moby:Collection
> moby:articleName=''><moby:Simple><moby:Object
> moby:namespace='AGI_LocusCode' moby:id='AT3G23130'
>  ><CrossReference><moby:Object moby:namespace='PHYTOPROT_CLUSTER_Id' 
> moby:id='148'
> /></CrossReference></moby:Object></moby:Simple></moby:Collection></moby:mobyData></moby:mobyContent></moby:MOBY>
> 
> I'm using the Perl API with a genericServiceInputParser call and then a 
> getCrossReferences call to obtain the cross reference. But in this case, 
> I don't get any cross reference. If I delete the "moby:" namespaces like 
> this :
> <CrossReference><moby:Object namespace='PHYTOPROT_CLUSTER_Id'  id='148' 
> /></CrossReference>
> it works well.
> 
> So I looked in the code, and I modified the following function in 
> MOBY::CommunSubs.pm, and then it works:
> 
> sub _makeObjectType {
>      my ($xref) = @_;
>      my $ns = $xref->getAttributeNode('namespace');
>      $ns = $xref->getAttributeNode('moby:namespace') unless $ns;
>      return undef unless $ns;
>      my $id = $xref->getAttributeNode('id');
>      $id = $xref->getAttributeNode('moby:id') unless $id;  # INSTEAD OF $ns
>      return undef unless $id;
>      my $XREF = MOBY::CrossReference->new(
>          type => "object",
>          namespace => $ns->getValue,
>          id => $id->getValue,
>       );
> }
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada



From gss at ncgr.org  Tue Feb  8 12:35:46 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue, 08 Feb 2005 10:35:46 -0700
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208A8E4.4040603@cs.man.ac.uk>
References: <4208A8E4.4040603@cs.man.ac.uk>
Message-ID: <4208F872.3000105@ncgr.org>

Something indeed seems to be awry:

wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl

--10:30:24--  http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
           => `-'
Resolving mobycentral.cbr.nrc.ca... 198.166.4.151
Connecting to mobycentral.cbr.nrc.ca[198.166.4.151]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 411 Length Required
 2 Date: Tue, 08 Feb 2005 17:30:25 GMT
 3 Server: Apache/1.3.29 (Unix) mod_perl/1.29
 4 Connection: close
 5 Content-Type: text/plain
10:30:25 ERROR 411: Length Required.

// Gary

Duncan Hull wrote:

> Dear moby-devvers
>
> Is anyone else having a problem getting to 
> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
> ???
>
> Duncan
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>


From senger at ebi.ac.uk  Tue Feb  8 12:47:26 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 8 Feb 2005 17:47:26 +0000 (GMT)
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208F872.3000105@ncgr.org>
Message-ID: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>

> Something indeed seems to be awry:
> 
> wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
   Let me claim again: according my test client contacting moby central,
everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
that wget should work properly? Moby central responses may not be good if
you contact it withour any SOAP message.

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From edward.kawas at gmail.com  Tue Feb  8 12:49:40 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 8 Feb 2005 09:49:40 -0800
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
Message-ID: <4208fbb5.7748301d.273c.55f3@smtp.gmail.com>

I second Martins' claim.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Tuesday, February 08, 2005 9:47 AM
> To: Core developer announcements
> Cc: Mark Wilkinson
> Subject: Re: [MOBY-dev] mobycentral down?
> 
> > Something indeed seems to be awry:
> >
> > wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-
> bin/MOBY05/mobycentral.pl
> >
>    Let me claim again: according my test client contacting
> moby central,
> everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why
> do you expect
> that wget should work properly? Moby central responses may
> not be good if
> you contact it withour any SOAP message.
> 
>    Martin
> 
> --
> Martin Senger
> 
> EMBL Outstation - Hinxton                Senger at EBI.ac.uk
> European Bioinformatics Institute        Phone: (+44) 1223
> 494636
> Wellcome Trust Genome Campus             (Switchboard:
> 494444)
> Hinxton                                  Fax  : (+44) 1223
> 494468
> Cambridge CB10 1SD
> United Kingdom
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From mwilkinson at mrl.ubc.ca  Tue Feb  8 13:32:08 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 08 Feb 2005 10:32:08 -0800
Subject: [moby] Re: [MOBY-dev] mobycentral down?
In-Reply-To: <4208F872.3000105@ncgr.org>
References: <4208A8E4.4040603@cs.man.ac.uk>  <4208F872.3000105@ncgr.org>
Message-ID: <1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>

Strange... I am having no problems with it today.  It passes all tests
both on the development and production server from a remote connection
to mobycentral.pl, and the CGI browser is working properly (local
connection).  

I do notice, however, that the services that rely on SeqHound are...
errr... not working properly is a mild way to say it ;-)  but that isn't
a MOBYCentral problem and I'm sure the SeqHound staff are already aware
of the problem.

...????  i dunno

I'll keep my eye on it for the rest of the day to see if i notice
anything unusual.  I wonder if it the same problem we have seen a few
times in the past few months with connections from Europe being
blocked??  We can't seem to track that one down - it is not happening on
our machines, we know that for sure... it is something elsewhere.

M



On Tue, 2005-02-08 at 09:35, Gary Schiltz wrote:
> Something indeed seems to be awry:
> 
> wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> 
> --10:30:24--  http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>            => `-'
> Resolving mobycentral.cbr.nrc.ca... 198.166.4.151
> Connecting to mobycentral.cbr.nrc.ca[198.166.4.151]:80... connected.
> HTTP request sent, awaiting response...
>  1 HTTP/1.1 411 Length Required
>  2 Date: Tue, 08 Feb 2005 17:30:25 GMT
>  3 Server: Apache/1.3.29 (Unix) mod_perl/1.29
>  4 Connection: close
>  5 Content-Type: text/plain
> 10:30:25 ERROR 411: Length Required.
> 
> // Gary
> 
> Duncan Hull wrote:
> 
> > Dear moby-devvers
> >
> > Is anyone else having a problem getting to 
> > http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> >
> > ???
> >
> > Duncan
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> >
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada



From gss at ncgr.org  Tue Feb  8 12:56:25 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue, 08 Feb 2005 10:56:25 -0700
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
Message-ID: <4208FD49.1080508@ncgr.org>

As someone famous must have said, "What was I thinking?", or "Never 
mind", or even more succinctly, "Duh" :-) I suppose I was thinking of 
the URL for the gbrowse interface to MOBY.

// Gary

Martin Senger wrote:

>>Something indeed seems to be awry:
>>
>>wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>>
>>
>   Let me claim again: according my test client contacting moby central,
>everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
>that wget should work properly? Moby central responses may not be good if
>you contact it withour any SOAP message.
>
>   Martin
>
>


From duncan.hull at cs.man.ac.uk  Tue Feb  8 13:18:49 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue, 08 Feb 2005 18:18:49 +0000
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>
References: <4208A8E4.4040603@cs.man.ac.uk> <4208F872.3000105@ncgr.org>
	<1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42090289.8010001@cs.man.ac.uk>

dear moby-devvers

re: my original message. For the record, mobycentral was temporarily 
unavailable from within Taverna, which may have been a local 
(Manchester) problem.

Its accessible again now...


Duncan

http://taverna.sourceforge.net/




From mwilkinson at mrl.ubc.ca  Tue Feb  8 14:06:41 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 08 Feb 2005 11:06:41 -0800
Subject: [moby] Re: [MOBY-dev] mobycentral down?
In-Reply-To: <4208FD49.1080508@ncgr.org>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
	<4208FD49.1080508@ncgr.org>
Message-ID: <1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>

I think the correct quote is:

"Doh!"

	H.J.Simpson




On Tue, 2005-02-08 at 09:56, Gary Schiltz wrote:
> As someone famous must have said, "What was I thinking?", or "Never 
> mind", or even more succinctly, "Duh" :-) I suppose I was thinking of 
> the URL for the gbrowse interface to MOBY.
> 
> // Gary
> 
> Martin Senger wrote:
> 
> >>Something indeed seems to be awry:
> >>
> >>wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> >>
> >>
> >   Let me claim again: according my test client contacting moby central,
> >everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
> >that wget should work properly? Moby central responses may not be good if
> >you contact it withour any SOAP message.
> >
> >   Martin
> >
> >
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada



From duncan.hull at cs.man.ac.uk  Tue Feb  8 14:01:02 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue, 08 Feb 2005 19:01:02 +0000
Subject: [MOBY-dev] Mobycentral D'oh?
In-Reply-To: <1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>	<4208FD49.1080508@ncgr.org>
	<1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42090C6E.8090902@cs.man.ac.uk>

Mark

Mark Wilkinson wrote:

>I think the correct quote is: "Doh!" 	H.J.Simpson
>  
>
Can't find it in Pubmed
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=pubmed&cmd=search&term=Simpson+HJ

Do you have the year/journal of publication? :)


Duncan


From mwilkinson at mrl.ubc.ca  Wed Feb  9 14:54:38 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 09 Feb 2005 11:54:38 -0800
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>

Hi MOBYers!

It's getting to that time again - time for the next (but hopefully not
last... touch wood!) BioMOBY developers meeting!

Due to overwhelming requests I am happy to host it here in Vancouver
again.  Alternately, and at higher cost, we could host it in a more
exotic location such as the spectacular Whistler Ski Resort (site of the
2010 winter olympics - about 1.5 hours north of Vancouver).

The dates are pretty limited.  It appears that the first weekend of May
(7th and 8th) is clear of other conferences that people might want to
attend.

Keeping with tradition, I will be using my Genome Canada grant to pay
for as much of the local expenses as I can afford, so hopefully the
charge to each of you will be primarily for travel, with only a little
bit to cover room and board.

So... a few questions:

1)  Are the dates (May 7-8) going to work for the majority of you core
developers?

2)  Do you want to meet in Vancouver, or should we make our potentially
last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
Rebecca, we can play hackeysac in either location ;-) )

3)  *** Can people please contact me ASAP indicating their interest in
attending so that I can ballpark the expenses and work out how much I
can afford to supplement from my grant ***

4)  Is there now sufficient interest in MOBY that it is worth having
back-to-back developers and implementers meetings?  If you are not a
"core developer", but would be interested in attending a one-day
hands-on meeting with people who have experience in building MOBY
Services please let me know.  If there is sufficient interest I'll see
if I can arrange something like this.


Looking forward to seeing you all again soon!

Mark


-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada



From simont at mcw.edu  Mon Feb 14 23:03:15 2005
From: simont at mcw.edu (Twigger Simon)
Date: Mon, 14 Feb 2005 22:03:15 -0600
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
In-Reply-To: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>
References: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>
Message-ID: <849AE9B6-7F06-11D9-83B7-000A959D1D82@mcw.edu>

Hi Mark,

Sign me up, the 7/8th of May look good and Im willing to go to a blow 
out meeting or a normal one. :) We are working on some java axis 
libraries to make Java services easier to create. We have prototype 
code in place at the moment but have just brought on board a java guru 
so Im having him look things over and give his blessing before we 
inflict them on the world. If we have an agenda for the potential 
implementers meeting I'd like to see if I can interest a few more 
people. We see a lot of promise in web services in general and MOBY in 
particular and Im hoping I can get some more of our teams to buy in, 
particularly when they see that their data can be made available via 
Taverna, etc. for free. Any guesstimates of the costs when you have 
some idea would be welcome so I can see who I can afford to bring 
along.

There is an increasing interest in developing ontologies, addressing 
datasharing, etc. in the cardiovascular arena here in the US and I 
would also be interested in chatting with you some more about your 
plans for CardioSHARE and how we might align our work at MCW to achieve 
this common goal.

Cheers,

	Simon.


On Feb 9, 2005, at 1:54 PM, Mark Wilkinson wrote:

> Hi MOBYers!
>
> It's getting to that time again - time for the next (but hopefully not
> last... touch wood!) BioMOBY developers meeting!
>
> Due to overwhelming requests I am happy to host it here in Vancouver
> again.  Alternately, and at higher cost, we could host it in a more
> exotic location such as the spectacular Whistler Ski Resort (site of 
> the
> 2010 winter olympics - about 1.5 hours north of Vancouver).
>
> The dates are pretty limited.  It appears that the first weekend of May
> (7th and 8th) is clear of other conferences that people might want to
> attend.
>
> Keeping with tradition, I will be using my Genome Canada grant to pay
> for as much of the local expenses as I can afford, so hopefully the
> charge to each of you will be primarily for travel, with only a little
> bit to cover room and board.
>
> So... a few questions:
>
> 1)  Are the dates (May 7-8) going to work for the majority of you core
> developers?
>
> 2)  Do you want to meet in Vancouver, or should we make our potentially
> last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
> Rebecca, we can play hackeysac in either location ;-) )
>
> 3)  *** Can people please contact me ASAP indicating their interest in
> attending so that I can ballpark the expenses and work out how much I
> can afford to supplement from my grant ***
>
> 4)  Is there now sufficient interest in MOBY that it is worth having
> back-to-back developers and implementers meetings?  If you are not a
> "core developer", but would be interested in attending a one-day
> hands-on meeting with people who have experience in building MOBY
> Services please let me know.  If there is sufficient interest I'll see
> if I can arrange something like this.
>
>
> Looking forward to seeing you all again soon!
>
> Mark
>
>
> -- 
> Mark Wilkinson
> Assistant Professor (Bioinformatics)
> Dept. Medical Genetics, UBC, Canada
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw



From mwilkinson at mobile.rogers.com  Mon Feb 14 23:04:05 2005
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Mon, 14 Feb 2005 23:04:05 -0500
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <200502150401.j1F41oKr013946@portal.open-bio.org>

Hey Simon,

Please post to the mailing list with your moby java activities since I have several people doing similar things - no point in duplicating effort if we can split the work :-)

I'll be posting the URL for the registration page before weeks end - I'm just waiting for a quote on the room rate.

Cheers!

M

-----Original Message-----
From: Twigger Simon <simont at mcw.edu>
Date: Mon, 14 Feb 2005 22:03:15 
To:Core developer announcements <moby-dev at portal.open-bio.org>
Subject: Re: [MOBY-dev] BioMOBY developers meeting pre-announcement

Hi Mark,

Sign me up, the 7/8th of May look good and Im willing to go to a blow 
out meeting or a normal one. :) We are working on some java axis 
libraries to make Java services easier to create. We have prototype 
code in place at the moment but have just brought on board a java guru 
so Im having him look things over and give his blessing before we 
inflict them on the world. If we have an agenda for the potential 
implementers meeting I'd like to see if I can interest a few more 
people. We see a lot of promise in web services in general and MOBY in 
particular and Im hoping I can get some more of our teams to buy in, 
particularly when they see that their data can be made available via 
Taverna, etc. for free. Any guesstimates of the costs when you have 
some idea would be welcome so I can see who I can afford to bring 
along.

There is an increasing interest in developing ontologies, addressing 
datasharing, etc. in the cardiovascular arena here in the US and I 
would also be interested in chatting with you some more about your 
plans for CardioSHARE and how we might align our work at MCW to achieve 
this common goal.

Cheers,

	Simon.


On Feb 9, 2005, at 1:54 PM, Mark Wilkinson wrote:

> Hi MOBYers!
>
> It's getting to that time again - time for the next (but hopefully not
> last... touch wood!) BioMOBY developers meeting!
>
> Due to overwhelming requests I am happy to host it here in Vancouver
> again.  Alternately, and at higher cost, we could host it in a more
> exotic location such as the spectacular Whistler Ski Resort (site of 
> the
> 2010 winter olympics - about 1.5 hours north of Vancouver).
>
> The dates are pretty limited.  It appears that the first weekend of May
> (7th and 8th) is clear of other conferences that people might want to
> attend.
>
> Keeping with tradition, I will be using my Genome Canada grant to pay
> for as much of the local expenses as I can afford, so hopefully the
> charge to each of you will be primarily for travel, with only a little
> bit to cover room and board.
>
> So... a few questions:
>
> 1)  Are the dates (May 7-8) going to work for the majority of you core
> developers?
>
> 2)  Do you want to meet in Vancouver, or should we make our potentially
> last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
> Rebecca, we can play hackeysac in either location ;-) )
>
> 3)  *** Can people please contact me ASAP indicating their interest in
> attending so that I can ballpark the expenses and work out how much I
> can afford to supplement from my grant ***
>
> 4)  Is there now sufficient interest in MOBY that it is worth having
> back-to-back developers and implementers meetings?  If you are not a
> "core developer", but would be interested in attending a one-day
> hands-on meeting with people who have experience in building MOBY
> Services please let me know.  If there is sufficient interest I'll see
> if I can arrange something like this.
>
>
> Looking forward to seeing you all again soon!
>
> Mark
>
>
> -- 
> Mark Wilkinson
> Assistant Professor (Bioinformatics)
> Dept. Medical Genetics, UBC, Canada
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw

_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From simont at mcw.edu  Tue Feb 15 00:18:58 2005
From: simont at mcw.edu (Twigger Simon)
Date: Mon, 14 Feb 2005 23:18:58 -0600
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
In-Reply-To: <200502150401.j1F41oKr013946@portal.open-bio.org>
References: <200502150401.j1F41oKr013946@portal.open-bio.org>
Message-ID: <186E1ACA-7F11-11D9-83B7-000A959D1D82@mcw.edu>

Hi Mark,

I'll see how things are looking and get the documentation together. The 
basic goal was to create some basic classes to simplify access to the 
MOBY payload of a webservice call so that we could concentrate on 
getting the services up rather than parsing the MOBY XML and rewriting 
the XML prior to returning the result. We've been using Axis to handle 
the webservice part of the equation, we've created some core classes 
and have a simple test service prototype that we are gearing up to do 
something meaningful with. If you have people doing similar things it 
would be great to get an overview of what you are working on too so we 
can divide and conquer where possible.

Simon.


On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:

> Hey Simon,
>
> Please post to the mailing list with your moby java activities since I 
> have several people doing similar things - no point in duplicating 
> effort if we can split the work :-)
>
> I'll be posting the URL for the registration page before weeks end - 
> I'm just waiting for a quote on the room rate.
>
> Cheers!
>
> M
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw


--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw



From ywong at infobiogen.fr  Tue Feb 15 03:18:47 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Tue, 15 Feb 2005 09:18:47 +0100 (CET)
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <32818.195.221.101.193.1108455527.squirrel@195.221.101.193>

Hi,
  I know that someone at mips (Octave Noubibou) is also working on that
field, on my side, I have an API in Java (based on the Python API) that
helps me to build moby webservices (with axis or j2ee)

> Hi Mark,
>
> I'll see how things are looking and get the documentation together. The
> basic goal was to create some basic classes to simplify access to the
> MOBY payload of a webservice call so that we could concentrate on
> getting the services up rather than parsing the MOBY XML and rewriting
> the XML prior to returning the result. We've been using Axis to handle
> the webservice part of the equation, we've created some core classes
> and have a simple test service prototype that we are gearing up to do
> something meaningful with. If you have people doing similar things it
> would be great to get an overview of what you are working on too so we
> can divide and conquer where possible.
>
> Simon.
>
>
> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>
>> Hey Simon,
>>
>> Please post to the mailing list with your moby java activities since I
>> have several people doing similar things - no point in duplicating
>> effort if we can split the work :-)
>>
>> I'll be posting the URL for the registration page before weeks end -
>> I'm just waiting for a quote on the room rate.
>>
>> Cheers!
>>
>> M
> --
>
> Simon N. Twigger, Ph.D.
> Assistant Professor, Department of Physiology
> Medical College of Wisconsin
> 8701 Watertown Plank Road,
> Milwaukee, WI, USA
> tel: 414-456-8802
> fax: 414-456-6595
> AIM/iChat: simontatmcw
>
>
> --
>
> Simon N. Twigger, Ph.D.
> Assistant Professor, Department of Physiology
> Medical College of Wisconsin
> 8701 Watertown Plank Road,
> Milwaukee, WI, USA
> tel: 414-456-8802
> fax: 414-456-6595
> AIM/iChat: simontatmcw
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From mwilkinson at mrl.ubc.ca  Tue Feb 15 10:01:50 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 15 Feb 2005 07:01:50 -0800
Subject: [MOBY-dev] MOBY Service code developments
Message-ID: <1108479710.24515.22.camel@mobycentral.icapture.ubc.ca>

I think both Ben and Eddie are working on things like this as well.  Ben
is at a course doing "wet" work (ugh!) this week, but Eddie should be
on-line somewhere.

Xref'ing with each other early on would probably be worthwhile - divide
and conquer :-)

I found in Perl that the code used by services was often identical to
that used by clients, so I ended up putting these kinds of routines into
a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
considering that rather than coding service/client specific modules...
if you haven't already.

M


-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
-------------- next part --------------
An embedded message was scrubbed...
From: ywong at infobiogen.fr
Subject: [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
Date: Tue, 15 Feb 2005 09:18:47 +0100 (CET)
Size: 4684
Url: http://www.biomoby.org/pipermail/moby-dev/attachments/20050215/0c9de6b1/attachment.mht

From bmg at sfu.ca  Tue Feb 15 11:16:16 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Tue, 15 Feb 2005 08:16:16 -0800
Subject: [MOBY-dev] java api
Message-ID: <42122050.400@sfu.ca>

Hi moby-dev,

 I think this from Simon sums up something that would be handy for 
everyone in the jMoby group - both client and service providers -(that 
hasn't written their own version already).

The
> basic goal was to create some basic classes to simplify access to the
> MOBY payload of a webservice call so that we could concentrate on
> getting the services up rather than parsing the MOBY XML and rewriting
> the XML prior to returning the result.

I don't really know the protocol here, but perhaps someone could post an 
Interface that others could check out, comment on, and code to?  Or 
perhaps some one already has a good solution?

-Ben


------------------------------------------------------------------------

Subject:
MOBY Service code developments
From:
Mark Wilkinson <mwilkinson at mrl.ubc.ca>
Date:
Tue, 15 Feb 2005 07:01:50 -0800

To:
Ben Good <bgood at mrl.ubc.ca>, Eddie Kawas <ed.kawas at gmail.com>, mobydev 
<moby-dev at biomoby.org>


I think both Ben and Eddie are working on things like this as well.  Ben
is at a course doing "wet" work (ugh!) this week, but Eddie should be
on-line somewhere.

Xref'ing with each other early on would probably be worthwhile - divide
and conquer  :-) 

I found in Perl that the code used by services was often identical to
that used by clients, so I ended up putting these kinds of routines into
a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
considering that rather than coding service/client specific modules...
if you haven't already.

M


-- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical 
Genetics, UBC, Canada


------------------------------------------------------------------------

Subject:
[moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
From:
ywong at infobiogen.fr
Date:
Tue, 15 Feb 2005 09:18:47 +0100 (CET)

To:
"Core developer announcements" <moby-dev at portal.open-bio.org>


Hi,
  I know that someone at mips (Octave Noubibou) is also working on that
field, on my side, I have an API in Java (based on the Python API) that
helps me to build moby webservices (with axis or j2ee)


>> Hi Mark,
>>
>> I'll see how things are looking and get the documentation together. The
>> basic goal was to create some basic classes to simplify access to the
>> MOBY payload of a webservice call so that we could concentrate on
>> getting the services up rather than parsing the MOBY XML and rewriting
>> the XML prior to returning the result. We've been using Axis to handle
>> the webservice part of the equation, we've created some core classes
>> and have a simple test service prototype that we are gearing up to do
>> something meaningful with. If you have people doing similar things it
>> would be great to get an overview of what you are working on too so we
>> can divide and conquer where possible.
>>
>> Simon.
>>
>>
>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>
>  
>
>>>> Hey Simon,
>>>>
>>>> Please post to the mailing list with your moby java activities since I
>>>> have several people doing similar things - no point in duplicating
>>>> effort if we can split the work  :-) 
>>>>
>>>> I'll be posting the URL for the registration page before weeks end -
>>>> I'm just waiting for a quote on the room rate.
>>>>
>>>> Cheers!
>>>>
>>>> M
>>    
>>
>> --
>>
>> Simon N. Twigger, Ph.D.
>> Assistant Professor, Department of Physiology
>> Medical College of Wisconsin
>> 8701 Watertown Plank Road,
>> Milwaukee, WI, USA
>> tel: 414-456-8802
>> fax: 414-456-6595
>> AIM/iChat: simontatmcw
>>
>>
>> --
>>
>> Simon N. Twigger, Ph.D.
>> Assistant Professor, Department of Physiology
>> Medical College of Wisconsin
>> 8701 Watertown Plank Road,
>> Milwaukee, WI, USA
>> tel: 414-456-8802
>> fax: 414-456-6595
>> AIM/iChat: simontatmcw
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>  
>


_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev



From edward.kawas at gmail.com  Tue Feb 15 11:35:14 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 15 Feb 2005 08:35:14 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
Message-ID: <421224c7.7ea94a2b.4fa7.0513@smtp.gmail.com>

Hi,

Ben and I just coded some methods that given certain inputs
create DOM elements, parse them, etc for Moby Objects. I
attached the javadoc for them to this message (ignore the
package name and we probably will rethink the method names,
but just as an example take a look). 

Is this something similar to what people would like for
services? I think that Ben is right and that we should
create some interfaces containing methods that people would
find useful and then we could code them. Right now I think
that there is an awful lot of code duplication.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Benjamin
> Good
> Sent: Tuesday, February 15, 2005 8:16 AM
> To: moby-dev at biomoby.org
> Subject: [MOBY-dev] java api
> 
> Hi moby-dev,
> 
>  I think this from Simon sums up something that would be
> handy for
> everyone in the jMoby group - both client and service
> providers -(that
> hasn't written their own version already).
> 
> The
> > basic goal was to create some basic classes to simplify
> access to the
> > MOBY payload of a webservice call so that we could
> concentrate on
> > getting the services up rather than parsing the MOBY XML
> and rewriting
> > the XML prior to returning the result.
> 
> I don't really know the protocol here, but perhaps someone
> could post an
> Interface that others could check out, comment on, and
> code to?  Or
> perhaps some one already has a good solution?
> 
> -Ben
> 
> 
> ----------------------------------------------------------
> --------------
> 
> Subject:
> MOBY Service code developments
> From:
> Mark Wilkinson <mwilkinson at mrl.ubc.ca>
> Date:
> Tue, 15 Feb 2005 07:01:50 -0800
> 
> To:
> Ben Good <bgood at mrl.ubc.ca>, Eddie Kawas
> <ed.kawas at gmail.com>, mobydev
> <moby-dev at biomoby.org>
> 
> 
> I think both Ben and Eddie are working on things like this
> as well.  Ben
> is at a course doing "wet" work (ugh!) this week, but
> Eddie should be
> on-line somewhere.
> 
> Xref'ing with each other early on would probably be
> worthwhile - divide
> and conquer  :-)
> 
> I found in Perl that the code used by services was often
> identical to
> that used by clients, so I ended up putting these kinds of
> routines into
> a "neutral" location (MOBY::CommonSubs).  It's probably
> worthwhile
> considering that rather than coding service/client
> specific modules...
> if you haven't already.
> 
> M
> 
> 
> -- Mark Wilkinson Assistant Professor (Bioinformatics)
> Dept. Medical
> Genetics, UBC, Canada
> 
> 
> ----------------------------------------------------------
> --------------
> 
> Subject:
> [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-
> announcement
> From:
> ywong at infobiogen.fr
> Date:
> Tue, 15 Feb 2005 09:18:47 +0100 (CET)
> 
> To:
> "Core developer announcements" <moby-dev at portal.open-
> bio.org>
> 
> 
> Hi,
>   I know that someone at mips (Octave Noubibou) is also
> working on that
> field, on my side, I have an API in Java (based on the
> Python API) that
> helps me to build moby webservices (with axis or j2ee)
> 
> 
> >> Hi Mark,
> >>
> >> I'll see how things are looking and get the
> documentation together. The
> >> basic goal was to create some basic classes to simplify
> access to the
> >> MOBY payload of a webservice call so that we could
> concentrate on
> >> getting the services up rather than parsing the MOBY
> XML and rewriting
> >> the XML prior to returning the result. We've been using
> Axis to handle
> >> the webservice part of the equation, we've created some
> core classes
> >> and have a simple test service prototype that we are
> gearing up to do
> >> something meaningful with. If you have people doing
> similar things it
> >> would be great to get an overview of what you are
> working on too so we
> >> can divide and conquer where possible.
> >>
> >> Simon.
> >>
> >>
> >> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
> >>
> >
> >
> >>>> Hey Simon,
> >>>>
> >>>> Please post to the mailing list with your moby java
> activities since I
> >>>> have several people doing similar things - no point
> in duplicating
> >>>> effort if we can split the work  :-)
> >>>>
> >>>> I'll be posting the URL for the registration page
> before weeks end -
> >>>> I'm just waiting for a quote on the room rate.
> >>>>
> >>>> Cheers!
> >>>>
> >>>> M
> >>
> >>
> >> --
> >>
> >> Simon N. Twigger, Ph.D.
> >> Assistant Professor, Department of Physiology
> >> Medical College of Wisconsin
> >> 8701 Watertown Plank Road,
> >> Milwaukee, WI, USA
> >> tel: 414-456-8802
> >> fax: 414-456-6595
> >> AIM/iChat: simontatmcw
> >>
> >>
> >> --
> >>
> >> Simon N. Twigger, Ph.D.
> >> Assistant Professor, Department of Physiology
> >> Medical College of Wisconsin
> >> 8701 Watertown Plank Road,
> >> Milwaukee, WI, USA
> >> tel: 414-456-8802
> >> fax: 414-456-6595
> >> AIM/iChat: simontatmcw
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> >
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Triples.html
Url: http://www.biomoby.org/pipermail/moby-dev/attachments/20050215/ebf2cf98/Triples.pl
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MobyObjectPrimitiveExtractor.html
Url: http://www.biomoby.org/pipermail/moby-dev/attachments/20050215/ebf2cf98/MobyObjectPrimitiveExtractor.pl

From gordonp at ucalgary.ca  Tue Feb 15 12:37:21 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 15 Feb 2005 10:37:21 -0700
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
References: <42122050.400@sfu.ca>
Message-ID: <42123351.6090206@ucalgary.ca>

Hi all,

    I'm replying directly to you since the mailing list gets confused 
over my various e-mail addresses and bounces messages (I'm trying to fix 
this).  We should definitely open a dialog even before the May meeting 
because it seems that a lot of people are trying to acheive the same 
goals, and I think  most of the code to do these things are already in 
place.  For parsing and outputting data, org.biomoby.client.MobyRequest 
should be able to act as both the client and server code as MOBY 
messages are the same from a formatting point of view.  MobyRequest is 
nice and robust too, because it uses namespace-aware XPath to grab the 
relevant payload data.

In principle you should also not need to touch the XML directly, and we 
are almost to that stage.  Martin created the base type classes for when 
he started the registration side of things in Java:

org.biomoby.shared.MobyData 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyData.html>
org.biomoby.shared.MobyPrimaryDataSimple 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyPrimaryDataSimple.html>
org.biomoby.shared.MobyPrimaryDataSet 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyPrimaryDataSet.html>

I then extended these classes for actual instances of MOBY data (so they 
can conveniently be used for querying MOBY central and running services):

*org.biomoby.shared.MobyDataSetInstance*
org.biomoby.shared.MobyDataSimpleInstance 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyDataSimpleInstance.html>*
**org.biomoby.shared.MobyDataFloat (arbitrary precision)*
*org.biomoby.shared.MobyDataInt (arbitrary precision)*
*org.biomoby.shared.MobyDataString

*And a convenience class for otherwise painful to parse data (ISO 8601):*

**org.biomoby.shared.MobyDataDateTime*

Since an object is always made up fundamentally of the base classes 
object, string, int and float, there should be no need to generate any 
more classes to hold the data.  The only thing that remains is defining 
the methods in MobyDataSimpleInstance to set the data members for 
composite objects (maybe addMember(MobyDataSimpleInstance)?) and perhaps 
do a run-time check against MOBY Central that the data type given in 
setDataType is fullfilled before to XML() is called.

I was thinking something like this (PDGJOB is probably the most complex 
objects registered right now):

MobyDataSimpleInstance mdsi = new MobyDataSimpleInstance(new MobyDataType("PDGJOB"), "random object name", "some object id");
mdsi.addMember(new MobyDataString("answerService", "put your favorite answer service name here"));
mdsi.addMember(new MobyDataString("authURI", "http://my.great.domain.org/"));

GregorianCalendar gc = new GregorianCalendar();
gc.add(Calendar.MINUTE, 10); // Time out in 10 minutes
mdsi.addMember(new MobyDataDateTime("timeout", gc);

mdsi.addMember(new MobyDataString("killcode", "12345");
mdsi.addMember(new MobyDataString("killService", "put your favorite kill service name here");


As  service provider, to get the MOBY enveloped required to send this 
back to a client we call:

Central worker = new CentralImpl ();
MobyRequest mr = new MobyRequest(worker);
String responseXML = mr.convertMOBYDataToMOBYRequest(mdsis);
/* proceed to send this response back through the SOAP call you've 
received to start this code execution*/

If we are the client and we were SENDING this data instead, we can 
simply use the MobyRequest built-in SOAP handling:

mr.setInput(mdsi);
Vector output = mr.invokeService();


My CDN$0.02 :-)

Paul


Benjamin Good wrote:

> Hi moby-dev,
>
> I think this from Simon sums up something that would be handy for 
> everyone in the jMoby group - both client and service providers -(that 
> hasn't written their own version already).
>
> The
>
>> basic goal was to create some basic classes to simplify access to the
>> MOBY payload of a webservice call so that we could concentrate on
>> getting the services up rather than parsing the MOBY XML and rewriting
>> the XML prior to returning the result.
>
>
> I don't really know the protocol here, but perhaps someone could post 
> an Interface that others could check out, comment on, and code to?  Or 
> perhaps some one already has a good solution?
>
> -Ben
>
>
> ------------------------------------------------------------------------
>
> Subject:
> MOBY Service code developments
> From:
> Mark Wilkinson <mwilkinson at mrl.ubc.ca>
> Date:
> Tue, 15 Feb 2005 07:01:50 -0800
>
> To:
> Ben Good <bgood at mrl.ubc.ca>, Eddie Kawas <ed.kawas at gmail.com>, mobydev 
> <moby-dev at biomoby.org>
>
>
> I think both Ben and Eddie are working on things like this as well.  Ben
> is at a course doing "wet" work (ugh!) this week, but Eddie should be
> on-line somewhere.
>
> Xref'ing with each other early on would probably be worthwhile - divide
> and conquer  :-)
> I found in Perl that the code used by services was often identical to
> that used by clients, so I ended up putting these kinds of routines into
> a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
> considering that rather than coding service/client specific modules...
> if you haven't already.
>
> M
>
>
> -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical 
> Genetics, UBC, Canada
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
> From:
> ywong at infobiogen.fr
> Date:
> Tue, 15 Feb 2005 09:18:47 +0100 (CET)
>
> To:
> "Core developer announcements" <moby-dev at portal.open-bio.org>
>
>
> Hi,
>  I know that someone at mips (Octave Noubibou) is also working on that
> field, on my side, I have an API in Java (based on the Python API) that
> helps me to build moby webservices (with axis or j2ee)
>
>
>>> Hi Mark,
>>>
>>> I'll see how things are looking and get the documentation together. The
>>> basic goal was to create some basic classes to simplify access to the
>>> MOBY payload of a webservice call so that we could concentrate on
>>> getting the services up rather than parsing the MOBY XML and rewriting
>>> the XML prior to returning the result. We've been using Axis to handle
>>> the webservice part of the equation, we've created some core classes
>>> and have a simple test service prototype that we are gearing up to do
>>> something meaningful with. If you have people doing similar things it
>>> would be great to get an overview of what you are working on too so we
>>> can divide and conquer where possible.
>>>
>>> Simon.
>>>
>>>
>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>
>>  
>>
>>>>> Hey Simon,
>>>>>
>>>>> Please post to the mailing list with your moby java activities 
>>>>> since I
>>>>> have several people doing similar things - no point in duplicating
>>>>> effort if we can split the work  :-)
>>>>> I'll be posting the URL for the registration page before weeks end -
>>>>> I'm just waiting for a quote on the room rate.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> M
>>>>
>>>   
>>> -- 
>>>
>>> Simon N. Twigger, Ph.D.
>>> Assistant Professor, Department of Physiology
>>> Medical College of Wisconsin
>>> 8701 Watertown Plank Road,
>>> Milwaukee, WI, USA
>>> tel: 414-456-8802
>>> fax: 414-456-6595
>>> AIM/iChat: simontatmcw
>>>
>>>
>>> -- 
>>>
>>> Simon N. Twigger, Ph.D.
>>> Assistant Professor, Department of Physiology
>>> Medical College of Wisconsin
>>> 8701 Watertown Plank Road,
>>> Milwaukee, WI, USA
>>> tel: 414-456-8802
>>> fax: 414-456-6595
>>> AIM/iChat: simontatmcw
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>  
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>



From gordonp at ucalgary.ca  Tue Feb 15 12:53:11 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 15 Feb 2005 10:53:11 -0700
Subject: [MOBY-dev] java api
In-Reply-To: <42123351.6090206@ucalgary.ca>
References: <42122050.400@sfu.ca> <42123351.6090206@ucalgary.ca>
Message-ID: <42123707.7060504@ucalgary.ca>

Hi Eddie,

    The attchment was blank for we, can you resend it directly?  Perhaps 
we could integrate this code into MobyDataSimpleInstance.getMembers() 
and MobyDataSimpleInstance.getMember(String name) methods?  Also, there 
was a typo in my example, it should have read:

String responseXML = mr.convertMOBYDataToMOBYRequest(mdsi, null);

Cheers!

Paul




From edward.kawas at gmail.com  Tue Feb 15 13:01:52 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 15 Feb 2005 10:01:52 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <42123707.7060504@ucalgary.ca>
Message-ID: <42123912.362bff4b.58cb.30c8@smtp.gmail.com>

Try: 
http://mobycentral.cbr.nrc.ca/applets/MobyObjectPrimitiveExt
ractor.html

and

http://mobycentral.cbr.nrc.ca/applets/Triples.html

Probably integrating this into MobyDataSimpleInstance would
be a good idea.

Eddie
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Paul Gordon
> Sent: Tuesday, February 15, 2005 9:53 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] java api
> 
> Hi Eddie,
> 
>     The attchment was blank for we, can you resend it
> directly?  Perhaps
> we could integrate this code into
> MobyDataSimpleInstance.getMembers()
> and MobyDataSimpleInstance.getMember(String name) methods?
> Also, there
> was a typo in my example, it should have read:
> 
> String responseXML = mr.convertMOBYDataToMOBYRequest(mdsi,
> null);
> 
> Cheers!
> 
> Paul
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From octave.noubibou at gsf.de  Wed Feb 16 06:19:09 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Wed, 16 Feb 2005 12:19:09 +0100
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
References: <42122050.400@sfu.ca>
Message-ID: <42132C2D.4010200@gsf.de>

Hi all,

as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since  
3  months  now. 
one of my first tasks was to provide a generic API to  simplify access 
to the pameters (queryID, namespace, id)
one needs from the moby input xml to run the services and also methods 
to generate moby conform xml result.

I have used DOM4J and XPATH to implement concrete classes for this purpose.
At the moment all you need to get your parameters is to use the method 
"allParsedData(inputxml)" no matter how complex the inputxml is.
This method return a vector of the form e.g.:

(((queryID1,ns,id))) for a simple type

or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a 
collection
 
or 
(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))  
for an input with 2 invocations, the first been a collection and the 
second a simple type.

currently i do not handle secondary articles, but this should not be 
difficult.

we habe tried in our java services and everything seems to be ok.

i am commenting the code now. once it is finished, i will like to share 
it with you for comment or rectification and of course use.
Is there any possibility to upload this in central repository?

best regards

octave

>
>
> Hi,
>  I know that someone at mips (Octave Noubibou) is also working on that
> field, on my side, I have an API in Java (based on the Python API) that
> helps me to build moby webservices (with axis or j2ee)
>
>
>>> Hi Mark,
>>>
>>> I'll see how things are looking and get the documentation together. The
>>> basic goal was to create some basic classes to simplify access to the
>>> MOBY payload of a webservice call so that we could concentrate on
>>> getting the services up rather than parsing the MOBY XML and rewriting
>>> the XML prior to returning the result. We've been using Axis to handle
>>> the webservice part of the equation, we've created some core classes
>>> and have a simple test service prototype that we are gearing up to do
>>> something meaningful with. If you have people doing similar things it
>>> would be great to get an overview of what you are working on too so we
>>> can divide and conquer where possible.
>>>
>>> Simon.
>>>
>>>
>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>



From ywong at infobiogen.fr  Wed Feb 16 08:02:14 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Wed, 16 Feb 2005 14:02:14 +0100 (CET)
Subject: [MOBY-dev] java api
In-Reply-To: <42132C2D.4010200@gsf.de>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
Message-ID: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>

Hi,
  My API was based on my Python API and uses Xerces library (but can use
any DOM API compatible library) and as for the Python library, was
intended to be generic:

  XML Moby String <-> Java Objects

  People should only use java object and serialize their results in moby
XML .

  The only thing it doesn't support (yet) is the PIB. It is also intended
to ease the building of java webservices without being tied to any
webservice's API (j2ee or axis or anything else)

  It can also execute moby webservices (client interface) but doesn't
support registration of objects/services to the bioMoby directory.

  For instance, the documentation of the API is just in plain javadoc  and
there are just two examples (client querying a bioMoby webservice and a
server serving moby contents)

  The client API can query the bioMoby directory (find a service)

  I can send the source and documentation to whom it may concern but
consider the code to be beta quality code :p ...

one example of usage:

    public String aHelloWorld(String mobyContent) throws
MobyParserException {
        MobyContent mobyInput=new MobyContent();
        MobyContent mobyOutput=new MobyContent(this.authority, this.notes);

        mobyInput.fromXML(mobyContent);

        /*browse all the queries */
        Iterator iterator=mobyInput.keys().iterator();

        while (iterator.hasNext()) {
            String queryID=(String)iterator.next();

            MobyQuery mq=mobyInput.getQuery(queryID);
            MobyQuery queryResult=new MobyQuery(queryID);

            if (mq.getObjects().size()>0) {
                MobyObject o=(MobyObject)mq.getObjects().elementAt(0);

                queryResult.addObject(o);
                queryResult.addObject(new MobyObject(o.getArticleName(),
"Global_Keyword", "hello world"));

                mobyOutput.setQuery(queryResult);
            }
        }

        return mobyOutput.toXML();
    }


Don't know if it is easy enough...

> Hi all,
>
> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since
> 3  months  now.
> one of my first tasks was to provide a generic API to  simplify access
> to the pameters (queryID, namespace, id)
> one needs from the moby input xml to run the services and also methods
> to generate moby conform xml result.
>
> I have used DOM4J and XPATH to implement concrete classes for this
> purpose.
> At the moment all you need to get your parameters is to use the method
> "allParsedData(inputxml)" no matter how complex the inputxml is.
> This method return a vector of the form e.g.:
>
> (((queryID1,ns,id))) for a simple type
>
> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
> collection
>
> or
> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
> for an input with 2 invocations, the first been a collection and the
> second a simple type.
>
> currently i do not handle secondary articles, but this should not be
> difficult.
>
> we habe tried in our java services and everything seems to be ok.
>
> i am commenting the code now. once it is finished, i will like to share
> it with you for comment or rectification and of course use.
> Is there any possibility to upload this in central repository?
>
> best regards
>
> octave
>
>>
>>
>> Hi,
>>  I know that someone at mips (Octave Noubibou) is also working on that
>> field, on my side, I have an API in Java (based on the Python API) that
>> helps me to build moby webservices (with axis or j2ee)
>>
>>
>>>> Hi Mark,
>>>>
>>>> I'll see how things are looking and get the documentation together.
>>>> The
>>>> basic goal was to create some basic classes to simplify access to the
>>>> MOBY payload of a webservice call so that we could concentrate on
>>>> getting the services up rather than parsing the MOBY XML and rewriting
>>>> the XML prior to returning the result. We've been using Axis to handle
>>>> the webservice part of the equation, we've created some core classes
>>>> and have a simple test service prototype that we are gearing up to do
>>>> something meaningful with. If you have people doing similar things it
>>>> would be great to get an overview of what you are working on too so we
>>>> can divide and conquer where possible.
>>>>
>>>> Simon.
>>>>
>>>>
>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From ywong at infobiogen.fr  Wed Feb 16 09:30:43 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Wed, 16 Feb 2005 15:30:43 +0100 (CET)
Subject: [MOBY-dev] java api
In-Reply-To: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
Message-ID: <34006.195.221.101.193.1108564243.squirrel@195.221.101.193>

PS: I've put the sources at this url:
    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2

    you'll need a login and password:
    login: Invite
    password: invite

    Documentation of the API is in <wsGenoplante_src_dir>/dist/
    a compiled jar is also in this directory

    You'll find the two examples in the <jws_src_dir>/src/ directory
    To setup the webservice (in the case of axis) just copy the
MobyWebService.java to the axis directory as a jws file:

   cp <jws_src_dir>/src/MobyWebService.java
<jakarta_instance_directory>/webapps/axis/

  and use Perl, Python Java API to query the service :p

  A more exhaustive documentation of the API will be produced but I lack
some time doing it... (maybe just look at the examples to have an idea)

  The two projects were written using netbeans 4.0 but the ant file should
work without it:

 build from source:
 $ant
 the resulting jar will be found in the dist directory
<wsGenoplante_src_dir>/dist/wsGenoplante.jar

> Hi,
>   My API was based on my Python API and uses Xerces library (but can use
> any DOM API compatible library) and as for the Python library, was
> intended to be generic:
>
>   XML Moby String <-> Java Objects
>
>   People should only use java object and serialize their results in moby
> XML .
>
>   The only thing it doesn't support (yet) is the PIB. It is also intended
> to ease the building of java webservices without being tied to any
> webservice's API (j2ee or axis or anything else)
>
>   It can also execute moby webservices (client interface) but doesn't
> support registration of objects/services to the bioMoby directory.
>
>   For instance, the documentation of the API is just in plain javadoc  and
> there are just two examples (client querying a bioMoby webservice and a
> server serving moby contents)
>
>   The client API can query the bioMoby directory (find a service)
>
>   I can send the source and documentation to whom it may concern but
> consider the code to be beta quality code :p ...
>
> one example of usage:
>
>     public String aHelloWorld(String mobyContent) throws
> MobyParserException {
>         MobyContent mobyInput=new MobyContent();
>         MobyContent mobyOutput=new MobyContent(this.authority,
> this.notes);
>
>         mobyInput.fromXML(mobyContent);
>
>         /*browse all the queries */
>         Iterator iterator=mobyInput.keys().iterator();
>
>         while (iterator.hasNext()) {
>             String queryID=(String)iterator.next();
>
>             MobyQuery mq=mobyInput.getQuery(queryID);
>             MobyQuery queryResult=new MobyQuery(queryID);
>
>             if (mq.getObjects().size()>0) {
>                 MobyObject o=(MobyObject)mq.getObjects().elementAt(0);
>
>                 queryResult.addObject(o);
>                 queryResult.addObject(new MobyObject(o.getArticleName(),
> "Global_Keyword", "hello world"));
>
>                 mobyOutput.setQuery(queryResult);
>             }
>         }
>
>         return mobyOutput.toXML();
>     }
>
>
> Don't know if it is easy enough...
>
>> Hi all,
>>
>> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since
>> 3  months  now.
>> one of my first tasks was to provide a generic API to  simplify access
>> to the pameters (queryID, namespace, id)
>> one needs from the moby input xml to run the services and also methods
>> to generate moby conform xml result.
>>
>> I have used DOM4J and XPATH to implement concrete classes for this
>> purpose.
>> At the moment all you need to get your parameters is to use the method
>> "allParsedData(inputxml)" no matter how complex the inputxml is.
>> This method return a vector of the form e.g.:
>>
>> (((queryID1,ns,id))) for a simple type
>>
>> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>> collection
>>
>> or
>> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>> for an input with 2 invocations, the first been a collection and the
>> second a simple type.
>>
>> currently i do not handle secondary articles, but this should not be
>> difficult.
>>
>> we habe tried in our java services and everything seems to be ok.
>>
>> i am commenting the code now. once it is finished, i will like to share
>> it with you for comment or rectification and of course use.
>> Is there any possibility to upload this in central repository?
>>
>> best regards
>>
>> octave
>>
>>>
>>>
>>> Hi,
>>>  I know that someone at mips (Octave Noubibou) is also working on that
>>> field, on my side, I have an API in Java (based on the Python API) that
>>> helps me to build moby webservices (with axis or j2ee)
>>>
>>>
>>>>> Hi Mark,
>>>>>
>>>>> I'll see how things are looking and get the documentation together.
>>>>> The
>>>>> basic goal was to create some basic classes to simplify access to the
>>>>> MOBY payload of a webservice call so that we could concentrate on
>>>>> getting the services up rather than parsing the MOBY XML and
>>>>> rewriting
>>>>> the XML prior to returning the result. We've been using Axis to
>>>>> handle
>>>>> the webservice part of the equation, we've created some core classes
>>>>> and have a simple test service prototype that we are gearing up to do
>>>>> something meaningful with. If you have people doing similar things it
>>>>> would be great to get an overview of what you are working on too so
>>>>> we
>>>>> can divide and conquer where possible.
>>>>>
>>>>> Simon.
>>>>>
>>>>>
>>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From bmg at sfu.ca  Wed Feb 16 20:20:44 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed, 16 Feb 2005 17:20:44 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
Message-ID: <4213F16C.5030302@sfu.ca>

ywong at infobiogen.fr wrote:

>Hi,
>  My API was based on my Python API and uses Xerces library (but can use
>any DOM API compatible library) and as for the Python library, was
>intended to be generic:
>
>  XML Moby String <-> Java Objects
>  
>
Does this mean that you have a Java object for each Moby data-type 
(Object, DNASequence...) ?

-Ben



From bmg at sfu.ca  Wed Feb 16 20:23:01 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed, 16 Feb 2005 17:23:01 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <42132C2D.4010200@gsf.de>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
Message-ID: <4213F1F5.4020202@sfu.ca>

What about accessing the rest of the contents of the data in a MobyData 
block (ie the primitive values)?

-Ben

Octave Noubibou wrote:

> Hi all,
>
> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS 
> since  3  months  now. one of my first tasks was to provide a generic 
> API to  simplify access to the pameters (queryID, namespace, id)
> one needs from the moby input xml to run the services and also methods 
> to generate moby conform xml result.
>
> I have used DOM4J and XPATH to implement concrete classes for this 
> purpose.
> At the moment all you need to get your parameters is to use the method 
> "allParsedData(inputxml)" no matter how complex the inputxml is.
> This method return a vector of the form e.g.:
>
> (((queryID1,ns,id))) for a simple type
>
> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a 
> collection
>
> or 
> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))  
> for an input with 2 invocations, the first been a collection and the 
> second a simple type.
>
> currently i do not handle secondary articles, but this should not be 
> difficult.
>
> we habe tried in our java services and everything seems to be ok.
>
> i am commenting the code now. once it is finished, i will like to 
> share it with you for comment or rectification and of course use.
> Is there any possibility to upload this in central repository?
>
> best regards
>
> octave
>
>>
>>
>> Hi,
>>  I know that someone at mips (Octave Noubibou) is also working on that
>> field, on my side, I have an API in Java (based on the Python API) that
>> helps me to build moby webservices (with axis or j2ee)
>>
>>
>>>> Hi Mark,
>>>>
>>>> I'll see how things are looking and get the documentation together. 
>>>> The
>>>> basic goal was to create some basic classes to simplify access to the
>>>> MOBY payload of a webservice call so that we could concentrate on
>>>> getting the services up rather than parsing the MOBY XML and rewriting
>>>> the XML prior to returning the result. We've been using Axis to handle
>>>> the webservice part of the equation, we've created some core classes
>>>> and have a simple test service prototype that we are gearing up to do
>>>> something meaningful with. If you have people doing similar things it
>>>> would be great to get an overview of what you are working on too so we
>>>> can divide and conquer where possible.
>>>>
>>>> Simon.
>>>>
>>>>
>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>



From ywong at infobiogen.fr  Thu Feb 17 03:39:18 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Thu, 17 Feb 2005 09:39:18 +0100 (CET)
Subject: [MOBY-dev] java api
In-Reply-To: <4213F1F5.4020202@sfu.ca>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<4213F1F5.4020202@sfu.ca>
Message-ID: <32888.195.221.101.193.1108629558.squirrel@195.221.101.193>

Hi,
  No, unlike Python, I can't generate on the fly classes so the MobyObject
class is generic, it describes an Moby XML object as a class with
attributes:

  -prefix (default is moby, for XML serialization)
  -tag (for the XML serialization and specify what kind of Moby object it is)
  -namespace (Moby namespace eg AGI_LocusCode)
  -id (object identifier)
  -articleName (name of this object)
  -other moby objects (described in the ontology)
  -a raw content (the serializer only require this object to have a
toString method)

To determine what kind of object it is, I just look at the tag property
with a getTag method.

It is possible to build a specific object from this one using inheritance.

This structure should be enough exhaustive to describe all possible Moby
objects:

    <Object1 namespace="aNamespace" id="anId">
        <Object2 articleName="something">
            <Object3 articleName="A">
                   <Xref .../>
                   <Xref ...>Description</Xref>
                   RAW CONTENT for Object with article Name A
            </Object3>
        </Object2>
        <Object4 namespace="aNamespace" id="anId"/>
        RAW Content for Object 1
    </Object1>

Just have a look at the MobyObject class and the example MobyWebservice
(the method getRandomDNASequence return a DNA sequence object).

Yan

> What about accessing the rest of the contents of the data in a MobyData
> block (ie the primitive values)?
>
> -Ben
>
> Octave Noubibou wrote:
>
>> Hi all,
>>
>> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>> since  3  months  now. one of my first tasks was to provide a generic
>> API to  simplify access to the pameters (queryID, namespace, id)
>> one needs from the moby input xml to run the services and also methods
>> to generate moby conform xml result.
>>
>> I have used DOM4J and XPATH to implement concrete classes for this
>> purpose.
>> At the moment all you need to get your parameters is to use the method
>> "allParsedData(inputxml)" no matter how complex the inputxml is.
>> This method return a vector of the form e.g.:
>>
>> (((queryID1,ns,id))) for a simple type
>>
>> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>> collection
>>
>> or
>> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>> for an input with 2 invocations, the first been a collection and the
>> second a simple type.
>>
>> currently i do not handle secondary articles, but this should not be
>> difficult.
>>
>> we habe tried in our java services and everything seems to be ok.
>>
>> i am commenting the code now. once it is finished, i will like to
>> share it with you for comment or rectification and of course use.
>> Is there any possibility to upload this in central repository?
>>
>> best regards
>>
>> octave
>>
>>>
>>>
>>> Hi,
>>>  I know that someone at mips (Octave Noubibou) is also working on that
>>> field, on my side, I have an API in Java (based on the Python API) that
>>> helps me to build moby webservices (with axis or j2ee)
>>>
>>>
>>>>> Hi Mark,
>>>>>
>>>>> I'll see how things are looking and get the documentation together.
>>>>> The
>>>>> basic goal was to create some basic classes to simplify access to the
>>>>> MOBY payload of a webservice call so that we could concentrate on
>>>>> getting the services up rather than parsing the MOBY XML and
>>>>> rewriting
>>>>> the XML prior to returning the result. We've been using Axis to
>>>>> handle
>>>>> the webservice part of the equation, we've created some core classes
>>>>> and have a simple test service prototype that we are gearing up to do
>>>>> something meaningful with. If you have people doing similar things it
>>>>> would be great to get an overview of what you are working on too so
>>>>> we
>>>>> can divide and conquer where possible.
>>>>>
>>>>> Simon.
>>>>>
>>>>>
>>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From gordonp at ucalgary.ca  Thu Feb 17 10:21:41 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Thu, 17 Feb 2005 08:21:41 -0700
Subject: [MOBY-dev] java api
In-Reply-To: <32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<4213F1F5.4020202@sfu.ca>
	<32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
Message-ID: <4214B685.6090105@ucalgary.ca>

It's great to see all of this code coming out, who new there were so 
many Java MOBY developers! :-)

We should really think about how to consolidate the best parts of the 
everyone's code into a cohesive object hierarchy.  This can be a bit 
tricky, since it's easy to feel insulted because some great code you 
wrote doesn't make it into the amalgam.  In practice, current coders 
will probably continue to use the classes they have already developed, 
since they've build other code around it, so the amalgam is more for the 
benefit of new Java coders.  I'm volunteering myself to take some of Ben 
and Eddie's PIB and RDF type-checking code and fold it into the existing 
MobyDataSimpleInstance. 

Yan, I haven't looked thoroughly, does your Java code use Jython to 
access your underlying Python implementation of the API?

Simon, what data instance classes are you planning on using for the Axis 
streamlining?

>Hi,
>  No, unlike Python, I can't generate on the fly classes so the MobyObject
>class is generic, it describes an Moby XML object as a class with
>attributes:
>
>  -prefix (default is moby, for XML serialization)
>  -tag (for the XML serialization and specify what kind of Moby object it is)
>  -namespace (Moby namespace eg AGI_LocusCode)
>  -id (object identifier)
>  -articleName (name of this object)
>  -other moby objects (described in the ontology)
>  -a raw content (the serializer only require this object to have a
>toString method)
>
>To determine what kind of object it is, I just look at the tag property
>with a getTag method.
>
>It is possible to build a specific object from this one using inheritance.
>
>This structure should be enough exhaustive to describe all possible Moby
>objects:
>
>    <Object1 namespace="aNamespace" id="anId">
>        <Object2 articleName="something">
>            <Object3 articleName="A">
>                   <Xref .../>
>                   <Xref ...>Description</Xref>
>                   RAW CONTENT for Object with article Name A
>            </Object3>
>        </Object2>
>        <Object4 namespace="aNamespace" id="anId"/>
>        RAW Content for Object 1
>    </Object1>
>
>Just have a look at the MobyObject class and the example MobyWebservice
>(the method getRandomDNASequence return a DNA sequence object).
>
>Yan
>
>  
>
>>What about accessing the rest of the contents of the data in a MobyData
>>block (ie the primitive values)?
>>
>>-Ben
>>
>>Octave Noubibou wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>since  3  months  now. one of my first tasks was to provide a generic
>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>one needs from the moby input xml to run the services and also methods
>>>to generate moby conform xml result.
>>>
>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>purpose.
>>>At the moment all you need to get your parameters is to use the method
>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>This method return a vector of the form e.g.:
>>>
>>>(((queryID1,ns,id))) for a simple type
>>>
>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>collection
>>>
>>>or
>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>for an input with 2 invocations, the first been a collection and the
>>>second a simple type.
>>>
>>>currently i do not handle secondary articles, but this should not be
>>>difficult.
>>>
>>>we habe tried in our java services and everything seems to be ok.
>>>
>>>i am commenting the code now. once it is finished, i will like to
>>>share it with you for comment or rectification and of course use.
>>>Is there any possibility to upload this in central repository?
>>>
>>>best regards
>>>
>>>octave
>>>
>>>      
>>>
>>>>Hi,
>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>field, on my side, I have an API in Java (based on the Python API) that
>>>>helps me to build moby webservices (with axis or j2ee)
>>>>
>>>>
>>>>        
>>>>
>>>>>>Hi Mark,
>>>>>>
>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>The
>>>>>>basic goal was to create some basic classes to simplify access to the
>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>rewriting
>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>handle
>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>and have a simple test service prototype that we are gearing up to do
>>>>>>something meaningful with. If you have people doing similar things it
>>>>>>would be great to get an overview of what you are working on too so
>>>>>>we
>>>>>>can divide and conquer where possible.
>>>>>>
>>>>>>Simon.
>>>>>>
>>>>>>
>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev at biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>    
>>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>  
>



From ywong at infobiogen.fr  Thu Feb 17 10:34:50 2005
From: ywong at infobiogen.fr (ywong@infobiogen.fr)
Date: Thu, 17 Feb 2005 16:34:50 +0100 (CET)
Subject: [MOBY-dev] java api
In-Reply-To: <4214B685.6090105@ucalgary.ca>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<4213F1F5.4020202@sfu.ca>
	<32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
	<4214B685.6090105@ucalgary.ca>
Message-ID: <34198.195.221.101.193.1108654490.squirrel@195.221.101.193>

No, the API I wrote is 100% java :p, the Python API was the model on which
I based the development.


> It's great to see all of this code coming out, who new there were so
> many Java MOBY developers! :-)
>
> We should really think about how to consolidate the best parts of the
> everyone's code into a cohesive object hierarchy.  This can be a bit
> tricky, since it's easy to feel insulted because some great code you
> wrote doesn't make it into the amalgam.  In practice, current coders
> will probably continue to use the classes they have already developed,
> since they've build other code around it, so the amalgam is more for the
> benefit of new Java coders.  I'm volunteering myself to take some of Ben
> and Eddie's PIB and RDF type-checking code and fold it into the existing
> MobyDataSimpleInstance.
>
> Yan, I haven't looked thoroughly, does your Java code use Jython to
> access your underlying Python implementation of the API?
>
> Simon, what data instance classes are you planning on using for the Axis
> streamlining?
>
>>Hi,
>>  No, unlike Python, I can't generate on the fly classes so the
>> MobyObject
>>class is generic, it describes an Moby XML object as a class with
>>attributes:
>>
>>  -prefix (default is moby, for XML serialization)
>>  -tag (for the XML serialization and specify what kind of Moby object it
>> is)
>>  -namespace (Moby namespace eg AGI_LocusCode)
>>  -id (object identifier)
>>  -articleName (name of this object)
>>  -other moby objects (described in the ontology)
>>  -a raw content (the serializer only require this object to have a
>>toString method)
>>
>>To determine what kind of object it is, I just look at the tag property
>>with a getTag method.
>>
>>It is possible to build a specific object from this one using
>> inheritance.
>>
>>This structure should be enough exhaustive to describe all possible Moby
>>objects:
>>
>>    <Object1 namespace="aNamespace" id="anId">
>>        <Object2 articleName="something">
>>            <Object3 articleName="A">
>>                   <Xref .../>
>>                   <Xref ...>Description</Xref>
>>                   RAW CONTENT for Object with article Name A
>>            </Object3>
>>        </Object2>
>>        <Object4 namespace="aNamespace" id="anId"/>
>>        RAW Content for Object 1
>>    </Object1>
>>
>>Just have a look at the MobyObject class and the example MobyWebservice
>>(the method getRandomDNASequence return a DNA sequence object).
>>
>>Yan
>>
>>
>>
>>>What about accessing the rest of the contents of the data in a MobyData
>>>block (ie the primitive values)?
>>>
>>>-Ben
>>>
>>>Octave Noubibou wrote:
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>>since  3  months  now. one of my first tasks was to provide a generic
>>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>>one needs from the moby input xml to run the services and also methods
>>>>to generate moby conform xml result.
>>>>
>>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>>purpose.
>>>>At the moment all you need to get your parameters is to use the method
>>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>>This method return a vector of the form e.g.:
>>>>
>>>>(((queryID1,ns,id))) for a simple type
>>>>
>>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>>collection
>>>>
>>>>or
>>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>>for an input with 2 invocations, the first been a collection and the
>>>>second a simple type.
>>>>
>>>>currently i do not handle secondary articles, but this should not be
>>>>difficult.
>>>>
>>>>we habe tried in our java services and everything seems to be ok.
>>>>
>>>>i am commenting the code now. once it is finished, i will like to
>>>>share it with you for comment or rectification and of course use.
>>>>Is there any possibility to upload this in central repository?
>>>>
>>>>best regards
>>>>
>>>>octave
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>>field, on my side, I have an API in Java (based on the Python API)
>>>>> that
>>>>>helps me to build moby webservices (with axis or j2ee)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Hi Mark,
>>>>>>>
>>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>>The
>>>>>>>basic goal was to create some basic classes to simplify access to
>>>>>>> the
>>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>>rewriting
>>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>>handle
>>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>>and have a simple test service prototype that we are gearing up to
>>>>>>> do
>>>>>>>something meaningful with. If you have people doing similar things
>>>>>>> it
>>>>>>>would be great to get an overview of what you are working on too so
>>>>>>>we
>>>>>>>can divide and conquer where possible.
>>>>>>>
>>>>>>>Simon.
>>>>>>>
>>>>>>>
>>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev at biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev at biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>>
>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From mwilkinson at mobile.rogers.com  Sat Feb 19 02:38:30 2005
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Sat, 19 Feb 2005 02:38:30 -0500
Subject: [MOBY-dev] java api
Message-ID: <200502190736.j1J7aPKr002666@portal.open-bio.org>

Hi Paul, Aloha from Honolulu! (just a stopover on the way to Sydney, unfortunately...)


Thanks for the offer of your time in doing some java code merging!

I had planned to write a message to the group shortly in this regard, so now seems a good moment to do so :-). It seems to me that Eddie is a good choice for the person who makes the final decisions for the moby java codebase structure if only because he is currently employed to do java moby 100% of his time.  This doesn't mean that he wouldn't discuss it with everyone else, just that he would take the time (and responsibility) for taking the "best of the best" code and consolidating it into a unified API.

I was thinking that the next moby meeting (May) would be a good time to talk about this face-to-face and make sure everyone knows the strengths and limitations of each others code.

Na?  Opinions?

M


-----Original Message-----
From: Paul Gordon <gordonp at ucalgary.ca>
Date: Thu, 17 Feb 2005 08:21:41 
To:Core developer announcements <moby-dev at portal.open-bio.org>
Subject: Re: [MOBY-dev] java api

It's great to see all of this code coming out, who new there were so 
many Java MOBY developers! :-)

We should really think about how to consolidate the best parts of the 
everyone's code into a cohesive object hierarchy.  This can be a bit 
tricky, since it's easy to feel insulted because some great code you 
wrote doesn't make it into the amalgam.  In practice, current coders 
will probably continue to use the classes they have already developed, 
since they've build other code around it, so the amalgam is more for the 
benefit of new Java coders.  I'm volunteering myself to take some of Ben 
and Eddie's PIB and RDF type-checking code and fold it into the existing 
MobyDataSimpleInstance. 

Yan, I haven't looked thoroughly, does your Java code use Jython to 
access your underlying Python implementation of the API?

Simon, what data instance classes are you planning on using for the Axis 
streamlining?

>Hi,
>  No, unlike Python, I can't generate on the fly classes so the MobyObject
>class is generic, it describes an Moby XML object as a class with
>attributes:
>
>  -prefix (default is moby, for XML serialization)
>  -tag (for the XML serialization and specify what kind of Moby object it is)
>  -namespace (Moby namespace eg AGI_LocusCode)
>  -id (object identifier)
>  -articleName (name of this object)
>  -other moby objects (described in the ontology)
>  -a raw content (the serializer only require this object to have a
>toString method)
>
>To determine what kind of object it is, I just look at the tag property
>with a getTag method.
>
>It is possible to build a specific object from this one using inheritance.
>
>This structure should be enough exhaustive to describe all possible Moby
>objects:
>
>    <Object1 namespace="aNamespace" id="anId">
>        <Object2 articleName="something">
>            <Object3 articleName="A">
>                   <Xref .../>
>                   <Xref ...>Description</Xref>
>                   RAW CONTENT for Object with article Name A
>            </Object3>
>        </Object2>
>        <Object4 namespace="aNamespace" id="anId"/>
>        RAW Content for Object 1
>    </Object1>
>
>Just have a look at the MobyObject class and the example MobyWebservice
>(the method getRandomDNASequence return a DNA sequence object).
>
>Yan
>
>  
>
>>What about accessing the rest of the contents of the data in a MobyData
>>block (ie the primitive values)?
>>
>>-Ben
>>
>>Octave Noubibou wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>since  3  months  now. one of my first tasks was to provide a generic
>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>one needs from the moby input xml to run the services and also methods
>>>to generate moby conform xml result.
>>>
>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>purpose.
>>>At the moment all you need to get your parameters is to use the method
>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>This method return a vector of the form e.g.:
>>>
>>>(((queryID1,ns,id))) for a simple type
>>>
>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>collection
>>>
>>>or
>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>for an input with 2 invocations, the first been a collection and the
>>>second a simple type.
>>>
>>>currently i do not handle secondary articles, but this should not be
>>>difficult.
>>>
>>>we habe tried in our java services and everything seems to be ok.
>>>
>>>i am commenting the code now. once it is finished, i will like to
>>>share it with you for comment or rectification and of course use.
>>>Is there any possibility to upload this in central repository?
>>>
>>>best regards
>>>
>>>octave
>>>
>>>      
>>>
>>>>Hi,
>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>field, on my side, I have an API in Java (based on the Python API) that
>>>>helps me to build moby webservices (with axis or j2ee)
>>>>
>>>>
>>>>        
>>>>
>>>>>>Hi Mark,
>>>>>>
>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>The
>>>>>>basic goal was to create some basic classes to simplify access to the
>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>rewriting
>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>handle
>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>and have a simple test service prototype that we are gearing up to do
>>>>>>something meaningful with. If you have people doing similar things it
>>>>>>would be great to get an overview of what you are working on too so
>>>>>>we
>>>>>>can divide and conquer where possible.
>>>>>>
>>>>>>Simon.
>>>>>>
>>>>>>
>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev at biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>    
>>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>  
>

_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From edward.kawas at gmail.com  Wed Feb 23 01:02:47 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 22 Feb 2005 22:02:47 -0800
Subject: [MOBY-dev] java api
Message-ID: <421c1c8d.080cc2c8.5369.1953@smtp.gmail.com>

Hello Moby,

  I have been tasked with organizing and extending the jMoby
code.  My goal is to maximize the usefulness of what has
already been written and to provide a solid structure upon
which the next generations of jMoby can be based.  In
seeking to accomplish these goals I would like to start with
a discussion of what jMoby does well at the moment and what
it does not so well or does not do at all.  I'd like to use
this discussion to set some specific goals for the next
version of the API. 
 
Once these goals are clarified I would like to use them to
create a conceptually meaningful package hierarchy, slot the
existing classes into it, and to produce the interfaces for
the classes that need to be written. For instance, the
package "shared" could usefully be decomposed into a set of
more meaningful package names which would facilitate the use
of the code by newbies, reducing code duplication and
allowing us developers to be more efficient. The help and
participation from all the jMoby developers will be vital
for this revision to succeed.

Here are some questions I have about jMoby2005:
   Will we be supporting automatic generation of service
templates?  How (axis?)?  Will the library allow for the
addition of real wsdl descriptions of the services so that
client developers outside of the Moby community can use
their .NET/Axis tools to make use of Moby services?  How
will jMoby deal with service ontologies?  Is there interest
in providing GUI development support?

So, let's hear what you think about the future of jMoby!

Eddie Kawas

-B



From ed.kawas at gmail.com  Wed Feb 23 00:54:53 2005
From: ed.kawas at gmail.com (Eddie Kawas)
Date: Tue, 22 Feb 2005 21:54:53 -0800
Subject: [MOBY-dev] java api
Message-ID: <421c1ab0.13628b9a.6ca6.2fdf@smtp.gmail.com>

Hello Moby,

  I have been tasked with organizing and extending the jMoby
code.  My goal is to maximize the usefulness of what has
already been written and to provide a solid structure upon
which the next generations of jMoby can be based.  In
seeking to accomplish these goals I would like to start with
a discussion of what jMoby does well at the moment and what
it does not so well or does not do at all.  I'd like to use
this discussion to set some specific goals for the next
version of the API. 
 
Once these goals are clarified I would like to use them to
create a conceptually meaningful package hierarchy, slot the
existing classes into it, and to produce the interfaces for
the classes that need to be written. For instance, the
package "shared" could usefully be decomposed into a set of
more meaningful package names which would facilitate the use
of the code by newbies, reducing code duplication and
allowing us developers to be more efficient. The help and
participation from all the jMoby developers will be vital
for this revision to succeed.

Here are some questions I have about jMoby2005:
   Will we be supporting automatic generation of service
templates?  How (axis?)?  Will the library allow for the
addition of real wsdl descriptions of the services so that
client developers outside of the Moby community can use
their .NET/Axis tools to make use of Moby services?  How
will jMoby deal with service ontologies?  Is there interest
in providing GUI development support?

So, let's hear what you think about the future of jMoby!

Eddie Kawas

-B



From bmg at sfu.ca  Wed Feb 23 21:27:09 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed, 23 Feb 2005 18:27:09 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
	<34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
Message-ID: <421D3B7D.4040805@sfu.ca>

Hi Yan,

 I couldn't log in to check out your code, is it still there with Invite 
Invite ?

thanks
-Ben

regarding

PS: I've put the sources at this url:
    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2




From ywong at infobiogen.fr  Thu Feb 24 03:22:49 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Thu, 24 Feb 2005 09:22:49 +0100
Subject: [MOBY-dev] java api
In-Reply-To: <421D3B7D.4040805@sfu.ca>
References: <42122050.400@sfu.ca>	<42132C2D.4010200@gsf.de>	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>	<34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
	<421D3B7D.4040805@sfu.ca>
Message-ID: <421D8ED9.9030509@infobiogen.fr>

Benjamin Good wrote:

> Hi Yan,
>
> I couldn't log in to check out your code, is it still there with 
> Invite Invite ?
>
> thanks
> -Ben
>
> regarding
>
> PS: I've put the sources at this url:
>    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
>    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
It should be
login: Invite (first letter in caps)
password: invite (no caps at all)

I send you the two files... wsGenoplante.tar.bz2 contains the API and 
jws.tar.bz2 the examples of how to use it
they were developed with netbeans 4 but has a ant file (build.xml). A  
javadoc and a ready to use binary is also  provided in the  package
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wsGenoplante.tar.bz2
Type: application/octet-stream
Size: 33088 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050224/014f211d/wsGenoplante.tar-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jws.tar.bz2
Type: application/octet-stream
Size: 12818 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050224/014f211d/jws.tar-0002.obj

From duncan.hull at cs.man.ac.uk  Tue Feb  8 11:56:20 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue, 08 Feb 2005 11:56:20 +0000
Subject: [MOBY-dev] mobycentral down?
Message-ID: <4208A8E4.4040603@cs.man.ac.uk>

Dear moby-devvers

Is anyone else having a problem getting to 
http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl

???

Duncan


From senger at ebi.ac.uk  Tue Feb  8 12:04:57 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 8 Feb 2005 12:04:57 +0000 (GMT)
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208A8E4.4040603@cs.man.ac.uk>
Message-ID: <Pine.LNX.4.44.0502081204260.5027-100000@bagheera.ebi.ac.uk>

> Is anyone else having a problem getting to 
> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
   Works fine for me (Tue Feb  8 12:04:42 GMT 2005).
   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From sophie.durand at infobiogen.fr  Tue Feb  8 10:41:34 2005
From: sophie.durand at infobiogen.fr (Sophie Durand)
Date: Tue, 08 Feb 2005 11:41:34 +0100
Subject: [MOBY-dev] bug in MOBY::CommunSubs:getCrossReferences
Message-ID: <4208975E.6050201@infobiogen.fr>

Hello,

I have a problem while parsing the following moby output:

<?xml version='1.0' encoding='UTF-8'?><moby:MOBY
xmlns:moby='http://www.biomoby.org/moby'><moby:mobyContent
moby:authority='genoplante-info.infobiogen.fr'><moby:serviceNotes>GENOPLANTE 

PHYTOPROT. IDDN.FR.001.250004.000.S.P.2003.000.10300. This database, its
constitutive components and its documentation, are the intellectual
property of GENOPLANTE-VALOR.</moby:serviceNotes><moby:mobyData
moby:queryID='1'><moby:Collection
moby:articleName=''><moby:Simple><moby:Object
moby:namespace='AGI_LocusCode' moby:id='AT3G23130'
 ><CrossReference><moby:Object moby:namespace='PHYTOPROT_CLUSTER_Id' 
moby:id='148'
/></CrossReference></moby:Object></moby:Simple></moby:Collection></moby:mobyData></moby:mobyContent></moby:MOBY>

I'm using the Perl API with a genericServiceInputParser call and then a 
getCrossReferences call to obtain the cross reference. But in this case, 
I don't get any cross reference. If I delete the "moby:" namespaces like 
this :
<CrossReference><moby:Object namespace='PHYTOPROT_CLUSTER_Id'  id='148' 
/></CrossReference>
it works well.

So I looked in the code, and I modified the following function in 
MOBY::CommunSubs.pm, and then it works:

sub _makeObjectType {
     my ($xref) = @_;
     my $ns = $xref->getAttributeNode('namespace');
     $ns = $xref->getAttributeNode('moby:namespace') unless $ns;
     return undef unless $ns;
     my $id = $xref->getAttributeNode('id');
     $id = $xref->getAttributeNode('moby:id') unless $id;  # INSTEAD OF $ns
     return undef unless $id;
     my $XREF = MOBY::CrossReference->new(
         type => "object",
         namespace => $ns->getValue,
         id => $id->getValue,
      );
}

-- 
Sophie Durand
Ing?nieure en Bioinformatique
INRA / URGI chez Infobiogen
523, place des Terrasses de l'Agora
91000 Evry - FRANCE


From mwilkinson at mrl.ubc.ca  Tue Feb  8 17:21:46 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 08 Feb 2005 09:21:46 -0800
Subject: [moby] [MOBY-dev] bug in MOBY::CommunSubs:getCrossReferences
In-Reply-To: <4208975E.6050201@infobiogen.fr>
References: <4208975E.6050201@infobiogen.fr>
Message-ID: <1107883306.8689.75.camel@mobycentral.icapture.ubc.ca>

thanks!  Bug squashed.

M


On Tue, 2005-02-08 at 02:41, Sophie Durand wrote:
> Hello,
> 
> I have a problem while parsing the following moby output:
> 
> <?xml version='1.0' encoding='UTF-8'?><moby:MOBY
> xmlns:moby='http://www.biomoby.org/moby'><moby:mobyContent
> moby:authority='genoplante-info.infobiogen.fr'><moby:serviceNotes>GENOPLANTE 
> 
> PHYTOPROT. IDDN.FR.001.250004.000.S.P.2003.000.10300. This database, its
> constitutive components and its documentation, are the intellectual
> property of GENOPLANTE-VALOR.</moby:serviceNotes><moby:mobyData
> moby:queryID='1'><moby:Collection
> moby:articleName=''><moby:Simple><moby:Object
> moby:namespace='AGI_LocusCode' moby:id='AT3G23130'
>  ><CrossReference><moby:Object moby:namespace='PHYTOPROT_CLUSTER_Id' 
> moby:id='148'
> /></CrossReference></moby:Object></moby:Simple></moby:Collection></moby:mobyData></moby:mobyContent></moby:MOBY>
> 
> I'm using the Perl API with a genericServiceInputParser call and then a 
> getCrossReferences call to obtain the cross reference. But in this case, 
> I don't get any cross reference. If I delete the "moby:" namespaces like 
> this :
> <CrossReference><moby:Object namespace='PHYTOPROT_CLUSTER_Id'  id='148' 
> /></CrossReference>
> it works well.
> 
> So I looked in the code, and I modified the following function in 
> MOBY::CommunSubs.pm, and then it works:
> 
> sub _makeObjectType {
>      my ($xref) = @_;
>      my $ns = $xref->getAttributeNode('namespace');
>      $ns = $xref->getAttributeNode('moby:namespace') unless $ns;
>      return undef unless $ns;
>      my $id = $xref->getAttributeNode('id');
>      $id = $xref->getAttributeNode('moby:id') unless $id;  # INSTEAD OF $ns
>      return undef unless $id;
>      my $XREF = MOBY::CrossReference->new(
>          type => "object",
>          namespace => $ns->getValue,
>          id => $id->getValue,
>       );
> }
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada



From gss at ncgr.org  Tue Feb  8 17:35:46 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue, 08 Feb 2005 10:35:46 -0700
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208A8E4.4040603@cs.man.ac.uk>
References: <4208A8E4.4040603@cs.man.ac.uk>
Message-ID: <4208F872.3000105@ncgr.org>

Something indeed seems to be awry:

wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl

--10:30:24--  http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
           => `-'
Resolving mobycentral.cbr.nrc.ca... 198.166.4.151
Connecting to mobycentral.cbr.nrc.ca[198.166.4.151]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 411 Length Required
 2 Date: Tue, 08 Feb 2005 17:30:25 GMT
 3 Server: Apache/1.3.29 (Unix) mod_perl/1.29
 4 Connection: close
 5 Content-Type: text/plain
10:30:25 ERROR 411: Length Required.

// Gary

Duncan Hull wrote:

> Dear moby-devvers
>
> Is anyone else having a problem getting to 
> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
> ???
>
> Duncan
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>


From senger at ebi.ac.uk  Tue Feb  8 17:47:26 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 8 Feb 2005 17:47:26 +0000 (GMT)
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <4208F872.3000105@ncgr.org>
Message-ID: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>

> Something indeed seems to be awry:
> 
> wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>
   Let me claim again: according my test client contacting moby central,
everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
that wget should work properly? Moby central responses may not be good if
you contact it withour any SOAP message.

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger



From edward.kawas at gmail.com  Tue Feb  8 17:49:40 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 8 Feb 2005 09:49:40 -0800
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
Message-ID: <4208fbb5.7748301d.273c.55f3@smtp.gmail.com>

I second Martins' claim.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Tuesday, February 08, 2005 9:47 AM
> To: Core developer announcements
> Cc: Mark Wilkinson
> Subject: Re: [MOBY-dev] mobycentral down?
> 
> > Something indeed seems to be awry:
> >
> > wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-
> bin/MOBY05/mobycentral.pl
> >
>    Let me claim again: according my test client contacting
> moby central,
> everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why
> do you expect
> that wget should work properly? Moby central responses may
> not be good if
> you contact it withour any SOAP message.
> 
>    Martin
> 
> --
> Martin Senger
> 
> EMBL Outstation - Hinxton                Senger at EBI.ac.uk
> European Bioinformatics Institute        Phone: (+44) 1223
> 494636
> Wellcome Trust Genome Campus             (Switchboard:
> 494444)
> Hinxton                                  Fax  : (+44) 1223
> 494468
> Cambridge CB10 1SD
> United Kingdom
> http://industry.ebi.ac.uk/~senger
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From mwilkinson at mrl.ubc.ca  Tue Feb  8 18:32:08 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 08 Feb 2005 10:32:08 -0800
Subject: [moby] Re: [MOBY-dev] mobycentral down?
In-Reply-To: <4208F872.3000105@ncgr.org>
References: <4208A8E4.4040603@cs.man.ac.uk>  <4208F872.3000105@ncgr.org>
Message-ID: <1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>

Strange... I am having no problems with it today.  It passes all tests
both on the development and production server from a remote connection
to mobycentral.pl, and the CGI browser is working properly (local
connection).  

I do notice, however, that the services that rely on SeqHound are...
errr... not working properly is a mild way to say it ;-)  but that isn't
a MOBYCentral problem and I'm sure the SeqHound staff are already aware
of the problem.

...????  i dunno

I'll keep my eye on it for the rest of the day to see if i notice
anything unusual.  I wonder if it the same problem we have seen a few
times in the past few months with connections from Europe being
blocked??  We can't seem to track that one down - it is not happening on
our machines, we know that for sure... it is something elsewhere.

M



On Tue, 2005-02-08 at 09:35, Gary Schiltz wrote:
> Something indeed seems to be awry:
> 
> wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> 
> --10:30:24--  http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>            => `-'
> Resolving mobycentral.cbr.nrc.ca... 198.166.4.151
> Connecting to mobycentral.cbr.nrc.ca[198.166.4.151]:80... connected.
> HTTP request sent, awaiting response...
>  1 HTTP/1.1 411 Length Required
>  2 Date: Tue, 08 Feb 2005 17:30:25 GMT
>  3 Server: Apache/1.3.29 (Unix) mod_perl/1.29
>  4 Connection: close
>  5 Content-Type: text/plain
> 10:30:25 ERROR 411: Length Required.
> 
> // Gary
> 
> Duncan Hull wrote:
> 
> > Dear moby-devvers
> >
> > Is anyone else having a problem getting to 
> > http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> >
> > ???
> >
> > Duncan
> > _______________________________________________
> > MOBY-dev mailing list
> > MOBY-dev at biomoby.org
> > http://www.biomoby.org/mailman/listinfo/moby-dev
> >
> >
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada



From gss at ncgr.org  Tue Feb  8 17:56:25 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue, 08 Feb 2005 10:56:25 -0700
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
Message-ID: <4208FD49.1080508@ncgr.org>

As someone famous must have said, "What was I thinking?", or "Never 
mind", or even more succinctly, "Duh" :-) I suppose I was thinking of 
the URL for the gbrowse interface to MOBY.

// Gary

Martin Senger wrote:

>>Something indeed seems to be awry:
>>
>>wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
>>
>>
>   Let me claim again: according my test client contacting moby central,
>everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
>that wget should work properly? Moby central responses may not be good if
>you contact it withour any SOAP message.
>
>   Martin
>
>


From duncan.hull at cs.man.ac.uk  Tue Feb  8 18:18:49 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue, 08 Feb 2005 18:18:49 +0000
Subject: [MOBY-dev] mobycentral down?
In-Reply-To: <1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>
References: <4208A8E4.4040603@cs.man.ac.uk> <4208F872.3000105@ncgr.org>
	<1107887528.10238.26.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42090289.8010001@cs.man.ac.uk>

dear moby-devvers

re: my original message. For the record, mobycentral was temporarily 
unavailable from within Taverna, which may have been a local 
(Manchester) problem.

Its accessible again now...


Duncan

http://taverna.sourceforge.net/




From mwilkinson at mrl.ubc.ca  Tue Feb  8 19:06:41 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 08 Feb 2005 11:06:41 -0800
Subject: [moby] Re: [MOBY-dev] mobycentral down?
In-Reply-To: <4208FD49.1080508@ncgr.org>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>
	<4208FD49.1080508@ncgr.org>
Message-ID: <1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>

I think the correct quote is:

"Doh!"

	H.J.Simpson




On Tue, 2005-02-08 at 09:56, Gary Schiltz wrote:
> As someone famous must have said, "What was I thinking?", or "Never 
> mind", or even more succinctly, "Duh" :-) I suppose I was thinking of 
> the URL for the gbrowse interface to MOBY.
> 
> // Gary
> 
> Martin Senger wrote:
> 
> >>Something indeed seems to be awry:
> >>
> >>wget -S -O - http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl
> >>
> >>
> >   Let me claim again: according my test client contacting moby central,
> >everything works fine (Tue Feb  8 17:43:50 GMT 2005). Why do you expect
> >that wget should work properly? Moby central responses may not be good if
> >you contact it withour any SOAP message.
> >
> >   Martin
> >
> >
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada



From duncan.hull at cs.man.ac.uk  Tue Feb  8 19:01:02 2005
From: duncan.hull at cs.man.ac.uk (Duncan Hull)
Date: Tue, 08 Feb 2005 19:01:02 +0000
Subject: [MOBY-dev] Mobycentral D'oh?
In-Reply-To: <1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>
References: <Pine.OSF.4.21.0502081743060.1071865-100000@mozart.ebi.ac.uk>	<4208FD49.1080508@ncgr.org>
	<1107889601.10238.37.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42090C6E.8090902@cs.man.ac.uk>

Mark

Mark Wilkinson wrote:

>I think the correct quote is: "Doh!" 	H.J.Simpson
>  
>
Can't find it in Pubmed
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=pubmed&cmd=search&term=Simpson+HJ

Do you have the year/journal of publication? :)


Duncan


From mwilkinson at mrl.ubc.ca  Wed Feb  9 19:54:38 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 09 Feb 2005 11:54:38 -0800
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>

Hi MOBYers!

It's getting to that time again - time for the next (but hopefully not
last... touch wood!) BioMOBY developers meeting!

Due to overwhelming requests I am happy to host it here in Vancouver
again.  Alternately, and at higher cost, we could host it in a more
exotic location such as the spectacular Whistler Ski Resort (site of the
2010 winter olympics - about 1.5 hours north of Vancouver).

The dates are pretty limited.  It appears that the first weekend of May
(7th and 8th) is clear of other conferences that people might want to
attend.

Keeping with tradition, I will be using my Genome Canada grant to pay
for as much of the local expenses as I can afford, so hopefully the
charge to each of you will be primarily for travel, with only a little
bit to cover room and board.

So... a few questions:

1)  Are the dates (May 7-8) going to work for the majority of you core
developers?

2)  Do you want to meet in Vancouver, or should we make our potentially
last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
Rebecca, we can play hackeysac in either location ;-) )

3)  *** Can people please contact me ASAP indicating their interest in
attending so that I can ballpark the expenses and work out how much I
can afford to supplement from my grant ***

4)  Is there now sufficient interest in MOBY that it is worth having
back-to-back developers and implementers meetings?  If you are not a
"core developer", but would be interested in attending a one-day
hands-on meeting with people who have experience in building MOBY
Services please let me know.  If there is sufficient interest I'll see
if I can arrange something like this.


Looking forward to seeing you all again soon!

Mark


-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada



From simont at mcw.edu  Tue Feb 15 04:03:15 2005
From: simont at mcw.edu (Twigger Simon)
Date: Mon, 14 Feb 2005 22:03:15 -0600
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
In-Reply-To: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>
References: <1107978877.17164.70.camel@mobycentral.icapture.ubc.ca>
Message-ID: <849AE9B6-7F06-11D9-83B7-000A959D1D82@mcw.edu>

Hi Mark,

Sign me up, the 7/8th of May look good and Im willing to go to a blow 
out meeting or a normal one. :) We are working on some java axis 
libraries to make Java services easier to create. We have prototype 
code in place at the moment but have just brought on board a java guru 
so Im having him look things over and give his blessing before we 
inflict them on the world. If we have an agenda for the potential 
implementers meeting I'd like to see if I can interest a few more 
people. We see a lot of promise in web services in general and MOBY in 
particular and Im hoping I can get some more of our teams to buy in, 
particularly when they see that their data can be made available via 
Taverna, etc. for free. Any guesstimates of the costs when you have 
some idea would be welcome so I can see who I can afford to bring 
along.

There is an increasing interest in developing ontologies, addressing 
datasharing, etc. in the cardiovascular arena here in the US and I 
would also be interested in chatting with you some more about your 
plans for CardioSHARE and how we might align our work at MCW to achieve 
this common goal.

Cheers,

	Simon.


On Feb 9, 2005, at 1:54 PM, Mark Wilkinson wrote:

> Hi MOBYers!
>
> It's getting to that time again - time for the next (but hopefully not
> last... touch wood!) BioMOBY developers meeting!
>
> Due to overwhelming requests I am happy to host it here in Vancouver
> again.  Alternately, and at higher cost, we could host it in a more
> exotic location such as the spectacular Whistler Ski Resort (site of 
> the
> 2010 winter olympics - about 1.5 hours north of Vancouver).
>
> The dates are pretty limited.  It appears that the first weekend of May
> (7th and 8th) is clear of other conferences that people might want to
> attend.
>
> Keeping with tradition, I will be using my Genome Canada grant to pay
> for as much of the local expenses as I can afford, so hopefully the
> charge to each of you will be primarily for travel, with only a little
> bit to cover room and board.
>
> So... a few questions:
>
> 1)  Are the dates (May 7-8) going to work for the majority of you core
> developers?
>
> 2)  Do you want to meet in Vancouver, or should we make our potentially
> last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
> Rebecca, we can play hackeysac in either location ;-) )
>
> 3)  *** Can people please contact me ASAP indicating their interest in
> attending so that I can ballpark the expenses and work out how much I
> can afford to supplement from my grant ***
>
> 4)  Is there now sufficient interest in MOBY that it is worth having
> back-to-back developers and implementers meetings?  If you are not a
> "core developer", but would be interested in attending a one-day
> hands-on meeting with people who have experience in building MOBY
> Services please let me know.  If there is sufficient interest I'll see
> if I can arrange something like this.
>
>
> Looking forward to seeing you all again soon!
>
> Mark
>
>
> -- 
> Mark Wilkinson
> Assistant Professor (Bioinformatics)
> Dept. Medical Genetics, UBC, Canada
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw



From mwilkinson at mobile.rogers.com  Tue Feb 15 04:04:05 2005
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Mon, 14 Feb 2005 23:04:05 -0500
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <200502150401.j1F41oKr013946@portal.open-bio.org>

Hey Simon,

Please post to the mailing list with your moby java activities since I have several people doing similar things - no point in duplicating effort if we can split the work :-)

I'll be posting the URL for the registration page before weeks end - I'm just waiting for a quote on the room rate.

Cheers!

M

-----Original Message-----
From: Twigger Simon <simont at mcw.edu>
Date: Mon, 14 Feb 2005 22:03:15 
To:Core developer announcements <moby-dev at portal.open-bio.org>
Subject: Re: [MOBY-dev] BioMOBY developers meeting pre-announcement

Hi Mark,

Sign me up, the 7/8th of May look good and Im willing to go to a blow 
out meeting or a normal one. :) We are working on some java axis 
libraries to make Java services easier to create. We have prototype 
code in place at the moment but have just brought on board a java guru 
so Im having him look things over and give his blessing before we 
inflict them on the world. If we have an agenda for the potential 
implementers meeting I'd like to see if I can interest a few more 
people. We see a lot of promise in web services in general and MOBY in 
particular and Im hoping I can get some more of our teams to buy in, 
particularly when they see that their data can be made available via 
Taverna, etc. for free. Any guesstimates of the costs when you have 
some idea would be welcome so I can see who I can afford to bring 
along.

There is an increasing interest in developing ontologies, addressing 
datasharing, etc. in the cardiovascular arena here in the US and I 
would also be interested in chatting with you some more about your 
plans for CardioSHARE and how we might align our work at MCW to achieve 
this common goal.

Cheers,

	Simon.


On Feb 9, 2005, at 1:54 PM, Mark Wilkinson wrote:

> Hi MOBYers!
>
> It's getting to that time again - time for the next (but hopefully not
> last... touch wood!) BioMOBY developers meeting!
>
> Due to overwhelming requests I am happy to host it here in Vancouver
> again.  Alternately, and at higher cost, we could host it in a more
> exotic location such as the spectacular Whistler Ski Resort (site of 
> the
> 2010 winter olympics - about 1.5 hours north of Vancouver).
>
> The dates are pretty limited.  It appears that the first weekend of May
> (7th and 8th) is clear of other conferences that people might want to
> attend.
>
> Keeping with tradition, I will be using my Genome Canada grant to pay
> for as much of the local expenses as I can afford, so hopefully the
> charge to each of you will be primarily for travel, with only a little
> bit to cover room and board.
>
> So... a few questions:
>
> 1)  Are the dates (May 7-8) going to work for the majority of you core
> developers?
>
> 2)  Do you want to meet in Vancouver, or should we make our potentially
> last meeting a "big blow-out" and have it somewhere more exotic?  (yes,
> Rebecca, we can play hackeysac in either location ;-) )
>
> 3)  *** Can people please contact me ASAP indicating their interest in
> attending so that I can ballpark the expenses and work out how much I
> can afford to supplement from my grant ***
>
> 4)  Is there now sufficient interest in MOBY that it is worth having
> back-to-back developers and implementers meetings?  If you are not a
> "core developer", but would be interested in attending a one-day
> hands-on meeting with people who have experience in building MOBY
> Services please let me know.  If there is sufficient interest I'll see
> if I can arrange something like this.
>
>
> Looking forward to seeing you all again soon!
>
> Mark
>
>
> -- 
> Mark Wilkinson
> Assistant Professor (Bioinformatics)
> Dept. Medical Genetics, UBC, Canada
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw

_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From simont at mcw.edu  Tue Feb 15 05:18:58 2005
From: simont at mcw.edu (Twigger Simon)
Date: Mon, 14 Feb 2005 23:18:58 -0600
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
In-Reply-To: <200502150401.j1F41oKr013946@portal.open-bio.org>
References: <200502150401.j1F41oKr013946@portal.open-bio.org>
Message-ID: <186E1ACA-7F11-11D9-83B7-000A959D1D82@mcw.edu>

Hi Mark,

I'll see how things are looking and get the documentation together. The 
basic goal was to create some basic classes to simplify access to the 
MOBY payload of a webservice call so that we could concentrate on 
getting the services up rather than parsing the MOBY XML and rewriting 
the XML prior to returning the result. We've been using Axis to handle 
the webservice part of the equation, we've created some core classes 
and have a simple test service prototype that we are gearing up to do 
something meaningful with. If you have people doing similar things it 
would be great to get an overview of what you are working on too so we 
can divide and conquer where possible.

Simon.


On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:

> Hey Simon,
>
> Please post to the mailing list with your moby java activities since I 
> have several people doing similar things - no point in duplicating 
> effort if we can split the work :-)
>
> I'll be posting the URL for the registration page before weeks end - 
> I'm just waiting for a quote on the room rate.
>
> Cheers!
>
> M
--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw


--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw



From ywong at infobiogen.fr  Tue Feb 15 08:18:47 2005
From: ywong at infobiogen.fr (ywong at infobiogen.fr)
Date: Tue, 15 Feb 2005 09:18:47 +0100 (CET)
Subject: [MOBY-dev] BioMOBY developers meeting pre-announcement
Message-ID: <32818.195.221.101.193.1108455527.squirrel@195.221.101.193>

Hi,
  I know that someone at mips (Octave Noubibou) is also working on that
field, on my side, I have an API in Java (based on the Python API) that
helps me to build moby webservices (with axis or j2ee)

> Hi Mark,
>
> I'll see how things are looking and get the documentation together. The
> basic goal was to create some basic classes to simplify access to the
> MOBY payload of a webservice call so that we could concentrate on
> getting the services up rather than parsing the MOBY XML and rewriting
> the XML prior to returning the result. We've been using Axis to handle
> the webservice part of the equation, we've created some core classes
> and have a simple test service prototype that we are gearing up to do
> something meaningful with. If you have people doing similar things it
> would be great to get an overview of what you are working on too so we
> can divide and conquer where possible.
>
> Simon.
>
>
> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>
>> Hey Simon,
>>
>> Please post to the mailing list with your moby java activities since I
>> have several people doing similar things - no point in duplicating
>> effort if we can split the work :-)
>>
>> I'll be posting the URL for the registration page before weeks end -
>> I'm just waiting for a quote on the room rate.
>>
>> Cheers!
>>
>> M
> --
>
> Simon N. Twigger, Ph.D.
> Assistant Professor, Department of Physiology
> Medical College of Wisconsin
> 8701 Watertown Plank Road,
> Milwaukee, WI, USA
> tel: 414-456-8802
> fax: 414-456-6595
> AIM/iChat: simontatmcw
>
>
> --
>
> Simon N. Twigger, Ph.D.
> Assistant Professor, Department of Physiology
> Medical College of Wisconsin
> 8701 Watertown Plank Road,
> Milwaukee, WI, USA
> tel: 414-456-8802
> fax: 414-456-6595
> AIM/iChat: simontatmcw
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From mwilkinson at mrl.ubc.ca  Tue Feb 15 15:01:50 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 15 Feb 2005 07:01:50 -0800
Subject: [MOBY-dev] MOBY Service code developments
Message-ID: <1108479710.24515.22.camel@mobycentral.icapture.ubc.ca>

I think both Ben and Eddie are working on things like this as well.  Ben
is at a course doing "wet" work (ugh!) this week, but Eddie should be
on-line somewhere.

Xref'ing with each other early on would probably be worthwhile - divide
and conquer :-)

I found in Perl that the code used by services was often identical to
that used by clients, so I ended up putting these kinds of routines into
a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
considering that rather than coding service/client specific modules...
if you haven't already.

M


-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
-------------- next part --------------
An embedded message was scrubbed...
From: ywong at infobiogen.fr
Subject: [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
Date: Tue, 15 Feb 2005 09:18:47 +0100 (CET)
Size: 4684
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050215/0c9de6b1/attachment-0001.mht>

From bmg at sfu.ca  Tue Feb 15 16:16:16 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Tue, 15 Feb 2005 08:16:16 -0800
Subject: [MOBY-dev] java api
Message-ID: <42122050.400@sfu.ca>

Hi moby-dev,

 I think this from Simon sums up something that would be handy for 
everyone in the jMoby group - both client and service providers -(that 
hasn't written their own version already).

The
> basic goal was to create some basic classes to simplify access to the
> MOBY payload of a webservice call so that we could concentrate on
> getting the services up rather than parsing the MOBY XML and rewriting
> the XML prior to returning the result.

I don't really know the protocol here, but perhaps someone could post an 
Interface that others could check out, comment on, and code to?  Or 
perhaps some one already has a good solution?

-Ben


------------------------------------------------------------------------

Subject:
MOBY Service code developments
From:
Mark Wilkinson <mwilkinson at mrl.ubc.ca>
Date:
Tue, 15 Feb 2005 07:01:50 -0800

To:
Ben Good <bgood at mrl.ubc.ca>, Eddie Kawas <ed.kawas at gmail.com>, mobydev 
<moby-dev at biomoby.org>


I think both Ben and Eddie are working on things like this as well.  Ben
is at a course doing "wet" work (ugh!) this week, but Eddie should be
on-line somewhere.

Xref'ing with each other early on would probably be worthwhile - divide
and conquer  :-) 

I found in Perl that the code used by services was often identical to
that used by clients, so I ended up putting these kinds of routines into
a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
considering that rather than coding service/client specific modules...
if you haven't already.

M


-- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical 
Genetics, UBC, Canada


------------------------------------------------------------------------

Subject:
[moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
From:
ywong at infobiogen.fr
Date:
Tue, 15 Feb 2005 09:18:47 +0100 (CET)

To:
"Core developer announcements" <moby-dev at portal.open-bio.org>


Hi,
  I know that someone at mips (Octave Noubibou) is also working on that
field, on my side, I have an API in Java (based on the Python API) that
helps me to build moby webservices (with axis or j2ee)


>> Hi Mark,
>>
>> I'll see how things are looking and get the documentation together. The
>> basic goal was to create some basic classes to simplify access to the
>> MOBY payload of a webservice call so that we could concentrate on
>> getting the services up rather than parsing the MOBY XML and rewriting
>> the XML prior to returning the result. We've been using Axis to handle
>> the webservice part of the equation, we've created some core classes
>> and have a simple test service prototype that we are gearing up to do
>> something meaningful with. If you have people doing similar things it
>> would be great to get an overview of what you are working on too so we
>> can divide and conquer where possible.
>>
>> Simon.
>>
>>
>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>
>  
>
>>>> Hey Simon,
>>>>
>>>> Please post to the mailing list with your moby java activities since I
>>>> have several people doing similar things - no point in duplicating
>>>> effort if we can split the work  :-) 
>>>>
>>>> I'll be posting the URL for the registration page before weeks end -
>>>> I'm just waiting for a quote on the room rate.
>>>>
>>>> Cheers!
>>>>
>>>> M
>>    
>>
>> --
>>
>> Simon N. Twigger, Ph.D.
>> Assistant Professor, Department of Physiology
>> Medical College of Wisconsin
>> 8701 Watertown Plank Road,
>> Milwaukee, WI, USA
>> tel: 414-456-8802
>> fax: 414-456-6595
>> AIM/iChat: simontatmcw
>>
>>
>> --
>>
>> Simon N. Twigger, Ph.D.
>> Assistant Professor, Department of Physiology
>> Medical College of Wisconsin
>> 8701 Watertown Plank Road,
>> Milwaukee, WI, USA
>> tel: 414-456-8802
>> fax: 414-456-6595
>> AIM/iChat: simontatmcw
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>  
>


_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev



From edward.kawas at gmail.com  Tue Feb 15 16:35:14 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 15 Feb 2005 08:35:14 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
Message-ID: <421224c7.7ea94a2b.4fa7.0513@smtp.gmail.com>

Hi,

Ben and I just coded some methods that given certain inputs
create DOM elements, parse them, etc for Moby Objects. I
attached the javadoc for them to this message (ignore the
package name and we probably will rethink the method names,
but just as an example take a look). 

Is this something similar to what people would like for
services? I think that Ben is right and that we should
create some interfaces containing methods that people would
find useful and then we could code them. Right now I think
that there is an awful lot of code duplication.

Eddie

> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Benjamin
> Good
> Sent: Tuesday, February 15, 2005 8:16 AM
> To: moby-dev at biomoby.org
> Subject: [MOBY-dev] java api
> 
> Hi moby-dev,
> 
>  I think this from Simon sums up something that would be
> handy for
> everyone in the jMoby group - both client and service
> providers -(that
> hasn't written their own version already).
> 
> The
> > basic goal was to create some basic classes to simplify
> access to the
> > MOBY payload of a webservice call so that we could
> concentrate on
> > getting the services up rather than parsing the MOBY XML
> and rewriting
> > the XML prior to returning the result.
> 
> I don't really know the protocol here, but perhaps someone
> could post an
> Interface that others could check out, comment on, and
> code to?  Or
> perhaps some one already has a good solution?
> 
> -Ben
> 
> 
> ----------------------------------------------------------
> --------------
> 
> Subject:
> MOBY Service code developments
> From:
> Mark Wilkinson <mwilkinson at mrl.ubc.ca>
> Date:
> Tue, 15 Feb 2005 07:01:50 -0800
> 
> To:
> Ben Good <bgood at mrl.ubc.ca>, Eddie Kawas
> <ed.kawas at gmail.com>, mobydev
> <moby-dev at biomoby.org>
> 
> 
> I think both Ben and Eddie are working on things like this
> as well.  Ben
> is at a course doing "wet" work (ugh!) this week, but
> Eddie should be
> on-line somewhere.
> 
> Xref'ing with each other early on would probably be
> worthwhile - divide
> and conquer  :-)
> 
> I found in Perl that the code used by services was often
> identical to
> that used by clients, so I ended up putting these kinds of
> routines into
> a "neutral" location (MOBY::CommonSubs).  It's probably
> worthwhile
> considering that rather than coding service/client
> specific modules...
> if you haven't already.
> 
> M
> 
> 
> -- Mark Wilkinson Assistant Professor (Bioinformatics)
> Dept. Medical
> Genetics, UBC, Canada
> 
> 
> ----------------------------------------------------------
> --------------
> 
> Subject:
> [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-
> announcement
> From:
> ywong at infobiogen.fr
> Date:
> Tue, 15 Feb 2005 09:18:47 +0100 (CET)
> 
> To:
> "Core developer announcements" <moby-dev at portal.open-
> bio.org>
> 
> 
> Hi,
>   I know that someone at mips (Octave Noubibou) is also
> working on that
> field, on my side, I have an API in Java (based on the
> Python API) that
> helps me to build moby webservices (with axis or j2ee)
> 
> 
> >> Hi Mark,
> >>
> >> I'll see how things are looking and get the
> documentation together. The
> >> basic goal was to create some basic classes to simplify
> access to the
> >> MOBY payload of a webservice call so that we could
> concentrate on
> >> getting the services up rather than parsing the MOBY
> XML and rewriting
> >> the XML prior to returning the result. We've been using
> Axis to handle
> >> the webservice part of the equation, we've created some
> core classes
> >> and have a simple test service prototype that we are
> gearing up to do
> >> something meaningful with. If you have people doing
> similar things it
> >> would be great to get an overview of what you are
> working on too so we
> >> can divide and conquer where possible.
> >>
> >> Simon.
> >>
> >>
> >> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
> >>
> >
> >
> >>>> Hey Simon,
> >>>>
> >>>> Please post to the mailing list with your moby java
> activities since I
> >>>> have several people doing similar things - no point
> in duplicating
> >>>> effort if we can split the work  :-)
> >>>>
> >>>> I'll be posting the URL for the registration page
> before weeks end -
> >>>> I'm just waiting for a quote on the room rate.
> >>>>
> >>>> Cheers!
> >>>>
> >>>> M
> >>
> >>
> >> --
> >>
> >> Simon N. Twigger, Ph.D.
> >> Assistant Professor, Department of Physiology
> >> Medical College of Wisconsin
> >> 8701 Watertown Plank Road,
> >> Milwaukee, WI, USA
> >> tel: 414-456-8802
> >> fax: 414-456-6595
> >> AIM/iChat: simontatmcw
> >>
> >>
> >> --
> >>
> >> Simon N. Twigger, Ph.D.
> >> Assistant Professor, Department of Physiology
> >> Medical College of Wisconsin
> >> 8701 Watertown Plank Road,
> >> Milwaukee, WI, USA
> >> tel: 414-456-8802
> >> fax: 414-456-6595
> >> AIM/iChat: simontatmcw
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at biomoby.org
> >> http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> >
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Triples.html
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050215/ebf2cf98/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MobyObjectPrimitiveExtractor.html
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050215/ebf2cf98/attachment-0001.ksh>

From gordonp at ucalgary.ca  Tue Feb 15 17:37:21 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 15 Feb 2005 10:37:21 -0700
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
References: <42122050.400@sfu.ca>
Message-ID: <42123351.6090206@ucalgary.ca>

Hi all,

    I'm replying directly to you since the mailing list gets confused 
over my various e-mail addresses and bounces messages (I'm trying to fix 
this).  We should definitely open a dialog even before the May meeting 
because it seems that a lot of people are trying to acheive the same 
goals, and I think  most of the code to do these things are already in 
place.  For parsing and outputting data, org.biomoby.client.MobyRequest 
should be able to act as both the client and server code as MOBY 
messages are the same from a formatting point of view.  MobyRequest is 
nice and robust too, because it uses namespace-aware XPath to grab the 
relevant payload data.

In principle you should also not need to touch the XML directly, and we 
are almost to that stage.  Martin created the base type classes for when 
he started the registration side of things in Java:

org.biomoby.shared.MobyData 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyData.html>
org.biomoby.shared.MobyPrimaryDataSimple 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyPrimaryDataSimple.html>
org.biomoby.shared.MobyPrimaryDataSet 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyPrimaryDataSet.html>

I then extended these classes for actual instances of MOBY data (so they 
can conveniently be used for querying MOBY central and running services):

*org.biomoby.shared.MobyDataSetInstance*
org.biomoby.shared.MobyDataSimpleInstance 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyDataSimpleInstance.html>*
**org.biomoby.shared.MobyDataFloat (arbitrary precision)*
*org.biomoby.shared.MobyDataInt (arbitrary precision)*
*org.biomoby.shared.MobyDataString

*And a convenience class for otherwise painful to parse data (ISO 8601):*

**org.biomoby.shared.MobyDataDateTime*

Since an object is always made up fundamentally of the base classes 
object, string, int and float, there should be no need to generate any 
more classes to hold the data.  The only thing that remains is defining 
the methods in MobyDataSimpleInstance to set the data members for 
composite objects (maybe addMember(MobyDataSimpleInstance)?) and perhaps 
do a run-time check against MOBY Central that the data type given in 
setDataType is fullfilled before to XML() is called.

I was thinking something like this (PDGJOB is probably the most complex 
objects registered right now):

MobyDataSimpleInstance mdsi = new MobyDataSimpleInstance(new MobyDataType("PDGJOB"), "random object name", "some object id");
mdsi.addMember(new MobyDataString("answerService", "put your favorite answer service name here"));
mdsi.addMember(new MobyDataString("authURI", "http://my.great.domain.org/"));

GregorianCalendar gc = new GregorianCalendar();
gc.add(Calendar.MINUTE, 10); // Time out in 10 minutes
mdsi.addMember(new MobyDataDateTime("timeout", gc);

mdsi.addMember(new MobyDataString("killcode", "12345");
mdsi.addMember(new MobyDataString("killService", "put your favorite kill service name here");


As  service provider, to get the MOBY enveloped required to send this 
back to a client we call:

Central worker = new CentralImpl ();
MobyRequest mr = new MobyRequest(worker);
String responseXML = mr.convertMOBYDataToMOBYRequest(mdsis);
/* proceed to send this response back through the SOAP call you've 
received to start this code execution*/

If we are the client and we were SENDING this data instead, we can 
simply use the MobyRequest built-in SOAP handling:

mr.setInput(mdsi);
Vector output = mr.invokeService();


My CDN$0.02 :-)

Paul


Benjamin Good wrote:

> Hi moby-dev,
>
> I think this from Simon sums up something that would be handy for 
> everyone in the jMoby group - both client and service providers -(that 
> hasn't written their own version already).
>
> The
>
>> basic goal was to create some basic classes to simplify access to the
>> MOBY payload of a webservice call so that we could concentrate on
>> getting the services up rather than parsing the MOBY XML and rewriting
>> the XML prior to returning the result.
>
>
> I don't really know the protocol here, but perhaps someone could post 
> an Interface that others could check out, comment on, and code to?  Or 
> perhaps some one already has a good solution?
>
> -Ben
>
>
> ------------------------------------------------------------------------
>
> Subject:
> MOBY Service code developments
> From:
> Mark Wilkinson <mwilkinson at mrl.ubc.ca>
> Date:
> Tue, 15 Feb 2005 07:01:50 -0800
>
> To:
> Ben Good <bgood at mrl.ubc.ca>, Eddie Kawas <ed.kawas at gmail.com>, mobydev 
> <moby-dev at biomoby.org>
>
>
> I think both Ben and Eddie are working on things like this as well.  Ben
> is at a course doing "wet" work (ugh!) this week, but Eddie should be
> on-line somewhere.
>
> Xref'ing with each other early on would probably be worthwhile - divide
> and conquer  :-)
> I found in Perl that the code used by services was often identical to
> that used by clients, so I ended up putting these kinds of routines into
> a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
> considering that rather than coding service/client specific modules...
> if you haven't already.
>
> M
>
>
> -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical 
> Genetics, UBC, Canada
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
> From:
> ywong at infobiogen.fr
> Date:
> Tue, 15 Feb 2005 09:18:47 +0100 (CET)
>
> To:
> "Core developer announcements" <moby-dev at portal.open-bio.org>
>
>
> Hi,
>  I know that someone at mips (Octave Noubibou) is also working on that
> field, on my side, I have an API in Java (based on the Python API) that
> helps me to build moby webservices (with axis or j2ee)
>
>
>>> Hi Mark,
>>>
>>> I'll see how things are looking and get the documentation together. The
>>> basic goal was to create some basic classes to simplify access to the
>>> MOBY payload of a webservice call so that we could concentrate on
>>> getting the services up rather than parsing the MOBY XML and rewriting
>>> the XML prior to returning the result. We've been using Axis to handle
>>> the webservice part of the equation, we've created some core classes
>>> and have a simple test service prototype that we are gearing up to do
>>> something meaningful with. If you have people doing similar things it
>>> would be great to get an overview of what you are working on too so we
>>> can divide and conquer where possible.
>>>
>>> Simon.
>>>
>>>
>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>
>>  
>>
>>>>> Hey Simon,
>>>>>
>>>>> Please post to the mailing list with your moby java activities 
>>>>> since I
>>>>> have several people doing similar things - no point in duplicating
>>>>> effort if we can split the work  :-)
>>>>> I'll be posting the URL for the registration page before weeks end -
>>>>> I'm just waiting for a quote on the room rate.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> M
>>>>
>>>   
>>> -- 
>>>
>>> Simon N. Twigger, Ph.D.
>>> Assistant Professor, Department of Physiology
>>> Medical College of Wisconsin
>>> 8701 Watertown Plank Road,
>>> Milwaukee, WI, USA
>>> tel: 414-456-8802
>>> fax: 414-456-6595
>>> AIM/iChat: simontatmcw
>>>
>>>
>>> -- 
>>>
>>> Simon N. Twigger, Ph.D.
>>> Assistant Professor, Department of Physiology
>>> Medical College of Wisconsin
>>> 8701 Watertown Plank Road,
>>> Milwaukee, WI, USA
>>> tel: 414-456-8802
>>> fax: 414-456-6595
>>> AIM/iChat: simontatmcw
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>  
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>



From gordonp at ucalgary.ca  Tue Feb 15 17:53:11 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 15 Feb 2005 10:53:11 -0700
Subject: [MOBY-dev] java api
In-Reply-To: <42123351.6090206@ucalgary.ca>
References: <42122050.400@sfu.ca> <42123351.6090206@ucalgary.ca>
Message-ID: <42123707.7060504@ucalgary.ca>

Hi Eddie,

    The attchment was blank for we, can you resend it directly?  Perhaps 
we could integrate this code into MobyDataSimpleInstance.getMembers() 
and MobyDataSimpleInstance.getMember(String name) methods?  Also, there 
was a typo in my example, it should have read:

String responseXML = mr.convertMOBYDataToMOBYRequest(mdsi, null);

Cheers!

Paul




From edward.kawas at gmail.com  Tue Feb 15 18:01:52 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 15 Feb 2005 10:01:52 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <42123707.7060504@ucalgary.ca>
Message-ID: <42123912.362bff4b.58cb.30c8@smtp.gmail.com>

Try: 
http://mobycentral.cbr.nrc.ca/applets/MobyObjectPrimitiveExt
ractor.html

and

http://mobycentral.cbr.nrc.ca/applets/Triples.html

Probably integrating this into MobyDataSimpleInstance would
be a good idea.

Eddie
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Paul Gordon
> Sent: Tuesday, February 15, 2005 9:53 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] java api
> 
> Hi Eddie,
> 
>     The attchment was blank for we, can you resend it
> directly?  Perhaps
> we could integrate this code into
> MobyDataSimpleInstance.getMembers()
> and MobyDataSimpleInstance.getMember(String name) methods?
> Also, there
> was a typo in my example, it should have read:
> 
> String responseXML = mr.convertMOBYDataToMOBYRequest(mdsi,
> null);
> 
> Cheers!
> 
> Paul
> 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev



From octave.noubibou at gsf.de  Wed Feb 16 11:19:09 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Wed, 16 Feb 2005 12:19:09 +0100
Subject: [MOBY-dev] java api
In-Reply-To: <42122050.400@sfu.ca>
References: <42122050.400@sfu.ca>
Message-ID: <42132C2D.4010200@gsf.de>

Hi all,

as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since  
3  months  now. 
one of my first tasks was to provide a generic API to  simplify access 
to the pameters (queryID, namespace, id)
one needs from the moby input xml to run the services and also methods 
to generate moby conform xml result.

I have used DOM4J and XPATH to implement concrete classes for this purpose.
At the moment all you need to get your parameters is to use the method 
"allParsedData(inputxml)" no matter how complex the inputxml is.
This method return a vector of the form e.g.:

(((queryID1,ns,id))) for a simple type

or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a 
collection
 
or 
(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))  
for an input with 2 invocations, the first been a collection and the 
second a simple type.

currently i do not handle secondary articles, but this should not be 
difficult.

we habe tried in our java services and everything seems to be ok.

i am commenting the code now. once it is finished, i will like to share 
it with you for comment or rectification and of course use.
Is there any possibility to upload this in central repository?

best regards

octave

>
>
> Hi,
>  I know that someone at mips (Octave Noubibou) is also working on that
> field, on my side, I have an API in Java (based on the Python API) that
> helps me to build moby webservices (with axis or j2ee)
>
>
>>> Hi Mark,
>>>
>>> I'll see how things are looking and get the documentation together. The
>>> basic goal was to create some basic classes to simplify access to the
>>> MOBY payload of a webservice call so that we could concentrate on
>>> getting the services up rather than parsing the MOBY XML and rewriting
>>> the XML prior to returning the result. We've been using Axis to handle
>>> the webservice part of the equation, we've created some core classes
>>> and have a simple test service prototype that we are gearing up to do
>>> something meaningful with. If you have people doing similar things it
>>> would be great to get an overview of what you are working on too so we
>>> can divide and conquer where possible.
>>>
>>> Simon.
>>>
>>>
>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>



From ywong at infobiogen.fr  Wed Feb 16 13:02:14 2005
From: ywong at infobiogen.fr (ywong at infobiogen.fr)
Date: Wed, 16 Feb 2005 14:02:14 +0100 (CET)
Subject: [MOBY-dev] java api
In-Reply-To: <42132C2D.4010200@gsf.de>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
Message-ID: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>

Hi,
  My API was based on my Python API and uses Xerces library (but can use
any DOM API compatible library) and as for the Python library, was
intended to be generic:

  XML Moby String <-> Java Objects

  People should only use java object and serialize their results in moby
XML .

  The only thing it doesn't support (yet) is the PIB. It is also intended
to ease the building of java webservices without being tied to any
webservice's API (j2ee or axis or anything else)

  It can also execute moby webservices (client interface) but doesn't
support registration of objects/services to the bioMoby directory.

  For instance, the documentation of the API is just in plain javadoc  and
there are just two examples (client querying a bioMoby webservice and a
server serving moby contents)

  The client API can query the bioMoby directory (find a service)

  I can send the source and documentation to whom it may concern but
consider the code to be beta quality code :p ...

one example of usage:

    public String aHelloWorld(String mobyContent) throws
MobyParserException {
        MobyContent mobyInput=new MobyContent();
        MobyContent mobyOutput=new MobyContent(this.authority, this.notes);

        mobyInput.fromXML(mobyContent);

        /*browse all the queries */
        Iterator iterator=mobyInput.keys().iterator();

        while (iterator.hasNext()) {
            String queryID=(String)iterator.next();

            MobyQuery mq=mobyInput.getQuery(queryID);
            MobyQuery queryResult=new MobyQuery(queryID);

            if (mq.getObjects().size()>0) {
                MobyObject o=(MobyObject)mq.getObjects().elementAt(0);

                queryResult.addObject(o);
                queryResult.addObject(new MobyObject(o.getArticleName(),
"Global_Keyword", "hello world"));

                mobyOutput.setQuery(queryResult);
            }
        }

        return mobyOutput.toXML();
    }


Don't know if it is easy enough...

> Hi all,
>
> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since
> 3  months  now.
> one of my first tasks was to provide a generic API to  simplify access
> to the pameters (queryID, namespace, id)
> one needs from the moby input xml to run the services and also methods
> to generate moby conform xml result.
>
> I have used DOM4J and XPATH to implement concrete classes for this
> purpose.
> At the moment all you need to get your parameters is to use the method
> "allParsedData(inputxml)" no matter how complex the inputxml is.
> This method return a vector of the form e.g.:
>
> (((queryID1,ns,id))) for a simple type
>
> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
> collection
>
> or
> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
> for an input with 2 invocations, the first been a collection and the
> second a simple type.
>
> currently i do not handle secondary articles, but this should not be
> difficult.
>
> we habe tried in our java services and everything seems to be ok.
>
> i am commenting the code now. once it is finished, i will like to share
> it with you for comment or rectification and of course use.
> Is there any possibility to upload this in central repository?
>
> best regards
>
> octave
>
>>
>>
>> Hi,
>>  I know that someone at mips (Octave Noubibou) is also working on that
>> field, on my side, I have an API in Java (based on the Python API) that
>> helps me to build moby webservices (with axis or j2ee)
>>
>>
>>>> Hi Mark,
>>>>
>>>> I'll see how things are looking and get the documentation together.
>>>> The
>>>> basic goal was to create some basic classes to simplify access to the
>>>> MOBY payload of a webservice call so that we could concentrate on
>>>> getting the services up rather than parsing the MOBY XML and rewriting
>>>> the XML prior to returning the result. We've been using Axis to handle
>>>> the webservice part of the equation, we've created some core classes
>>>> and have a simple test service prototype that we are gearing up to do
>>>> something meaningful with. If you have people doing similar things it
>>>> would be great to get an overview of what you are working on too so we
>>>> can divide and conquer where possible.
>>>>
>>>> Simon.
>>>>
>>>>
>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From ywong at infobiogen.fr  Wed Feb 16 14:30:43 2005
From: ywong at infobiogen.fr (ywong at infobiogen.fr)
Date: Wed, 16 Feb 2005 15:30:43 +0100 (CET)
Subject: [MOBY-dev] java api
In-Reply-To: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
Message-ID: <34006.195.221.101.193.1108564243.squirrel@195.221.101.193>

PS: I've put the sources at this url:
    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2

    you'll need a login and password:
    login: Invite
    password: invite

    Documentation of the API is in <wsGenoplante_src_dir>/dist/
    a compiled jar is also in this directory

    You'll find the two examples in the <jws_src_dir>/src/ directory
    To setup the webservice (in the case of axis) just copy the
MobyWebService.java to the axis directory as a jws file:

   cp <jws_src_dir>/src/MobyWebService.java
<jakarta_instance_directory>/webapps/axis/

  and use Perl, Python Java API to query the service :p

  A more exhaustive documentation of the API will be produced but I lack
some time doing it... (maybe just look at the examples to have an idea)

  The two projects were written using netbeans 4.0 but the ant file should
work without it:

 build from source:
 $ant
 the resulting jar will be found in the dist directory
<wsGenoplante_src_dir>/dist/wsGenoplante.jar

> Hi,
>   My API was based on my Python API and uses Xerces library (but can use
> any DOM API compatible library) and as for the Python library, was
> intended to be generic:
>
>   XML Moby String <-> Java Objects
>
>   People should only use java object and serialize their results in moby
> XML .
>
>   The only thing it doesn't support (yet) is the PIB. It is also intended
> to ease the building of java webservices without being tied to any
> webservice's API (j2ee or axis or anything else)
>
>   It can also execute moby webservices (client interface) but doesn't
> support registration of objects/services to the bioMoby directory.
>
>   For instance, the documentation of the API is just in plain javadoc  and
> there are just two examples (client querying a bioMoby webservice and a
> server serving moby contents)
>
>   The client API can query the bioMoby directory (find a service)
>
>   I can send the source and documentation to whom it may concern but
> consider the code to be beta quality code :p ...
>
> one example of usage:
>
>     public String aHelloWorld(String mobyContent) throws
> MobyParserException {
>         MobyContent mobyInput=new MobyContent();
>         MobyContent mobyOutput=new MobyContent(this.authority,
> this.notes);
>
>         mobyInput.fromXML(mobyContent);
>
>         /*browse all the queries */
>         Iterator iterator=mobyInput.keys().iterator();
>
>         while (iterator.hasNext()) {
>             String queryID=(String)iterator.next();
>
>             MobyQuery mq=mobyInput.getQuery(queryID);
>             MobyQuery queryResult=new MobyQuery(queryID);
>
>             if (mq.getObjects().size()>0) {
>                 MobyObject o=(MobyObject)mq.getObjects().elementAt(0);
>
>                 queryResult.addObject(o);
>                 queryResult.addObject(new MobyObject(o.getArticleName(),
> "Global_Keyword", "hello world"));
>
>                 mobyOutput.setQuery(queryResult);
>             }
>         }
>
>         return mobyOutput.toXML();
>     }
>
>
> Don't know if it is easy enough...
>
>> Hi all,
>>
>> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS since
>> 3  months  now.
>> one of my first tasks was to provide a generic API to  simplify access
>> to the pameters (queryID, namespace, id)
>> one needs from the moby input xml to run the services and also methods
>> to generate moby conform xml result.
>>
>> I have used DOM4J and XPATH to implement concrete classes for this
>> purpose.
>> At the moment all you need to get your parameters is to use the method
>> "allParsedData(inputxml)" no matter how complex the inputxml is.
>> This method return a vector of the form e.g.:
>>
>> (((queryID1,ns,id))) for a simple type
>>
>> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>> collection
>>
>> or
>> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>> for an input with 2 invocations, the first been a collection and the
>> second a simple type.
>>
>> currently i do not handle secondary articles, but this should not be
>> difficult.
>>
>> we habe tried in our java services and everything seems to be ok.
>>
>> i am commenting the code now. once it is finished, i will like to share
>> it with you for comment or rectification and of course use.
>> Is there any possibility to upload this in central repository?
>>
>> best regards
>>
>> octave
>>
>>>
>>>
>>> Hi,
>>>  I know that someone at mips (Octave Noubibou) is also working on that
>>> field, on my side, I have an API in Java (based on the Python API) that
>>> helps me to build moby webservices (with axis or j2ee)
>>>
>>>
>>>>> Hi Mark,
>>>>>
>>>>> I'll see how things are looking and get the documentation together.
>>>>> The
>>>>> basic goal was to create some basic classes to simplify access to the
>>>>> MOBY payload of a webservice call so that we could concentrate on
>>>>> getting the services up rather than parsing the MOBY XML and
>>>>> rewriting
>>>>> the XML prior to returning the result. We've been using Axis to
>>>>> handle
>>>>> the webservice part of the equation, we've created some core classes
>>>>> and have a simple test service prototype that we are gearing up to do
>>>>> something meaningful with. If you have people doing similar things it
>>>>> would be great to get an overview of what you are working on too so
>>>>> we
>>>>> can divide and conquer where possible.
>>>>>
>>>>> Simon.
>>>>>
>>>>>
>>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From bmg at sfu.ca  Thu Feb 17 01:20:44 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed, 16 Feb 2005 17:20:44 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
Message-ID: <4213F16C.5030302@sfu.ca>

ywong at infobiogen.fr wrote:

>Hi,
>  My API was based on my Python API and uses Xerces library (but can use
>any DOM API compatible library) and as for the Python library, was
>intended to be generic:
>
>  XML Moby String <-> Java Objects
>  
>
Does this mean that you have a Java object for each Moby data-type 
(Object, DNASequence...) ?

-Ben



From bmg at sfu.ca  Thu Feb 17 01:23:01 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed, 16 Feb 2005 17:23:01 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <42132C2D.4010200@gsf.de>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
Message-ID: <4213F1F5.4020202@sfu.ca>

What about accessing the rest of the contents of the data in a MobyData 
block (ie the primitive values)?

-Ben

Octave Noubibou wrote:

> Hi all,
>
> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS 
> since  3  months  now. one of my first tasks was to provide a generic 
> API to  simplify access to the pameters (queryID, namespace, id)
> one needs from the moby input xml to run the services and also methods 
> to generate moby conform xml result.
>
> I have used DOM4J and XPATH to implement concrete classes for this 
> purpose.
> At the moment all you need to get your parameters is to use the method 
> "allParsedData(inputxml)" no matter how complex the inputxml is.
> This method return a vector of the form e.g.:
>
> (((queryID1,ns,id))) for a simple type
>
> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a 
> collection
>
> or 
> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))  
> for an input with 2 invocations, the first been a collection and the 
> second a simple type.
>
> currently i do not handle secondary articles, but this should not be 
> difficult.
>
> we habe tried in our java services and everything seems to be ok.
>
> i am commenting the code now. once it is finished, i will like to 
> share it with you for comment or rectification and of course use.
> Is there any possibility to upload this in central repository?
>
> best regards
>
> octave
>
>>
>>
>> Hi,
>>  I know that someone at mips (Octave Noubibou) is also working on that
>> field, on my side, I have an API in Java (based on the Python API) that
>> helps me to build moby webservices (with axis or j2ee)
>>
>>
>>>> Hi Mark,
>>>>
>>>> I'll see how things are looking and get the documentation together. 
>>>> The
>>>> basic goal was to create some basic classes to simplify access to the
>>>> MOBY payload of a webservice call so that we could concentrate on
>>>> getting the services up rather than parsing the MOBY XML and rewriting
>>>> the XML prior to returning the result. We've been using Axis to handle
>>>> the webservice part of the equation, we've created some core classes
>>>> and have a simple test service prototype that we are gearing up to do
>>>> something meaningful with. If you have people doing similar things it
>>>> would be great to get an overview of what you are working on too so we
>>>> can divide and conquer where possible.
>>>>
>>>> Simon.
>>>>
>>>>
>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
>



From ywong at infobiogen.fr  Thu Feb 17 08:39:18 2005
From: ywong at infobiogen.fr (ywong at infobiogen.fr)
Date: Thu, 17 Feb 2005 09:39:18 +0100 (CET)
Subject: [MOBY-dev] java api
In-Reply-To: <4213F1F5.4020202@sfu.ca>
References: <42122050.400@sfu.ca> <42132C2D.4010200@gsf.de>
	<4213F1F5.4020202@sfu.ca>
Message-ID: <32888.195.221.101.193.1108629558.squirrel@195.221.101.193>

Hi,
  No, unlike Python, I can't generate on the fly classes so the MobyObject
class is generic, it describes an Moby XML object as a class with
attributes:

  -prefix (default is moby, for XML serialization)
  -tag (for the XML serialization and specify what kind of Moby object it is)
  -namespace (Moby namespace eg AGI_LocusCode)
  -id (object identifier)
  -articleName (name of this object)
  -other moby objects (described in the ontology)
  -a raw content (the serializer only require this object to have a
toString method)

To determine what kind of object it is, I just look at the tag property
with a getTag method.

It is possible to build a specific object from this one using inheritance.

This structure should be enough exhaustive to describe all possible Moby
objects:

    <Object1 namespace="aNamespace" id="anId">
        <Object2 articleName="something">
            <Object3 articleName="A">
                   <Xref .../>
                   <Xref ...>Description</Xref>
                   RAW CONTENT for Object with article Name A
            </Object3>
        </Object2>
        <Object4 namespace="aNamespace" id="anId"/>
        RAW Content for Object 1
    </Object1>

Just have a look at the MobyObject class and the example MobyWebservice
(the method getRandomDNASequence return a DNA sequence object).

Yan

> What about accessing the rest of the contents of the data in a MobyData
> block (ie the primitive values)?
>
> -Ben
>
> Octave Noubibou wrote:
>
>> Hi all,
>>
>> as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>> since  3  months  now. one of my first tasks was to provide a generic
>> API to  simplify access to the pameters (queryID, namespace, id)
>> one needs from the moby input xml to run the services and also methods
>> to generate moby conform xml result.
>>
>> I have used DOM4J and XPATH to implement concrete classes for this
>> purpose.
>> At the moment all you need to get your parameters is to use the method
>> "allParsedData(inputxml)" no matter how complex the inputxml is.
>> This method return a vector of the form e.g.:
>>
>> (((queryID1,ns,id))) for a simple type
>>
>> or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>> collection
>>
>> or
>> (((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>> for an input with 2 invocations, the first been a collection and the
>> second a simple type.
>>
>> currently i do not handle secondary articles, but this should not be
>> difficult.
>>
>> we habe tried in our java services and everything seems to be ok.
>>
>> i am commenting the code now. once it is finished, i will like to
>> share it with you for comment or rectification and of course use.
>> Is there any possibility to upload this in central repository?
>>
>> best regards
>>
>> octave
>>
>>>
>>>
>>> Hi,
>>>  I know that someone at mips (Octave Noubibou) is also working on that
>>> field, on my side, I have an API in Java (based on the Python API) that
>>> helps me to build moby webservices (with axis or j2ee)
>>>
>>>
>>>>> Hi Mark,
>>>>>
>>>>> I'll see how things are looking and get the documentation together.
>>>>> The
>>>>> basic goal was to create some basic classes to simplify access to the
>>>>> MOBY payload of a webservice call so that we could concentrate on
>>>>> getting the services up rather than parsing the MOBY XML and
>>>>> rewriting
>>>>> the XML prior to returning the result. We've been using Axis to
>>>>> handle
>>>>> the webservice part of the equation, we've created some core classes
>>>>> and have a simple test service prototype that we are gearing up to do
>>>>> something meaningful with. If you have people doing similar things it
>>>>> would be great to get an overview of what you are working on too so
>>>>> we
>>>>> can divide and conquer where possible.
>>>>>
>>>>> Simon.
>>>>>
>>>>>
>>>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From gordonp at ucalgary.ca  Thu Feb 17 15:21:41 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Thu, 17 Feb 2005 08:21:41 -0700
Subject: [MOBY-dev] java api
In-Reply-To: <32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<4213F1F5.4020202@sfu.ca>
	<32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
Message-ID: <4214B685.6090105@ucalgary.ca>

It's great to see all of this code coming out, who new there were so 
many Java MOBY developers! :-)

We should really think about how to consolidate the best parts of the 
everyone's code into a cohesive object hierarchy.  This can be a bit 
tricky, since it's easy to feel insulted because some great code you 
wrote doesn't make it into the amalgam.  In practice, current coders 
will probably continue to use the classes they have already developed, 
since they've build other code around it, so the amalgam is more for the 
benefit of new Java coders.  I'm volunteering myself to take some of Ben 
and Eddie's PIB and RDF type-checking code and fold it into the existing 
MobyDataSimpleInstance. 

Yan, I haven't looked thoroughly, does your Java code use Jython to 
access your underlying Python implementation of the API?

Simon, what data instance classes are you planning on using for the Axis 
streamlining?

>Hi,
>  No, unlike Python, I can't generate on the fly classes so the MobyObject
>class is generic, it describes an Moby XML object as a class with
>attributes:
>
>  -prefix (default is moby, for XML serialization)
>  -tag (for the XML serialization and specify what kind of Moby object it is)
>  -namespace (Moby namespace eg AGI_LocusCode)
>  -id (object identifier)
>  -articleName (name of this object)
>  -other moby objects (described in the ontology)
>  -a raw content (the serializer only require this object to have a
>toString method)
>
>To determine what kind of object it is, I just look at the tag property
>with a getTag method.
>
>It is possible to build a specific object from this one using inheritance.
>
>This structure should be enough exhaustive to describe all possible Moby
>objects:
>
>    <Object1 namespace="aNamespace" id="anId">
>        <Object2 articleName="something">
>            <Object3 articleName="A">
>                   <Xref .../>
>                   <Xref ...>Description</Xref>
>                   RAW CONTENT for Object with article Name A
>            </Object3>
>        </Object2>
>        <Object4 namespace="aNamespace" id="anId"/>
>        RAW Content for Object 1
>    </Object1>
>
>Just have a look at the MobyObject class and the example MobyWebservice
>(the method getRandomDNASequence return a DNA sequence object).
>
>Yan
>
>  
>
>>What about accessing the rest of the contents of the data in a MobyData
>>block (ie the primitive values)?
>>
>>-Ben
>>
>>Octave Noubibou wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>since  3  months  now. one of my first tasks was to provide a generic
>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>one needs from the moby input xml to run the services and also methods
>>>to generate moby conform xml result.
>>>
>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>purpose.
>>>At the moment all you need to get your parameters is to use the method
>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>This method return a vector of the form e.g.:
>>>
>>>(((queryID1,ns,id))) for a simple type
>>>
>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>collection
>>>
>>>or
>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>for an input with 2 invocations, the first been a collection and the
>>>second a simple type.
>>>
>>>currently i do not handle secondary articles, but this should not be
>>>difficult.
>>>
>>>we habe tried in our java services and everything seems to be ok.
>>>
>>>i am commenting the code now. once it is finished, i will like to
>>>share it with you for comment or rectification and of course use.
>>>Is there any possibility to upload this in central repository?
>>>
>>>best regards
>>>
>>>octave
>>>
>>>      
>>>
>>>>Hi,
>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>field, on my side, I have an API in Java (based on the Python API) that
>>>>helps me to build moby webservices (with axis or j2ee)
>>>>
>>>>
>>>>        
>>>>
>>>>>>Hi Mark,
>>>>>>
>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>The
>>>>>>basic goal was to create some basic classes to simplify access to the
>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>rewriting
>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>handle
>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>and have a simple test service prototype that we are gearing up to do
>>>>>>something meaningful with. If you have people doing similar things it
>>>>>>would be great to get an overview of what you are working on too so
>>>>>>we
>>>>>>can divide and conquer where possible.
>>>>>>
>>>>>>Simon.
>>>>>>
>>>>>>
>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev at biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>    
>>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>  
>



From ywong at infobiogen.fr  Thu Feb 17 15:34:50 2005
From: ywong at infobiogen.fr (ywong at infobiogen.fr)
Date: Thu, 17 Feb 2005 16:34:50 +0100 (CET)
Subject: [MOBY-dev] java api
In-Reply-To: <4214B685.6090105@ucalgary.ca>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<4213F1F5.4020202@sfu.ca>
	<32888.195.221.101.193.1108629558.squirrel@195.221.101.193>
	<4214B685.6090105@ucalgary.ca>
Message-ID: <34198.195.221.101.193.1108654490.squirrel@195.221.101.193>

No, the API I wrote is 100% java :p, the Python API was the model on which
I based the development.


> It's great to see all of this code coming out, who new there were so
> many Java MOBY developers! :-)
>
> We should really think about how to consolidate the best parts of the
> everyone's code into a cohesive object hierarchy.  This can be a bit
> tricky, since it's easy to feel insulted because some great code you
> wrote doesn't make it into the amalgam.  In practice, current coders
> will probably continue to use the classes they have already developed,
> since they've build other code around it, so the amalgam is more for the
> benefit of new Java coders.  I'm volunteering myself to take some of Ben
> and Eddie's PIB and RDF type-checking code and fold it into the existing
> MobyDataSimpleInstance.
>
> Yan, I haven't looked thoroughly, does your Java code use Jython to
> access your underlying Python implementation of the API?
>
> Simon, what data instance classes are you planning on using for the Axis
> streamlining?
>
>>Hi,
>>  No, unlike Python, I can't generate on the fly classes so the
>> MobyObject
>>class is generic, it describes an Moby XML object as a class with
>>attributes:
>>
>>  -prefix (default is moby, for XML serialization)
>>  -tag (for the XML serialization and specify what kind of Moby object it
>> is)
>>  -namespace (Moby namespace eg AGI_LocusCode)
>>  -id (object identifier)
>>  -articleName (name of this object)
>>  -other moby objects (described in the ontology)
>>  -a raw content (the serializer only require this object to have a
>>toString method)
>>
>>To determine what kind of object it is, I just look at the tag property
>>with a getTag method.
>>
>>It is possible to build a specific object from this one using
>> inheritance.
>>
>>This structure should be enough exhaustive to describe all possible Moby
>>objects:
>>
>>    <Object1 namespace="aNamespace" id="anId">
>>        <Object2 articleName="something">
>>            <Object3 articleName="A">
>>                   <Xref .../>
>>                   <Xref ...>Description</Xref>
>>                   RAW CONTENT for Object with article Name A
>>            </Object3>
>>        </Object2>
>>        <Object4 namespace="aNamespace" id="anId"/>
>>        RAW Content for Object 1
>>    </Object1>
>>
>>Just have a look at the MobyObject class and the example MobyWebservice
>>(the method getRandomDNASequence return a DNA sequence object).
>>
>>Yan
>>
>>
>>
>>>What about accessing the rest of the contents of the data in a MobyData
>>>block (ie the primitive values)?
>>>
>>>-Ben
>>>
>>>Octave Noubibou wrote:
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>>since  3  months  now. one of my first tasks was to provide a generic
>>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>>one needs from the moby input xml to run the services and also methods
>>>>to generate moby conform xml result.
>>>>
>>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>>purpose.
>>>>At the moment all you need to get your parameters is to use the method
>>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>>This method return a vector of the form e.g.:
>>>>
>>>>(((queryID1,ns,id))) for a simple type
>>>>
>>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>>collection
>>>>
>>>>or
>>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>>for an input with 2 invocations, the first been a collection and the
>>>>second a simple type.
>>>>
>>>>currently i do not handle secondary articles, but this should not be
>>>>difficult.
>>>>
>>>>we habe tried in our java services and everything seems to be ok.
>>>>
>>>>i am commenting the code now. once it is finished, i will like to
>>>>share it with you for comment or rectification and of course use.
>>>>Is there any possibility to upload this in central repository?
>>>>
>>>>best regards
>>>>
>>>>octave
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>>field, on my side, I have an API in Java (based on the Python API)
>>>>> that
>>>>>helps me to build moby webservices (with axis or j2ee)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Hi Mark,
>>>>>>>
>>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>>The
>>>>>>>basic goal was to create some basic classes to simplify access to
>>>>>>> the
>>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>>rewriting
>>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>>handle
>>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>>and have a simple test service prototype that we are gearing up to
>>>>>>> do
>>>>>>>something meaningful with. If you have people doing similar things
>>>>>>> it
>>>>>>>would be great to get an overview of what you are working on too so
>>>>>>>we
>>>>>>>can divide and conquer where possible.
>>>>>>>
>>>>>>>Simon.
>>>>>>>
>>>>>>>
>>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev at biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev at biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>>
>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>




From mwilkinson at mobile.rogers.com  Sat Feb 19 07:38:30 2005
From: mwilkinson at mobile.rogers.com (mwilkinson)
Date: Sat, 19 Feb 2005 02:38:30 -0500
Subject: [MOBY-dev] java api
Message-ID: <200502190736.j1J7aPKr002666@portal.open-bio.org>

Hi Paul, Aloha from Honolulu! (just a stopover on the way to Sydney, unfortunately...)


Thanks for the offer of your time in doing some java code merging!

I had planned to write a message to the group shortly in this regard, so now seems a good moment to do so :-). It seems to me that Eddie is a good choice for the person who makes the final decisions for the moby java codebase structure if only because he is currently employed to do java moby 100% of his time.  This doesn't mean that he wouldn't discuss it with everyone else, just that he would take the time (and responsibility) for taking the "best of the best" code and consolidating it into a unified API.

I was thinking that the next moby meeting (May) would be a good time to talk about this face-to-face and make sure everyone knows the strengths and limitations of each others code.

Na?  Opinions?

M


-----Original Message-----
From: Paul Gordon <gordonp at ucalgary.ca>
Date: Thu, 17 Feb 2005 08:21:41 
To:Core developer announcements <moby-dev at portal.open-bio.org>
Subject: Re: [MOBY-dev] java api

It's great to see all of this code coming out, who new there were so 
many Java MOBY developers! :-)

We should really think about how to consolidate the best parts of the 
everyone's code into a cohesive object hierarchy.  This can be a bit 
tricky, since it's easy to feel insulted because some great code you 
wrote doesn't make it into the amalgam.  In practice, current coders 
will probably continue to use the classes they have already developed, 
since they've build other code around it, so the amalgam is more for the 
benefit of new Java coders.  I'm volunteering myself to take some of Ben 
and Eddie's PIB and RDF type-checking code and fold it into the existing 
MobyDataSimpleInstance. 

Yan, I haven't looked thoroughly, does your Java code use Jython to 
access your underlying Python implementation of the API?

Simon, what data instance classes are you planning on using for the Axis 
streamlining?

>Hi,
>  No, unlike Python, I can't generate on the fly classes so the MobyObject
>class is generic, it describes an Moby XML object as a class with
>attributes:
>
>  -prefix (default is moby, for XML serialization)
>  -tag (for the XML serialization and specify what kind of Moby object it is)
>  -namespace (Moby namespace eg AGI_LocusCode)
>  -id (object identifier)
>  -articleName (name of this object)
>  -other moby objects (described in the ontology)
>  -a raw content (the serializer only require this object to have a
>toString method)
>
>To determine what kind of object it is, I just look at the tag property
>with a getTag method.
>
>It is possible to build a specific object from this one using inheritance.
>
>This structure should be enough exhaustive to describe all possible Moby
>objects:
>
>    <Object1 namespace="aNamespace" id="anId">
>        <Object2 articleName="something">
>            <Object3 articleName="A">
>                   <Xref .../>
>                   <Xref ...>Description</Xref>
>                   RAW CONTENT for Object with article Name A
>            </Object3>
>        </Object2>
>        <Object4 namespace="aNamespace" id="anId"/>
>        RAW Content for Object 1
>    </Object1>
>
>Just have a look at the MobyObject class and the example MobyWebservice
>(the method getRandomDNASequence return a DNA sequence object).
>
>Yan
>
>  
>
>>What about accessing the rest of the contents of the data in a MobyData
>>block (ie the primitive values)?
>>
>>-Ben
>>
>>Octave Noubibou wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>since  3  months  now. one of my first tasks was to provide a generic
>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>one needs from the moby input xml to run the services and also methods
>>>to generate moby conform xml result.
>>>
>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>purpose.
>>>At the moment all you need to get your parameters is to use the method
>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>This method return a vector of the form e.g.:
>>>
>>>(((queryID1,ns,id))) for a simple type
>>>
>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>collection
>>>
>>>or
>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>for an input with 2 invocations, the first been a collection and the
>>>second a simple type.
>>>
>>>currently i do not handle secondary articles, but this should not be
>>>difficult.
>>>
>>>we habe tried in our java services and everything seems to be ok.
>>>
>>>i am commenting the code now. once it is finished, i will like to
>>>share it with you for comment or rectification and of course use.
>>>Is there any possibility to upload this in central repository?
>>>
>>>best regards
>>>
>>>octave
>>>
>>>      
>>>
>>>>Hi,
>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>field, on my side, I have an API in Java (based on the Python API) that
>>>>helps me to build moby webservices (with axis or j2ee)
>>>>
>>>>
>>>>        
>>>>
>>>>>>Hi Mark,
>>>>>>
>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>The
>>>>>>basic goal was to create some basic classes to simplify access to the
>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>rewriting
>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>handle
>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>and have a simple test service prototype that we are gearing up to do
>>>>>>something meaningful with. If you have people doing similar things it
>>>>>>would be great to get an overview of what you are working on too so
>>>>>>we
>>>>>>can divide and conquer where possible.
>>>>>>
>>>>>>Simon.
>>>>>>
>>>>>>
>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev at biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>    
>>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>  
>

_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!


From edward.kawas at gmail.com  Wed Feb 23 06:02:47 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 22 Feb 2005 22:02:47 -0800
Subject: [MOBY-dev] java api
Message-ID: <421c1c8d.080cc2c8.5369.1953@smtp.gmail.com>

Hello Moby,

  I have been tasked with organizing and extending the jMoby
code.  My goal is to maximize the usefulness of what has
already been written and to provide a solid structure upon
which the next generations of jMoby can be based.  In
seeking to accomplish these goals I would like to start with
a discussion of what jMoby does well at the moment and what
it does not so well or does not do at all.  I'd like to use
this discussion to set some specific goals for the next
version of the API. 
 
Once these goals are clarified I would like to use them to
create a conceptually meaningful package hierarchy, slot the
existing classes into it, and to produce the interfaces for
the classes that need to be written. For instance, the
package "shared" could usefully be decomposed into a set of
more meaningful package names which would facilitate the use
of the code by newbies, reducing code duplication and
allowing us developers to be more efficient. The help and
participation from all the jMoby developers will be vital
for this revision to succeed.

Here are some questions I have about jMoby2005:
   Will we be supporting automatic generation of service
templates?  How (axis?)?  Will the library allow for the
addition of real wsdl descriptions of the services so that
client developers outside of the Moby community can use
their .NET/Axis tools to make use of Moby services?  How
will jMoby deal with service ontologies?  Is there interest
in providing GUI development support?

So, let's hear what you think about the future of jMoby!

Eddie Kawas

-B



From ed.kawas at gmail.com  Wed Feb 23 05:54:53 2005
From: ed.kawas at gmail.com (Eddie Kawas)
Date: Tue, 22 Feb 2005 21:54:53 -0800
Subject: [MOBY-dev] java api
Message-ID: <421c1ab0.13628b9a.6ca6.2fdf@smtp.gmail.com>

Hello Moby,

  I have been tasked with organizing and extending the jMoby
code.  My goal is to maximize the usefulness of what has
already been written and to provide a solid structure upon
which the next generations of jMoby can be based.  In
seeking to accomplish these goals I would like to start with
a discussion of what jMoby does well at the moment and what
it does not so well or does not do at all.  I'd like to use
this discussion to set some specific goals for the next
version of the API. 
 
Once these goals are clarified I would like to use them to
create a conceptually meaningful package hierarchy, slot the
existing classes into it, and to produce the interfaces for
the classes that need to be written. For instance, the
package "shared" could usefully be decomposed into a set of
more meaningful package names which would facilitate the use
of the code by newbies, reducing code duplication and
allowing us developers to be more efficient. The help and
participation from all the jMoby developers will be vital
for this revision to succeed.

Here are some questions I have about jMoby2005:
   Will we be supporting automatic generation of service
templates?  How (axis?)?  Will the library allow for the
addition of real wsdl descriptions of the services so that
client developers outside of the Moby community can use
their .NET/Axis tools to make use of Moby services?  How
will jMoby deal with service ontologies?  Is there interest
in providing GUI development support?

So, let's hear what you think about the future of jMoby!

Eddie Kawas

-B



From bmg at sfu.ca  Thu Feb 24 02:27:09 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed, 23 Feb 2005 18:27:09 -0800
Subject: [MOBY-dev] java api
In-Reply-To: <34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
References: <42122050.400@sfu.ca>
	<42132C2D.4010200@gsf.de>	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>
	<34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
Message-ID: <421D3B7D.4040805@sfu.ca>

Hi Yan,

 I couldn't log in to check out your code, is it still there with Invite 
Invite ?

thanks
-Ben

regarding

PS: I've put the sources at this url:
    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2




From ywong at infobiogen.fr  Thu Feb 24 08:22:49 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Thu, 24 Feb 2005 09:22:49 +0100
Subject: [MOBY-dev] java api
In-Reply-To: <421D3B7D.4040805@sfu.ca>
References: <42122050.400@sfu.ca>	<42132C2D.4010200@gsf.de>	<32994.195.221.101.193.1108558934.squirrel@195.221.101.193>	<34006.195.221.101.193.1108564243.squirrel@195.221.101.193>
	<421D3B7D.4040805@sfu.ca>
Message-ID: <421D8ED9.9030509@infobiogen.fr>

Benjamin Good wrote:

> Hi Yan,
>
> I couldn't log in to check out your code, is it still there with 
> Invite Invite ?
>
> thanks
> -Ben
>
> regarding
>
> PS: I've put the sources at this url:
>    The API: http://yan.wong.free.fr/Public/wsGenoplante.tar.bz2
>    The two examples: http://yan.wong.free.fr/Public/jws.tar.bz2
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
It should be
login: Invite (first letter in caps)
password: invite (no caps at all)

I send you the two files... wsGenoplante.tar.bz2 contains the API and 
jws.tar.bz2 the examples of how to use it
they were developed with netbeans 4 but has a ant file (build.xml). A  
javadoc and a ready to use binary is also  provided in the  package
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wsGenoplante.tar.bz2
Type: application/octet-stream
Size: 33088 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050224/014f211d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jws.tar.bz2
Type: application/octet-stream
Size: 12818 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050224/014f211d/attachment-0001.obj>