From senger at ebi.ac.uk Thu Apr 1 10:18:29 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Apr 1 10:23:36 2004 Subject: [MOBY-l] help needed for GetPubmed service In-Reply-To: Message-ID: [Sorry for sending this email here, I should send it directly to the service provider...] Still playing with some services, so far I have not succeeded with not a single one (my fault, of course). What is wrong, for example, with this input: sent to service GetPubmed, located at: http://prometheus.brc.mcw.edu/pubfetch-bin/PubFetchService.pl I am getting an error: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [stackTrace: null] Fault string: Failed to access class (MOBY::Central): Can't locate MOBY/Central.pm in @INC (@INC contains:) at (eval 140) line 3. Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client Fault actor: null When calling: http://prometheus.brc.mcw.edu/pubfetch-bin/PubFetchService.pl =========== Which frustrates me because I am *not* calling a moby central and still the error message tells me that somewhere someone cannot locate moby central. Thanks for any advise, actually, if someone can get me any simple XML object and tell me where to send it in order to get an answer and not an errror I will be happy... :-) 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 VNarayan at mail.brc.mcw.edu Thu Apr 1 10:48:03 2004 From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy) Date: Thu Apr 1 10:58:06 2004 Subject: [MOBY-l] help needed for GetPubmed service Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DF6F@baldar.brc.mcw.edu> Martin, The namespace of the input to the GetPubmed should be PMID (not Object). -Vijay Vijay Narayanasamy Project Programmer / Analyst Bioinformatics Program, Human and Molecular Genetics Center Medical College of Wisconsin 8701, W. Watertown Plank Road Milwaukee, WI 53226 414-456-8026 vnarayan@mcw.edu http://brc.mcw.edu/ -----Original Message----- From: Martin Senger [mailto:senger@ebi.ac.uk] Sent: Thursday, April 01, 2004 9:18 AM To: mobyl Cc: markw@illuminae.com Subject: [MOBY-l] help needed for GetPubmed service [Sorry for sending this email here, I should send it directly to the service provider...] Still playing with some services, so far I have not succeeded with not a single one (my fault, of course). What is wrong, for example, with this input: sent to service GetPubmed, located at: http://prometheus.brc.mcw.edu/pubfetch-bin/PubFetchService.pl I am getting an error: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [stackTrace: null] Fault string: Failed to access class (MOBY::Central): Can't locate MOBY/Central.pm in @INC (@INC contains:) at (eval 140) line 3. Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client Fault actor: null When calling: http://prometheus.brc.mcw.edu/pubfetch-bin/PubFetchService.pl =========== Which frustrates me because I am *not* calling a moby central and still the error message tells me that somewhere someone cannot locate moby central. Thanks for any advise, actually, if someone can get me any simple XML object and tell me where to send it in order to get an answer and not an errror I will be happy... :-) 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-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l From senger at ebi.ac.uk Thu Apr 1 10:56:04 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Apr 1 11:01:12 2004 Subject: [MOBY-l] help needed for GetPubmed service In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DF6F@baldar.brc.mcw.edu> Message-ID: > The namespace of the input to the GetPubmed should be PMID (not Object). > Thanks, I have got this tip from more people now (but I forgot to forwarded here). But, unfortunately, it does not help... :-( I think perhaps we have again some problem with the URI and SOAPACtion... ? I do not know. 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 fgibbons at hms.harvard.edu Thu Apr 1 10:58:59 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu Apr 1 11:37:42 2004 Subject: [MOBY-l] help needed for GetPubmed service In-Reply-To: References: Message-ID: <5.2.1.1.2.20040401105334.01a6bf98@email.med.harvard.edu> Martin, Thanks for any advise, actually, if someone can get me any simple XML >object and tell me where to send it in order to get an answer and not an >errror I will be happy... :-) I'm attaching some Perl code (PMid.pl) that calls the GetPubmed service at prometheus. I wrote it last week, and just tried it right now, and it still works. I'm also appending the output from the service also (PM.txt). I hope this helps. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons -------------- next part -------------- Service provided by ================================================================================ GetPubmed prometheus.brc.mcw.edu Retrieve PubMed articles in MEDLINE display format for given PMIDs Result: Result: Result: From markw at illuminae.com Thu Apr 1 11:39:47 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Apr 1 11:45:01 2004 Subject: [MOBY] RE: [MOBY-l] help needed for GetPubmed service In-Reply-To: References: Message-ID: <1080837587.1658.20.camel@localhost.localdomain> Can you post the code that you are using, and a trace of the message that is going out over the wire? I know that service is running because the CGI client has no problem with it, so you are probably right that the SOAP message is somehow malformed... M On Thu, 2004-04-01 at 07:56, Martin Senger wrote: > > The namespace of the input to the GetPubmed should be PMID (not Object). > > > Thanks, I have got this tip from more people now (but I forgot to > forwarded here). > But, unfortunately, it does not help... :-( > I think perhaps we have again some problem with the URI and > SOAPACtion... ? I do not know. > > Martin -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From VNarayan at mail.brc.mcw.edu Thu Apr 1 12:15:34 2004 From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy) Date: Thu Apr 1 12:25:36 2004 Subject: [MOBY-l] help needed for GetPubmed service Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DF71@baldar.brc.mcw.edu> Frank, The attachment PMid.pl is missing. Vijay Vijay Narayanasamy Project Programmer / Analyst Bioinformatics Program, Human and Molecular Genetics Center Medical College of Wisconsin 8701, W. Watertown Plank Road Milwaukee, WI 53226 414-456-8026 vnarayan@mcw.edu http://brc.mcw.edu/ -----Original Message----- From: Frank Gibbons [mailto:fgibbons@hms.harvard.edu] Sent: Thursday, April 01, 2004 9:59 AM To: moby-l@biomoby.org Subject: Re: [MOBY-l] help needed for GetPubmed service Martin, Thanks for any advise, actually, if someone can get me any simple XML >object and tell me where to send it in order to get an answer and not an >errror I will be happy... :-) I'm attaching some Perl code (PMid.pl) that calls the GetPubmed service at prometheus. I wrote it last week, and just tried it right now, and it still works. I'm also appending the output from the service also (PM.txt). I hope this helps. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From fgibbons at hms.harvard.edu Thu Apr 1 12:38:12 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu Apr 1 12:50:04 2004 Subject: [MOBY-l] GetPubmed service: calling from Perl, sample response In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DF71@baldar.brc.mcw.edu> Message-ID: <5.2.1.1.2.20040401123319.01a23ca0@email.med.harvard.edu> Oops - sorry about that, Vijay, I was sure I had attached it. The list server told me my message looked suspicious, and perhaps it stripped it. Whatever the reason, here it is appended, the output is attached, since it's rather long. -Frank At 12:15 PM 4/1/2004, Vijay Narayanasamy wrote: >Frank, > >The attachment PMid.pl is missing. > >Vijay > >Vijay Narayanasamy >Project Programmer / Analyst >Bioinformatics Program, Human and Molecular Genetics Center >Medical College of Wisconsin >8701, W. Watertown Plank Road >Milwaukee, WI 53226 >414-456-8026 >vnarayan@mcw.edu >http://brc.mcw.edu/ > >-----Original Message----- >From: Frank Gibbons [mailto:fgibbons@hms.harvard.edu] >Sent: Thursday, April 01, 2004 9:59 AM >To: moby-l@biomoby.org >Subject: Re: [MOBY-l] help needed for GetPubmed service > >Martin, > > Thanks for any advise, actually, if someone can get me any simple XML > >object and tell me where to send it in order to get an answer and not an > >errror I will be happy... :-) > > >I'm attaching some Perl code (PMid.pl) that calls the GetPubmed service at >prometheus. I wrote it last week, and just tried it right now, and it still >works. I'm also appending the output from the service also (PM.txt). > >I hope this helps. > >-Frank > > > >PhD, Computational Biologist, >Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. >Tel: 617-432-3555 Fax: >617-432-3557 http://llama.med.harvard.edu/~fgibbons ================= Perl code to look up PubMed IDs at GetPubmed service =============== #!/home/fgibbons/bin/perl use MOBY::Client::Central; use MOBY::Client::Service; my $Central = MOBY::Client::Central->new(); my ($Services, $REG) = $Central->findService( authURI => 'prometheus.brc.mcw.edu', serviceName => 'GetPubmed' ); unless ($Services) { print "Service discovery failed with the following errror: ", $REG->message; end } my @PMids = ("9788350", "14730315", "12368250"); printf("%-35s\t\t %s\n%s\n", "Service", "provided by", "="x80); foreach my $S ( @{$Services}) { printf("%-35s\t\t%s%s\n", $S->name, $S->authority, $S->description); my $WSDL = $Central->retrieveService($S); my $service = MOBY::Client::Service->new(service => $WSDL); foreach my $pmid (@PMids) { my $result = $service->execute( XMLinputlist => [ ['object0', ""], ] ) || 'None'; print "Result: ", $result, "\n"; } } PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons -------------- next part -------------- Service provided by ================================================================================ GetPubmed prometheus.brc.mcw.edu Retrieve PubMed articles in MEDLINE display format for given PMIDs Result: Result: Result: From markw at illuminae.com Thu Apr 1 13:07:01 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Apr 1 13:14:15 2004 Subject: [MISC] Re: [MOBY-l] How to debug multi-parameter services In-Reply-To: <406C4B92.7020902@cnb.uam.es> References: <200403300801.i2U81FEU337439@electre.pasteur.fr> <406C4B92.7020902@cnb.uam.es> Message-ID: <1080842821.2348.22.camel@localhost.localdomain> Hi Both! Sorry for the delay in dealing with this issue - I'm still setting up my new lab, so I'm not getting a lot of coding done these days... I went into the (Perl) code just now and noticed a HUGE bug in the XML output for executing a service using the MOBY::Service->execute method (I am associating the articleName attribute with the queryInput element in the module, but it is supposed to be an attribute of the Simple or Collection element according to the API). This is an ugly mistake, since my server-side parsing libraries probably compensate for this error by looking for the articleName attribute in the wrong place as well! Anyway, this bug prevents me from writing a quick solution to your problem. I'll try to fix this over the next couple of days - it will get fixed at the CSHL MOBY meeting this weekend for sure, since we are highly unlikely to stay out late while we are there ;-) ;-) Anyway, I'm **really** sorry about that! I'll get it fixed as quickly as I can. Mark On Thu, 2004-04-01 at 09:04, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hello Catherine, > I'm sending a copy of this mail to Mark Wilkinson, so he can answer us. > My own answer is below. > > Catherine Letondal wrote: > > Jos?_Mar?a_Fern?ndez_Gonz?lez wrote: > > > >>Hi everybody, > >> I have developed a couple of services which take two arguments as > >>input, and now, how do I debug them? The 'debugYourService' script (very > >>useful) only works with single Simple input services. > >> > >> I have read the MOBY Client API (Service and ServiceInstance), and as I > >>have understood you can invoke a service with a Simple parameter, a > >>service with a Collection parameter but I'm unable to see the way to > >>invoke a service with two Simple parameters. > > > > > > Have you found out how to do this? We actually have the same question. > > Thanks in advance, > > > > > > -- > > Catherine Letondal -- Pasteur Institute Computing Center > > > > > > No, I haven't discovered an easy way to do that. Well, I was talking > about that with Mark a few weeks ago, and the problem is not inside the > protocol, but in the current design of the client libraries. MOBY people > is thinking on fixing the problem, but meanwhile we'd have to use some > tricks, and I don't like any of those I have thought. > > The first trick is to create a new object type which models the service > call parameters as declared HAS elements in the object definition. I > don't like it because the MOBY registry will grow with each new > multi-parameter service. > > The second one. I have dug in the perl libraries code, and I saw how the > MOBY message is built. You could create your own expanded version of > 'execute' method based on the one in MOBY::Client::Service. Then, you > should be able to test your service. But, the drawback is your service > could only be instantiated by your expanded 'execute', so it will not be > widely usable until the client API evolves. > > So, Mark, what do you think about the tricks? Or, do you better think > we should wait for the new client API? I have also seen there is no way > to send 'Secondary' parameters to a service, and they are very > interesting when you are implementing a computational service. > > Best regards, > Jos? Mar?a Fern?ndez -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Thu Apr 1 14:14:31 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Apr 1 14:19:49 2004 Subject: [CBIN] [MOBY-l] GetPubmed service: calling from Perl, sample response In-Reply-To: <5.2.1.1.2.20040401123319.01a23ca0@email.med.harvard.edu> References: <5.2.1.1.2.20040401123319.01a23ca0@email.med.harvard.edu> Message-ID: <1080846870.3733.4.camel@localhost.localdomain> Yeah, the list server is stripping all attachments right now. I must have "hit a switch" that I didn't mean to when I was playing with the settings to cut down on the amount of spam we were getting... I'll try to see where I went wrong. In the meantime, inline is the best we can do. M On Thu, 2004-04-01 at 09:38, Frank Gibbons wrote: > Oops - sorry about that, Vijay, I was sure I had attached it. The list > server told me my message looked suspicious, and perhaps it stripped it. > Whatever the reason, here it is appended, the output is attached, since > it's rather long. > > -Frank > > At 12:15 PM 4/1/2004, Vijay Narayanasamy wrote: > >Frank, > > > >The attachment PMid.pl is missing. > > > >Vijay > > > >Vijay Narayanasamy > >Project Programmer / Analyst > >Bioinformatics Program, Human and Molecular Genetics Center > >Medical College of Wisconsin > >8701, W. Watertown Plank Road > >Milwaukee, WI 53226 > >414-456-8026 > >vnarayan@mcw.edu > >http://brc.mcw.edu/ > > > >-----Original Message----- > >From: Frank Gibbons [mailto:fgibbons@hms.harvard.edu] > >Sent: Thursday, April 01, 2004 9:59 AM > >To: moby-l@biomoby.org > >Subject: Re: [MOBY-l] help needed for GetPubmed service > > > >Martin, > > > > Thanks for any advise, actually, if someone can get me any simple XML > > >object and tell me where to send it in order to get an answer and not an > > >errror I will be happy... :-) > > > > > >I'm attaching some Perl code (PMid.pl) that calls the GetPubmed service at > >prometheus. I wrote it last week, and just tried it right now, and it still > >works. I'm also appending the output from the service also (PM.txt). > > > >I hope this helps. > > > >-Frank > > > > > > > >PhD, Computational Biologist, > >Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > >Tel: 617-432-3555 Fax: > >617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > ================= Perl code to look up PubMed IDs at GetPubmed service > =============== > #!/home/fgibbons/bin/perl > > use MOBY::Client::Central; > use MOBY::Client::Service; > > my $Central = MOBY::Client::Central->new(); > > my ($Services, $REG) = > $Central->findService( authURI => 'prometheus.brc.mcw.edu', > serviceName => 'GetPubmed' > ); > unless ($Services) { > print "Service discovery failed with the following errror: ", > $REG->message; > end > } > > my @PMids = ("9788350", "14730315", "12368250"); > printf("%-35s\t\t %s\n%s\n", "Service", "provided by", "="x80); > foreach my $S ( @{$Services}) { > printf("%-35s\t\t%s%s\n", $S->name, $S->authority, $S->description); > my $WSDL = $Central->retrieveService($S); > my $service = MOBY::Client::Service->new(service => $WSDL); > foreach my $pmid (@PMids) { > my $result = > $service->execute( XMLinputlist => [ > ['object0', > " namespace='PMID' id='" . $pmid > . "' articleName='" . > $pmid . "'/>"], > ] > ) || 'None'; > print "Result: ", $result, "\n"; > } > } > > > > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > ______________________________________________________________________ > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Thu Apr 1 16:29:38 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Apr 1 16:35:50 2004 Subject: [MISC] Re: [MOBY-l] How to debug multi-parameter services In-Reply-To: <1080842821.2348.22.camel@localhost.localdomain> References: <200403300801.i2U81FEU337439@electre.pasteur.fr> <406C4B92.7020902@cnb.uam.es> <1080842821.2348.22.camel@localhost.localdomain> Message-ID: <1080854978.3734.43.camel@localhost.localdomain> Okay, it should be working properly now. The MOBY::Client::Service->execute method takes the following arguments: ->execute(XMLinputlist => \@invocations) where: @invocations = (\@inputs1, \@inputs2, \@inputs3) @inputs1 = ($name_a,$Object_a, $name_b,$Object-b,...) or @inputs1 = ($name_a,\@Collect_a, $name_b,\@Collect-b) @Collect_a = ($Object_a, $Object_b, $Object_c) So... The way to pass multiple Simple articles as arguments to a single invocation of a service (i.e. a service that takes more than one input per invocation) is to call the MOBY::Client::Service->execute method as follows: ->execute(XMLinputlist => [ [ 'thing1', '', 'thing2', '', 'thing3', '' ] ] I just tested that and it seems to work, however if anyone notices that there is still a bug please let me know ASAP! Sorry for being so slow... Mark -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Thu Apr 1 20:22:29 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Apr 1 20:27:37 2004 Subject: [MOBY-l] GetPubmed service: calling from Perl, sample response In-Reply-To: <5.2.1.1.2.20040401123319.01a23ca0@email.med.harvard.edu> Message-ID: Thanks for sending me data and code. The differences (between your perl and my Java) are in SOAPAction header and in the coding. I am sending input as a string - you are sending it as CDATA block. The second difference should not matter. The SOAPAction is created from given URI. I was using 'http://mobycentral.cbr.nrc.ca/MOBY/Central' - which was wrong. When I changed it to yours: 'http://biomoby.org/' I got results correctly back. I GOT RESULTS CORRECTLY BACK. So, Mark, what did you mean (in doc) by "At this moment" when talking about this URI as mandatory one? Is this a pending issue or a solved one? I would still feel more comfortable if this datum become part of the service registration... Thanks for the help, 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 simont at mcw.edu Sun Apr 4 16:39:32 2004 From: simont at mcw.edu (Twigger, Simon) Date: Sun Apr 4 16:49:24 2004 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology Message-ID: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> Hi there, After some hacking around online whilst waiting in the scenic Concourse B at La Guardia airport, I found a DAML/Oil editor that I could get to work on my Mac and that accepted the MyGrid ontology files: I tried the Protege editor which looked really nice but I couldnt find a way to get DAML/Oil into the app from the flat file, the DAML/Oil plugin is out of date and doesnt work with the latest version of protege (http://protege.stanford.edu). It looks good and has an Owl plugin but I dont have Owl files to play with to test it out. OilEd : http://oiled.man.ac.uk/ (java app) The MyGrid ontology files can be found here: http://cvs.mygrid.org.uk/cgi-bin/viewcvs.cgi/mygrid/ontology-server/etc/onto logy/ I used the mygrid.daml file in OilEd and its working nicely. >From preliminary review, it looks like the branches of interest for the MOBY service ontology might be: top:domain_concept#1:process#1:generic_process#1 This has things like: aligning, calculating, filtering, grouping, parsing, retrieving, etc. and is along the same lines as we have right now in MOBY, there are 17 terms in this brank with only aligning having any children. I'll look more at this and go from there. Simon. From p.lord at russet.org.uk Mon Apr 5 06:59:02 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Mon Apr 5 07:07:30 2004 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> Message-ID: >>>>> "Simon" == Twigger, Simon writes: Simon> After some hacking around online whilst waiting in the scenic Simon> Concourse B at La Guardia airport, I found a DAML/Oil editor Simon> that I could get to work on my Mac and that accepted the Simon> MyGrid ontology files: Simon> I tried the Protege editor which looked really nice but I Simon> couldnt find a way to get DAML/Oil into the app from the flat Simon> file, the DAML/Oil plugin is out of date and doesnt work with Simon> the latest version of protege Simon> (http://protege.stanford.edu). It looks good and has an Owl Simon> plugin but I dont have Owl files to play with to test it out. OWL support for protege certainly exists. As well as the OWL plugin you might want to look at... http://www.co-ode.org/ which is starting to build some quite nifty support for OWL editing into protege. Simon> OilEd : http://oiled.man.ac.uk/ (java app) Simon> The MyGrid ontology files can be found here: Simon> http://cvs.mygrid.org.uk/cgi-bin/viewcvs.cgi/mygrid/ontology-server/etc/onto Simon> logy/ Simon> I used the mygrid.daml file in OilEd and its working nicely. It would be depressing if oiled could not load mygrid.daml. It was written with oiled, at least initially. And later it was generated with the oiled code base. One thing which is worth mentioning is that the file you are looking at has not been reasoned over. So many of the is-a links that you might expect to see are not there; they will magically appear if you use the reasoner. Sadly at the moment the reasoner will not run on a mac, although we have a new version that should do. >> From preliminary review, it looks like the branches of interest >> for the MOBY Simon> service ontology might be: Simon> top:domain_concept#1:process#1:generic_process#1 Simon> This has things like: aligning, calculating, filtering, Simon> grouping, parsing, retrieving, etc. and is along the same Simon> lines as we have right now in MOBY, there are 17 terms in Simon> this brank with only aligning having any children. I'll look Simon> more at this and go from there. I think that it would be nice if we can try and keep the meanings of the different properties in sync in so far as that is possible between the mygrid ontology and the moby one. Ontologies are, after all, only useful in so far as they are shared. Cheers Phil From p.lord at russet.org.uk Mon Apr 5 13:22:10 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Mon Apr 5 13:30:33 2004 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Many thanks for your comments, I was hoping someone from Simon> MyGrid would catch this. At the MOBY developers meeting this Simon> weekend we decided it was time to expand the MOBY service Simon> ontology and the existing MyGrid ontology seemed like a great Simon> place to start. I completely agree that we should endeavor to Simon> keep things in sync where ever possible. Something that I would be keen to do is to come up with an OBO style ontology from the original mygrid one. Mark and I have discussed this before, but we've never got around to it. Simon> I've been looking through the list of pubs from MyGrid and it Simon> looks like Chris Wroe's paper in Int. J. Cooperative Simon> Info. Systems. Vol. 12, No. 2 (2003) 197-224 on "DAML+OIL Simon> ontologies to describe bioinformatics web services and Simon> data"would be a good place for me to start reading about how Simon> this ontology came together. If there are other docs that you Simon> would recommend please let me know. Once I've got a better Simon> feel for things I'll probably pester you for more information Simon> if thats Ok. This paper is probably the best place to start. You might want to try this ontology.... http://www.cs.man.ac.uk/~phillord/download/scratch/mygrid-reasoned.daml which is the same ontology but fully reasoned over you. Simon> Thanks for the info on Protege at http://www.co-ode.org/, I Simon> found an OWL plugin already but the graph drawing plugin Simon> looks handy so I'll give that a go too. It's very cute I think. Cheers Phil From simont at mcw.edu Mon Apr 5 17:34:23 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon Apr 5 17:39:22 2004 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> Hi Phil, On Apr 5, 2004, at 12:22 PM, Phillip Lord wrote: > > > Something that I would be keen to do is to come up with an OBO style > ontology from the original mygrid one. Mark and I have discussed this > before, but we've never got around to it. By OBO style do you mean convert the existing DAML version into a format accepted by OBO, presumably OWL? The Reasoned version of the DAML makes a huge difference - thanks. Just to check my understanding of what's going on here - reasoning the ontology has pulled together all possible hierarchies that were defined in the model but previously 'hidden' in the unreasoned version by virtue of it being a non-redundant listing of terms? Hence the reasoned version now shows every allowable path to a class and so you get a better perspective of what lives where? Cheers, Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 From p.lord at russet.org.uk Tue Apr 6 06:18:06 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Tue Apr 6 06:26:45 2004 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Hi Phil, Simon> On Apr 5, 2004, at 12:22 PM, Phillip Lord wrote: >> >> >> Something that I would be keen to do is to come up with an OBO >> style ontology from the original mygrid one. Mark and I have >> discussed this before, but we've never got around to it. Simon> By OBO style do you mean convert the existing DAML version Simon> into a format accepted by OBO, presumably OWL? Yes and no. Translating to OWL by itself is (nearly) trivial and something that we can just do. The deeper issue is considering the semantics of OWL and the less defined semantics of OBO. We could just take the ontology as stands and turn it into a DAG. But if we just take the class hierarchy we will loose much of the information. Simon> The Reasoned version of the DAML makes a huge difference - Simon> thanks. Simon> Just to check my understanding of what's going on here - Simon> reasoning the ontology has pulled together all possible Simon> hierarchies that were defined in the model but previously Simon> 'hidden' in the unreasoned version by virtue of it being a Simon> non-redundant listing of terms? Hence the reasoned version Simon> now shows every allowable path to a class and so you get a Simon> better perspective of what lives where? Not really no. The hierarchy browser in Oiled shows the information that it has. That terms occur redundantly is just a way of displaying a multiple inheritance hierarchy. The reasoner does something more complex. In a description logic based ontology you tend to model the classes by describing their properties and then let the reasoner work out what subclass and super class relationships. Take the following example. This is using the (poorly named) OWL concrete abstract syntax. Class(SegregatingUnit complete restriction(involvedIn someValuesFrom (Segregation ))) segregating units are involved in segregation.... Class(Chromosome complete intersectionOf(SegregatingUnit restriction(hasPart someValuesFrom (Telomere )) restriction(hasPart someValuesFrom (Centromere )))) chromosomes are things which are segregating units, and have a part which is a telomere and a part which is a centromere. This is definitional. Class(CloningVector partial SegregatingUnit ) cloning vectors are segregating units also... Class(YAC partial CloningVector restriction(hasPart someValuesFrom (Telomere )) restriction(hasPart someValuesFrom (Centromere ))) A YAC (yeast artificial chromosome...all the rage when I still worked in the lab!) is a cloning vector with a telomere and centromere. >From which we can conclude that a YAC is a chromosome as it's a segregating unit with a telomere and a centromere. We can also conclude that... Class(AcentricChromosome partial Chromosome ) DisjointClasses(restriction(hasPart someValuesFrom (Centromere )) AcentricChromosome ) a chromosome with out a centromere is a contradiction in terms.... DisjointClasses(AcentricChromosome SegregatingUnit) as is a chromosome which is not a segregating unit. In the mygrid ontology a lot of the super class/sub class links are not stated explicitly but only generated by the reasoner. This style of modelling is sort of like Object orientation...but upside down. Properties define super classes, rather than sub classes inheriting properties. This is one of the big selling points of OWL (or at least OWL-DL). Its highly expressive but still computationally tractable. We can mathematically guarantee that any statement you can make in OWL-DL can be reasoner over. This is not true of OWL-Full or RDF; there are questions which can not be answered: that is are "undecidable". If this sounds counter intuitive then it can be considered as a variation on the theme of Turing's halting problem. There are somethings you just can't work out. Anyway from a practical point of view the reasoned ontology has all of the super/sub class relationships explicitly stated. It's the "compiled" form if you like. Cheers Phil From simont at mcw.edu Mon Apr 5 10:33:46 2004 From: simont at mcw.edu (Simon Twigger) Date: Tue Apr 6 10:22:10 2004 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> Message-ID: <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> Hi Phil, Many thanks for your comments, I was hoping someone from MyGrid would catch this. At the MOBY developers meeting this weekend we decided it was time to expand the MOBY service ontology and the existing MyGrid ontology seemed like a great place to start. I completely agree that we should endeavor to keep things in sync where ever possible. I've been looking through the list of pubs from MyGrid and it looks like Chris Wroe's paper in Int. J. Cooperative Info. Systems. Vol. 12, No. 2 (2003) 197-224 on "DAML+OIL ontologies to describe bioinformatics web services and data"would be a good place for me to start reading about how this ontology came together. If there are other docs that you would recommend please let me know. Once I've got a better feel for things I'll probably pester you for more information if thats Ok. Thanks for the info on Protege at http://www.co-ode.org/, I found an OWL plugin already but the graph drawing plugin looks handy so I'll give that a go too. Cheers, Simon. On Apr 5, 2004, at 5:59 AM, Phillip Lord wrote: > >>>>>> "Simon" == Twigger, Simon writes: > > Simon> After some hacking around online whilst waiting in the scenic > Simon> Concourse B at La Guardia airport, I found a DAML/Oil editor > Simon> that I could get to work on my Mac and that accepted the > Simon> MyGrid ontology files: > > Simon> I tried the Protege editor which looked really nice but I > Simon> couldnt find a way to get DAML/Oil into the app from the flat > Simon> file, the DAML/Oil plugin is out of date and doesnt work with > Simon> the latest version of protege > Simon> (http://protege.stanford.edu). It looks good and has an Owl > Simon> plugin but I dont have Owl files to play with to test it out. > > OWL support for protege certainly exists. As well as the OWL plugin > you might want to look at... > > http://www.co-ode.org/ > > which is starting to build some quite nifty support for OWL editing > into protege. > > > Simon> OilEd : http://oiled.man.ac.uk/ (java app) > > Simon> The MyGrid ontology files can be found here: > > Simon> > http://cvs.mygrid.org.uk/cgi-bin/viewcvs.cgi/mygrid/ontology-server/ > etc/onto > Simon> logy/ > > Simon> I used the mygrid.daml file in OilEd and its working nicely. > > It would be depressing if oiled could not load mygrid.daml. It was > written with oiled, at least initially. And later it was generated > with the oiled code base. > > One thing which is worth mentioning is that the file you are looking > at has not been reasoned over. So many of the is-a links that you > might expect to see are not there; they will magically appear if you > use the reasoner. Sadly at the moment the reasoner will not run on a > mac, although we have a new version that should do. > > >>> From preliminary review, it looks like the branches of interest >>> for the MOBY > Simon> service ontology might be: > > Simon> top:domain_concept#1:process#1:generic_process#1 > > Simon> This has things like: aligning, calculating, filtering, > Simon> grouping, parsing, retrieving, etc. and is along the same > Simon> lines as we have right now in MOBY, there are 17 terms in > Simon> this brank with only aligning having any children. I'll look > Simon> more at this and go from there. > > I think that it would be nice if we can try and keep the meanings of > the different properties in sync in so far as that is possible between > the mygrid ontology and the moby one. Ontologies are, after all, only > useful in so far as they are shared. > > Cheers > > Phil > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > > -- 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 From markw at illuminae.com Tue Apr 6 10:30:57 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 6 10:36:24 2004 Subject: [MOBY] Re: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> Message-ID: <1081261856.1983.43.camel@localhost.localdomain> > Simon> This has things like: aligning, calculating, filtering, > Simon> grouping, parsing, retrieving, etc. and is along the same > Simon> lines as we have right now in MOBY, there are 17 terms in > Simon> this brank with only aligning having any children. I'll look > Simon> more at this and go from there. > > I think that it would be nice if we can try and keep the meanings of > the different properties in sync in so far as that is possible between > the mygrid ontology and the moby one. I think we can all agree on that :-) Phil, do you guys have canonical LSID representations for your service ontology terms? Also, I notice that URI's like: http://www.mygrid.org.uk/ontology#bioinformatics_service don't actually resolve. Is there a plan to do this such that in MOBY we can "point to" a node on your ontology and have a client program be able to find it? Cheers! M > Ontologies are, after all, only > useful in so far as they are shared. > > Cheers > > Phil > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From simont at mcw.edu Tue Apr 6 11:53:57 2004 From: simont at mcw.edu (Simon Twigger) Date: Tue Apr 6 11:58:55 2004 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: <9D325ECA-87E2-11D8-B4C2-000A959D1D82@mcw.edu> On Apr 6, 2004, at 5:18 AM, Phillip Lord wrote: > Simon> By OBO style do you mean convert the existing DAML version > Simon> into a format accepted by OBO, presumably OWL? > > Yes and no. Translating to OWL by itself is (nearly) trivial and > something that we can just do. > I found a convertor script from DAML+OIL to OWL so i did wonder if I was missing something here. > The deeper issue is considering the semantics of OWL and the less > defined semantics of OBO. We could just take the ontology as stands > and turn it into a DAG. But if we just take the class hierarchy we > will loose much of the information. By OBO-style I take it that you are referring to the DAG structure of something like GO. What would be goal be of converting to this style - a more 'friendly' format for existing users to work from, rather than asking them to step up to OWL and the extra complexity & functionality? > > The reasoner does something more complex. In a description logic based > ontology you tend to model the classes by describing their > properties and then let the reasoner work out what subclass and super > class relationships. Thanks for the explanation of the reasoner, it makes much more sense now. Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 From p.lord at russet.org.uk Tue Apr 6 12:19:36 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Tue Apr 6 12:28:02 2004 Subject: [MOBY] Re: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <1081261856.1983.43.camel@localhost.localdomain> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <1081261856.1983.43.camel@localhost.localdomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Simon> This has things like: aligning, calculating, filtering, Simon> grouping, parsing, retrieving, etc. and is along the same Simon> lines as we have right now in MOBY, there are 17 terms in Simon> this brank with only aligning having any children. I'll look Simon> more at this and go from there. >> >> I think that it would be nice if we can try and keep the meanings >> of the different properties in sync in so far as that is possible >> between the mygrid ontology and the moby one. Mark> I think we can all agree on that :-) Phil, do you guys have Mark> canonical LSID representations for your service ontology Mark> terms? Mark> Also, I notice that URI's like: Mark> http://www.mygrid.org.uk/ontology#bioinformatics_service don't Mark> actually resolve. Is there a plan to do this such that in Mark> MOBY we can "point to" a node on your ontology and have a Mark> client program be able to find it? Well they aren't supposed to resolve. The URI's in OWL and RDF are supposed to be semantic free. I agree that there is nothing to stop us adding additional semantics to the URI. When you say "have a client program find it", what are you expecting to find? Phil From p.lord at russet.org.uk Tue Apr 6 12:22:58 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Tue Apr 6 12:29:49 2004 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <9D325ECA-87E2-11D8-B4C2-000A959D1D82@mcw.edu> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> <9D325ECA-87E2-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: >> Yes and no. Translating to OWL by itself is (nearly) trivial and >> something that we can just do. >> Simon> I found a convertor script from DAML+OIL to OWL so i did Simon> wonder if I was missing something here. There are some things that DAML+OIL can do which OWL cannot (and vice versa). And the mygrid ontology does use them at points. It adds to the complexity. >> The deeper issue is considering the semantics of OWL and the less >> defined semantics of OBO. We could just take the ontology as >> stands and turn it into a DAG. But if we just take the class >> hierarchy we will loose much of the information. Simon> By OBO-style I take it that you are referring to the DAG Simon> structure of something like GO. What would be goal be of Simon> converting to this style - a more 'friendly' format for Simon> existing users to work from, rather than asking them to step Simon> up to OWL and the extra complexity & functionality? Mostly the later. One obvious way to manage the complexity is to keep the source ontology as the OWL version that mygrid has using reasoning the like. The OBO style ontology would then be an alternate simplified view. Clearly its easier to generate out a simpler representation from a richer one than the other way around. >> >> The reasoner does something more complex. In a description logic >> based ontology you tend to model the classes by describing their >> properties and then let the reasoner work out what subclass and >> super class relationships. Simon> Thanks for the explanation of the reasoner, it makes much Simon> more sense now. I wish I could say that same. I've been using it for several years and I still don't quite understand what the reasoner does! Cheers Phil From markw at illuminae.com Tue Apr 6 14:47:10 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 6 14:52:06 2004 Subject: [MOBY-l] [Fwd: [Hackathon] OBO and OWL formats (fwd)] Message-ID: <1081277230.1983.131.camel@localhost.localdomain> -----Forwarded Message----- > From: Chris Mungall > To: Mark Wilkinson > Subject: OBO and OWL formats > As one of people responsible for the OBO format I just wanted to let you > know that this format was designed to be both a lightweight format for > simple DAG-style ontologies (which presently covers all the ontologies > within OBO) as well as an extensible format capable of handling the full > semantics of OWL. > > Although we haven't fully tried yet, it should be possible to represent > any OWL construct in OBO (we just haven't fully documented how to do this > yet). We care specifically about intersectionOf (for making complete vs > partial definitions) - there should be support for this in DAG Edit soon. > > The go-perl library from www.godatabase.org/dev has a converter for going > GO/OBO format to OWL and a (currently very lossy) converter for the > reverse. This should also be built into DAG Edit sometime soon. > > With regards to reasoners, I've found the combination of protege plus OWL > plug in plus racer to also work well. > > It seems that OBO format would be a good choice for MOBY since it is > always possible to treat OBO format as just a simple DAG ontology (just > ignore the pesky stuff in the {}s) yet at the same time you can have > complex enough definitions to warrant reasoning over. > > Cheers > Chris From gberriz at hms.harvard.edu Thu Apr 8 13:41:42 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Thu Apr 8 13:42:40 2004 Subject: [MOBY-l] Message syntax Message-ID: <5.2.1.1.2.20040408133737.0730ee00@email.med.harvard.edu> Hi. I'm relatively new to MOBY; still finding my way around. Where can I find a description of the syntax for MOBY requests and responses? My immediate interest is learning about the correct syntax for elements with tags "queryInput", "Simple", and "Collection"? Thanks, G. From fgibbons at hms.harvard.edu Thu Apr 8 17:03:08 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu Apr 8 17:05:01 2004 Subject: [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example Message-ID: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> Mark, One topic which I'm having great difficulty with, and for which I can find no obvious examples, is how to parse the response from a service. As was discussed at the MOBY meeting in CSHL, there's a somewhat different syntax for queries and responses. The examples I have found describe how to provide a service (how to handle incoming requests). None talks about how to parse incoming responses. Now perhaps I'm just being really dense here: the difference really couldn't be that big. I've tried running your MOBYSHoundGetGetBankff with NCBI_gi:431260 as the query, I get back a nice fat response. But I'm really having difficulty extracting the information. Do you (or anyone else on the list) have an example you could post, showing how to deal with the response from a query? Maybe there are examples out there already - if so, I'd really appreciate someone pointing them out to me. Thanks for that, and thanks to yourself and the other CSHL::MOBYers for a great introduction to things MOBY. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From fgibbons at hms.harvard.edu Thu Apr 8 17:21:56 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu Apr 8 17:23:49 2004 Subject: [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example In-Reply-To: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040408171437.01aa7518@email.med.harvard.edu> Hi, Let me add to my previous comment, to make it more specific: If I'm trying to process a request, the first thing I do is call "getInputs( )". What is the analogue of that for handling the service's response to a request? I'm just looking for the sequence of function calls, and the names of the API functions that I should be using. Thanks, -Frank At 05:03 PM 4/8/2004, you wrote: >One topic which I'm having great difficulty with, and for which I can find >no obvious examples, is how to parse the response from a service. As was >discussed at the MOBY meeting in CSHL, there's a somewhat different >syntax for queries and responses. The examples I have found describe how >to provide a service (how to handle incoming requests). None talks about >how to parse incoming responses. > >Now perhaps I'm just being really dense here: the difference really >couldn't be that big. I've tried running your MOBYSHoundGetGetBankff with >NCBI_gi:431260 as the query, I get back a nice fat response. But I'm >really having difficulty extracting the information. Do you (or anyone >else on the list) have an example you could post, showing how to deal with >the response from a query? Maybe there are examples out there already - if >so, I'd really appreciate someone pointing them out to me. > >Thanks for that, and thanks to yourself and the other CSHL::MOBYers for a >great introduction to things MOBY. PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Apr 8 18:41:20 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Apr 8 19:25:59 2004 Subject: [MISC] [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example In-Reply-To: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> References: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> Message-ID: <1081464080.3075.76.camel@localhost.localdomain> Hi Frank, It is best to use the provided libraries (or add to them) to do the parsing, since that allows us to change the "guts" of the messaging structure without it affecting you on either the service or client side. There is only one ~useful client-side method call "extract response articles", that is available in the MOBY::CommonSubs module. my $result = $SERVICE->execute(XMLinputlist => [['',$OBJECT]]); # execute the service unless ($result){ print h3("Service returned no response"); exit 0; } my ($collections, $simples) =extractResponseArticles($result); This (unfortunately) returns the individual responses as XML::DOM objects, rather than having a MOBY-specific API to access the information in these objects. Ken has some code that does a much nicer job of creating Perl objects from MOBY Object XML, but at the moment it isn't 100% API compliant. I'm hoping this will one day this will migrate into this CommonSubs routine so that all of the libraries are in one place... A complete example of a client-side parsing is available in the gbrowse_moby 'execute' subroutine. I attach the code here (it will get to you, but it will probably get stripped off of the copy that goes to the mailing list). It will show you how the existing CGI client (the one you see when you browse MOBY from the website) parses the response message into its component parts using calls to the XML::DOM library. Let me know if I can help some more - the need for tooling is becoming quite urgent, I know! Just a couple more grants to write and then I will have a ~month clear to attack the code again :-) M On Thu, 2004-04-08 at 14:03, Frank Gibbons wrote: > Mark, > > One topic which I'm having great difficulty with, and for which I can find > no obvious examples, is how to parse the response from a service. As was > discussed at the MOBY meeting in CSHL, there's a somewhat different syntax > for queries and responses. The examples I have found describe how to > provide a service (how to handle incoming requests). None talks about how > to parse incoming responses. > > Now perhaps I'm just being really dense here: the difference really > couldn't be that big. I've tried running your MOBYSHoundGetGetBankff with > NCBI_gi:431260 as the query, I get back a nice fat response. But I'm really > having difficulty extracting the information. Do you (or anyone else on the > list) have an example you could post, showing how to deal with the response > from a query? Maybe there are examples out there already - if so, I'd > really appreciate someone pointing them out to me. > > Thanks for that, and thanks to yourself and the other CSHL::MOBYers for a > great introduction to things MOBY. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gberriz at hms.harvard.edu Fri Apr 9 09:30:01 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Fri Apr 9 09:31:02 2004 Subject: [MISC] [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example In-Reply-To: <1081464080.3075.76.camel@localhost.localdomain> References: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040409092440.0264ea78@email.med.harvard.edu> At 03:41 PM 4/8/2004 -0700, Mark Wilkinson wrote: >There is only one ~useful client-side method call "extract response >articles", that is available in the MOBY::CommonSubs module. > >This (unfortunately) returns the individual responses as XML::DOM >objects, rather than having a MOBY-specific API to access the >information in these objects. Ken has some code that does a much nicer >job of creating Perl objects from MOBY Object XML, but at the moment it >isn't 100% API compliant. I'm hoping this will one day this will migrate >into this CommonSubs routine so that all of the libraries are in one >place... Mark, I'd be happy to take a crack at it. Where can I find this code by Ken? What's the name of the sub, and what exactly is not API-compliant about it? (I assume that the API you are referring to is the one at http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI ; please correct me if I'm wrong.) Regards, Gabriel From gberriz at hms.harvard.edu Fri Apr 9 09:46:38 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Fri Apr 9 09:47:40 2004 Subject: [MISC] [MOBY-l] Processing MOBY responses:MOBYSHoundGetGenBankff as an example In-Reply-To: Message-ID: <5.2.1.1.2.20040409094111.0731d5d8@email.med.harvard.edu> In that case, I'd be happy to try coding it from scratch. I would need to know the specific API/input-output signature for this sub. Do you (or anyone else reading this) have it? Regards, G. At 08:29 AM 4/9/2004 -0500, mwilkinson wrote: >Hi Gabriel > >I decided to take advantage of the easter weekend to upgrade my Linux >kernel... It didn't go as well as I had hoped! I don't have a network at >the moment so I can't point you to Ken's library (I'm responding from my >blackberry) > >If you don't get a response from someone else first, I'll reply as soon as >I get my net back up. > >Thanks for the offer! > >M > >-----Original Message----- >From: Gabriel Berriz >Date: Fri, 09 Apr 2004 09:30:01 >To:markw@illuminae.com >Cc:mobyl >Subject: Re: [MISC] [MOBY-l] Processing MOBY responses: > MOBYSHoundGetGenBankff as an example > >At 03:41 PM 4/8/2004 -0700, Mark Wilkinson wrote: > >There is only one ~useful client-side method call "extract response > >articles", that is available in the MOBY::CommonSubs module. > > > >This (unfortunately) returns the individual responses as XML::DOM > >objects, rather than having a MOBY-specific API to access the > >information in these objects. Ken has some code that does a much nicer > >job of creating Perl objects from MOBY Object XML, but at the moment it > >isn't 100% API compliant. I'm hoping this will one day this will migrate > >into this CommonSubs routine so that all of the libraries are in one > >place... > >Mark, > >I'd be happy to take a crack at it. Where can I find this code by >Ken? What's the name of the sub, and what exactly is not API-compliant >about it? (I assume that the API you are referring to is the one at >http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI ; please correct me if >I'm wrong.) > >Regards, > >Gabriel > > >_______________________________________________ >moby-l mailing list >moby-l@biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > >!!!!!!!!!!!!!!!! >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 gberriz at hms.harvard.edu Fri Apr 9 12:53:06 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Fri Apr 9 12:54:06 2004 Subject: [MOBY] Re: [MISC] [MOBY-l] Processing MOBY responses:MOBYSHoundGetGenBankff as an example In-Reply-To: <1081528661.1051.13.camel@localhost.localdomain> References: <5.2.1.1.2.20040409094111.0731d5d8@email.med.harvard.edu> <5.2.1.1.2.20040409094111.0731d5d8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040409125153.073d3488@email.med.harvard.edu> OK, I'll look over the code and get to it. Thanks. G. At 09:37 AM 4/9/2004 -0700, Mark Wilkinson wrote: >Ha! Network is back up :-) > >So, the module is described on the following page: > >http://plantgenome.sdsc.edu/mobyed2/learn.html > >It is called "MobyXmlObject.pm" > >The portions that are not fully API compliant (AFAIK) are: > >1) It does not record the queryID when parsing MOBY messages. This >will be critical for both client and service-side message parsing. > >2) The latest API change (not yet implemented, since we only decided it >last weekend) is that the message structure for both request and >response will be identical. Thus the moby:Query moby:queryInput, >moby:Response and moby:queryResponse have been replaced by the two tags >moby:mobyContent (outer tag) and moby:mobyData (inner tag). I don't >know if Ken's parser is parsing messages based on these tags, but it if >is, it will need to be tweaked to accept both the old and the new for at >least the transition period. > > >If you are planning to migrate this into the CommonSubs routine (sub >genericServiceInputParser and sub extractResponseArticles) that would be >wonderful! > >That code (CommonSubs.pm) is quite hairy, though, since it is really >just in the prototype stages... I hope it is readable! > >M > > > > >On Fri, 2004-04-09 at 06:46, Gabriel Berriz wrote: > > In that case, I'd be happy to try coding it from scratch. I would need to > > know the specific API/input-output signature for this sub. Do you (or > > anyone else reading this) have it? > > > > Regards, > > > > G. > > > > At 08:29 AM 4/9/2004 -0500, mwilkinson wrote: > > > > >Hi Gabriel > > > > > >I decided to take advantage of the easter weekend to upgrade my Linux > > >kernel... It didn't go as well as I had hoped! I don't have a network at > > >the moment so I can't point you to Ken's library (I'm responding from my > > >blackberry) > > > > > >If you don't get a response from someone else first, I'll reply as > soon as > > >I get my net back up. > > > > > >Thanks for the offer! > > > > > >M > > > > > >-----Original Message----- > > >From: Gabriel Berriz > > >Date: Fri, 09 Apr 2004 09:30:01 > > >To:markw@illuminae.com > > >Cc:mobyl > > >Subject: Re: [MISC] [MOBY-l] Processing MOBY responses: > > > MOBYSHoundGetGenBankff as an example > > > > > >At 03:41 PM 4/8/2004 -0700, Mark Wilkinson wrote: > > > >There is only one ~useful client-side method call "extract response > > > >articles", that is available in the MOBY::CommonSubs module. > > > > > > > >This (unfortunately) returns the individual responses as XML::DOM > > > >objects, rather than having a MOBY-specific API to access the > > > >information in these objects. Ken has some code that does a much nicer > > > >job of creating Perl objects from MOBY Object XML, but at the moment it > > > >isn't 100% API compliant. I'm hoping this will one day this will migrate > > > >into this CommonSubs routine so that all of the libraries are in one > > > >place... > > > > > >Mark, > > > > > >I'd be happy to take a crack at it. Where can I find this code by > > >Ken? What's the name of the sub, and what exactly is not API-compliant > > >about it? (I assume that the API you are referring to is the one at > > >http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI ; please correct > me if > > >I'm wrong.) > > > > > >Regards, > > > > > >Gabriel > > > > > > > > >_______________________________________________ > > >moby-l mailing list > > >moby-l@biomoby.org > > >http://biomoby.org/mailman/listinfo/moby-l > > > > > >!!!!!!!!!!!!!!!! > > >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! > > >!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > _______________________________________________ > > moby-l mailing list > > moby-l@biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l >-- >Mark Wilkinson (mwilkinson@mrl.ubc.ca) >University of British Columbia iCAPTURE Centre From mwilkinson at mobile.rogers.com Fri Apr 9 09:29:13 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Mon Apr 12 12:08:00 2004 Subject: [MISC] [MOBY-l] Processing MOBY responses:MOBYSHoundGetGenBankff as an example Message-ID: <200404091338.i39DcSg2028395@portal.open-bio.org> Hi Gabriel I decided to take advantage of the easter weekend to upgrade my Linux kernel... It didn't go as well as I had hoped! I don't have a network at the moment so I can't point you to Ken's library (I'm responding from my blackberry) If you don't get a response from someone else first, I'll reply as soon as I get my net back up. Thanks for the offer! M -----Original Message----- From: Gabriel Berriz Date: Fri, 09 Apr 2004 09:30:01 To:markw@illuminae.com Cc:mobyl Subject: Re: [MISC] [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example At 03:41 PM 4/8/2004 -0700, Mark Wilkinson wrote: >There is only one ~useful client-side method call "extract response >articles", that is available in the MOBY::CommonSubs module. > >This (unfortunately) returns the individual responses as XML::DOM >objects, rather than having a MOBY-specific API to access the >information in these objects. Ken has some code that does a much nicer >job of creating Perl objects from MOBY Object XML, but at the moment it >isn't 100% API compliant. I'm hoping this will one day this will migrate >into this CommonSubs routine so that all of the libraries are in one >place... Mark, I'd be happy to take a crack at it. Where can I find this code by Ken? What's the name of the sub, and what exactly is not API-compliant about it? (I assume that the API you are referring to is the one at http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI ; please correct me if I'm wrong.) Regards, Gabriel _______________________________________________ moby-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l !!!!!!!!!!!!!!!! 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 gabriel_berriz at hms.harvard.edu Mon Apr 12 07:00:20 2004 From: gabriel_berriz at hms.harvard.edu (Berriz, Gabriel F.) Date: Mon Apr 12 12:08:01 2004 Subject: [MOBY-l] SGD IDs Message-ID: <16C1B7E52D13C54D9297F8102407AC800651C2@MAILSERVER02.MED.HARVARD.EDU> I'm trying to prototype a service that takes a single gene ID as input. For starters I want to limit myself to yeast genes IDs, and more specifically to SGD IDs, which match the Perl pattern /^[SL]\d{7}$/. I'm trying to determine the right syntax for the service's input object. My *guess* is that it will be something like: but I have not been able to confirm this guess. The list returned by retrieveNamespaces includes at least three plausible candidates: SGD, SGD_LOCUS, and SGD_ORF. The description that comes along with these entries is not enough to disambiguate this choice. I am also confused by the fact that the namespace "Genbank/gi", which is used in several examples in MOBY-S's documentation, does not appear in the list returned by retrieveNamespaces. (It is possible that answers to some or all of the questions above are in some part of the documentation that I have missed; if so, please let me know.) Thanks, and regards, Gabriel From gberriz at hms.harvard.edu Mon Apr 12 12:10:12 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Mon Apr 12 12:10:42 2004 Subject: [MOBY-l] String & text-plain Message-ID: <5.2.1.1.2.20040412114659.01db2610@email.med.harvard.edu> Hi all. I'm trying to code a toy service that all it does is to echo back *verbatim* (through a text-plain object) the raw XML that it received as input. One thing I have not been able to figure out is the correspondence between an object's definition (as given in registerObject) and the raw XML string corresponding to this object. My immediate questions are 1. What exactly is the difference between String and text-plain? 2. It is my understanding that the raw XML representation for the String object corresponding to "my favorite string" is something like: What is the raw XML representation for the text-plain object corresponding to "my favorite string"? The larger question is that from the point of view of someone coding a service, how do I know the structure of the XML that my script will receive as input? An even larger concern is that I'm surprised by the amount of XML munging that I see in sample BioMOBY code. I thought the whole point of using SOAP modules was to insulate oneself from having to do much (or any) parsing and munging of XML. Gabriel A far more important question has to do with a client's ability to handle a given output from a service. This output presumably comes back as XML. How does the client figure out how to parse this output to get the desired information? I thought the whole idea was that this should be transparent to the client, but From steube at sdsc.edu Mon Apr 12 14:35:30 2004 From: steube at sdsc.edu (Ken Steube) Date: Mon Apr 12 14:40:17 2004 Subject: [MOBY-l] SGD IDs In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800651C2@MAILSERVER02.MED.HARVARD.EDU> Message-ID: I believe that Genbank/gi is NCBI_gi. Many of our namespaces come from the Gene Ontology Cross-reference Abbreviations List. I don't personally know which of the three for SGD you should use, but looking that list might help. Ken On Mon, 12 Apr 2004, Berriz, Gabriel F. wrote: > I'm trying to prototype a service that takes a single gene ID as > input. For starters I want to limit myself to yeast genes IDs, and > more specifically to SGD IDs, which match the Perl pattern > /^[SL]\d{7}$/. I'm trying to determine the right syntax for the > service's input object. My *guess* is that it will be something like: > > > > but I have not been able to confirm this guess. The list returned by > retrieveNamespaces includes at least three plausible candidates: SGD, > SGD_LOCUS, and SGD_ORF. The description that comes along with these > entries is not enough to disambiguate this choice. > > I am also confused by the fact that the namespace "Genbank/gi", which > is used in several examples in MOBY-S's documentation, does not appear > in the list returned by retrieveNamespaces. > > (It is possible that answers to some or all of the questions above are > in some part of the documentation that I have missed; if so, please > let me know.) > > Thanks, and regards, > > Gabriel > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > -- -- -- Ken Steube San Diego Supercomputer Center University of California, San Diego, MC 0505 9500 Gilman Drive San Diego, California, 92093-0505 USA FAX (858) 822-3610 From steube at sdsc.edu Mon Apr 12 14:49:46 2004 From: steube at sdsc.edu (Ken Steube) Date: Mon Apr 12 14:54:31 2004 Subject: [MOBY-l] String & text-plain In-Reply-To: <5.2.1.1.2.20040412114659.01db2610@email.med.harvard.edu> Message-ID: On Mon, 12 Apr 2004, Gabriel Berriz wrote: > Hi all. > > I'm trying to code a toy service that all it does is to echo back > *verbatim* (through a text-plain object) the raw XML that it received > as input. Just return the query string exactly: sub test_SequenceToFASTA { my ($caller, $query) = @_; return $query; # echo back the input } > > One thing I have not been able to figure out is the correspondence > between an object's definition (as given in registerObject) and the > raw XML string corresponding to this object. My immediate questions > are Here's a CGI that shows the XML for any object: http://plantsp.sdsc.edu/cgi-bin/MOBY/MOBY_display_object_xml.cgi?obj=AminoAcidSequence > > 1. What exactly is the difference between String and text-plain? text-plain ISA String, so they are identical in all except name (and therefore interpretation). An object only becomes different in content from its immediate parent when is HAS-A or HAS some item(s). > > 2. It is my understanding that the raw XML representation for the > String object corresponding to "my favorite string" is something like: > > It's more like this: my fav string id is some kind of ID describing where the string came from (it may be empty if that's appropriate). e.g. a string containing a sequence usually has the ID of the gene from which it came. > > What is the raw XML representation for the text-plain object > corresponding to "my favorite string"? my fav string > > The larger question is that from the point of view of someone coding a > service, how do I know the structure of the XML that my script will > receive as input? In the API document read about queryInput tags and Simple and Collection tags. Inside each simple/collection are MOBY XML objects. > > An even larger concern is that I'm surprised by the amount of XML > munging that I see in sample BioMOBY code. I thought the whole point > of using SOAP modules was to insulate oneself from having to do much > (or any) parsing and munging of XML. I tried to relieve us of some of that with my MobyXmlObject.pm object used in my FASTA example at http://plantgenome.sdsc.edu/mobyed2/Fasta_Service It needs some further development (to supply queryIDs + other things), but is very usable as-is. > > Gabriel > > > > > > A far more important question has to do with a client's ability to > handle a given output from a service. This output presumably comes > back as XML. How does the client figure out how to parse this output > to get the desired information? I thought the whole idea was that > this should be transparent to the client, but I have an example of chaining services together on my page http://plantgenome.sdsc.edu/mobyed2/Talks/discovering_executing_services.html It shows how to extract XML output from a service and feed it into another service. Ken -- -- -- Ken Steube San Diego Supercomputer Center University of California, San Diego, MC 0505 9500 Gilman Drive San Diego, California, 92093-0505 USA FAX (858) 822-3610 From gberriz at hms.harvard.edu Mon Apr 12 17:06:46 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Mon Apr 12 17:07:16 2004 Subject: [MOBY-l] Policy on the use of prefix 'moby'? Message-ID: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> Hello! I've noticed that in the sample code, some tagnames are qualified with the 'moby' prefix, while others (e.g. Integer) are not. I find this surprising, because I names like "Integer" and "Object" seem like likely candidates for namespace collisions. I couldn't find in the docs and the list's archive anything like a policy on the use of the moby prefix. Is there one? Thanks again, Gabriel From mwilkinson at mobile.rogers.com Tue Apr 13 01:04:45 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Tue Apr 13 01:15:50 2004 Subject: [MOBY-l] String & text-plain Message-ID: <200404130515.i3D5Flg2032727@portal.open-bio.org> The object looks like: some string content Date: Mon, 12 Apr 2004 12:10:12 To:moby-l@biomoby.org Subject: [MOBY-l] String & text-plain Hi all. I'm trying to code a toy service that all it does is to echo back *verbatim* (through a text-plain object) the raw XML that it received as input. One thing I have not been able to figure out is the correspondence between an object's definition (as given in registerObject) and the raw XML string corresponding to this object. My immediate questions are 1. What exactly is the difference between String and text-plain? 2. It is my understanding that the raw XML representation for the String object corresponding to "my favorite string" is something like: What is the raw XML representation for the text-plain object corresponding to "my favorite string"? The larger question is that from the point of view of someone coding a service, how do I know the structure of the XML that my script will receive as input? An even larger concern is that I'm surprised by the amount of XML munging that I see in sample BioMOBY code. I thought the whole point of using SOAP modules was to insulate oneself from having to do much (or any) parsing and munging of XML. Gabriel A far more important question has to do with a client's ability to handle a given output from a service. This output presumably comes back as XML. How does the client figure out how to parse this output to get the desired information? I thought the whole idea was that this should be transparent to the client, but _______________________________________________ moby-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l !!!!!!!!!!!!!!!! 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 gordonp at cbr.nrc.ca Tue Apr 13 09:24:40 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue Apr 13 09:29:25 2004 Subject: [MOBY-l] String & text-plain In-Reply-To: <200404130515.i3D5Flg2032727@portal.open-bio.org> References: <200404130515.i3D5Flg2032727@portal.open-bio.org> Message-ID: <407BEA18.7050109@cbr.nrc.ca> Yeah, there is some confusion among users here I think. SOAP uses XML for its envelope information, and if you use appropriate packages in the language of your choice, you can be unaware of that transaction envelope's syntax and semantics. But the payload of those SOAP messages is a MOBY XML document. We don't, as of yet, hide that from the user. >Soap does not insulate you from XML. > > From gordonp at cbr.nrc.ca Tue Apr 13 09:31:06 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue Apr 13 09:35:49 2004 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> References: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> Message-ID: <407BEB9A.3080200@cbr.nrc.ca> I have found many variations on this theme from different services, including non-prefixed Simple tags. I think the good old Web mantra applies here: be strict in what you produce, and forgiving in what you accept. In the Java peer-to-peer implementation (which I'll commit this week, honest) I accept objects like this with no namespace as being MOBY semantics. Sends a shiver down my spine... > Hello! > > I've noticed that in the sample code, some tagnames are qualified with > the 'moby' prefix, while others (e.g. Integer) are not. I find this > surprising, because I names like "Integer" and "Object" seem like > likely candidates for namespace collisions. > > I couldn't find in the docs and the list's archive anything like a > policy on the use of the moby prefix. Is there one? > > Thanks again, > > Gabriel > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From gordonp at cbr.nrc.ca Tue Apr 13 10:30:51 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue Apr 13 10:35:35 2004 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> References: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> Message-ID: <407BF99B.4050305@cbr.nrc.ca> Perhaps the best thing to do would be to have a RUWF? type service on the biomoby.org Web site for service developers... or perhaps have the MOBY clients send e-mails to the service provider every time they access a non-namespace compliant service :-) Gabriel Berriz wrote: > At 07:31 AM 4/13/2004 -0600, you wrote: > >> I think the good old Web mantra applies here: be strict in what you >> produce, and forgiving in what you accept. > > > Is this still the reigning principle? I was under the impression that > there's a strong movement in the Web standards community to fix the > mess we have now where so much of the HTML out there is malformed. > > Gabriel > > > From markw at illuminae.com Tue Apr 13 11:05:34 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 13 11:10:18 2004 Subject: [MOBY] Re: [MOBY-l] String & text-plain In-Reply-To: <407BEA18.7050109@cbr.nrc.ca> References: <200404130515.i3D5Flg2032727@portal.open-bio.org> <407BEA18.7050109@cbr.nrc.ca> Message-ID: <1081868733.1963.15.camel@localhost.localdomain> On Tue, 2004-04-13 at 06:24, Paul Gordon wrote: > But the payload of those SOAP messages > is a MOBY XML document. We don't, as of yet, hide that from the user. The key here is the word "yet" :-) I think it is important to remind newcomers to MOBY that it is not a "shrink-wrapped product". There is still quite a bit of tooling to be done, though I must say that things are working surprisingly well already, even though some of the messaging is a bit arcane... M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Tue Apr 13 11:16:56 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 13 11:21:44 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407BF99B.4050305@cbr.nrc.ca> References: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> Message-ID: <1081869416.2068.1.camel@localhost.localdomain> On Tue, 2004-04-13 at 07:30, Paul Gordon wrote: > Perhaps the best thing to do would be to have a RUWF? type service on > the biomoby.org Web site for service developers... That is probably a good idea for the time-being (who is going to volunteer to write that? ;-) ). In the future, as we get more tools, this problem will probably go away entirely. > or perhaps have the > MOBY clients send e-mails to the service provider every time they access > a non-namespace compliant service :-) Oh, yeah... they will LOVE us for that! :-) We (e.g. at the developers meeting last week) have been talking about various forms of meta-data servers that might be a good place to store information like this rather than annoying our service providers with email... I agree with your earlier comment about being forgiving in what you consume, though (in fact, this is somewhat mandated by the API, in that you are obligated to consume more complex objects than you advertise in your service signature). So, Paul, in your peer-to-peer implementation are you making assumptions about the namespace because there is no default, or because you want to be ultra-forgiving? Cheers! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Tue Apr 13 11:23:02 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Apr 13 11:27:57 2004 Subject: [MOBY] Re: [MOBY-l] String & text-plain In-Reply-To: <1081868733.1963.15.camel@localhost.localdomain> Message-ID: > > But the payload of those SOAP messages > > is a MOBY XML document. We don't, as of yet, hide that from the user. > > The key here is the word "yet" :-) > Well, my 2c opinion would put it slightly differently: "the key here is the word 'user'". Because if the 'user' is using Moby Central/Services API, it will always be dealing with XML, because MOBY Central/Services methods define their input and output parameters always as XML strings. And always will (unless Mark changes to RDF completely, but that would not help 'users' much). But if the 'user' is a user of libraries provided for individual languages then I agree that the word 'yet' is in order... 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 markw at illuminae.com Tue Apr 13 11:31:40 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 13 11:36:24 2004 Subject: [MOBY] Re: [MOBY-l] String & text-plain In-Reply-To: References: Message-ID: <1081870299.2068.12.camel@localhost.localdomain> On Tue, 2004-04-13 at 08:23, Martin Senger wrote: > unless Mark changes to RDF completely, but that would not > help 'users' much Well... this certainly sounded like a reasonable way to go after our discussions at the last meeting ;-) M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gordonp at cbr.nrc.ca Tue Apr 13 11:37:12 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue Apr 13 11:42:01 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <1081869416.2068.1.camel@localhost.localdomain> References: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <1081869416.2068.1.camel@localhost.localdomain> Message-ID: <407C0928.6090600@cbr.nrc.ca> I ONLY use namespace to match the tags (as namespace-aware XML should be done). Whether the tag has no namespace because there is no default, or because its prefix resolves to an empty namespace or any other reason you can imagine, is inconsequential. I try to digest things that are in the MOBY namespace, or in no namespace at all (a and b). If the default prefix was pointing to the XHTML namspace, I wouldn't try to digest that unprefixed tag (a), since it is neither a blank namespace, nor the MOBY namespace. >I agree with your earlier comment about being forgiving in what you >consume, though (in fact, this is somewhat mandated by the API, in that >you are obligated to consume more complex objects than you advertise in >your service signature). So, Paul, in your peer-to-peer implementation >are you making assumptions about the namespace because there is no >default, or because you want to be ultra-forgiving? > > From senger at ebi.ac.uk Tue Apr 13 11:40:28 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Apr 13 11:45:25 2004 Subject: [MOBY] Re: [MOBY-l] String & text-plain In-Reply-To: <1081870299.2068.12.camel@localhost.localdomain> Message-ID: > Well... this certainly sounded like a reasonable way to go after our > discussions at the last meeting ;-) > I am not saying that I disagree with turning to RDF, I was just expressing the fact, that the API users will never be protected against computer-readable formats (such as XML or RDF). That's all... 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 gberriz at hms.harvard.edu Tue Apr 13 11:48:01 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue Apr 13 11:48:34 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <1081869416.2068.1.camel@localhost.localdomain> References: <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> Message-ID: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> I realize now that the subject line for my post was somewhat misleading, because it suggested that I was bringing up the issue of how strictly software should enforce standards (which is an important one) In fact my main concern is that some very common keywords (such as Object, String, Integer, Float, text-plain) in the MOBY-S API belong to the default namespace. These keywords seem to me prime candidates for the kind of collisions that namespaces are meant to solve. It seems to me that whatever rationale one may have for qualifying a keyword such as queryInput or mobyData with the prefix moby applies with even greater force to a keywords such as String or text-plain. I realize that I'm a newcomer to BioMOBY, and don't know about earlier discussions about this subject. I am still figuring out my way around. When I kept coming across unqualified keywords such as String I was not sure whether the BioMoby standard really intended to make these keywords part of the default namespace, or whether the 'moby' prefix was being omitted to avoid clutter and coders were also omitting it because the software was tolerating this deviation from the standard. Gabriel From markw at illuminae.com Tue Apr 13 11:59:35 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 13 12:04:20 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> References: <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> Message-ID: <1081871975.2068.25.camel@localhost.localdomain> On Tue, 2004-04-13 at 08:48, Gabriel Berriz wrote: > was not sure whether the BioMoby standard really intended to make these > keywords part of the default namespace, or whether the 'moby' prefix was > being omitted to avoid clutter and coders were also omitting it because the > software was tolerating this deviation from the standard. I believe the latter is the case - what is happening is that I wrote the first example services, trying to keep them as "clean" as possible to help people follow what was going on - this included "munging" the XML as plaintext so that it was plainly visible by-eye in my scripts to help people visualize what the messages were. People then copy/pasted these examples into their own services, and VOILA! Again, I think that the tooling here is the key - we shouldn't be writing XML "my hand" in any case, and it would be fairly straightforward (though perhaps not as intuitive) to write thin wrappers around the standard XML libraries that built MOBY messages using an API rather than plaintext. Then we could enforce good message structure at the library level. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gordonp at cbr.nrc.ca Tue Apr 13 12:01:08 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue Apr 13 12:05:56 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> References: <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> Message-ID: <407C0EC4.70200@cbr.nrc.ca> There should probably be a caveat at the start of the MOBY-S API saying that the use/lack of prefixes in the examples is not canonical. To XML aware applications, whether you use a default prefix, moby:, or even xhtml: (if you're crazy), makes no difference at all, since the namespace should always resolve to http://www.biomoby.org/moby in the examples implicitly. Gabriel Berriz wrote: > I realize now that the subject line for my post was somewhat > misleading, because it suggested that I was bringing up the issue of > how strictly software should enforce standards (which is an important > one) > > In fact my main concern is that some very common keywords (such as > Object, String, Integer, Float, text-plain) in the MOBY-S API belong > to the default namespace. These keywords seem to me prime candidates > for the kind of collisions that namespaces are meant to solve. It > seems to me that whatever rationale one may have for qualifying a > keyword such as queryInput or mobyData with the prefix moby applies > with even greater force to a keywords such as String or text-plain. > > I realize that I'm a newcomer to BioMOBY, and don't know about earlier > discussions about this subject. I am still figuring out my way > around. When I kept coming across unqualified keywords such as String > I was not sure whether the BioMoby standard really intended to make > these keywords part of the default namespace, or whether the 'moby' > prefix was being omitted to avoid clutter and coders were also > omitting it because the software was tolerating this deviation from > the standard. > > Gabriel > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From gberriz at hms.harvard.edu Tue Apr 13 15:07:33 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue Apr 13 15:10:09 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407C0EC4.70200@cbr.nrc.ca> References: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> At 10:01 AM 4/13/2004 -0600, you wrote: >There should probably be a caveat at the start of the MOBY-S API saying >that the use/lack of prefixes in the examples is not canonical. To XML >aware applications, whether you use a default prefix, moby:, or even >xhtml: (if you're crazy), makes no difference at all, since the namespace >should always resolve to http://www.biomoby.org/moby in the examples >implicitly. Gordon, I don't understand what you mean. Please correct me if I'm wrong, but in ...an XML-aware application should resolve the namespace of Simple, Object, queryID, articleName, namespace (the attribute), and id to null, not to http://www.biomoby.org/moby. And as far as I can tell, this code would be not be valid XML: ...because the xhtml prefix (for articleName) is not defined (again, please correct me if I'm wrong). The quickest fix for the last case would be to: xmnls:xhtml="http://www.w3.org/1999/xhtml"> I agree that all those 'moby:' prefixes make the code hard to read. My guess is that the least cluttered version for the first example above would be xmlns:moby="http://www.biomoby.org/moby"> ...since there's no away around using a prefix if we want attribute names such as id to belong to the MOBY namespace. Incidentally, I've come across both http://www.biomoby.org/moby and http://www.biomoby.org/moby-s as the namespace for MOBY keywords. Which one is preferable? Gabriel From steube at sdsc.edu Tue Apr 13 15:27:32 2004 From: steube at sdsc.edu (Ken Steube) Date: Tue Apr 13 15:32:16 2004 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407BEB9A.3080200@cbr.nrc.ca> Message-ID: > names like "Integer" and "Object" seem like likely candidates for > namespace collisions. I'm not sure, but in the case of MOBY are these tags really are candidates for collisions? These blocks of XML like and come from the MOBY data ontology and so there is exactly one precise meaning for these tags. One reason for having a MOBY ontology is to give specific meanings to these tags and to give an exact specification on what the XML should look like. So I think there's no room for conflicts. If we later allow multiple data object ontologies then there may be a conflict. That's when we would start to need XML namespaces to distinguish between the alternate ontologies. So my understanding then is that an XML namespace in front of Integer would only serve to distinguish between alternate MOBY ontologies (and there's only one so far). Is that correct? Ken From markw at illuminae.com Tue Apr 13 15:41:09 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 13 15:46:15 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> References: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> Message-ID: <1081885269.2068.47.camel@localhost.localdomain> Hi Gabriel, > The quickest fix for the last case would be to: > > > xmlns="http://www.biomoby.org/moby" > xmnls:xhtml="http://www.w3.org/1999/xhtml"> Absolutely right... I thought I had made that change, actually, but I might have only fixed it in one place... I'll look again. > Incidentally, I've come across both http://www.biomoby.org/moby and > http://www.biomoby.org/moby-s as the namespace for MOBY keywords. Which > one is preferable? this is legacy cruft. In the beginning, there was only "moby", and then we split the project into two branches "moby-s" and "s-moby". It was impractical (impossible?) to update all the various pieces of documentation in all the various locations, so... they were generally left as-is, and the correct namespace-of-the-moment is whatever is coded in the libraries at any given time. This is subject to change... and in fact, will change again fairly soon since we are now describing everything in the moby-s ontologies project as RDF Resources, which have their own namespace URI's. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gordonp at cbr.nrc.ca Tue Apr 13 15:45:22 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue Apr 13 15:50:06 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> References: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> Message-ID: <407C4352.5020305@cbr.nrc.ca> >> There should probably be a caveat at the start of the MOBY-S API >> saying that the use/lack of prefixes in the examples is not >> canonical. To XML aware applications, whether you use a default >> prefix, moby:, or even xhtml: (if you're crazy), makes no difference >> at all, since the namespace should always resolve to >> http://www.biomoby.org/moby in the examples implicitly. > >> >> I agree that all those 'moby:' prefixes make the code hard to read. >> My guess is that the least cluttered version for the first example >> above would be >> >> >> >> xmlns:moby="http://www.biomoby.org/moby"> >> >> >> >> >> >> >> >> >> >> ...since there's no away around using a prefix if we want attribute >> names such as id to belong to the MOBY namespace. > Indeed, all of the statements you made are correct. My point with the xhtml prefix is that people who aren't familiar with namespaces might confuse the moby: prefix with the MOBY namespace, or not pick up that the unprefixed examples really should have a default namespace binding to MOBY, hence we should put a caveat in the API examples. The following document is equivalent to the one you list above. xmlns:xhtml="http://www.biomoby.org/moby"> The fact that the prefix used is not moby: doesn't make it any less valid as a MOBY document (though of course it does make it more confusing :-)). You make a good point with the attributes too. Currently, like the element names, I don't require the MOBY namespace the peer-to-peer implementation, but do exclude attributes explicitly declared in another namespace... It's either be strict and have half the services fail, or parse forgivingly and have all of them work. My users prefer the latter. :-) We definitely need a systematic feedback mechanism for the service providers... >> >> Incidentally, I've come across both http://www.biomoby.org/moby and >> http://www.biomoby.org/moby-s as the namespace for MOBY keywords. >> Which one is preferable? > All of the examples in the API state http://www.biomoby.org/moby, so we should probably stick with that. If we were really nice about it, we'd put a RDDL document at that URL... >> >> Gabriel >> >> _______________________________________________ >> moby-l mailing list >> moby-l@biomoby.org >> http://biomoby.org/mailman/listinfo/moby-l >> From markw at illuminae.com Tue Apr 13 16:04:47 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 13 16:09:36 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407C4352.5020305@cbr.nrc.ca> References: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> <407C4352.5020305@cbr.nrc.ca> Message-ID: <1081886687.2068.55.camel@localhost.localdomain> On Tue, 2004-04-13 at 12:45, Paul Gordon wrote: > We definitely need a systematic feedback mechanism for the service > providers... We discussed this at the last meeting - it is a very difficult problem! Services are transacted directly between a client and the service provider, so "moby" doesn't play a role in that process - we're merely the brokers. We could build-in some server-side filtering, but that is a given... nevertheless, unless the server is using our libraries, we can't enforce this. Other than having the client library spam the service provider every time they find a malformed message, the only other solution I can think of is to have knowledgable individuals keeping an eye on things, and publishing "best practices" on the mailing list. >All of the examples in the API state http://www.biomoby.org/moby, so we > should probably stick with that. If we were really nice about it, we'd > put a RDDL document at that URL... Yes - though the correct URL for things like Objects is now: http://biomoby.org/RESOURCES/MOBY-S/Objects and that resolves to RDF. I will probably add this as another namespace in the MOBY XML header - xmlns:mrdf="..." or something like that... M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gberriz at hms.harvard.edu Tue Apr 13 16:13:57 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue Apr 13 16:14:30 2004 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: References: <407BEB9A.3080200@cbr.nrc.ca> Message-ID: <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> At 12:27 PM 4/13/2004 -0700, Ken Steube wrote: > > names like "Integer" and "Object" seem like likely candidates for > > namespace collisions. > >I'm not sure, but in the case of MOBY are these tags really are candidates >for collisions? > >These blocks of XML like and come from the MOBY >data ontology and so there is exactly one precise meaning for these tags. >One reason for having a MOBY ontology is to give specific meanings to >these tags and to give an exact specification on what the XML should look >like. So I think there's no room for conflicts. Hi Ken, The problem I see is not with the choice of terms Object, Integer, etc. (I think they are perfectly fine), but rather with not specifying that these terms belong to the MOBY namespace (either via a prefix bound to it, or by setting the enclosing default namespace to it). One scenario that would introduce collisions (if Object, Integer, etc. were left out in the clear) would be a MOBY service that served chunks of XML from various sources (other than MOBY), or alternatively, an application that embedded MOBY-generated XML within other XML. Even in these cases, all would probably be OK if MOBY were the only source of XML that used unqualified keywords. In this case one could say that MOBY's namespace is effectively the "null" namespace. But I think that if all goes well, MOBY-generated XML will find itself rubbing shoulders with XML that uses unqualified keywords. :-) BTW, of the keywords I've seen, I think my top candidate for collisions is not Object or Integer but id. G. From gordonp at cbr.nrc.ca Tue Apr 13 16:29:43 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue Apr 13 16:34:29 2004 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> References: <407BEB9A.3080200@cbr.nrc.ca> <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> Message-ID: <407C4DB7.9000404@cbr.nrc.ca> Another candidate is Parameter (the wrapper for secondary input values to service calls). Both MAGE-ML and BSML have Parameter tags, and neither qualifies their elements by default. To make matters worse, many languages don't have a namespace floating around anywhere, so you have to make one up if you want to fix them. I'm trying to do this for our own parsing purposes, and would like to encourage others to use the same URIs. I've started this at http://www.bioxml.info, though it's rough right now. Other language submissions would be appreciated! > > BTW, of the keywords I've seen, I think my top candidate for > collisions is not Object or Integer but id. > > G. > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From gberriz at hms.harvard.edu Tue Apr 13 16:26:36 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue Apr 13 16:51:37 2004 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> References: <407BEB9A.3080200@cbr.nrc.ca> Message-ID: <5.2.1.1.2.20040413162249.024b6d68@email.med.harvard.edu> >Even in these cases, all would probably be OK if MOBY were the only source >of XML that used unqualified keywords. In this case one could say that >MOBY's namespace is effectively the "null" namespace. But I think that if >all goes well, MOBY-generated XML will find itself rubbing shoulders with >XML that uses unqualified keywords. :-) Sorry, in the above "unqualified keywords" should have been "keywords with no namespace". G. From markw at illuminae.com Tue Apr 13 16:47:51 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 13 16:52:40 2004 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407C4DB7.9000404@cbr.nrc.ca> References: <407BEB9A.3080200@cbr.nrc.ca> <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> <407C4DB7.9000404@cbr.nrc.ca> Message-ID: <1081889271.2068.58.camel@localhost.localdomain> On Tue, 2004-04-13 at 13:29, Paul Gordon wrote: > Another candidate is Parameter (the wrapper for secondary input values > to service calls). Both MAGE-ML and BSML have Parameter tags, and > neither qualifies their elements by default. >>sigh<< Oh what a tangled web we weave! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gberriz at hms.harvard.edu Wed Apr 14 14:21:11 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Wed Apr 14 14:54:20 2004 Subject: [MOBY-l] Registering new MOBY object Message-ID: <5.2.1.1.2.20040414135706.0238f1c0@email.med.harvard.edu> Hi, all. When registering a new MOBY object one is supposed to pass a Relationships parameter: Relationships => { relationshipType1 => [ [Object1, articleName], [Object2, articleName]], relationshipType2 => [ [Object1, articleName]]} What is the meaning of articleName? In the case when the relationship type is "hasa" I suppose that articleName is analogous to the name of a "field" for a class. In the cases when the relationship type is either "isa" or "has" it is not clear to me how to intepret this parameter. In any case, how is this "articleName" used subsequently? How are additional attributes (such as namespace and id) for these object elements specified? One last question: it is not clear to me what exactly the function of the SImple element is. As I understand it, Simple elements must contain exactly one MOBY object. Other than acting as a wrapper around this MOBY object, what purpose does the Simple element fulfill? Thanks! Gabriel From markw at illuminae.com Wed Apr 14 15:25:51 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Apr 14 15:30:40 2004 Subject: [MOBY] [MOBY-l] Registering new MOBY object In-Reply-To: <5.2.1.1.2.20040414135706.0238f1c0@email.med.harvard.edu> References: <5.2.1.1.2.20040414135706.0238f1c0@email.med.harvard.edu> Message-ID: <1081970751.1974.11.camel@localhost.localdomain> Hi Gabriel, I think you should perhaps look at a few examples of services, or walk through one of Ken's tutorials online (click on the "Tutorials and How To's" link on the moby homepage), to answer many of your questions all in one shot, since most of the answers you are looking for are explicit or implicit in these tutorials... > What is the meaning of articleName? In the case when the relationship type > is "hasa" I suppose that articleName is analogous to the name of a "field" > for a class. In the cases when the relationship type is either "isa" or > "has" it is not clear to me how to intepret this parameter. articleName is meaningless for ISA relationships - just leave it blank. > In any case, how is this "articleName" used subsequently? it is used to identify a subcomponent of a complex object. If you look at a few example objects in the API this will be clear. 10 > How are additional attributes (such as namespace and id) for these object > elements specified? again, please look at the examples, and see above. Everything is an object, and objects have namespace and id attributes. > Other than acting as a wrapper around this MOBY > object, what purpose does the Simple element fulfill? none. that is their only function. There may be a reason to add additional substructure in the future, but at the moment they are an empty wrapper around a single object, and help to ensure that Simple and Collection inputs have ~the same XML structures. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 15 14:30:33 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Apr 15 14:35:16 2004 Subject: [MOBY-l] MOBY Central down on Sunday for one hour Message-ID: <1082053832.3511.39.camel@localhost.localdomain> Hi all, MOBY Central's server room will be down for electrical upgrades from 1300 to 1400 EST on Sunday. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From fgibbons at hms.harvard.edu Fri Apr 16 09:57:07 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Fri Apr 16 09:58:23 2004 Subject: [MOBY-l] Version numbers? Message-ID: <5.2.1.1.2.20040416095218.019f5c60@email.med.harvard.edu> Hey listers, Gabriel Berriz and I are working on setting up and using each other's services. We've run into a little hitch, in that we appear to be using different versions of MOBY. However, we don't know for sure, because the only version information available in the MOBY package is in MOBY.pm, and that's "0.04". It would REALLY help if each version came out with a different version number. It doesn't have to mean anything, just be different. Maybe someone could change it daily or weekly? I don't know the best way to do this on something that's undergoing rapid change, maybe there's a better way to do it? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From fgibbons at hms.harvard.edu Mon Apr 19 10:11:48 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Mon Apr 19 10:12:43 2004 Subject: [MOBY] [MOBY-l] Version numbers? In-Reply-To: <1082128727.2587.8.camel@localhost.localdomain> References: <5.2.1.1.2.20040416095218.019f5c60@email.med.harvard.edu> <5.2.1.1.2.20040416095218.019f5c60@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040419094938.01a02a40@email.med.harvard.edu> At 11:18 AM 4/16/2004, you wrote: >I'm dubious that it is a difference in MOBY version that is causing the >problem, unless it has been a long long time since you upgraded your >libraries. Services have continued to be interoperable over the past >few months even over CVS updates on the client, server, and Central >side... > >What are the symptoms of the problem you are seeing? Mark, Well, one symptom was that the 'articleName', provided as the first element of the array ref used to construct XMLinputlist in the execute call, was being added to the tag, not to the tag where it's apparently supposed to be. Since Gabriel's service relied on pulling articleNames out of , to get query data, it thought there was never any data in my queries. We both have our own installations of MOBY, but I downloaded it a few weeks before the CSHL MOBY meeting, whereas he downloaded the week afterwards. We diffed our two installations, and there were significant differences, but no version numbers, so we couldn't really track things down. Once I started using his, the problem disappeared. Hence my conclusion that I was merely using an out-dated version of the library. I realise that you've been going to great pains to maintain interoperability, but perhaps this was a bug in an earlier version that got fixed. Clearly you don't keep compatibility with bugs, right? On a somewhat related note, what's the regression-testing situation in MOBY? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From steube at sdsc.edu Mon Apr 19 10:57:02 2004 From: steube at sdsc.edu (Ken Steube) Date: Mon Apr 19 11:01:35 2004 Subject: [MOBY-l] Regression testing In-Reply-To: <5.2.1.1.2.20040419094938.01a02a40@email.med.harvard.edu> Message-ID: On Mon, 19 Apr 2004, Frank Gibbons wrote: > On a somewhat related note, what's the regression-testing situation in > MOBY? -Frank I have a few regression tests for my services which I'll describe below. How should we make the regression tests available to everyone? Maybe the tWiki could be used for this...many people could contribute regression tests and put 'em up on the Wiki. My regression tests consist of a script that downloads a seq and verifies it is correct and says yes or no. Another is a web page with two forms from which I can execute some services: http://plantsp.sdsc.edu/plantsp/html/service_demo.html Try out this URL. It's ugly but it's a versatile test and you can edit the inputs before running it. Ken -- -- -- Ken Steube San Diego Supercomputer Center University of California, San Diego, MC 0505 9500 Gilman Drive San Diego, California, 92093-0505 USA FAX (858) 822-3610 From gberriz at hms.harvard.edu Tue Apr 20 13:36:04 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue Apr 20 13:36:55 2004 Subject: [MOBY-l] Object name conflicts Message-ID: <5.2.1.1.2.20040420132034.01dcc368@email.med.harvard.edu> Hi. I wanted to register an object named "Interaction", but I discovered that an object of this name has already been registered. Unfortunately, this Interaction object is not a suitable substitute for the object we had wanted to register under the same name, so we still would like to register our version of the "Interaction" object. In other words, a textbook example of a namespace collision. My temporary stop-gap solution was to register objects with names of the form "prefix:objectName", i.e. I resorted to a crude implementation of something like a namespace. What's the word on dealing with such name collisions in the BioMOBY Object Ontology? I think it would be nice to have namespace support for the names of objects in the Object Ontology. Thanks, Gabriel From markw at illuminae.com Tue Apr 20 15:27:16 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Apr 20 15:32:00 2004 Subject: [MOBY] [MOBY-l] Object name conflicts In-Reply-To: <5.2.1.1.2.20040420132034.01dcc368@email.med.harvard.edu> References: <5.2.1.1.2.20040420132034.01dcc368@email.med.harvard.edu> Message-ID: <1082489236.1656.62.camel@localhost.localdomain> On Tue, 2004-04-20 at 10:36, Gabriel Berriz wrote: > I wanted to register an object named "Interaction", but I discovered that > an object of this name has already been registered. Unfortunately, this > Interaction object is not a suitable substitute for the object we had > wanted to register under the same name, so we still would like to register > our version of the "Interaction" object. In other words, a textbook > example of a namespace collision. yup. Like the GO, I was hoping that names could be human-readable, and somewhat more specific than "Interaction", but that clearly does not work in a community-curated system :-P If you are desperate to namespace your object identifiers, then I suggest that you register your object "term" as a full-blown LSID, since that will be allowed by the registration system (though note that this is currently untested). Otherwise, to be safe, or if you prefer human-readability in your object names, pick a more specific name (ProteinProteinInteraction, or something like that) that wont collide with the existing name. Also, be careful about putting colons or other strange characters into your human-readable names, since the code might not be very forgiving of that... Nina begins work on Monday, and she will tighten up the codebase and clean up all of these kinds of things, but for now, be gentle! This is NOT professionally written code! M > My temporary stop-gap solution was to register objects with names of the > form "prefix:objectName", i.e. I resorted to a crude implementation of > something like a namespace. What's the word on dealing with such name > collisions in the BioMOBY Object Ontology? I think it would be nice to > have namespace support for the names of objects in the Object Ontology. > > Thanks, > > Gabriel > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Tue Apr 20 15:48:32 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Apr 20 15:53:17 2004 Subject: [MOBY-l] Welcome Nina! Message-ID: <1082490512.1656.77.camel@localhost.localdomain> Hi everyone, I wanted to send a quick note to introduce you to Nina - our newest MOBY developer. She will be acting as "my hands" for the foreseeable future cleaning/tightening the MOBY Central & Ontology Server core code and MOBY Cient/Server libraries, enhancing the functionality, bringing the entire MOBY-S API to fruition (finally!), and working with Martin and others to put together the Java libraries etc. She is hired as a 100% MOBY software developer, so this is great news for me/us! I'm pleased to have her working with me here at iCAPTURE! I apologize to you all for the lack of progress over the past couple of months, but having Nina around will get us back up to speed :-) Cheers all! Mark -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From bneron at pasteur.fr Tue Apr 27 03:57:11 2004 From: bneron at pasteur.fr (Bertrand Neron) Date: Tue Apr 27 04:10:40 2004 Subject: [MOBY-l] Paramter structure Message-ID: <20040427075711.GA15471@caroline.sis.pasteur.fr> I 'd like to build a service which take in input a Simple and several Secondaries. which structure should have the xml input ? On the page http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI, I found an example of xml where the Parameters have the following structure: 34 The complete example from http://www.biomoby.org/twiki/bin/view/Moby/MobySAPI: ... A message to a service that requires Secondary Articles is invoked as in the following example: 34 ... But on the page of the api of Moby.CommonSubs ( http://www.biomoby.org/moby-live/Perl/MOBY/CommonSubs.htm). I found an other example of xml input. Where the parameter have this structure dataType The complete example from complexServiceInputParser at http://www.biomoby.org/moby-live/Perl/MOBY/CommonSubs.htm : ... for example, the input message: Float 10 will become: (note that SIMPLE, COLLECTION, and SECONDARY are exported constants from this module) $inputs->{1} = [ [SIMPLE, $DOM_name1], [SECONDARY, $DOM_cutoff] ] ... Thanks, Bertrand -- Bertrand Neron Pasteur Institute Computing Center. From gordonp at cbr.nrc.ca Tue Apr 27 09:33:34 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue Apr 27 09:37:52 2004 Subject: [MOBY-l] Paramter structure In-Reply-To: <20040427075711.GA15471@caroline.sis.pasteur.fr> References: <20040427075711.GA15471@caroline.sis.pasteur.fr> Message-ID: <408E612E.60000@cbr.nrc.ca> Hi Bertrand, We are implementing the same thing, and I think the first form, with Parameter/value is the correct one since it is in the API, and because the second declaration is redundant or potentially in conflict with the datatype declared in the service registration. i.e. you could say it's a float, but the service asked for a string. Bertrand Neron wrote: >I 'd like to build a service which take in input a Simple and several >Secondaries. > >which structure should have the xml input ? > >On the page http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI, I found an >example of xml where the Parameters have the following structure: > > > 34 > > >The complete example from >http://www.biomoby.org/twiki/bin/view/Moby/MobySAPI: > >... >A message to a service that requires Secondary Articles is invoked as in the following example: > > > > > > > > > > > 34 > > > > > > >... > > >But on the page of the api of Moby.CommonSubs ( >http://www.biomoby.org/moby-live/Perl/MOBY/CommonSubs.htm). I found an >other example of xml input. Where the parameter have this structure > > > dataType > > > >The complete example from complexServiceInputParser at >http://www.biomoby.org/moby-live/Perl/MOBY/CommonSubs.htm : > >... > for example, the input message: > > > > > > > Float > 10 > > > > will become: > (note that SIMPLE, COLLECTION, and SECONDARY are exported constants from this module) > > $inputs->{1} = [ [SIMPLE, $DOM_name1], > [SECONDARY, $DOM_cutoff] > ] > >... > > >Thanks, > >Bertrand > >-- >Bertrand Neron >Pasteur Institute Computing Center. > >_______________________________________________ >moby-l mailing list >moby-l@biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > From mwilkinson at mrl.ubc.ca Thu Apr 29 14:25:58 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Apr 29 14:30:45 2004 Subject: [MOBY-l] Update from the last developers meeting: MOBY-S API changes Message-ID: <1083263157.1632.41.camel@myhost.mydomain> Hi all, I am finally getting around to writing the update from our last developers meeting, hosted by Lincoln at CSHL. Thanks Lincoln! Well, the whisky and ideas flowed like a river :-) and as a consequence there were some important decisions made affecting the MOBY-S API: (1) The process of registering and deregistering a service will now become more of a "pull", rather than a "push"; your server will now host a simple RDF document that describes your service such that MOBY Central can GET this document on a regular basis to decide if your service is still registered and/or modified. Thus we don't need any fancy security model for deregistration, since presumably only you have access to your own server. This is quite Google-like. (2) The messaging XML format has changed slightly: (a) the moby:Query and moby:Response tags have now been merged into a single tag moby:mobyContent (b) the moby:queryInput and moby:queryResponse tags have now been merged into a single tag moby:mobyData -- these two changes now make the input message structure ~identical to the output message structure, thus we truly can pipe messages from one service to the next without fiddling with them. Change #1 has not yet been implemented, and might take a while. I'll try to make some progress on it this weekend. The idea is that you will register your service using the existing registerService API call as usual, with the inclusion of one additional parameter representing the location where you will store your service description RDF documents for MOBY Central to GET. MOBY Central will parse your registerService call and return you a registration Object as usual, however the registration Object will contain an additional parameter, representing the RDF document that describes your service as per the parameters you sent it - i.e. MOBY Central will create the RDF for you. You place the RDF in the location that you indicated in the registerService call and MOBY will troll your server every ~week to see if it is still there, and update the registry if it has changed. Change #2 will be implemented in the Perl libraries (e.g. MOBY::Client::Central and MOBY::CommonSubs), and hopefully also in the Java libraries, thus people using the libraries to create/parse the messages should not notice the change... so if you are not using the libraries, you should be! :-) I'm trying to ensure that both message structures are understood by these libraries so that we continue to have backward compatibility at least for a while. I'm going to update the API documentation on the web ASAP. I'll put the photo's from the meeting up on the web as soon as they have been edited for content... ;-) ;-) Cheers all! Mark -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 29 18:39:56 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Apr 29 18:44:38 2004 Subject: [MOBY-l] CVS update required from all service providers Message-ID: <1083278395.1662.17.camel@myhost.mydomain> Hi everyone, All current service providers will need to cvs update their MOBY::CommonSubs module to bring everyone into sync with the message format changes. I just checked and all of my own services kicked back to life as soon as I updated, so as long as you are using the libraries a CVS update will fix everything and you wont have to change your services. ...I know... this was an ugly one... Sorry! :-( I hate changing the API, but we don't do this often, considering how young the project is! It's all for the best, though... or so they say ;-) Java people: If you do a simple substitution of Query -> mobyContent Response -> mobyContent queryInput -> mobyData queryResponse -> mobyData that is all that should be required to bring your code up to date with the API. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Thu Apr 1 10:18:29 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 1 Apr 2004 16:18:29 +0100 (BST) Subject: [MOBY-l] help needed for GetPubmed service In-Reply-To: Message-ID: [Sorry for sending this email here, I should send it directly to the service provider...] Still playing with some services, so far I have not succeeded with not a single one (my fault, of course). What is wrong, for example, with this input: sent to service GetPubmed, located at: http://prometheus.brc.mcw.edu/pubfetch-bin/PubFetchService.pl I am getting an error: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [stackTrace: null] Fault string: Failed to access class (MOBY::Central): Can't locate MOBY/Central.pm in @INC (@INC contains:) at (eval 140) line 3. Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client Fault actor: null When calling: http://prometheus.brc.mcw.edu/pubfetch-bin/PubFetchService.pl =========== Which frustrates me because I am *not* calling a moby central and still the error message tells me that somewhere someone cannot locate moby central. Thanks for any advise, actually, if someone can get me any simple XML object and tell me where to send it in order to get an answer and not an errror I will be happy... :-) 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 VNarayan at mail.brc.mcw.edu Thu Apr 1 10:48:03 2004 From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy) Date: Thu, 1 Apr 2004 09:48:03 -0600 Subject: [MOBY-l] help needed for GetPubmed service Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DF6F@baldar.brc.mcw.edu> Martin, The namespace of the input to the GetPubmed should be PMID (not Object). -Vijay Vijay Narayanasamy Project Programmer / Analyst Bioinformatics Program, Human and Molecular Genetics Center Medical College of Wisconsin 8701, W. Watertown Plank Road Milwaukee, WI 53226 414-456-8026 vnarayan at mcw.edu http://brc.mcw.edu/ -----Original Message----- From: Martin Senger [mailto:senger at ebi.ac.uk] Sent: Thursday, April 01, 2004 9:18 AM To: mobyl Cc: markw at illuminae.com Subject: [MOBY-l] help needed for GetPubmed service [Sorry for sending this email here, I should send it directly to the service provider...] Still playing with some services, so far I have not succeeded with not a single one (my fault, of course). What is wrong, for example, with this input: sent to service GetPubmed, located at: http://prometheus.brc.mcw.edu/pubfetch-bin/PubFetchService.pl I am getting an error: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [stackTrace: null] Fault string: Failed to access class (MOBY::Central): Can't locate MOBY/Central.pm in @INC (@INC contains:) at (eval 140) line 3. Fault code: {http://schemas.xmlsoap.org/soap/envelope/}Client Fault actor: null When calling: http://prometheus.brc.mcw.edu/pubfetch-bin/PubFetchService.pl =========== Which frustrates me because I am *not* calling a moby central and still the error message tells me that somewhere someone cannot locate moby central. Thanks for any advise, actually, if someone can get me any simple XML object and tell me where to send it in order to get an answer and not an errror I will be happy... :-) 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-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l From senger at ebi.ac.uk Thu Apr 1 10:56:04 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 1 Apr 2004 16:56:04 +0100 (BST) Subject: [MOBY-l] help needed for GetPubmed service In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DF6F@baldar.brc.mcw.edu> Message-ID: > The namespace of the input to the GetPubmed should be PMID (not Object). > Thanks, I have got this tip from more people now (but I forgot to forwarded here). But, unfortunately, it does not help... :-( I think perhaps we have again some problem with the URI and SOAPACtion... ? I do not know. 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 fgibbons at hms.harvard.edu Thu Apr 1 10:58:59 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 01 Apr 2004 10:58:59 -0500 Subject: [MOBY-l] help needed for GetPubmed service In-Reply-To: References: Message-ID: <5.2.1.1.2.20040401105334.01a6bf98@email.med.harvard.edu> Martin, Thanks for any advise, actually, if someone can get me any simple XML >object and tell me where to send it in order to get an answer and not an >errror I will be happy... :-) I'm attaching some Perl code (PMid.pl) that calls the GetPubmed service at prometheus. I wrote it last week, and just tried it right now, and it still works. I'm also appending the output from the service also (PM.txt). I hope this helps. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PM.txt Url: http://biomoby.org/pipermail/moby-l/attachments/20040401/984cdca9/PM.txt From markw at illuminae.com Thu Apr 1 11:39:47 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 01 Apr 2004 08:39:47 -0800 Subject: [MOBY] RE: [MOBY-l] help needed for GetPubmed service In-Reply-To: References: Message-ID: <1080837587.1658.20.camel@localhost.localdomain> Can you post the code that you are using, and a trace of the message that is going out over the wire? I know that service is running because the CGI client has no problem with it, so you are probably right that the SOAP message is somehow malformed... M On Thu, 2004-04-01 at 07:56, Martin Senger wrote: > > The namespace of the input to the GetPubmed should be PMID (not Object). > > > Thanks, I have got this tip from more people now (but I forgot to > forwarded here). > But, unfortunately, it does not help... :-( > I think perhaps we have again some problem with the URI and > SOAPACtion... ? I do not know. > > Martin -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From VNarayan at mail.brc.mcw.edu Thu Apr 1 12:15:34 2004 From: VNarayan at mail.brc.mcw.edu (Vijay Narayanasamy) Date: Thu, 1 Apr 2004 11:15:34 -0600 Subject: [MOBY-l] help needed for GetPubmed service Message-ID: <295CC5EB4257D411B34D00D0B7748F4432DF71@baldar.brc.mcw.edu> Frank, The attachment PMid.pl is missing. Vijay Vijay Narayanasamy Project Programmer / Analyst Bioinformatics Program, Human and Molecular Genetics Center Medical College of Wisconsin 8701, W. Watertown Plank Road Milwaukee, WI 53226 414-456-8026 vnarayan at mcw.edu http://brc.mcw.edu/ -----Original Message----- From: Frank Gibbons [mailto:fgibbons at hms.harvard.edu] Sent: Thursday, April 01, 2004 9:59 AM To: moby-l at biomoby.org Subject: Re: [MOBY-l] help needed for GetPubmed service Martin, Thanks for any advise, actually, if someone can get me any simple XML >object and tell me where to send it in order to get an answer and not an >errror I will be happy... :-) I'm attaching some Perl code (PMid.pl) that calls the GetPubmed service at prometheus. I wrote it last week, and just tried it right now, and it still works. I'm also appending the output from the service also (PM.txt). I hope this helps. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From fgibbons at hms.harvard.edu Thu Apr 1 12:38:12 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 01 Apr 2004 12:38:12 -0500 Subject: [MOBY-l] GetPubmed service: calling from Perl, sample response In-Reply-To: <295CC5EB4257D411B34D00D0B7748F4432DF71@baldar.brc.mcw.edu> Message-ID: <5.2.1.1.2.20040401123319.01a23ca0@email.med.harvard.edu> Oops - sorry about that, Vijay, I was sure I had attached it. The list server told me my message looked suspicious, and perhaps it stripped it. Whatever the reason, here it is appended, the output is attached, since it's rather long. -Frank At 12:15 PM 4/1/2004, Vijay Narayanasamy wrote: >Frank, > >The attachment PMid.pl is missing. > >Vijay > >Vijay Narayanasamy >Project Programmer / Analyst >Bioinformatics Program, Human and Molecular Genetics Center >Medical College of Wisconsin >8701, W. Watertown Plank Road >Milwaukee, WI 53226 >414-456-8026 >vnarayan at mcw.edu >http://brc.mcw.edu/ > >-----Original Message----- >From: Frank Gibbons [mailto:fgibbons at hms.harvard.edu] >Sent: Thursday, April 01, 2004 9:59 AM >To: moby-l at biomoby.org >Subject: Re: [MOBY-l] help needed for GetPubmed service > >Martin, > > Thanks for any advise, actually, if someone can get me any simple XML > >object and tell me where to send it in order to get an answer and not an > >errror I will be happy... :-) > > >I'm attaching some Perl code (PMid.pl) that calls the GetPubmed service at >prometheus. I wrote it last week, and just tried it right now, and it still >works. I'm also appending the output from the service also (PM.txt). > >I hope this helps. > >-Frank > > > >PhD, Computational Biologist, >Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. >Tel: 617-432-3555 Fax: >617-432-3557 http://llama.med.harvard.edu/~fgibbons ================= Perl code to look up PubMed IDs at GetPubmed service =============== #!/home/fgibbons/bin/perl use MOBY::Client::Central; use MOBY::Client::Service; my $Central = MOBY::Client::Central->new(); my ($Services, $REG) = $Central->findService( authURI => 'prometheus.brc.mcw.edu', serviceName => 'GetPubmed' ); unless ($Services) { print "Service discovery failed with the following errror: ", $REG->message; end } my @PMids = ("9788350", "14730315", "12368250"); printf("%-35s\t\t %s\n%s\n", "Service", "provided by", "="x80); foreach my $S ( @{$Services}) { printf("%-35s\t\t%s%s\n", $S->name, $S->authority, $S->description); my $WSDL = $Central->retrieveService($S); my $service = MOBY::Client::Service->new(service => $WSDL); foreach my $pmid (@PMids) { my $result = $service->execute( XMLinputlist => [ ['object0', ""], ] ) || 'None'; print "Result: ", $result, "\n"; } } PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PM.txt Url: http://biomoby.org/pipermail/moby-l/attachments/20040401/a70fbefa/PM.txt From markw at illuminae.com Thu Apr 1 13:07:01 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 01 Apr 2004 10:07:01 -0800 Subject: [MISC] Re: [MOBY-l] How to debug multi-parameter services In-Reply-To: <406C4B92.7020902@cnb.uam.es> References: <200403300801.i2U81FEU337439@electre.pasteur.fr> <406C4B92.7020902@cnb.uam.es> Message-ID: <1080842821.2348.22.camel@localhost.localdomain> Hi Both! Sorry for the delay in dealing with this issue - I'm still setting up my new lab, so I'm not getting a lot of coding done these days... I went into the (Perl) code just now and noticed a HUGE bug in the XML output for executing a service using the MOBY::Service->execute method (I am associating the articleName attribute with the queryInput element in the module, but it is supposed to be an attribute of the Simple or Collection element according to the API). This is an ugly mistake, since my server-side parsing libraries probably compensate for this error by looking for the articleName attribute in the wrong place as well! Anyway, this bug prevents me from writing a quick solution to your problem. I'll try to fix this over the next couple of days - it will get fixed at the CSHL MOBY meeting this weekend for sure, since we are highly unlikely to stay out late while we are there ;-) ;-) Anyway, I'm **really** sorry about that! I'll get it fixed as quickly as I can. Mark On Thu, 2004-04-01 at 09:04, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hello Catherine, > I'm sending a copy of this mail to Mark Wilkinson, so he can answer us. > My own answer is below. > > Catherine Letondal wrote: > > Jos?_Mar?a_Fern?ndez_Gonz?lez wrote: > > > >>Hi everybody, > >> I have developed a couple of services which take two arguments as > >>input, and now, how do I debug them? The 'debugYourService' script (very > >>useful) only works with single Simple input services. > >> > >> I have read the MOBY Client API (Service and ServiceInstance), and as I > >>have understood you can invoke a service with a Simple parameter, a > >>service with a Collection parameter but I'm unable to see the way to > >>invoke a service with two Simple parameters. > > > > > > Have you found out how to do this? We actually have the same question. > > Thanks in advance, > > > > > > -- > > Catherine Letondal -- Pasteur Institute Computing Center > > > > > > No, I haven't discovered an easy way to do that. Well, I was talking > about that with Mark a few weeks ago, and the problem is not inside the > protocol, but in the current design of the client libraries. MOBY people > is thinking on fixing the problem, but meanwhile we'd have to use some > tricks, and I don't like any of those I have thought. > > The first trick is to create a new object type which models the service > call parameters as declared HAS elements in the object definition. I > don't like it because the MOBY registry will grow with each new > multi-parameter service. > > The second one. I have dug in the perl libraries code, and I saw how the > MOBY message is built. You could create your own expanded version of > 'execute' method based on the one in MOBY::Client::Service. Then, you > should be able to test your service. But, the drawback is your service > could only be instantiated by your expanded 'execute', so it will not be > widely usable until the client API evolves. > > So, Mark, what do you think about the tricks? Or, do you better think > we should wait for the new client API? I have also seen there is no way > to send 'Secondary' parameters to a service, and they are very > interesting when you are implementing a computational service. > > Best regards, > Jos? Mar?a Fern?ndez -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Thu Apr 1 14:14:31 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 01 Apr 2004 11:14:31 -0800 Subject: [CBIN] [MOBY-l] GetPubmed service: calling from Perl, sample response In-Reply-To: <5.2.1.1.2.20040401123319.01a23ca0@email.med.harvard.edu> References: <5.2.1.1.2.20040401123319.01a23ca0@email.med.harvard.edu> Message-ID: <1080846870.3733.4.camel@localhost.localdomain> Yeah, the list server is stripping all attachments right now. I must have "hit a switch" that I didn't mean to when I was playing with the settings to cut down on the amount of spam we were getting... I'll try to see where I went wrong. In the meantime, inline is the best we can do. M On Thu, 2004-04-01 at 09:38, Frank Gibbons wrote: > Oops - sorry about that, Vijay, I was sure I had attached it. The list > server told me my message looked suspicious, and perhaps it stripped it. > Whatever the reason, here it is appended, the output is attached, since > it's rather long. > > -Frank > > At 12:15 PM 4/1/2004, Vijay Narayanasamy wrote: > >Frank, > > > >The attachment PMid.pl is missing. > > > >Vijay > > > >Vijay Narayanasamy > >Project Programmer / Analyst > >Bioinformatics Program, Human and Molecular Genetics Center > >Medical College of Wisconsin > >8701, W. Watertown Plank Road > >Milwaukee, WI 53226 > >414-456-8026 > >vnarayan at mcw.edu > >http://brc.mcw.edu/ > > > >-----Original Message----- > >From: Frank Gibbons [mailto:fgibbons at hms.harvard.edu] > >Sent: Thursday, April 01, 2004 9:59 AM > >To: moby-l at biomoby.org > >Subject: Re: [MOBY-l] help needed for GetPubmed service > > > >Martin, > > > > Thanks for any advise, actually, if someone can get me any simple XML > > >object and tell me where to send it in order to get an answer and not an > > >errror I will be happy... :-) > > > > > >I'm attaching some Perl code (PMid.pl) that calls the GetPubmed service at > >prometheus. I wrote it last week, and just tried it right now, and it still > >works. I'm also appending the output from the service also (PM.txt). > > > >I hope this helps. > > > >-Frank > > > > > > > >PhD, Computational Biologist, > >Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > >Tel: 617-432-3555 Fax: > >617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > ================= Perl code to look up PubMed IDs at GetPubmed service > =============== > #!/home/fgibbons/bin/perl > > use MOBY::Client::Central; > use MOBY::Client::Service; > > my $Central = MOBY::Client::Central->new(); > > my ($Services, $REG) = > $Central->findService( authURI => 'prometheus.brc.mcw.edu', > serviceName => 'GetPubmed' > ); > unless ($Services) { > print "Service discovery failed with the following errror: ", > $REG->message; > end > } > > my @PMids = ("9788350", "14730315", "12368250"); > printf("%-35s\t\t %s\n%s\n", "Service", "provided by", "="x80); > foreach my $S ( @{$Services}) { > printf("%-35s\t\t%s%s\n", $S->name, $S->authority, $S->description); > my $WSDL = $Central->retrieveService($S); > my $service = MOBY::Client::Service->new(service => $WSDL); > foreach my $pmid (@PMids) { > my $result = > $service->execute( XMLinputlist => [ > ['object0', > " namespace='PMID' id='" . $pmid > . "' articleName='" . > $pmid . "'/>"], > ] > ) || 'None'; > print "Result: ", $result, "\n"; > } > } > > > > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > ______________________________________________________________________ > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Thu Apr 1 16:29:38 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 01 Apr 2004 13:29:38 -0800 Subject: [MISC] Re: [MOBY-l] How to debug multi-parameter services In-Reply-To: <1080842821.2348.22.camel@localhost.localdomain> References: <200403300801.i2U81FEU337439@electre.pasteur.fr> <406C4B92.7020902@cnb.uam.es> <1080842821.2348.22.camel@localhost.localdomain> Message-ID: <1080854978.3734.43.camel@localhost.localdomain> Okay, it should be working properly now. The MOBY::Client::Service->execute method takes the following arguments: ->execute(XMLinputlist => \@invocations) where: @invocations = (\@inputs1, \@inputs2, \@inputs3) @inputs1 = ($name_a,$Object_a, $name_b,$Object-b,...) or @inputs1 = ($name_a,\@Collect_a, $name_b,\@Collect-b) @Collect_a = ($Object_a, $Object_b, $Object_c) So... The way to pass multiple Simple articles as arguments to a single invocation of a service (i.e. a service that takes more than one input per invocation) is to call the MOBY::Client::Service->execute method as follows: ->execute(XMLinputlist => [ [ 'thing1', '', 'thing2', '', 'thing3', '' ] ] I just tested that and it seems to work, however if anyone notices that there is still a bug please let me know ASAP! Sorry for being so slow... Mark -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Thu Apr 1 20:22:29 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 2 Apr 2004 02:22:29 +0100 (BST) Subject: [MOBY-l] GetPubmed service: calling from Perl, sample response In-Reply-To: <5.2.1.1.2.20040401123319.01a23ca0@email.med.harvard.edu> Message-ID: Thanks for sending me data and code. The differences (between your perl and my Java) are in SOAPAction header and in the coding. I am sending input as a string - you are sending it as CDATA block. The second difference should not matter. The SOAPAction is created from given URI. I was using 'http://mobycentral.cbr.nrc.ca/MOBY/Central' - which was wrong. When I changed it to yours: 'http://biomoby.org/' I got results correctly back. I GOT RESULTS CORRECTLY BACK. So, Mark, what did you mean (in doc) by "At this moment" when talking about this URI as mandatory one? Is this a pending issue or a solved one? I would still feel more comfortable if this datum become part of the service registration... Thanks for the help, 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 simont at mcw.edu Sun Apr 4 16:39:32 2004 From: simont at mcw.edu (Twigger, Simon) Date: Sun, 4 Apr 2004 15:39:32 -0500 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology Message-ID: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> Hi there, After some hacking around online whilst waiting in the scenic Concourse B at La Guardia airport, I found a DAML/Oil editor that I could get to work on my Mac and that accepted the MyGrid ontology files: I tried the Protege editor which looked really nice but I couldnt find a way to get DAML/Oil into the app from the flat file, the DAML/Oil plugin is out of date and doesnt work with the latest version of protege (http://protege.stanford.edu). It looks good and has an Owl plugin but I dont have Owl files to play with to test it out. OilEd : http://oiled.man.ac.uk/ (java app) The MyGrid ontology files can be found here: http://cvs.mygrid.org.uk/cgi-bin/viewcvs.cgi/mygrid/ontology-server/etc/onto logy/ I used the mygrid.daml file in OilEd and its working nicely. >From preliminary review, it looks like the branches of interest for the MOBY service ontology might be: top:domain_concept#1:process#1:generic_process#1 This has things like: aligning, calculating, filtering, grouping, parsing, retrieving, etc. and is along the same lines as we have right now in MOBY, there are 17 terms in this brank with only aligning having any children. I'll look more at this and go from there. Simon. From p.lord at russet.org.uk Mon Apr 5 06:59:02 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 05 Apr 2004 11:59:02 +0100 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> Message-ID: >>>>> "Simon" == Twigger, Simon writes: Simon> After some hacking around online whilst waiting in the scenic Simon> Concourse B at La Guardia airport, I found a DAML/Oil editor Simon> that I could get to work on my Mac and that accepted the Simon> MyGrid ontology files: Simon> I tried the Protege editor which looked really nice but I Simon> couldnt find a way to get DAML/Oil into the app from the flat Simon> file, the DAML/Oil plugin is out of date and doesnt work with Simon> the latest version of protege Simon> (http://protege.stanford.edu). It looks good and has an Owl Simon> plugin but I dont have Owl files to play with to test it out. OWL support for protege certainly exists. As well as the OWL plugin you might want to look at... http://www.co-ode.org/ which is starting to build some quite nifty support for OWL editing into protege. Simon> OilEd : http://oiled.man.ac.uk/ (java app) Simon> The MyGrid ontology files can be found here: Simon> http://cvs.mygrid.org.uk/cgi-bin/viewcvs.cgi/mygrid/ontology-server/etc/onto Simon> logy/ Simon> I used the mygrid.daml file in OilEd and its working nicely. It would be depressing if oiled could not load mygrid.daml. It was written with oiled, at least initially. And later it was generated with the oiled code base. One thing which is worth mentioning is that the file you are looking at has not been reasoned over. So many of the is-a links that you might expect to see are not there; they will magically appear if you use the reasoner. Sadly at the moment the reasoner will not run on a mac, although we have a new version that should do. >> From preliminary review, it looks like the branches of interest >> for the MOBY Simon> service ontology might be: Simon> top:domain_concept#1:process#1:generic_process#1 Simon> This has things like: aligning, calculating, filtering, Simon> grouping, parsing, retrieving, etc. and is along the same Simon> lines as we have right now in MOBY, there are 17 terms in Simon> this brank with only aligning having any children. I'll look Simon> more at this and go from there. I think that it would be nice if we can try and keep the meanings of the different properties in sync in so far as that is possible between the mygrid ontology and the moby one. Ontologies are, after all, only useful in so far as they are shared. Cheers Phil From p.lord at russet.org.uk Mon Apr 5 13:22:10 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 05 Apr 2004 18:22:10 +0100 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Many thanks for your comments, I was hoping someone from Simon> MyGrid would catch this. At the MOBY developers meeting this Simon> weekend we decided it was time to expand the MOBY service Simon> ontology and the existing MyGrid ontology seemed like a great Simon> place to start. I completely agree that we should endeavor to Simon> keep things in sync where ever possible. Something that I would be keen to do is to come up with an OBO style ontology from the original mygrid one. Mark and I have discussed this before, but we've never got around to it. Simon> I've been looking through the list of pubs from MyGrid and it Simon> looks like Chris Wroe's paper in Int. J. Cooperative Simon> Info. Systems. Vol. 12, No. 2 (2003) 197-224 on "DAML+OIL Simon> ontologies to describe bioinformatics web services and Simon> data"would be a good place for me to start reading about how Simon> this ontology came together. If there are other docs that you Simon> would recommend please let me know. Once I've got a better Simon> feel for things I'll probably pester you for more information Simon> if thats Ok. This paper is probably the best place to start. You might want to try this ontology.... http://www.cs.man.ac.uk/~phillord/download/scratch/mygrid-reasoned.daml which is the same ontology but fully reasoned over you. Simon> Thanks for the info on Protege at http://www.co-ode.org/, I Simon> found an OWL plugin already but the graph drawing plugin Simon> looks handy so I'll give that a go too. It's very cute I think. Cheers Phil From simont at mcw.edu Mon Apr 5 17:34:23 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon, 5 Apr 2004 16:34:23 -0500 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> Hi Phil, On Apr 5, 2004, at 12:22 PM, Phillip Lord wrote: > > > Something that I would be keen to do is to come up with an OBO style > ontology from the original mygrid one. Mark and I have discussed this > before, but we've never got around to it. By OBO style do you mean convert the existing DAML version into a format accepted by OBO, presumably OWL? The Reasoned version of the DAML makes a huge difference - thanks. Just to check my understanding of what's going on here - reasoning the ontology has pulled together all possible hierarchies that were defined in the model but previously 'hidden' in the unreasoned version by virtue of it being a non-redundant listing of terms? Hence the reasoned version now shows every allowable path to a class and so you get a better perspective of what lives where? Cheers, Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 From p.lord at russet.org.uk Tue Apr 6 06:18:06 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 06 Apr 2004 11:18:06 +0100 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Hi Phil, Simon> On Apr 5, 2004, at 12:22 PM, Phillip Lord wrote: >> >> >> Something that I would be keen to do is to come up with an OBO >> style ontology from the original mygrid one. Mark and I have >> discussed this before, but we've never got around to it. Simon> By OBO style do you mean convert the existing DAML version Simon> into a format accepted by OBO, presumably OWL? Yes and no. Translating to OWL by itself is (nearly) trivial and something that we can just do. The deeper issue is considering the semantics of OWL and the less defined semantics of OBO. We could just take the ontology as stands and turn it into a DAG. But if we just take the class hierarchy we will loose much of the information. Simon> The Reasoned version of the DAML makes a huge difference - Simon> thanks. Simon> Just to check my understanding of what's going on here - Simon> reasoning the ontology has pulled together all possible Simon> hierarchies that were defined in the model but previously Simon> 'hidden' in the unreasoned version by virtue of it being a Simon> non-redundant listing of terms? Hence the reasoned version Simon> now shows every allowable path to a class and so you get a Simon> better perspective of what lives where? Not really no. The hierarchy browser in Oiled shows the information that it has. That terms occur redundantly is just a way of displaying a multiple inheritance hierarchy. The reasoner does something more complex. In a description logic based ontology you tend to model the classes by describing their properties and then let the reasoner work out what subclass and super class relationships. Take the following example. This is using the (poorly named) OWL concrete abstract syntax. Class(SegregatingUnit complete restriction(involvedIn someValuesFrom (Segregation ))) segregating units are involved in segregation.... Class(Chromosome complete intersectionOf(SegregatingUnit restriction(hasPart someValuesFrom (Telomere )) restriction(hasPart someValuesFrom (Centromere )))) chromosomes are things which are segregating units, and have a part which is a telomere and a part which is a centromere. This is definitional. Class(CloningVector partial SegregatingUnit ) cloning vectors are segregating units also... Class(YAC partial CloningVector restriction(hasPart someValuesFrom (Telomere )) restriction(hasPart someValuesFrom (Centromere ))) A YAC (yeast artificial chromosome...all the rage when I still worked in the lab!) is a cloning vector with a telomere and centromere. >From which we can conclude that a YAC is a chromosome as it's a segregating unit with a telomere and a centromere. We can also conclude that... Class(AcentricChromosome partial Chromosome ) DisjointClasses(restriction(hasPart someValuesFrom (Centromere )) AcentricChromosome ) a chromosome with out a centromere is a contradiction in terms.... DisjointClasses(AcentricChromosome SegregatingUnit) as is a chromosome which is not a segregating unit. In the mygrid ontology a lot of the super class/sub class links are not stated explicitly but only generated by the reasoner. This style of modelling is sort of like Object orientation...but upside down. Properties define super classes, rather than sub classes inheriting properties. This is one of the big selling points of OWL (or at least OWL-DL). Its highly expressive but still computationally tractable. We can mathematically guarantee that any statement you can make in OWL-DL can be reasoner over. This is not true of OWL-Full or RDF; there are questions which can not be answered: that is are "undecidable". If this sounds counter intuitive then it can be considered as a variation on the theme of Turing's halting problem. There are somethings you just can't work out. Anyway from a practical point of view the reasoned ontology has all of the super/sub class relationships explicitly stated. It's the "compiled" form if you like. Cheers Phil From simont at mcw.edu Mon Apr 5 10:33:46 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon, 5 Apr 2004 09:33:46 -0500 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> Message-ID: <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> Hi Phil, Many thanks for your comments, I was hoping someone from MyGrid would catch this. At the MOBY developers meeting this weekend we decided it was time to expand the MOBY service ontology and the existing MyGrid ontology seemed like a great place to start. I completely agree that we should endeavor to keep things in sync where ever possible. I've been looking through the list of pubs from MyGrid and it looks like Chris Wroe's paper in Int. J. Cooperative Info. Systems. Vol. 12, No. 2 (2003) 197-224 on "DAML+OIL ontologies to describe bioinformatics web services and data"would be a good place for me to start reading about how this ontology came together. If there are other docs that you would recommend please let me know. Once I've got a better feel for things I'll probably pester you for more information if thats Ok. Thanks for the info on Protege at http://www.co-ode.org/, I found an OWL plugin already but the graph drawing plugin looks handy so I'll give that a go too. Cheers, Simon. On Apr 5, 2004, at 5:59 AM, Phillip Lord wrote: > >>>>>> "Simon" == Twigger, Simon writes: > > Simon> After some hacking around online whilst waiting in the scenic > Simon> Concourse B at La Guardia airport, I found a DAML/Oil editor > Simon> that I could get to work on my Mac and that accepted the > Simon> MyGrid ontology files: > > Simon> I tried the Protege editor which looked really nice but I > Simon> couldnt find a way to get DAML/Oil into the app from the flat > Simon> file, the DAML/Oil plugin is out of date and doesnt work with > Simon> the latest version of protege > Simon> (http://protege.stanford.edu). It looks good and has an Owl > Simon> plugin but I dont have Owl files to play with to test it out. > > OWL support for protege certainly exists. As well as the OWL plugin > you might want to look at... > > http://www.co-ode.org/ > > which is starting to build some quite nifty support for OWL editing > into protege. > > > Simon> OilEd : http://oiled.man.ac.uk/ (java app) > > Simon> The MyGrid ontology files can be found here: > > Simon> > http://cvs.mygrid.org.uk/cgi-bin/viewcvs.cgi/mygrid/ontology-server/ > etc/onto > Simon> logy/ > > Simon> I used the mygrid.daml file in OilEd and its working nicely. > > It would be depressing if oiled could not load mygrid.daml. It was > written with oiled, at least initially. And later it was generated > with the oiled code base. > > One thing which is worth mentioning is that the file you are looking > at has not been reasoned over. So many of the is-a links that you > might expect to see are not there; they will magically appear if you > use the reasoner. Sadly at the moment the reasoner will not run on a > mac, although we have a new version that should do. > > >>> From preliminary review, it looks like the branches of interest >>> for the MOBY > Simon> service ontology might be: > > Simon> top:domain_concept#1:process#1:generic_process#1 > > Simon> This has things like: aligning, calculating, filtering, > Simon> grouping, parsing, retrieving, etc. and is along the same > Simon> lines as we have right now in MOBY, there are 17 terms in > Simon> this brank with only aligning having any children. I'll look > Simon> more at this and go from there. > > I think that it would be nice if we can try and keep the meanings of > the different properties in sync in so far as that is possible between > the mygrid ontology and the moby one. Ontologies are, after all, only > useful in so far as they are shared. > > Cheers > > Phil > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > > -- 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 From markw at illuminae.com Tue Apr 6 10:30:57 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 06 Apr 2004 07:30:57 -0700 Subject: [MOBY] Re: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> Message-ID: <1081261856.1983.43.camel@localhost.localdomain> > Simon> This has things like: aligning, calculating, filtering, > Simon> grouping, parsing, retrieving, etc. and is along the same > Simon> lines as we have right now in MOBY, there are 17 terms in > Simon> this brank with only aligning having any children. I'll look > Simon> more at this and go from there. > > I think that it would be nice if we can try and keep the meanings of > the different properties in sync in so far as that is possible between > the mygrid ontology and the moby one. I think we can all agree on that :-) Phil, do you guys have canonical LSID representations for your service ontology terms? Also, I notice that URI's like: http://www.mygrid.org.uk/ontology#bioinformatics_service don't actually resolve. Is there a plan to do this such that in MOBY we can "point to" a node on your ontology and have a client program be able to find it? Cheers! M > Ontologies are, after all, only > useful in so far as they are shared. > > Cheers > > Phil > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From simont at mcw.edu Tue Apr 6 11:53:57 2004 From: simont at mcw.edu (Simon Twigger) Date: Tue, 6 Apr 2004 10:53:57 -0500 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: <9D325ECA-87E2-11D8-B4C2-000A959D1D82@mcw.edu> On Apr 6, 2004, at 5:18 AM, Phillip Lord wrote: > Simon> By OBO style do you mean convert the existing DAML version > Simon> into a format accepted by OBO, presumably OWL? > > Yes and no. Translating to OWL by itself is (nearly) trivial and > something that we can just do. > I found a convertor script from DAML+OIL to OWL so i did wonder if I was missing something here. > The deeper issue is considering the semantics of OWL and the less > defined semantics of OBO. We could just take the ontology as stands > and turn it into a DAG. But if we just take the class hierarchy we > will loose much of the information. By OBO-style I take it that you are referring to the DAG structure of something like GO. What would be goal be of converting to this style - a more 'friendly' format for existing users to work from, rather than asking them to step up to OWL and the extra complexity & functionality? > > The reasoner does something more complex. In a description logic based > ontology you tend to model the classes by describing their > properties and then let the reasoner work out what subclass and super > class relationships. Thanks for the explanation of the reasoner, it makes much more sense now. Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 From p.lord at russet.org.uk Tue Apr 6 12:19:36 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 06 Apr 2004 17:19:36 +0100 Subject: [MOBY] Re: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <1081261856.1983.43.camel@localhost.localdomain> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <1081261856.1983.43.camel@localhost.localdomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Simon> This has things like: aligning, calculating, filtering, Simon> grouping, parsing, retrieving, etc. and is along the same Simon> lines as we have right now in MOBY, there are 17 terms in Simon> this brank with only aligning having any children. I'll look Simon> more at this and go from there. >> >> I think that it would be nice if we can try and keep the meanings >> of the different properties in sync in so far as that is possible >> between the mygrid ontology and the moby one. Mark> I think we can all agree on that :-) Phil, do you guys have Mark> canonical LSID representations for your service ontology Mark> terms? Mark> Also, I notice that URI's like: Mark> http://www.mygrid.org.uk/ontology#bioinformatics_service don't Mark> actually resolve. Is there a plan to do this such that in Mark> MOBY we can "point to" a node on your ontology and have a Mark> client program be able to find it? Well they aren't supposed to resolve. The URI's in OWL and RDF are supposed to be semantic free. I agree that there is nothing to stop us adding additional semantics to the URI. When you say "have a client program find it", what are you expecting to find? Phil From p.lord at russet.org.uk Tue Apr 6 12:22:58 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 06 Apr 2004 17:22:58 +0100 Subject: [MOBY-l] DAML/OIl editor for viewing MyGrid ontology In-Reply-To: <9D325ECA-87E2-11D8-B4C2-000A959D1D82@mcw.edu> References: <295CC5EB4257D411B34D00D0B7748F44583519@baldar.brc.mcw.edu> <3EF37D0A-870E-11D8-B4C2-000A959D1D82@mcw.edu> <017706DE-8749-11D8-B4C2-000A959D1D82@mcw.edu> <9D325ECA-87E2-11D8-B4C2-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: >> Yes and no. Translating to OWL by itself is (nearly) trivial and >> something that we can just do. >> Simon> I found a convertor script from DAML+OIL to OWL so i did Simon> wonder if I was missing something here. There are some things that DAML+OIL can do which OWL cannot (and vice versa). And the mygrid ontology does use them at points. It adds to the complexity. >> The deeper issue is considering the semantics of OWL and the less >> defined semantics of OBO. We could just take the ontology as >> stands and turn it into a DAG. But if we just take the class >> hierarchy we will loose much of the information. Simon> By OBO-style I take it that you are referring to the DAG Simon> structure of something like GO. What would be goal be of Simon> converting to this style - a more 'friendly' format for Simon> existing users to work from, rather than asking them to step Simon> up to OWL and the extra complexity & functionality? Mostly the later. One obvious way to manage the complexity is to keep the source ontology as the OWL version that mygrid has using reasoning the like. The OBO style ontology would then be an alternate simplified view. Clearly its easier to generate out a simpler representation from a richer one than the other way around. >> >> The reasoner does something more complex. In a description logic >> based ontology you tend to model the classes by describing their >> properties and then let the reasoner work out what subclass and >> super class relationships. Simon> Thanks for the explanation of the reasoner, it makes much Simon> more sense now. I wish I could say that same. I've been using it for several years and I still don't quite understand what the reasoner does! Cheers Phil From markw at illuminae.com Tue Apr 6 14:47:10 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 06 Apr 2004 11:47:10 -0700 Subject: [MOBY-l] [Fwd: [Hackathon] OBO and OWL formats (fwd)] Message-ID: <1081277230.1983.131.camel@localhost.localdomain> -----Forwarded Message----- > From: Chris Mungall > To: Mark Wilkinson > Subject: OBO and OWL formats > As one of people responsible for the OBO format I just wanted to let you > know that this format was designed to be both a lightweight format for > simple DAG-style ontologies (which presently covers all the ontologies > within OBO) as well as an extensible format capable of handling the full > semantics of OWL. > > Although we haven't fully tried yet, it should be possible to represent > any OWL construct in OBO (we just haven't fully documented how to do this > yet). We care specifically about intersectionOf (for making complete vs > partial definitions) - there should be support for this in DAG Edit soon. > > The go-perl library from www.godatabase.org/dev has a converter for going > GO/OBO format to OWL and a (currently very lossy) converter for the > reverse. This should also be built into DAG Edit sometime soon. > > With regards to reasoners, I've found the combination of protege plus OWL > plug in plus racer to also work well. > > It seems that OBO format would be a good choice for MOBY since it is > always possible to treat OBO format as just a simple DAG ontology (just > ignore the pesky stuff in the {}s) yet at the same time you can have > complex enough definitions to warrant reasoning over. > > Cheers > Chris From gberriz at hms.harvard.edu Thu Apr 8 13:41:42 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Thu, 08 Apr 2004 13:41:42 -0400 Subject: [MOBY-l] Message syntax Message-ID: <5.2.1.1.2.20040408133737.0730ee00@email.med.harvard.edu> Hi. I'm relatively new to MOBY; still finding my way around. Where can I find a description of the syntax for MOBY requests and responses? My immediate interest is learning about the correct syntax for elements with tags "queryInput", "Simple", and "Collection"? Thanks, G. From fgibbons at hms.harvard.edu Thu Apr 8 17:03:08 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 08 Apr 2004 17:03:08 -0400 Subject: [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example Message-ID: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> Mark, One topic which I'm having great difficulty with, and for which I can find no obvious examples, is how to parse the response from a service. As was discussed at the MOBY meeting in CSHL, there's a somewhat different syntax for queries and responses. The examples I have found describe how to provide a service (how to handle incoming requests). None talks about how to parse incoming responses. Now perhaps I'm just being really dense here: the difference really couldn't be that big. I've tried running your MOBYSHoundGetGetBankff with NCBI_gi:431260 as the query, I get back a nice fat response. But I'm really having difficulty extracting the information. Do you (or anyone else on the list) have an example you could post, showing how to deal with the response from a query? Maybe there are examples out there already - if so, I'd really appreciate someone pointing them out to me. Thanks for that, and thanks to yourself and the other CSHL::MOBYers for a great introduction to things MOBY. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From fgibbons at hms.harvard.edu Thu Apr 8 17:21:56 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 08 Apr 2004 17:21:56 -0400 Subject: [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example In-Reply-To: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040408171437.01aa7518@email.med.harvard.edu> Hi, Let me add to my previous comment, to make it more specific: If I'm trying to process a request, the first thing I do is call "getInputs( )". What is the analogue of that for handling the service's response to a request? I'm just looking for the sequence of function calls, and the names of the API functions that I should be using. Thanks, -Frank At 05:03 PM 4/8/2004, you wrote: >One topic which I'm having great difficulty with, and for which I can find >no obvious examples, is how to parse the response from a service. As was >discussed at the MOBY meeting in CSHL, there's a somewhat different >syntax for queries and responses. The examples I have found describe how >to provide a service (how to handle incoming requests). None talks about >how to parse incoming responses. > >Now perhaps I'm just being really dense here: the difference really >couldn't be that big. I've tried running your MOBYSHoundGetGetBankff with >NCBI_gi:431260 as the query, I get back a nice fat response. But I'm >really having difficulty extracting the information. Do you (or anyone >else on the list) have an example you could post, showing how to deal with >the response from a query? Maybe there are examples out there already - if >so, I'd really appreciate someone pointing them out to me. > >Thanks for that, and thanks to yourself and the other CSHL::MOBYers for a >great introduction to things MOBY. PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Apr 8 18:41:20 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 08 Apr 2004 15:41:20 -0700 Subject: [MISC] [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example In-Reply-To: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> References: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> Message-ID: <1081464080.3075.76.camel@localhost.localdomain> Hi Frank, It is best to use the provided libraries (or add to them) to do the parsing, since that allows us to change the "guts" of the messaging structure without it affecting you on either the service or client side. There is only one ~useful client-side method call "extract response articles", that is available in the MOBY::CommonSubs module. my $result = $SERVICE->execute(XMLinputlist => [['',$OBJECT]]); # execute the service unless ($result){ print h3("Service returned no response"); exit 0; } my ($collections, $simples) =extractResponseArticles($result); This (unfortunately) returns the individual responses as XML::DOM objects, rather than having a MOBY-specific API to access the information in these objects. Ken has some code that does a much nicer job of creating Perl objects from MOBY Object XML, but at the moment it isn't 100% API compliant. I'm hoping this will one day this will migrate into this CommonSubs routine so that all of the libraries are in one place... A complete example of a client-side parsing is available in the gbrowse_moby 'execute' subroutine. I attach the code here (it will get to you, but it will probably get stripped off of the copy that goes to the mailing list). It will show you how the existing CGI client (the one you see when you browse MOBY from the website) parses the response message into its component parts using calls to the XML::DOM library. Let me know if I can help some more - the need for tooling is becoming quite urgent, I know! Just a couple more grants to write and then I will have a ~month clear to attack the code again :-) M On Thu, 2004-04-08 at 14:03, Frank Gibbons wrote: > Mark, > > One topic which I'm having great difficulty with, and for which I can find > no obvious examples, is how to parse the response from a service. As was > discussed at the MOBY meeting in CSHL, there's a somewhat different syntax > for queries and responses. The examples I have found describe how to > provide a service (how to handle incoming requests). None talks about how > to parse incoming responses. > > Now perhaps I'm just being really dense here: the difference really > couldn't be that big. I've tried running your MOBYSHoundGetGetBankff with > NCBI_gi:431260 as the query, I get back a nice fat response. But I'm really > having difficulty extracting the information. Do you (or anyone else on the > list) have an example you could post, showing how to deal with the response > from a query? Maybe there are examples out there already - if so, I'd > really appreciate someone pointing them out to me. > > Thanks for that, and thanks to yourself and the other CSHL::MOBYers for a > great introduction to things MOBY. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gberriz at hms.harvard.edu Fri Apr 9 09:30:01 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Fri, 09 Apr 2004 09:30:01 -0400 Subject: [MISC] [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example In-Reply-To: <1081464080.3075.76.camel@localhost.localdomain> References: <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> <5.2.1.1.2.20040408165030.01af3740@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040409092440.0264ea78@email.med.harvard.edu> At 03:41 PM 4/8/2004 -0700, Mark Wilkinson wrote: >There is only one ~useful client-side method call "extract response >articles", that is available in the MOBY::CommonSubs module. > >This (unfortunately) returns the individual responses as XML::DOM >objects, rather than having a MOBY-specific API to access the >information in these objects. Ken has some code that does a much nicer >job of creating Perl objects from MOBY Object XML, but at the moment it >isn't 100% API compliant. I'm hoping this will one day this will migrate >into this CommonSubs routine so that all of the libraries are in one >place... Mark, I'd be happy to take a crack at it. Where can I find this code by Ken? What's the name of the sub, and what exactly is not API-compliant about it? (I assume that the API you are referring to is the one at http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI ; please correct me if I'm wrong.) Regards, Gabriel From gberriz at hms.harvard.edu Fri Apr 9 09:46:38 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Fri, 09 Apr 2004 09:46:38 -0400 Subject: [MISC] [MOBY-l] Processing MOBY responses:MOBYSHoundGetGenBankff as an example In-Reply-To: Message-ID: <5.2.1.1.2.20040409094111.0731d5d8@email.med.harvard.edu> In that case, I'd be happy to try coding it from scratch. I would need to know the specific API/input-output signature for this sub. Do you (or anyone else reading this) have it? Regards, G. At 08:29 AM 4/9/2004 -0500, mwilkinson wrote: >Hi Gabriel > >I decided to take advantage of the easter weekend to upgrade my Linux >kernel... It didn't go as well as I had hoped! I don't have a network at >the moment so I can't point you to Ken's library (I'm responding from my >blackberry) > >If you don't get a response from someone else first, I'll reply as soon as >I get my net back up. > >Thanks for the offer! > >M > >-----Original Message----- >From: Gabriel Berriz >Date: Fri, 09 Apr 2004 09:30:01 >To:markw at illuminae.com >Cc:mobyl >Subject: Re: [MISC] [MOBY-l] Processing MOBY responses: > MOBYSHoundGetGenBankff as an example > >At 03:41 PM 4/8/2004 -0700, Mark Wilkinson wrote: > >There is only one ~useful client-side method call "extract response > >articles", that is available in the MOBY::CommonSubs module. > > > >This (unfortunately) returns the individual responses as XML::DOM > >objects, rather than having a MOBY-specific API to access the > >information in these objects. Ken has some code that does a much nicer > >job of creating Perl objects from MOBY Object XML, but at the moment it > >isn't 100% API compliant. I'm hoping this will one day this will migrate > >into this CommonSubs routine so that all of the libraries are in one > >place... > >Mark, > >I'd be happy to take a crack at it. Where can I find this code by >Ken? What's the name of the sub, and what exactly is not API-compliant >about it? (I assume that the API you are referring to is the one at >http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI ; please correct me if >I'm wrong.) > >Regards, > >Gabriel > > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > >!!!!!!!!!!!!!!!! >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 gberriz at hms.harvard.edu Fri Apr 9 12:53:06 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Fri, 09 Apr 2004 12:53:06 -0400 Subject: [MOBY] Re: [MISC] [MOBY-l] Processing MOBY responses:MOBYSHoundGetGenBankff as an example In-Reply-To: <1081528661.1051.13.camel@localhost.localdomain> References: <5.2.1.1.2.20040409094111.0731d5d8@email.med.harvard.edu> <5.2.1.1.2.20040409094111.0731d5d8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040409125153.073d3488@email.med.harvard.edu> OK, I'll look over the code and get to it. Thanks. G. At 09:37 AM 4/9/2004 -0700, Mark Wilkinson wrote: >Ha! Network is back up :-) > >So, the module is described on the following page: > >http://plantgenome.sdsc.edu/mobyed2/learn.html > >It is called "MobyXmlObject.pm" > >The portions that are not fully API compliant (AFAIK) are: > >1) It does not record the queryID when parsing MOBY messages. This >will be critical for both client and service-side message parsing. > >2) The latest API change (not yet implemented, since we only decided it >last weekend) is that the message structure for both request and >response will be identical. Thus the moby:Query moby:queryInput, >moby:Response and moby:queryResponse have been replaced by the two tags >moby:mobyContent (outer tag) and moby:mobyData (inner tag). I don't >know if Ken's parser is parsing messages based on these tags, but it if >is, it will need to be tweaked to accept both the old and the new for at >least the transition period. > > >If you are planning to migrate this into the CommonSubs routine (sub >genericServiceInputParser and sub extractResponseArticles) that would be >wonderful! > >That code (CommonSubs.pm) is quite hairy, though, since it is really >just in the prototype stages... I hope it is readable! > >M > > > > >On Fri, 2004-04-09 at 06:46, Gabriel Berriz wrote: > > In that case, I'd be happy to try coding it from scratch. I would need to > > know the specific API/input-output signature for this sub. Do you (or > > anyone else reading this) have it? > > > > Regards, > > > > G. > > > > At 08:29 AM 4/9/2004 -0500, mwilkinson wrote: > > > > >Hi Gabriel > > > > > >I decided to take advantage of the easter weekend to upgrade my Linux > > >kernel... It didn't go as well as I had hoped! I don't have a network at > > >the moment so I can't point you to Ken's library (I'm responding from my > > >blackberry) > > > > > >If you don't get a response from someone else first, I'll reply as > soon as > > >I get my net back up. > > > > > >Thanks for the offer! > > > > > >M > > > > > >-----Original Message----- > > >From: Gabriel Berriz > > >Date: Fri, 09 Apr 2004 09:30:01 > > >To:markw at illuminae.com > > >Cc:mobyl > > >Subject: Re: [MISC] [MOBY-l] Processing MOBY responses: > > > MOBYSHoundGetGenBankff as an example > > > > > >At 03:41 PM 4/8/2004 -0700, Mark Wilkinson wrote: > > > >There is only one ~useful client-side method call "extract response > > > >articles", that is available in the MOBY::CommonSubs module. > > > > > > > >This (unfortunately) returns the individual responses as XML::DOM > > > >objects, rather than having a MOBY-specific API to access the > > > >information in these objects. Ken has some code that does a much nicer > > > >job of creating Perl objects from MOBY Object XML, but at the moment it > > > >isn't 100% API compliant. I'm hoping this will one day this will migrate > > > >into this CommonSubs routine so that all of the libraries are in one > > > >place... > > > > > >Mark, > > > > > >I'd be happy to take a crack at it. Where can I find this code by > > >Ken? What's the name of the sub, and what exactly is not API-compliant > > >about it? (I assume that the API you are referring to is the one at > > >http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI ; please correct > me if > > >I'm wrong.) > > > > > >Regards, > > > > > >Gabriel > > > > > > > > >_______________________________________________ > > >moby-l mailing list > > >moby-l at biomoby.org > > >http://biomoby.org/mailman/listinfo/moby-l > > > > > >!!!!!!!!!!!!!!!! > > >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! > > >!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > _______________________________________________ > > moby-l mailing list > > moby-l at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l >-- >Mark Wilkinson (mwilkinson at mrl.ubc.ca) >University of British Columbia iCAPTURE Centre From mwilkinson at mobile.rogers.com Fri Apr 9 09:29:13 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 9 Apr 2004 08:29:13 -0500 Subject: [MISC] [MOBY-l] Processing MOBY responses:MOBYSHoundGetGenBankff as an example Message-ID: <200404091338.i39DcSg2028395@portal.open-bio.org> Hi Gabriel I decided to take advantage of the easter weekend to upgrade my Linux kernel... It didn't go as well as I had hoped! I don't have a network at the moment so I can't point you to Ken's library (I'm responding from my blackberry) If you don't get a response from someone else first, I'll reply as soon as I get my net back up. Thanks for the offer! M -----Original Message----- From: Gabriel Berriz Date: Fri, 09 Apr 2004 09:30:01 To:markw at illuminae.com Cc:mobyl Subject: Re: [MISC] [MOBY-l] Processing MOBY responses: MOBYSHoundGetGenBankff as an example At 03:41 PM 4/8/2004 -0700, Mark Wilkinson wrote: >There is only one ~useful client-side method call "extract response >articles", that is available in the MOBY::CommonSubs module. > >This (unfortunately) returns the individual responses as XML::DOM >objects, rather than having a MOBY-specific API to access the >information in these objects. Ken has some code that does a much nicer >job of creating Perl objects from MOBY Object XML, but at the moment it >isn't 100% API compliant. I'm hoping this will one day this will migrate >into this CommonSubs routine so that all of the libraries are in one >place... Mark, I'd be happy to take a crack at it. Where can I find this code by Ken? What's the name of the sub, and what exactly is not API-compliant about it? (I assume that the API you are referring to is the one at http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI ; please correct me if I'm wrong.) Regards, Gabriel _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l !!!!!!!!!!!!!!!! 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 gabriel_berriz at hms.harvard.edu Mon Apr 12 07:00:20 2004 From: gabriel_berriz at hms.harvard.edu (Berriz, Gabriel F.) Date: Mon, 12 Apr 2004 07:00:20 -0400 Subject: [MOBY-l] SGD IDs Message-ID: <16C1B7E52D13C54D9297F8102407AC800651C2@MAILSERVER02.MED.HARVARD.EDU> I'm trying to prototype a service that takes a single gene ID as input. For starters I want to limit myself to yeast genes IDs, and more specifically to SGD IDs, which match the Perl pattern /^[SL]\d{7}$/. I'm trying to determine the right syntax for the service's input object. My *guess* is that it will be something like: but I have not been able to confirm this guess. The list returned by retrieveNamespaces includes at least three plausible candidates: SGD, SGD_LOCUS, and SGD_ORF. The description that comes along with these entries is not enough to disambiguate this choice. I am also confused by the fact that the namespace "Genbank/gi", which is used in several examples in MOBY-S's documentation, does not appear in the list returned by retrieveNamespaces. (It is possible that answers to some or all of the questions above are in some part of the documentation that I have missed; if so, please let me know.) Thanks, and regards, Gabriel From gberriz at hms.harvard.edu Mon Apr 12 12:10:12 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Mon, 12 Apr 2004 12:10:12 -0400 Subject: [MOBY-l] String & text-plain Message-ID: <5.2.1.1.2.20040412114659.01db2610@email.med.harvard.edu> Hi all. I'm trying to code a toy service that all it does is to echo back *verbatim* (through a text-plain object) the raw XML that it received as input. One thing I have not been able to figure out is the correspondence between an object's definition (as given in registerObject) and the raw XML string corresponding to this object. My immediate questions are 1. What exactly is the difference between String and text-plain? 2. It is my understanding that the raw XML representation for the String object corresponding to "my favorite string" is something like: What is the raw XML representation for the text-plain object corresponding to "my favorite string"? The larger question is that from the point of view of someone coding a service, how do I know the structure of the XML that my script will receive as input? An even larger concern is that I'm surprised by the amount of XML munging that I see in sample BioMOBY code. I thought the whole point of using SOAP modules was to insulate oneself from having to do much (or any) parsing and munging of XML. Gabriel A far more important question has to do with a client's ability to handle a given output from a service. This output presumably comes back as XML. How does the client figure out how to parse this output to get the desired information? I thought the whole idea was that this should be transparent to the client, but From steube at sdsc.edu Mon Apr 12 14:35:30 2004 From: steube at sdsc.edu (Ken Steube) Date: Mon, 12 Apr 2004 11:35:30 -0700 (PDT) Subject: [MOBY-l] SGD IDs In-Reply-To: <16C1B7E52D13C54D9297F8102407AC800651C2@MAILSERVER02.MED.HARVARD.EDU> Message-ID: I believe that Genbank/gi is NCBI_gi. Many of our namespaces come from the Gene Ontology Cross-reference Abbreviations List. I don't personally know which of the three for SGD you should use, but looking that list might help. Ken On Mon, 12 Apr 2004, Berriz, Gabriel F. wrote: > I'm trying to prototype a service that takes a single gene ID as > input. For starters I want to limit myself to yeast genes IDs, and > more specifically to SGD IDs, which match the Perl pattern > /^[SL]\d{7}$/. I'm trying to determine the right syntax for the > service's input object. My *guess* is that it will be something like: > > > > but I have not been able to confirm this guess. The list returned by > retrieveNamespaces includes at least three plausible candidates: SGD, > SGD_LOCUS, and SGD_ORF. The description that comes along with these > entries is not enough to disambiguate this choice. > > I am also confused by the fact that the namespace "Genbank/gi", which > is used in several examples in MOBY-S's documentation, does not appear > in the list returned by retrieveNamespaces. > > (It is possible that answers to some or all of the questions above are > in some part of the documentation that I have missed; if so, please > let me know.) > > Thanks, and regards, > > Gabriel > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > -- -- -- Ken Steube San Diego Supercomputer Center University of California, San Diego, MC 0505 9500 Gilman Drive San Diego, California, 92093-0505 USA FAX (858) 822-3610 From steube at sdsc.edu Mon Apr 12 14:49:46 2004 From: steube at sdsc.edu (Ken Steube) Date: Mon, 12 Apr 2004 11:49:46 -0700 (PDT) Subject: [MOBY-l] String & text-plain In-Reply-To: <5.2.1.1.2.20040412114659.01db2610@email.med.harvard.edu> Message-ID: On Mon, 12 Apr 2004, Gabriel Berriz wrote: > Hi all. > > I'm trying to code a toy service that all it does is to echo back > *verbatim* (through a text-plain object) the raw XML that it received > as input. Just return the query string exactly: sub test_SequenceToFASTA { my ($caller, $query) = @_; return $query; # echo back the input } > > One thing I have not been able to figure out is the correspondence > between an object's definition (as given in registerObject) and the > raw XML string corresponding to this object. My immediate questions > are Here's a CGI that shows the XML for any object: http://plantsp.sdsc.edu/cgi-bin/MOBY/MOBY_display_object_xml.cgi?obj=AminoAcidSequence > > 1. What exactly is the difference between String and text-plain? text-plain ISA String, so they are identical in all except name (and therefore interpretation). An object only becomes different in content from its immediate parent when is HAS-A or HAS some item(s). > > 2. It is my understanding that the raw XML representation for the > String object corresponding to "my favorite string" is something like: > > It's more like this: my fav string id is some kind of ID describing where the string came from (it may be empty if that's appropriate). e.g. a string containing a sequence usually has the ID of the gene from which it came. > > What is the raw XML representation for the text-plain object > corresponding to "my favorite string"? my fav string > > The larger question is that from the point of view of someone coding a > service, how do I know the structure of the XML that my script will > receive as input? In the API document read about queryInput tags and Simple and Collection tags. Inside each simple/collection are MOBY XML objects. > > An even larger concern is that I'm surprised by the amount of XML > munging that I see in sample BioMOBY code. I thought the whole point > of using SOAP modules was to insulate oneself from having to do much > (or any) parsing and munging of XML. I tried to relieve us of some of that with my MobyXmlObject.pm object used in my FASTA example at http://plantgenome.sdsc.edu/mobyed2/Fasta_Service It needs some further development (to supply queryIDs + other things), but is very usable as-is. > > Gabriel > > > > > > A far more important question has to do with a client's ability to > handle a given output from a service. This output presumably comes > back as XML. How does the client figure out how to parse this output > to get the desired information? I thought the whole idea was that > this should be transparent to the client, but I have an example of chaining services together on my page http://plantgenome.sdsc.edu/mobyed2/Talks/discovering_executing_services.html It shows how to extract XML output from a service and feed it into another service. Ken -- -- -- Ken Steube San Diego Supercomputer Center University of California, San Diego, MC 0505 9500 Gilman Drive San Diego, California, 92093-0505 USA FAX (858) 822-3610 From gberriz at hms.harvard.edu Mon Apr 12 17:06:46 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Mon, 12 Apr 2004 17:06:46 -0400 Subject: [MOBY-l] Policy on the use of prefix 'moby'? Message-ID: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> Hello! I've noticed that in the sample code, some tagnames are qualified with the 'moby' prefix, while others (e.g. Integer) are not. I find this surprising, because I names like "Integer" and "Object" seem like likely candidates for namespace collisions. I couldn't find in the docs and the list's archive anything like a policy on the use of the moby prefix. Is there one? Thanks again, Gabriel From mwilkinson at mobile.rogers.com Tue Apr 13 01:04:45 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Tue, 13 Apr 2004 00:04:45 -0500 Subject: [MOBY-l] String & text-plain Message-ID: <200404130515.i3D5Flg2032727@portal.open-bio.org> The object looks like: some string content Date: Mon, 12 Apr 2004 12:10:12 To:moby-l at biomoby.org Subject: [MOBY-l] String & text-plain Hi all. I'm trying to code a toy service that all it does is to echo back *verbatim* (through a text-plain object) the raw XML that it received as input. One thing I have not been able to figure out is the correspondence between an object's definition (as given in registerObject) and the raw XML string corresponding to this object. My immediate questions are 1. What exactly is the difference between String and text-plain? 2. It is my understanding that the raw XML representation for the String object corresponding to "my favorite string" is something like: What is the raw XML representation for the text-plain object corresponding to "my favorite string"? The larger question is that from the point of view of someone coding a service, how do I know the structure of the XML that my script will receive as input? An even larger concern is that I'm surprised by the amount of XML munging that I see in sample BioMOBY code. I thought the whole point of using SOAP modules was to insulate oneself from having to do much (or any) parsing and munging of XML. Gabriel A far more important question has to do with a client's ability to handle a given output from a service. This output presumably comes back as XML. How does the client figure out how to parse this output to get the desired information? I thought the whole idea was that this should be transparent to the client, but _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l !!!!!!!!!!!!!!!! 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 gordonp at cbr.nrc.ca Tue Apr 13 09:24:40 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue, 13 Apr 2004 07:24:40 -0600 Subject: [MOBY-l] String & text-plain In-Reply-To: <200404130515.i3D5Flg2032727@portal.open-bio.org> References: <200404130515.i3D5Flg2032727@portal.open-bio.org> Message-ID: <407BEA18.7050109@cbr.nrc.ca> Yeah, there is some confusion among users here I think. SOAP uses XML for its envelope information, and if you use appropriate packages in the language of your choice, you can be unaware of that transaction envelope's syntax and semantics. But the payload of those SOAP messages is a MOBY XML document. We don't, as of yet, hide that from the user. >Soap does not insulate you from XML. > > From gordonp at cbr.nrc.ca Tue Apr 13 09:31:06 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue, 13 Apr 2004 07:31:06 -0600 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> References: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> Message-ID: <407BEB9A.3080200@cbr.nrc.ca> I have found many variations on this theme from different services, including non-prefixed Simple tags. I think the good old Web mantra applies here: be strict in what you produce, and forgiving in what you accept. In the Java peer-to-peer implementation (which I'll commit this week, honest) I accept objects like this with no namespace as being MOBY semantics. Sends a shiver down my spine... > Hello! > > I've noticed that in the sample code, some tagnames are qualified with > the 'moby' prefix, while others (e.g. Integer) are not. I find this > surprising, because I names like "Integer" and "Object" seem like > likely candidates for namespace collisions. > > I couldn't find in the docs and the list's archive anything like a > policy on the use of the moby prefix. Is there one? > > Thanks again, > > Gabriel > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From gordonp at cbr.nrc.ca Tue Apr 13 10:30:51 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue, 13 Apr 2004 08:30:51 -0600 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> References: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> Message-ID: <407BF99B.4050305@cbr.nrc.ca> Perhaps the best thing to do would be to have a RUWF? type service on the biomoby.org Web site for service developers... or perhaps have the MOBY clients send e-mails to the service provider every time they access a non-namespace compliant service :-) Gabriel Berriz wrote: > At 07:31 AM 4/13/2004 -0600, you wrote: > >> I think the good old Web mantra applies here: be strict in what you >> produce, and forgiving in what you accept. > > > Is this still the reigning principle? I was under the impression that > there's a strong movement in the Web standards community to fix the > mess we have now where so much of the HTML out there is malformed. > > Gabriel > > > From markw at illuminae.com Tue Apr 13 11:05:34 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Apr 2004 08:05:34 -0700 Subject: [MOBY] Re: [MOBY-l] String & text-plain In-Reply-To: <407BEA18.7050109@cbr.nrc.ca> References: <200404130515.i3D5Flg2032727@portal.open-bio.org> <407BEA18.7050109@cbr.nrc.ca> Message-ID: <1081868733.1963.15.camel@localhost.localdomain> On Tue, 2004-04-13 at 06:24, Paul Gordon wrote: > But the payload of those SOAP messages > is a MOBY XML document. We don't, as of yet, hide that from the user. The key here is the word "yet" :-) I think it is important to remind newcomers to MOBY that it is not a "shrink-wrapped product". There is still quite a bit of tooling to be done, though I must say that things are working surprisingly well already, even though some of the messaging is a bit arcane... M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Tue Apr 13 11:16:56 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Apr 2004 08:16:56 -0700 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407BF99B.4050305@cbr.nrc.ca> References: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> Message-ID: <1081869416.2068.1.camel@localhost.localdomain> On Tue, 2004-04-13 at 07:30, Paul Gordon wrote: > Perhaps the best thing to do would be to have a RUWF? type service on > the biomoby.org Web site for service developers... That is probably a good idea for the time-being (who is going to volunteer to write that? ;-) ). In the future, as we get more tools, this problem will probably go away entirely. > or perhaps have the > MOBY clients send e-mails to the service provider every time they access > a non-namespace compliant service :-) Oh, yeah... they will LOVE us for that! :-) We (e.g. at the developers meeting last week) have been talking about various forms of meta-data servers that might be a good place to store information like this rather than annoying our service providers with email... I agree with your earlier comment about being forgiving in what you consume, though (in fact, this is somewhat mandated by the API, in that you are obligated to consume more complex objects than you advertise in your service signature). So, Paul, in your peer-to-peer implementation are you making assumptions about the namespace because there is no default, or because you want to be ultra-forgiving? Cheers! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Tue Apr 13 11:23:02 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 13 Apr 2004 16:23:02 +0100 (BST) Subject: [MOBY] Re: [MOBY-l] String & text-plain In-Reply-To: <1081868733.1963.15.camel@localhost.localdomain> Message-ID: > > But the payload of those SOAP messages > > is a MOBY XML document. We don't, as of yet, hide that from the user. > > The key here is the word "yet" :-) > Well, my 2c opinion would put it slightly differently: "the key here is the word 'user'". Because if the 'user' is using Moby Central/Services API, it will always be dealing with XML, because MOBY Central/Services methods define their input and output parameters always as XML strings. And always will (unless Mark changes to RDF completely, but that would not help 'users' much). But if the 'user' is a user of libraries provided for individual languages then I agree that the word 'yet' is in order... 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 markw at illuminae.com Tue Apr 13 11:31:40 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Apr 2004 08:31:40 -0700 Subject: [MOBY] Re: [MOBY-l] String & text-plain In-Reply-To: References: Message-ID: <1081870299.2068.12.camel@localhost.localdomain> On Tue, 2004-04-13 at 08:23, Martin Senger wrote: > unless Mark changes to RDF completely, but that would not > help 'users' much Well... this certainly sounded like a reasonable way to go after our discussions at the last meeting ;-) M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gordonp at cbr.nrc.ca Tue Apr 13 11:37:12 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue, 13 Apr 2004 09:37:12 -0600 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <1081869416.2068.1.camel@localhost.localdomain> References: <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <1081869416.2068.1.camel@localhost.localdomain> Message-ID: <407C0928.6090600@cbr.nrc.ca> I ONLY use namespace to match the tags (as namespace-aware XML should be done). Whether the tag has no namespace because there is no default, or because its prefix resolves to an empty namespace or any other reason you can imagine, is inconsequential. I try to digest things that are in the MOBY namespace, or in no namespace at all (a and b). If the default prefix was pointing to the XHTML namspace, I wouldn't try to digest that unprefixed tag (a), since it is neither a blank namespace, nor the MOBY namespace. >I agree with your earlier comment about being forgiving in what you >consume, though (in fact, this is somewhat mandated by the API, in that >you are obligated to consume more complex objects than you advertise in >your service signature). So, Paul, in your peer-to-peer implementation >are you making assumptions about the namespace because there is no >default, or because you want to be ultra-forgiving? > > From senger at ebi.ac.uk Tue Apr 13 11:40:28 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 13 Apr 2004 16:40:28 +0100 (BST) Subject: [MOBY] Re: [MOBY-l] String & text-plain In-Reply-To: <1081870299.2068.12.camel@localhost.localdomain> Message-ID: > Well... this certainly sounded like a reasonable way to go after our > discussions at the last meeting ;-) > I am not saying that I disagree with turning to RDF, I was just expressing the fact, that the API users will never be protected against computer-readable formats (such as XML or RDF). That's all... 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 gberriz at hms.harvard.edu Tue Apr 13 11:48:01 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue, 13 Apr 2004 11:48:01 -0400 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <1081869416.2068.1.camel@localhost.localdomain> References: <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> Message-ID: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> I realize now that the subject line for my post was somewhat misleading, because it suggested that I was bringing up the issue of how strictly software should enforce standards (which is an important one) In fact my main concern is that some very common keywords (such as Object, String, Integer, Float, text-plain) in the MOBY-S API belong to the default namespace. These keywords seem to me prime candidates for the kind of collisions that namespaces are meant to solve. It seems to me that whatever rationale one may have for qualifying a keyword such as queryInput or mobyData with the prefix moby applies with even greater force to a keywords such as String or text-plain. I realize that I'm a newcomer to BioMOBY, and don't know about earlier discussions about this subject. I am still figuring out my way around. When I kept coming across unqualified keywords such as String I was not sure whether the BioMoby standard really intended to make these keywords part of the default namespace, or whether the 'moby' prefix was being omitted to avoid clutter and coders were also omitting it because the software was tolerating this deviation from the standard. Gabriel From markw at illuminae.com Tue Apr 13 11:59:35 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Apr 2004 08:59:35 -0700 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> References: <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> Message-ID: <1081871975.2068.25.camel@localhost.localdomain> On Tue, 2004-04-13 at 08:48, Gabriel Berriz wrote: > was not sure whether the BioMoby standard really intended to make these > keywords part of the default namespace, or whether the 'moby' prefix was > being omitted to avoid clutter and coders were also omitting it because the > software was tolerating this deviation from the standard. I believe the latter is the case - what is happening is that I wrote the first example services, trying to keep them as "clean" as possible to help people follow what was going on - this included "munging" the XML as plaintext so that it was plainly visible by-eye in my scripts to help people visualize what the messages were. People then copy/pasted these examples into their own services, and VOILA! Again, I think that the tooling here is the key - we shouldn't be writing XML "my hand" in any case, and it would be fairly straightforward (though perhaps not as intuitive) to write thin wrappers around the standard XML libraries that built MOBY messages using an API rather than plaintext. Then we could enforce good message structure at the library level. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gordonp at cbr.nrc.ca Tue Apr 13 12:01:08 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue, 13 Apr 2004 10:01:08 -0600 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> References: <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> Message-ID: <407C0EC4.70200@cbr.nrc.ca> There should probably be a caveat at the start of the MOBY-S API saying that the use/lack of prefixes in the examples is not canonical. To XML aware applications, whether you use a default prefix, moby:, or even xhtml: (if you're crazy), makes no difference at all, since the namespace should always resolve to http://www.biomoby.org/moby in the examples implicitly. Gabriel Berriz wrote: > I realize now that the subject line for my post was somewhat > misleading, because it suggested that I was bringing up the issue of > how strictly software should enforce standards (which is an important > one) > > In fact my main concern is that some very common keywords (such as > Object, String, Integer, Float, text-plain) in the MOBY-S API belong > to the default namespace. These keywords seem to me prime candidates > for the kind of collisions that namespaces are meant to solve. It > seems to me that whatever rationale one may have for qualifying a > keyword such as queryInput or mobyData with the prefix moby applies > with even greater force to a keywords such as String or text-plain. > > I realize that I'm a newcomer to BioMOBY, and don't know about earlier > discussions about this subject. I am still figuring out my way > around. When I kept coming across unqualified keywords such as String > I was not sure whether the BioMoby standard really intended to make > these keywords part of the default namespace, or whether the 'moby' > prefix was being omitted to avoid clutter and coders were also > omitting it because the software was tolerating this deviation from > the standard. > > Gabriel > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From gberriz at hms.harvard.edu Tue Apr 13 15:07:33 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue, 13 Apr 2004 15:07:33 -0400 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407C0EC4.70200@cbr.nrc.ca> References: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> At 10:01 AM 4/13/2004 -0600, you wrote: >There should probably be a caveat at the start of the MOBY-S API saying >that the use/lack of prefixes in the examples is not canonical. To XML >aware applications, whether you use a default prefix, moby:, or even >xhtml: (if you're crazy), makes no difference at all, since the namespace >should always resolve to http://www.biomoby.org/moby in the examples >implicitly. Gordon, I don't understand what you mean. Please correct me if I'm wrong, but in ...an XML-aware application should resolve the namespace of Simple, Object, queryID, articleName, namespace (the attribute), and id to null, not to http://www.biomoby.org/moby. And as far as I can tell, this code would be not be valid XML: ...because the xhtml prefix (for articleName) is not defined (again, please correct me if I'm wrong). The quickest fix for the last case would be to: xmnls:xhtml="http://www.w3.org/1999/xhtml"> I agree that all those 'moby:' prefixes make the code hard to read. My guess is that the least cluttered version for the first example above would be xmlns:moby="http://www.biomoby.org/moby"> ...since there's no away around using a prefix if we want attribute names such as id to belong to the MOBY namespace. Incidentally, I've come across both http://www.biomoby.org/moby and http://www.biomoby.org/moby-s as the namespace for MOBY keywords. Which one is preferable? Gabriel From steube at sdsc.edu Tue Apr 13 15:27:32 2004 From: steube at sdsc.edu (Ken Steube) Date: Tue, 13 Apr 2004 12:27:32 -0700 (PDT) Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407BEB9A.3080200@cbr.nrc.ca> Message-ID: > names like "Integer" and "Object" seem like likely candidates for > namespace collisions. I'm not sure, but in the case of MOBY are these tags really are candidates for collisions? These blocks of XML like and come from the MOBY data ontology and so there is exactly one precise meaning for these tags. One reason for having a MOBY ontology is to give specific meanings to these tags and to give an exact specification on what the XML should look like. So I think there's no room for conflicts. If we later allow multiple data object ontologies then there may be a conflict. That's when we would start to need XML namespaces to distinguish between the alternate ontologies. So my understanding then is that an XML namespace in front of Integer would only serve to distinguish between alternate MOBY ontologies (and there's only one so far). Is that correct? Ken From markw at illuminae.com Tue Apr 13 15:41:09 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Apr 2004 12:41:09 -0700 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> References: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> Message-ID: <1081885269.2068.47.camel@localhost.localdomain> Hi Gabriel, > The quickest fix for the last case would be to: > > > xmlns="http://www.biomoby.org/moby" > xmnls:xhtml="http://www.w3.org/1999/xhtml"> Absolutely right... I thought I had made that change, actually, but I might have only fixed it in one place... I'll look again. > Incidentally, I've come across both http://www.biomoby.org/moby and > http://www.biomoby.org/moby-s as the namespace for MOBY keywords. Which > one is preferable? this is legacy cruft. In the beginning, there was only "moby", and then we split the project into two branches "moby-s" and "s-moby". It was impractical (impossible?) to update all the various pieces of documentation in all the various locations, so... they were generally left as-is, and the correct namespace-of-the-moment is whatever is coded in the libraries at any given time. This is subject to change... and in fact, will change again fairly soon since we are now describing everything in the moby-s ontologies project as RDF Resources, which have their own namespace URI's. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gordonp at cbr.nrc.ca Tue Apr 13 15:45:22 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue, 13 Apr 2004 13:45:22 -0600 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> References: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> Message-ID: <407C4352.5020305@cbr.nrc.ca> >> There should probably be a caveat at the start of the MOBY-S API >> saying that the use/lack of prefixes in the examples is not >> canonical. To XML aware applications, whether you use a default >> prefix, moby:, or even xhtml: (if you're crazy), makes no difference >> at all, since the namespace should always resolve to >> http://www.biomoby.org/moby in the examples implicitly. > >> >> I agree that all those 'moby:' prefixes make the code hard to read. >> My guess is that the least cluttered version for the first example >> above would be >> >> >> >> xmlns:moby="http://www.biomoby.org/moby"> >> >> >> >> >> >> >> >> >> >> ...since there's no away around using a prefix if we want attribute >> names such as id to belong to the MOBY namespace. > Indeed, all of the statements you made are correct. My point with the xhtml prefix is that people who aren't familiar with namespaces might confuse the moby: prefix with the MOBY namespace, or not pick up that the unprefixed examples really should have a default namespace binding to MOBY, hence we should put a caveat in the API examples. The following document is equivalent to the one you list above. xmlns:xhtml="http://www.biomoby.org/moby"> The fact that the prefix used is not moby: doesn't make it any less valid as a MOBY document (though of course it does make it more confusing :-)). You make a good point with the attributes too. Currently, like the element names, I don't require the MOBY namespace the peer-to-peer implementation, but do exclude attributes explicitly declared in another namespace... It's either be strict and have half the services fail, or parse forgivingly and have all of them work. My users prefer the latter. :-) We definitely need a systematic feedback mechanism for the service providers... >> >> Incidentally, I've come across both http://www.biomoby.org/moby and >> http://www.biomoby.org/moby-s as the namespace for MOBY keywords. >> Which one is preferable? > All of the examples in the API state http://www.biomoby.org/moby, so we should probably stick with that. If we were really nice about it, we'd put a RDDL document at that URL... >> >> Gabriel >> >> _______________________________________________ >> moby-l mailing list >> moby-l at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-l >> From markw at illuminae.com Tue Apr 13 16:04:47 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Apr 2004 13:04:47 -0700 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407C4352.5020305@cbr.nrc.ca> References: <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040412165909.01da7980@email.med.harvard.edu> <5.2.1.1.2.20040413093817.01da8ce8@email.med.harvard.edu> <407BF99B.4050305@cbr.nrc.ca> <5.2.1.1.2.20040413112430.022c3a28@email.med.harvard.edu> <5.2.1.1.2.20040413142415.0238b058@email.med.harvard.edu> <407C4352.5020305@cbr.nrc.ca> Message-ID: <1081886687.2068.55.camel@localhost.localdomain> On Tue, 2004-04-13 at 12:45, Paul Gordon wrote: > We definitely need a systematic feedback mechanism for the service > providers... We discussed this at the last meeting - it is a very difficult problem! Services are transacted directly between a client and the service provider, so "moby" doesn't play a role in that process - we're merely the brokers. We could build-in some server-side filtering, but that is a given... nevertheless, unless the server is using our libraries, we can't enforce this. Other than having the client library spam the service provider every time they find a malformed message, the only other solution I can think of is to have knowledgable individuals keeping an eye on things, and publishing "best practices" on the mailing list. >All of the examples in the API state http://www.biomoby.org/moby, so we > should probably stick with that. If we were really nice about it, we'd > put a RDDL document at that URL... Yes - though the correct URL for things like Objects is now: http://biomoby.org/RESOURCES/MOBY-S/Objects and that resolves to RDF. I will probably add this as another namespace in the MOBY XML header - xmlns:mrdf="..." or something like that... M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gberriz at hms.harvard.edu Tue Apr 13 16:13:57 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue, 13 Apr 2004 16:13:57 -0400 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: References: <407BEB9A.3080200@cbr.nrc.ca> Message-ID: <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> At 12:27 PM 4/13/2004 -0700, Ken Steube wrote: > > names like "Integer" and "Object" seem like likely candidates for > > namespace collisions. > >I'm not sure, but in the case of MOBY are these tags really are candidates >for collisions? > >These blocks of XML like and come from the MOBY >data ontology and so there is exactly one precise meaning for these tags. >One reason for having a MOBY ontology is to give specific meanings to >these tags and to give an exact specification on what the XML should look >like. So I think there's no room for conflicts. Hi Ken, The problem I see is not with the choice of terms Object, Integer, etc. (I think they are perfectly fine), but rather with not specifying that these terms belong to the MOBY namespace (either via a prefix bound to it, or by setting the enclosing default namespace to it). One scenario that would introduce collisions (if Object, Integer, etc. were left out in the clear) would be a MOBY service that served chunks of XML from various sources (other than MOBY), or alternatively, an application that embedded MOBY-generated XML within other XML. Even in these cases, all would probably be OK if MOBY were the only source of XML that used unqualified keywords. In this case one could say that MOBY's namespace is effectively the "null" namespace. But I think that if all goes well, MOBY-generated XML will find itself rubbing shoulders with XML that uses unqualified keywords. :-) BTW, of the keywords I've seen, I think my top candidate for collisions is not Object or Integer but id. G. From gordonp at cbr.nrc.ca Tue Apr 13 16:29:43 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue, 13 Apr 2004 14:29:43 -0600 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> References: <407BEB9A.3080200@cbr.nrc.ca> <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> Message-ID: <407C4DB7.9000404@cbr.nrc.ca> Another candidate is Parameter (the wrapper for secondary input values to service calls). Both MAGE-ML and BSML have Parameter tags, and neither qualifies their elements by default. To make matters worse, many languages don't have a namespace floating around anywhere, so you have to make one up if you want to fix them. I'm trying to do this for our own parsing purposes, and would like to encourage others to use the same URIs. I've started this at http://www.bioxml.info, though it's rough right now. Other language submissions would be appreciated! > > BTW, of the keywords I've seen, I think my top candidate for > collisions is not Object or Integer but id. > > G. > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From gberriz at hms.harvard.edu Tue Apr 13 16:26:36 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue, 13 Apr 2004 16:26:36 -0400 Subject: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> References: <407BEB9A.3080200@cbr.nrc.ca> Message-ID: <5.2.1.1.2.20040413162249.024b6d68@email.med.harvard.edu> >Even in these cases, all would probably be OK if MOBY were the only source >of XML that used unqualified keywords. In this case one could say that >MOBY's namespace is effectively the "null" namespace. But I think that if >all goes well, MOBY-generated XML will find itself rubbing shoulders with >XML that uses unqualified keywords. :-) Sorry, in the above "unqualified keywords" should have been "keywords with no namespace". G. From markw at illuminae.com Tue Apr 13 16:47:51 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 13 Apr 2004 13:47:51 -0700 Subject: [MOBY] Re: [MOBY-l] Policy on the use of prefix 'moby'? In-Reply-To: <407C4DB7.9000404@cbr.nrc.ca> References: <407BEB9A.3080200@cbr.nrc.ca> <5.2.1.1.2.20040413153601.023cc600@email.med.harvard.edu> <407C4DB7.9000404@cbr.nrc.ca> Message-ID: <1081889271.2068.58.camel@localhost.localdomain> On Tue, 2004-04-13 at 13:29, Paul Gordon wrote: > Another candidate is Parameter (the wrapper for secondary input values > to service calls). Both MAGE-ML and BSML have Parameter tags, and > neither qualifies their elements by default. >>sigh<< Oh what a tangled web we weave! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gberriz at hms.harvard.edu Wed Apr 14 14:21:11 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Wed, 14 Apr 2004 14:21:11 -0400 Subject: [MOBY-l] Registering new MOBY object Message-ID: <5.2.1.1.2.20040414135706.0238f1c0@email.med.harvard.edu> Hi, all. When registering a new MOBY object one is supposed to pass a Relationships parameter: Relationships => { relationshipType1 => [ [Object1, articleName], [Object2, articleName]], relationshipType2 => [ [Object1, articleName]]} What is the meaning of articleName? In the case when the relationship type is "hasa" I suppose that articleName is analogous to the name of a "field" for a class. In the cases when the relationship type is either "isa" or "has" it is not clear to me how to intepret this parameter. In any case, how is this "articleName" used subsequently? How are additional attributes (such as namespace and id) for these object elements specified? One last question: it is not clear to me what exactly the function of the SImple element is. As I understand it, Simple elements must contain exactly one MOBY object. Other than acting as a wrapper around this MOBY object, what purpose does the Simple element fulfill? Thanks! Gabriel From markw at illuminae.com Wed Apr 14 15:25:51 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 14 Apr 2004 12:25:51 -0700 Subject: [MOBY] [MOBY-l] Registering new MOBY object In-Reply-To: <5.2.1.1.2.20040414135706.0238f1c0@email.med.harvard.edu> References: <5.2.1.1.2.20040414135706.0238f1c0@email.med.harvard.edu> Message-ID: <1081970751.1974.11.camel@localhost.localdomain> Hi Gabriel, I think you should perhaps look at a few examples of services, or walk through one of Ken's tutorials online (click on the "Tutorials and How To's" link on the moby homepage), to answer many of your questions all in one shot, since most of the answers you are looking for are explicit or implicit in these tutorials... > What is the meaning of articleName? In the case when the relationship type > is "hasa" I suppose that articleName is analogous to the name of a "field" > for a class. In the cases when the relationship type is either "isa" or > "has" it is not clear to me how to intepret this parameter. articleName is meaningless for ISA relationships - just leave it blank. > In any case, how is this "articleName" used subsequently? it is used to identify a subcomponent of a complex object. If you look at a few example objects in the API this will be clear. 10 > How are additional attributes (such as namespace and id) for these object > elements specified? again, please look at the examples, and see above. Everything is an object, and objects have namespace and id attributes. > Other than acting as a wrapper around this MOBY > object, what purpose does the Simple element fulfill? none. that is their only function. There may be a reason to add additional substructure in the future, but at the moment they are an empty wrapper around a single object, and help to ensure that Simple and Collection inputs have ~the same XML structures. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 15 14:30:33 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 15 Apr 2004 11:30:33 -0700 Subject: [MOBY-l] MOBY Central down on Sunday for one hour Message-ID: <1082053832.3511.39.camel@localhost.localdomain> Hi all, MOBY Central's server room will be down for electrical upgrades from 1300 to 1400 EST on Sunday. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From fgibbons at hms.harvard.edu Fri Apr 16 09:57:07 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 16 Apr 2004 09:57:07 -0400 Subject: [MOBY-l] Version numbers? Message-ID: <5.2.1.1.2.20040416095218.019f5c60@email.med.harvard.edu> Hey listers, Gabriel Berriz and I are working on setting up and using each other's services. We've run into a little hitch, in that we appear to be using different versions of MOBY. However, we don't know for sure, because the only version information available in the MOBY package is in MOBY.pm, and that's "0.04". It would REALLY help if each version came out with a different version number. It doesn't have to mean anything, just be different. Maybe someone could change it daily or weekly? I don't know the best way to do this on something that's undergoing rapid change, maybe there's a better way to do it? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From fgibbons at hms.harvard.edu Mon Apr 19 10:11:48 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Mon, 19 Apr 2004 10:11:48 -0400 Subject: [MOBY] [MOBY-l] Version numbers? In-Reply-To: <1082128727.2587.8.camel@localhost.localdomain> References: <5.2.1.1.2.20040416095218.019f5c60@email.med.harvard.edu> <5.2.1.1.2.20040416095218.019f5c60@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040419094938.01a02a40@email.med.harvard.edu> At 11:18 AM 4/16/2004, you wrote: >I'm dubious that it is a difference in MOBY version that is causing the >problem, unless it has been a long long time since you upgraded your >libraries. Services have continued to be interoperable over the past >few months even over CVS updates on the client, server, and Central >side... > >What are the symptoms of the problem you are seeing? Mark, Well, one symptom was that the 'articleName', provided as the first element of the array ref used to construct XMLinputlist in the execute call, was being added to the tag, not to the tag where it's apparently supposed to be. Since Gabriel's service relied on pulling articleNames out of , to get query data, it thought there was never any data in my queries. We both have our own installations of MOBY, but I downloaded it a few weeks before the CSHL MOBY meeting, whereas he downloaded the week afterwards. We diffed our two installations, and there were significant differences, but no version numbers, so we couldn't really track things down. Once I started using his, the problem disappeared. Hence my conclusion that I was merely using an out-dated version of the library. I realise that you've been going to great pains to maintain interoperability, but perhaps this was a bug in an earlier version that got fixed. Clearly you don't keep compatibility with bugs, right? On a somewhat related note, what's the regression-testing situation in MOBY? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From steube at sdsc.edu Mon Apr 19 10:57:02 2004 From: steube at sdsc.edu (Ken Steube) Date: Mon, 19 Apr 2004 07:57:02 -0700 (PDT) Subject: [MOBY-l] Regression testing In-Reply-To: <5.2.1.1.2.20040419094938.01a02a40@email.med.harvard.edu> Message-ID: On Mon, 19 Apr 2004, Frank Gibbons wrote: > On a somewhat related note, what's the regression-testing situation in > MOBY? -Frank I have a few regression tests for my services which I'll describe below. How should we make the regression tests available to everyone? Maybe the tWiki could be used for this...many people could contribute regression tests and put 'em up on the Wiki. My regression tests consist of a script that downloads a seq and verifies it is correct and says yes or no. Another is a web page with two forms from which I can execute some services: http://plantsp.sdsc.edu/plantsp/html/service_demo.html Try out this URL. It's ugly but it's a versatile test and you can edit the inputs before running it. Ken -- -- -- Ken Steube San Diego Supercomputer Center University of California, San Diego, MC 0505 9500 Gilman Drive San Diego, California, 92093-0505 USA FAX (858) 822-3610 From gberriz at hms.harvard.edu Tue Apr 20 13:36:04 2004 From: gberriz at hms.harvard.edu (Gabriel Berriz) Date: Tue, 20 Apr 2004 13:36:04 -0400 Subject: [MOBY-l] Object name conflicts Message-ID: <5.2.1.1.2.20040420132034.01dcc368@email.med.harvard.edu> Hi. I wanted to register an object named "Interaction", but I discovered that an object of this name has already been registered. Unfortunately, this Interaction object is not a suitable substitute for the object we had wanted to register under the same name, so we still would like to register our version of the "Interaction" object. In other words, a textbook example of a namespace collision. My temporary stop-gap solution was to register objects with names of the form "prefix:objectName", i.e. I resorted to a crude implementation of something like a namespace. What's the word on dealing with such name collisions in the BioMOBY Object Ontology? I think it would be nice to have namespace support for the names of objects in the Object Ontology. Thanks, Gabriel From markw at illuminae.com Tue Apr 20 15:27:16 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 20 Apr 2004 12:27:16 -0700 Subject: [MOBY] [MOBY-l] Object name conflicts In-Reply-To: <5.2.1.1.2.20040420132034.01dcc368@email.med.harvard.edu> References: <5.2.1.1.2.20040420132034.01dcc368@email.med.harvard.edu> Message-ID: <1082489236.1656.62.camel@localhost.localdomain> On Tue, 2004-04-20 at 10:36, Gabriel Berriz wrote: > I wanted to register an object named "Interaction", but I discovered that > an object of this name has already been registered. Unfortunately, this > Interaction object is not a suitable substitute for the object we had > wanted to register under the same name, so we still would like to register > our version of the "Interaction" object. In other words, a textbook > example of a namespace collision. yup. Like the GO, I was hoping that names could be human-readable, and somewhat more specific than "Interaction", but that clearly does not work in a community-curated system :-P If you are desperate to namespace your object identifiers, then I suggest that you register your object "term" as a full-blown LSID, since that will be allowed by the registration system (though note that this is currently untested). Otherwise, to be safe, or if you prefer human-readability in your object names, pick a more specific name (ProteinProteinInteraction, or something like that) that wont collide with the existing name. Also, be careful about putting colons or other strange characters into your human-readable names, since the code might not be very forgiving of that... Nina begins work on Monday, and she will tighten up the codebase and clean up all of these kinds of things, but for now, be gentle! This is NOT professionally written code! M > My temporary stop-gap solution was to register objects with names of the > form "prefix:objectName", i.e. I resorted to a crude implementation of > something like a namespace. What's the word on dealing with such name > collisions in the BioMOBY Object Ontology? I think it would be nice to > have namespace support for the names of objects in the Object Ontology. > > Thanks, > > Gabriel > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Tue Apr 20 15:48:32 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 20 Apr 2004 12:48:32 -0700 Subject: [MOBY-l] Welcome Nina! Message-ID: <1082490512.1656.77.camel@localhost.localdomain> Hi everyone, I wanted to send a quick note to introduce you to Nina - our newest MOBY developer. She will be acting as "my hands" for the foreseeable future cleaning/tightening the MOBY Central & Ontology Server core code and MOBY Cient/Server libraries, enhancing the functionality, bringing the entire MOBY-S API to fruition (finally!), and working with Martin and others to put together the Java libraries etc. She is hired as a 100% MOBY software developer, so this is great news for me/us! I'm pleased to have her working with me here at iCAPTURE! I apologize to you all for the lack of progress over the past couple of months, but having Nina around will get us back up to speed :-) Cheers all! Mark -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From bneron at pasteur.fr Tue Apr 27 03:57:11 2004 From: bneron at pasteur.fr (Bertrand Neron) Date: Tue, 27 Apr 2004 09:57:11 +0200 Subject: [MOBY-l] Paramter structure Message-ID: <20040427075711.GA15471@caroline.sis.pasteur.fr> I 'd like to build a service which take in input a Simple and several Secondaries. which structure should have the xml input ? On the page http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI, I found an example of xml where the Parameters have the following structure: 34 The complete example from http://www.biomoby.org/twiki/bin/view/Moby/MobySAPI: ... A message to a service that requires Secondary Articles is invoked as in the following example: 34 ... But on the page of the api of Moby.CommonSubs ( http://www.biomoby.org/moby-live/Perl/MOBY/CommonSubs.htm). I found an other example of xml input. Where the parameter have this structure dataType The complete example from complexServiceInputParser at http://www.biomoby.org/moby-live/Perl/MOBY/CommonSubs.htm : ... for example, the input message: Float 10 will become: (note that SIMPLE, COLLECTION, and SECONDARY are exported constants from this module) $inputs->{1} = [ [SIMPLE, $DOM_name1], [SECONDARY, $DOM_cutoff] ] ... Thanks, Bertrand -- Bertrand Neron Pasteur Institute Computing Center. From gordonp at cbr.nrc.ca Tue Apr 27 09:33:34 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Tue, 27 Apr 2004 07:33:34 -0600 Subject: [MOBY-l] Paramter structure In-Reply-To: <20040427075711.GA15471@caroline.sis.pasteur.fr> References: <20040427075711.GA15471@caroline.sis.pasteur.fr> Message-ID: <408E612E.60000@cbr.nrc.ca> Hi Bertrand, We are implementing the same thing, and I think the first form, with Parameter/value is the correct one since it is in the API, and because the second declaration is redundant or potentially in conflict with the datatype declared in the service registration. i.e. you could say it's a float, but the service asked for a string. Bertrand Neron wrote: >I 'd like to build a service which take in input a Simple and several >Secondaries. > >which structure should have the xml input ? > >On the page http://www.biomoby.org/twiki/bin//view/Moby/MobySAPI, I found an >example of xml where the Parameters have the following structure: > > > 34 > > >The complete example from >http://www.biomoby.org/twiki/bin/view/Moby/MobySAPI: > >... >A message to a service that requires Secondary Articles is invoked as in the following example: > > > > > > > > > > > 34 > > > > > > >... > > >But on the page of the api of Moby.CommonSubs ( >http://www.biomoby.org/moby-live/Perl/MOBY/CommonSubs.htm). I found an >other example of xml input. Where the parameter have this structure > > > dataType > > > >The complete example from complexServiceInputParser at >http://www.biomoby.org/moby-live/Perl/MOBY/CommonSubs.htm : > >... > for example, the input message: > > > > > > > Float > 10 > > > > will become: > (note that SIMPLE, COLLECTION, and SECONDARY are exported constants from this module) > > $inputs->{1} = [ [SIMPLE, $DOM_name1], > [SECONDARY, $DOM_cutoff] > ] > >... > > >Thanks, > >Bertrand > >-- >Bertrand Neron >Pasteur Institute Computing Center. > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > From mwilkinson at mrl.ubc.ca Thu Apr 29 14:25:58 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 29 Apr 2004 11:25:58 -0700 Subject: [MOBY-l] Update from the last developers meeting: MOBY-S API changes Message-ID: <1083263157.1632.41.camel@myhost.mydomain> Hi all, I am finally getting around to writing the update from our last developers meeting, hosted by Lincoln at CSHL. Thanks Lincoln! Well, the whisky and ideas flowed like a river :-) and as a consequence there were some important decisions made affecting the MOBY-S API: (1) The process of registering and deregistering a service will now become more of a "pull", rather than a "push"; your server will now host a simple RDF document that describes your service such that MOBY Central can GET this document on a regular basis to decide if your service is still registered and/or modified. Thus we don't need any fancy security model for deregistration, since presumably only you have access to your own server. This is quite Google-like. (2) The messaging XML format has changed slightly: (a) the moby:Query and moby:Response tags have now been merged into a single tag moby:mobyContent (b) the moby:queryInput and moby:queryResponse tags have now been merged into a single tag moby:mobyData -- these two changes now make the input message structure ~identical to the output message structure, thus we truly can pipe messages from one service to the next without fiddling with them. Change #1 has not yet been implemented, and might take a while. I'll try to make some progress on it this weekend. The idea is that you will register your service using the existing registerService API call as usual, with the inclusion of one additional parameter representing the location where you will store your service description RDF documents for MOBY Central to GET. MOBY Central will parse your registerService call and return you a registration Object as usual, however the registration Object will contain an additional parameter, representing the RDF document that describes your service as per the parameters you sent it - i.e. MOBY Central will create the RDF for you. You place the RDF in the location that you indicated in the registerService call and MOBY will troll your server every ~week to see if it is still there, and update the registry if it has changed. Change #2 will be implemented in the Perl libraries (e.g. MOBY::Client::Central and MOBY::CommonSubs), and hopefully also in the Java libraries, thus people using the libraries to create/parse the messages should not notice the change... so if you are not using the libraries, you should be! :-) I'm trying to ensure that both message structures are understood by these libraries so that we continue to have backward compatibility at least for a while. I'm going to update the API documentation on the web ASAP. I'll put the photo's from the meeting up on the web as soon as they have been edited for content... ;-) ;-) Cheers all! Mark -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 29 18:39:56 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 29 Apr 2004 15:39:56 -0700 Subject: [MOBY-l] CVS update required from all service providers Message-ID: <1083278395.1662.17.camel@myhost.mydomain> Hi everyone, All current service providers will need to cvs update their MOBY::CommonSubs module to bring everyone into sync with the message format changes. I just checked and all of my own services kicked back to life as soon as I updated, so as long as you are using the libraries a CVS update will fix everything and you wont have to change your services. ...I know... this was an ugly one... Sorry! :-( I hate changing the API, but we don't do this often, considering how young the project is! It's all for the best, though... or so they say ;-) Java people: If you do a simple substitution of Query -> mobyContent Response -> mobyContent queryInput -> mobyData queryResponse -> mobyData that is all that should be required to bring your code up to date with the API. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre