From Pieter.Neerincx at wur.nl Mon May 2 11:36:08 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon May 2 11:29:09 2005 Subject: [MOBY-dev] SQL dump In-Reply-To: <20050419091628.GN17377@parrot.ebi.ac.uk> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> Message-ID: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Hi all, I'm trying to get an SQL dump from the BioMOBY central. I tried MOBY::CLient::Central::DUMP() from the perl API and a raw SOAP call, but all I get is: 500 Internal Server Error. With SOAP::Lite + 'trace' I also get: ...snip... can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. ...snip... For the complete trace see below. Anyone got an idea what I'm missing here? Any feedback would be appreciated. Cheers, Pieter -------------------------------------------------- SOAP::Lite trace: MOBY Central Data Dump: SOAP::Transport::new: () SOAP::Serializer::new: () SOAP::Deserializer::new: () SOAP::Parser::new: () SOAP::Lite::new: () SOAP::Transport::HTTP::Client::new: () SOAP::Lite::call: () SOAP::Serializer::envelope: () SOAP::Serializer::envelope: DUMP SOAP::Data::new: () SOAP::Data::new: () SOAP::Data::new: () SOAP::Data::new: () SOAP::Transport::HTTP::Client::send_receive: HTTP::Request=HASH(0x8475a84) SOAP::Transport::HTTP::Client::send_receive: POST http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl HTTP/1.1 Accept: text/xml Accept: multipart/* Content-Length: 466 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x8628038) SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error Connection: close Date: Mon, 02 May 2005 15:16:45 GMT Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 Content-Length: 600 Content-Type: text/xml; charset=utf-8 Client-Date: Mon, 02 May 2005 15:16:45 GMT Client-Peer: 198.166.4.225:80 Client-Response-Num: 1 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Servercan't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. SOAP::Deserializer::deserialize: () SOAP::Parser::decode: () 500 Internal Server Error at ./GetDumpRawSOAP.pl line 52 SOAP::Lite::DESTROY: () SOAP::Deserializer::DESTROY: () SOAP::Serializer::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Transport::DESTROY: () SOAP::Transport::HTTP::Client::DESTROY: () SOAP::Parser::DESTROY: () From senger at ebi.ac.uk Mon May 2 13:04:21 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon May 2 12:57:26 2005 Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: > For the complete trace see below. Anyone got an idea what I'm missing > here? Any feedback would be appreciated. > I can confirm the same problem using Java client. This is what I am sending: POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1 Host: mobycentral.cbr.nrc.ca:9999 Cache-Control: no-cache Pragma: no-cache SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" Content-Length: 402 And I am getting the same error message as with the Perl client: HTTP/1.0 500 Internal Server Error Date: Mon, 02 May 2005 17:03:53 GMT Content-Length: 600 Content-Type: text/xml; charset=utf-8 Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Server can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. Cheers, 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 senger at ebi.ac.uk Mon May 2 13:04:21 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon May 2 12:57:27 2005 Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: > For the complete trace see below. Anyone got an idea what I'm missing > here? Any feedback would be appreciated. > I can confirm the same problem using Java client. This is what I am sending: POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1 Host: mobycentral.cbr.nrc.ca:9999 Cache-Control: no-cache Pragma: no-cache SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" Content-Length: 402 And I am getting the same error message as with the Perl client: HTTP/1.0 500 Internal Server Error Date: Mon, 02 May 2005 17:03:53 GMT Content-Length: 600 Content-Type: text/xml; charset=utf-8 Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Server can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. Cheers, 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 Mon May 2 14:11:32 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon May 2 14:05:30 2005 Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: <42766D54.2060602@illuminae.com> fixed From markw at illuminae.com Mon May 2 14:11:32 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon May 2 14:05:37 2005 Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: <42766D54.2060602@illuminae.com> fixed From senger at ebi.ac.uk Mon May 2 14:16:32 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon May 2 14:09:53 2005 Subject: [MOBY-dev] SQL dump In-Reply-To: <42766D54.2060602@illuminae.com> Message-ID: > fixed > Confirmed. 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 senger at ebi.ac.uk Mon May 2 14:16:32 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon May 2 14:09:58 2005 Subject: [MOBY-dev] SQL dump In-Reply-To: <42766D54.2060602@illuminae.com> Message-ID: > fixed > Confirmed. 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 Pieter.Neerincx at wur.nl Tue May 3 07:51:32 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue May 3 07:44:56 2005 Subject: [MOBY-dev] SQL dump In-Reply-To: References: Message-ID: <818098468df1567f6549a31c365fd008@wur.nl> On 2 May, 2005, at 20:16, Martin Senger wrote: >> fixed >> > Confirmed. > Martin Check, works here again as well with Perl API. Thanx for the fast fix Mark! Cheers, Pieter From senger at ebi.ac.uk Tue May 17 10:36:19 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue May 17 10:29:06 2005 Subject: [MOBY-dev] how to get LSID of the registered service In-Reply-To: <1116254505.13769.68.camel@mobycentral.mrl.ubc.ca> Message-ID: Mark, Quite a long time ago we have discussed the inconsistency in the returned names from the registry. Recently Mathieu asked me how to get an LSID of a service (in order to ask for metadata etc.) so I have looked at the names again. It seems that: 1) One cannot get an LSID - using the registry API. The findService method seems to return only the simple service name. 2) The extended API (the rules for getting URLs returning RDF documents) is not yet in place. And more, my pretty old RDF document (so this may not be true anymore) does not show LSIDs either. 3) Regarding the names of data types, the situation is better (because one *can* get an LSID of a data type) - but not consistent: the method retriveObjectNames returns simple names and the method retrieveObjectDefinition returns LSIDs. I think that we should fix/solve/explain this asap. Any plans or suggestions for it? Cheers, Martin PS. It would also help if you explain in BioMoby API an official way how to get these RDF documents. I know that you mentioned that there was "an XML standard way" but I doubt that it was clear to most of us :-). Thanks. M. -- 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 May 17 11:13:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue May 17 11:07:14 2005 Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: References: Message-ID: <1116342789.19327.21.camel@mobycentral.mrl.ubc.ca> Hi Martin, I've been thinking about that problem quite a bit, actually. I know that the existing system is a bit of a mish-mash, and needs to be cleaned up. My suggested solution is as follows: for every XML tag in an outgoing MOBY Central API message, where the content of the tag is an element in one of the four MOBY ontologies, there should be an attribute lsid='xxx' indicating the LSID corresponding to the human-readable content of the XML tag. e.g. Service_Ontology_Term 1 moby your@email.addy.here http://service.endpoint.here/scriptname ObjectOntologyTerm NamespaceTerm ObjectOntologyTerm NamespaceTerm I suspect that we will eventually need to make the same true for inbound MOBY Central API messages, since we now have distributed ontologies so I cannot be sure if the object named GeneClass is part of the biomoby cenral object ontolgy, or one of the distributed ontologies... and as such, a lookup on that object by its human readable name might be a disaster! On the other hand, the human readable names are so friendly that I think we would be shooting ourselves in the foot if we discarded them altogether... Does that solution suit everyone? Are there any objections? I will be sure to make it entirely consistent such that the LSID is NOT present in the content of the XML tag, but only in the attribute. Let me know if there are any objections to this, and if not, I will try to implement this before next week. M On Tue, 2005-05-17 at 15:36 +0100, Martin Senger wrote: > Mark, > Quite a long time ago we have discussed the inconsistency in the > returned names from the registry. Recently Mathieu asked me how to get an > LSID of a service (in order to ask for metadata etc.) so I have looked at > the names again. It seems that: > > 1) One cannot get an LSID - using the registry API. The findService > method seems to return only the simple service name. > > 2) The extended API (the rules for getting URLs returning RDF > documents) is not yet in place. And more, my pretty old RDF document (so > this may not be true anymore) does not show LSIDs either. > > 3) Regarding the names of data types, the situation is better (because > one *can* get an LSID of a data type) - but not consistent: the method > retriveObjectNames returns simple names and the method > retrieveObjectDefinition returns LSIDs. > > I think that we should fix/solve/explain this asap. Any plans or > suggestions for it? > > Cheers, > Martin > > PS. It would also help if you explain in BioMoby API an official way how > to get these RDF documents. I know that you mentioned that there was "an > XML standard way" but I doubt that it was clear to most of us :-). > Thanks. M. > From senger at ebi.ac.uk Tue May 17 11:39:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue May 17 11:32:13 2005 Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: <1116342789.19327.21.camel@mobycentral.mrl.ubc.ca> Message-ID: Hi, > My suggested solution is as follows: for every XML tag in an outgoing > MOBY Central API message, where the content of the tag is an element in > one of the four MOBY ontologies, there should be an attribute lsid='xxx' > indicating the LSID corresponding to the human-readable content of the > XML tag. > This seems quite a good and reasonable solution to me. > I suspect that we will eventually need to make the same true for inbound > MOBY Central API messages, since we now have distributed ontologies so I > cannot be sure if the object named GeneClass is part of the biomoby > cenral object ontolgy, or one of the distributed ontologies... > I know that you keep repeating this, and I keep repeating that it is an implementation detail :-) I truly believe that you are confusing us by talking about various ontologies without changing the Central API. As long as the API does not change we *do not see" any distributed ontologies - so for us, the mortals, there is no difference between "the biomoby central object ontology" and any distributed ontology. Is this true or am I still missing anything? > On the other hand, the human readable names are so friendly that I think > we would be shooting ourselves in the foot if we discarded them > altogether... > Correct, I agree. I think that for inbound messages the simple names are fine. The users can keep the LSIDs only for calling the BioMoby LSID resolution service. That reminds me: is the LSID resolution service already running - or it is a work in progress? > Let me know if there are any objections to this, and if not, I will try > to implement this before next week. > This is a fantastic time plan! Could you perhaps add first the changes into the API document - and let us know - so we can change in advance also our libraries (in jMoby in my case)? Cheers, 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 May 17 11:50:27 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue May 17 11:42:57 2005 Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: References: Message-ID: <1116345027.19327.42.camel@mobycentral.mrl.ubc.ca> On Tue, 2005-05-17 at 16:39 +0100, Martin Senger wrote: > This seems quite a good and reasonable solution to me. Super - any objections from others? > I know that you keep repeating this, and I keep repeating that it is an > implementation detail :-) I truly believe that you are confusing us by > talking about various ontologies without changing the Central API. As long > as the API does not change we *do not see" any distributed ontologies - so > for us, the mortals, there is no difference between "the biomoby central > object ontology" and any distributed ontology. Is this true or am I still > missing anything? Well... there is the API, and then there is the reality. There are currently 3 MOBY Centrals (that I know about) that are interacting *exclusively* with their local ontologies, despite the fact that this is not officially supported by the API. I grant you that this is "not our problem"... but at the end of the day it IS our problem, since it shows that the behaviour and desire of the community we are serving is to have distributed ontologies. As such, the faster I make the official API compatible with what the user community is already doing, the faster we will all be able to work together again :-) > That reminds me: is the LSID resolution service already running - or it > is a work in progress? It is running - metadata resolution only for Namespaces, Services, Objects, and ServiceInstances. > This is a fantastic time plan! I'm feeling ambitious ;-) > Could you perhaps add first the changes into the API document - and let > us know - so we can change in advance also our libraries (in jMoby in my > case)? OK. Unless I hear any objections over the next day or two I will work on these code changes when I get back from California on Sunday... ...oh... oops! Perhaps it will be delayed longer than that... I forgot that my laptop was stolen last week, so I don't have a way to code from home anymore :-/ (also, all of my notes from the working group session were stolen along with it... if anyone has notes about what was decided can you post them to the list? thanks!) Anyway, I will get the API updated and the code updated ASAP. M From senger at ebi.ac.uk Tue May 17 11:56:34 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue May 17 11:49:04 2005 Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: <1116345027.19327.42.camel@mobycentral.mrl.ubc.ca> Message-ID: > As such, the faster I make the official API compatible with what the > user community is already doing, the faster we will all be able to work > together again :-) > That's exactly what I wish to have. I see that you are listening to my "voice in the desert". Thanks. > that my laptop was stolen last week > My condolences - that's must be awfull! Cheers, 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 Thu May 19 15:17:19 2005 From: simont at mcw.edu (Twigger Simon) Date: Thu May 19 15:11:04 2005 Subject: [MOBY-dev] last weeks issue of science Message-ID: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> Did people see last week's edition of Science with a special section on distributed computing? Lots of stuff on web services, etc. Im still reading it but havent see a mention of MOBY in there as yet. I wonder if there is scope for a follow up letter to Science commenting on this special edition and emphasizing the benefits of MOBY, its scope so far, goals, etc. Might not fly but then again you never know. Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From duncan.hull at cs.man.ac.uk Fri May 20 05:25:30 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri May 20 05:18:20 2005 Subject: [MOBY-dev] last weeks issue of science In-Reply-To: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> References: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> Message-ID: <428DAD0A.8090104@cs.man.ac.uk> Hi Simon Twigger Simon wrote: > Did people see last week's edition of Science with a special section > on distributed computing? There are two articles in Science issue on Distributed computing that mention myGrid, which uses biomoby services. If you write them a letter it would be worth pointing this out. Cyberinfrastructure for e-Science Tony Hey and Anne E. Trefethen http://www.sciencemag.org/cgi/content/abstract/308/5723/817?etoc p. 817 Cyberinfrastructure: Empowering a "Third Way" in Biomedical Research Kenneth H. Buetow http://www.sciencemag.org/cgi/content/abstract/308/5723/821?etoc p. 821 Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From senger at ebi.ac.uk Tue May 24 11:19:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue May 24 11:15:04 2005 Subject: [MOBY-dev] jMoby actions from the Vancouver meeting Message-ID: Dear moby-ers, I have commited changes (thanks to help by Eddie, Ben, Paul and others) we have discussed in Vancouver regarding the Java code base ("jMoby"). Please look at the new jMoby documentation (http://www.biomoby.org/moby-live/Java/docs/index.html) which is now being updated every few hours automatically. Which means - when you add new code or documentation into 'moby-live/Java' it will soon appear on the main biomoby pages. Please feel free to comment on the way how we create and share Java code base - because that is important for all us, Java developers in Moby world. Regards, 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 May 24 19:47:15 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue May 24 19:39:31 2005 Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Well... the time has come :-( We need to break many of the existing services in order to make this last change leading to the 1.0 API. The conclusion we came to at the meeting is that inheriting from the MOBY primitives was bad bad bad. As such, all primitives will continue to be MOBY objects, but nothing can inherit from them. Objects that require content (e.g. our Genbank Flat file object) will now be re- defined to HASA String rather than ISA string. Comically, this change in the API doesn't require any changes to the code, but nevertheless it will break many services out there! We just had a lab meeting and we made some decisions about how we think the new objects should look. The plan for the moment is to change the ISA's to HASA's when an object inherits from a primitive, and to make the HASA articleName be the same as the parent object type. Therefore the existing MOBY Object: Content Here will become: Content Here It's a shame to break so many services just when the latest paper has come out and people are madly playing with MOBY, but... it's all for the best! This change to the API will make things much easier in the long run. If anyone has any objections to this please voice them ASAP. It would be good to make this change before the end of the month if at all possible. Cheers! Mark From senger at ebi.ac.uk Wed May 25 03:49:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed May 25 03:42:23 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Message-ID: > Content Here > > > will become: > > > Content > Here > > Just a question: where do the 'ns' and 'id' in come from? 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 senger at ebi.ac.uk Wed May 25 03:49:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed May 25 03:42:28 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Message-ID: > Content Here > > > will become: > > > Content > Here > > Just a question: where do the 'ns' and 'id' in come from? 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 rebecca.ernst at gsf.de Wed May 25 03:56:26 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed May 25 03:48:42 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <42942FAA.8030008@gsf.de> I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From rebecca.ernst at gsf.de Wed May 25 03:56:26 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed May 25 03:48:59 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <42942FAA.8030008@gsf.de> I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From markw at illuminae.com Wed May 25 09:41:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed May 25 09:34:42 2005 Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> We briefly said that, but discarded the idea almost immediately. Primitives must be objects in moby so that services can operate on primitives (and be discoverable). So, yes, ns and I'd come from Object. Objections? Alternatives? M -----Original Message----- From: Rebecca Ernst Date: Wed, 25 May 2005 09:56:26 To:Core developer announcements Cc:mobydev , markw@illuminae.com Subject: Re: [MOBY-dev] Breakin' the services for the final API I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Wed May 25 09:41:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed May 25 09:34:45 2005 Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> We briefly said that, but discarded the idea almost immediately. Primitives must be objects in moby so that services can operate on primitives (and be discoverable). So, yes, ns and I'd come from Object. Objections? Alternatives? M -----Original Message----- From: Rebecca Ernst Date: Wed, 25 May 2005 09:56:26 To:Core developer announcements Cc:mobydev , markw@illuminae.com Subject: Re: [MOBY-dev] Breakin' the services for the final API I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Wed May 25 09:50:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed May 25 09:45:14 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> Message-ID: > So, yes, ns and I'd come from Object. > Well, it means that we have the same 'ns' and 'id' on two places now. Why? I understand that a primitive object must have 'ns' and 'id' if a service operates on that primitive. But if the primitive is in HASA? 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 senger at ebi.ac.uk Wed May 25 09:50:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed May 25 09:54:44 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> Message-ID: > So, yes, ns and I'd come from Object. > Well, it means that we have the same 'ns' and 'id' on two places now. Why? I understand that a primitive object must have 'ns' and 'id' if a service operates on that primitive. But if the primitive is in HASA? 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 Wed May 25 10:08:42 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed May 25 10:00:57 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> On Wed, 2005-05-25 at 14:50 +0100, Martin Senger wrote: > Well, it means that we have the same 'ns' and 'id' on two places now. No. Just like any other object, the namespace and id are associated with whichever object is most appropriate, and may be blank. Nothing has changed in that regard. > Why? I understand that a primitive object must have 'ns' and 'id' if a > service operates on that primitive. But if the primitive is in HASA? This is just like any other HASA. AnnotatedSequence HASA Sequence -> Both the AnnotatedSequence and the Sequence object it contains have their own namespace and id, and these are not identical in intent nor meaning. The AnnotatedSequence might have a namespace representing the annotating body, and the Sequence it contains may have a namespace representing the authority from which that sequence was derived. M From senger at ebi.ac.uk Wed May 25 10:15:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed May 25 10:08:14 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> Message-ID: > No. Just like any other object, the namespace and id are associated > with whichever object is most appropriate, and may be blank. Nothing > has changed in that regard. > Generally speaking, you are right. But I was not speaking generally, I was referring to the case when we convert a current object (that inherits from a primitive) into a new object with a primitive type in its HASA. In this case we do not have more than one 'ns' and 'id' so if we put it into HASA mamber it must be the same as in the upper level. That's why I said that we have the 'ns' and 'id' same in two places - and we do not need it I still think. Am I right? 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 senger at ebi.ac.uk Wed May 25 10:15:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed May 25 10:08:14 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> Message-ID: > No. Just like any other object, the namespace and id are associated > with whichever object is most appropriate, and may be blank. Nothing > has changed in that regard. > Generally speaking, you are right. But I was not speaking generally, I was referring to the case when we convert a current object (that inherits from a primitive) into a new object with a primitive type in its HASA. In this case we do not have more than one 'ns' and 'id' so if we put it into HASA mamber it must be the same as in the upper level. That's why I said that we have the 'ns' and 'id' same in two places - and we do not need it I still think. Am I right? 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 Wed May 25 10:21:54 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed May 25 10:14:19 2005 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <1117030914.25071.23.camel@mobycentral.mrl.ubc.ca> I am assuming that the ns and id of the contained object (the primitive) will be blank, unless there is a good reason to put something in there. This is quite typical MOBYesque behaviour. M On Wed, 2005-05-25 at 15:15 +0100, Martin Senger wrote: > > No. Just like any other object, the namespace and id are associated > > with whichever object is most appropriate, and may be blank. Nothing > > has changed in that regard. > > > Generally speaking, you are right. > But I was not speaking generally, I was referring to the case when we > convert a current object (that inherits from a primitive) into a new > object with a primitive type in its HASA. In this case we do not have more > than one 'ns' and 'id' so if we put it into HASA mamber it must be the > same as in the upper level. That's why I said that we have the 'ns' and > 'id' same in two places - and we do not need it I still think. Am I right? > > Martin > From markw at illuminae.com Wed May 25 12:32:54 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed May 25 12:26:00 2005 Subject: [MOBY-dev] a question and a comment about the new Object inheritance Message-ID: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Hi all, So, I just went through and updated all of my services to follow the new Object inheritance system. It took 5 minutes :-) Turns out that most of my services only output "Object" anyway, so they don't need any work, and the ones that output other things like DNASequence and GO_Term were already following the proposed API anyway, so... only TWO of my services actually were affected by the proposed change! I hope that others have the same experience. I did, however, notice a potential hiccup that we didn't foresee at the meeting. At the moment, binary data in MOBY is passed as a child of base-64-encoded, which is a child of String. Under the new system, we can't have children of String, so do we then need a new primitive class for binary data? I think it still needs to be b64 encoded, but it seems to me that it does need its own primitive now. opinions anyone? M From bmg at sfu.ca Wed May 25 21:03:12 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed May 25 20:55:38 2005 Subject: [MOBY-dev] a question and a comment about the new Object inheritance In-Reply-To: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> References: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Message-ID: It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From bmg at sfu.ca Wed May 25 21:03:12 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed May 25 20:55:46 2005 Subject: [MOBY-dev] a question and a comment about the new Object inheritance In-Reply-To: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> References: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Message-ID: It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From markw at illuminae.com Wed May 25 21:05:14 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed May 25 20:58:09 2005 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance Message-ID: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Good idea! The reason they weren't implemented initially was simple lack of need. M -----Original Message----- From: Benjamin Good Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements , markw@illuminae.com Cc:mobydev Subject: Re: [MOBY-dev] a question and a comment about the new Object inheritance It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Wed May 25 21:05:14 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed May 25 20:58:13 2005 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance Message-ID: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Good idea! The reason they weren't implemented initially was simple lack of need. M -----Original Message----- From: Benjamin Good Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements , markw@illuminae.com Cc:mobydev Subject: Re: [MOBY-dev] a question and a comment about the new Object inheritance It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From ywong at infobiogen.fr Thu May 26 04:19:58 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu May 26 04:12:38 2005 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Message-ID: <429586AE.1080306@infobiogen.fr> mark wilkinson wrote: >Good idea! > >The reason they weren't implemented initially was simple lack of need. > >M > >-----Original Message----- >From: Benjamin Good >Date: Wed, 25 May 2005 21:03:12 >To:Core developer announcements , markw@illuminae.com >Cc:mobydev >Subject: Re: [MOBY-dev] a question and a comment about the new Object > inheritance > >It might actually make sense to implement a few more primitives to >facilitate WSDL interoperability. Below see a set of standard >primitives from the Axis user-guide. (Primitives being the things in >the xml message that easily bind to existing Java classes). I wasn't >around when you picked the ones you did, so maybe there are reasons not >to include all of these? > >Standard mappings from WSDL to Java >xsd:base64Binary -> byte[] >xsd:boolean -> boolean >xsd:byte -> byte >xsd:dateTime -> java.util.Calendar >xsd:decimal -> java.math.BigDecimal >xsd:double -> double >xsd:float -> float >xsd:hexBinary -> byte[] >xsd:int -> int >xsd:integer -> java.math.BigInteger >xsd:long -> long >xsd:QName -> javax.xml.namespace.QName >xsd:short -> short >xsd:string -> java.lang.String > >-ben > > > >On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > > > >>Hi all, >> >>So, I just went through and updated all of my services to follow the >>new >>Object inheritance system. It took 5 minutes :-) Turns out that most >>of >>my services only output "Object" anyway, so they don't need any work, >>and the ones that output other things like DNASequence and GO_Term were >>already following the proposed API anyway, so... only TWO of my >>services >>actually were affected by the proposed change! I hope that others have >>the same experience. >> >>I did, however, notice a potential hiccup that we didn't foresee at the >>meeting. At the moment, binary data in MOBY is passed as a child of >>base-64-encoded, which is a child of String. Under the new system, we >>can't have children of String, so do we then need a new primitive class >>for binary data? I think it still needs to be b64 encoded, but it >>seems >>to me that it does need its own primitive now. >> >>opinions anyone? >> >>M >> >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> >> >http://bioinfo.icapture.ubc.ca/bgood >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > >-- >Mark Wilkinson >...on the road! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > Some remarks about Primitives and ontology: First: Do you think that FF is an integer??? If you say no, then you are wrong because FF is a valid hexadecimal REPRESENTATION of an integer number: 255 Reason: The client give the meaning for a message. Forany ordinary human who achieved child school FF is not an integer but for a computer IT CAN BE! Of course it is a bit extreme as an example. We all agree, by convention, that integers are written with Arab figures. In France (I don't know how it is in the rest of Europe) floating numbers are described as 3,1415 instead of 3.1415 (comma instead of point) In this case also, we agree by convention, that floating numbers use the american representation (integer part point fractional part etc..) Did you know that a Unicode string was inherited from a string ??? to display exotic but useful characters that does not exist in English (I don't speak of the strange french characters but also for spanish german etc..)!) and why not Bytes ??? after all a string is an array of bytes so bytes should be the actual primitive (String is an object has Byte) etc.. etc.. In java by default, all strings are unicode strings (AFAIK) but not all language adopted this convention. Primitives are computer related problems. I don't think it is wise to implement primitives inside the ontology because it is not in its place! Primitives were intended to solve problems of performance in language like Java (just see the superb mess between an Integer and an int both speaks about the same mathematical object everybody knows BUT for performance issues, it has been implemented this way poisoning life of millions software enginner and writers - you don't find that kind of issue in other languages -) As I understand from Moby and the ontology of Moby, we should not mix computer related problems with "Business logic" related problems. did you know that in ADA (for strict type checking and overflow control) you can actually subclass an integer in order to define the precision you want in your numbers and it doesn't violate (in any case) the object programming paragdim. For example: subtype Natural is Integer range 0.. Integer'Last; subtype Positive is Integer range 1.. Integer'Last; (I hope no one will have a heart attack on seeing these two lines :p) So if you want to know if an Integer is an integer CAST it (that what I do in Python (for the object mapping with bioMoby XML) ) for example with java use Integer.parse(etc) for Python use int(string) etc.. etc.. These instructions tells the program that the content of the XML is an integer (according to your language convention) I think I have been clear and hope I didn't bash anyone too hard :p From ywong at infobiogen.fr Thu May 26 04:19:58 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu May 26 04:12:49 2005 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Message-ID: <429586AE.1080306@infobiogen.fr> mark wilkinson wrote: >Good idea! > >The reason they weren't implemented initially was simple lack of need. > >M > >-----Original Message----- >From: Benjamin Good >Date: Wed, 25 May 2005 21:03:12 >To:Core developer announcements , markw@illuminae.com >Cc:mobydev >Subject: Re: [MOBY-dev] a question and a comment about the new Object > inheritance > >It might actually make sense to implement a few more primitives to >facilitate WSDL interoperability. Below see a set of standard >primitives from the Axis user-guide. (Primitives being the things in >the xml message that easily bind to existing Java classes). I wasn't >around when you picked the ones you did, so maybe there are reasons not >to include all of these? > >Standard mappings from WSDL to Java >xsd:base64Binary -> byte[] >xsd:boolean -> boolean >xsd:byte -> byte >xsd:dateTime -> java.util.Calendar >xsd:decimal -> java.math.BigDecimal >xsd:double -> double >xsd:float -> float >xsd:hexBinary -> byte[] >xsd:int -> int >xsd:integer -> java.math.BigInteger >xsd:long -> long >xsd:QName -> javax.xml.namespace.QName >xsd:short -> short >xsd:string -> java.lang.String > >-ben > > > >On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > > > >>Hi all, >> >>So, I just went through and updated all of my services to follow the >>new >>Object inheritance system. It took 5 minutes :-) Turns out that most >>of >>my services only output "Object" anyway, so they don't need any work, >>and the ones that output other things like DNASequence and GO_Term were >>already following the proposed API anyway, so... only TWO of my >>services >>actually were affected by the proposed change! I hope that others have >>the same experience. >> >>I did, however, notice a potential hiccup that we didn't foresee at the >>meeting. At the moment, binary data in MOBY is passed as a child of >>base-64-encoded, which is a child of String. Under the new system, we >>can't have children of String, so do we then need a new primitive class >>for binary data? I think it still needs to be b64 encoded, but it >>seems >>to me that it does need its own primitive now. >> >>opinions anyone? >> >>M >> >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> >> >http://bioinfo.icapture.ubc.ca/bgood >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > >-- >Mark Wilkinson >...on the road! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > Some remarks about Primitives and ontology: First: Do you think that FF is an integer??? If you say no, then you are wrong because FF is a valid hexadecimal REPRESENTATION of an integer number: 255 Reason: The client give the meaning for a message. Forany ordinary human who achieved child school FF is not an integer but for a computer IT CAN BE! Of course it is a bit extreme as an example. We all agree, by convention, that integers are written with Arab figures. In France (I don't know how it is in the rest of Europe) floating numbers are described as 3,1415 instead of 3.1415 (comma instead of point) In this case also, we agree by convention, that floating numbers use the american representation (integer part point fractional part etc..) Did you know that a Unicode string was inherited from a string ??? to display exotic but useful characters that does not exist in English (I don't speak of the strange french characters but also for spanish german etc..)!) and why not Bytes ??? after all a string is an array of bytes so bytes should be the actual primitive (String is an object has Byte) etc.. etc.. In java by default, all strings are unicode strings (AFAIK) but not all language adopted this convention. Primitives are computer related problems. I don't think it is wise to implement primitives inside the ontology because it is not in its place! Primitives were intended to solve problems of performance in language like Java (just see the superb mess between an Integer and an int both speaks about the same mathematical object everybody knows BUT for performance issues, it has been implemented this way poisoning life of millions software enginner and writers - you don't find that kind of issue in other languages -) As I understand from Moby and the ontology of Moby, we should not mix computer related problems with "Business logic" related problems. did you know that in ADA (for strict type checking and overflow control) you can actually subclass an integer in order to define the precision you want in your numbers and it doesn't violate (in any case) the object programming paragdim. For example: subtype Natural is Integer range 0.. Integer'Last; subtype Positive is Integer range 1.. Integer'Last; (I hope no one will have a heart attack on seeing these two lines :p) So if you want to know if an Integer is an integer CAST it (that what I do in Python (for the object mapping with bioMoby XML) ) for example with java use Integer.parse(etc) for Python use int(string) etc.. etc.. These instructions tells the program that the content of the XML is an integer (according to your language convention) I think I have been clear and hope I didn't bash anyone too hard :p From bmg at sfu.ca Thu May 26 07:35:17 2005 From: bmg at sfu.ca (Benjamin Good) Date: Thu May 26 07:28:08 2005 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429586AE.1080306@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> Message-ID: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Hi Yan, You make many good points (despite your anti-Java vibe!). The reason that we suggest keeping the primitives in their somewhat strange location within the object ontology is to provide the opportunity for low level services to be discovered in the same manner as all the other services. For example, say we want to post a service that does arithmetic operations or String concatenations or something. If we use the suggested approach, such services can be discovered using exactly the same mechanism that all other services can be discovered. If on the other hand we completely separate these primitives from the ontology, we will have to invent new discovery protocols for handling this use case. You are right, this is a strange beast of an ontology. Its principal purpose is to describe the nature of being a data-type. As such, including descriptions of what it means to be a primitive piece of a data-type does not seem wrong. I think that when we start using a more typical ontology in addition to this one, whose purpose is to describe the nature of the information represented by these data-types, the distinction will be more clear and the real utility of the Object ontology will be made less ambiguous. -Ben On May 26, 2005, at 4:19 AM, Yan Wong wrote: > mark wilkinson wrote: > >> Good idea! >> The reason they weren't implemented initially was simple lack of need. >> >> M >> >> -----Original Message----- >> From: Benjamin Good >> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >> , markw@illuminae.com >> Cc:mobydev >> Subject: Re: [MOBY-dev] a question and a comment about the new Object >> inheritance >> >> It might actually make sense to implement a few more primitives to >> facilitate WSDL interoperability. Below see a set of standard >> primitives from the Axis user-guide. (Primitives being the things in >> the xml message that easily bind to existing Java classes). I wasn't >> around when you picked the ones you did, so maybe there are reasons >> not to include all of these? >> >> Standard mappings from WSDL to Java >> xsd:base64Binary -> byte[] >> xsd:boolean -> boolean >> xsd:byte -> byte >> xsd:dateTime -> java.util.Calendar >> xsd:decimal -> java.math.BigDecimal >> xsd:double -> double >> xsd:float -> float >> xsd:hexBinary -> byte[] >> xsd:int -> int >> xsd:integer -> java.math.BigInteger >> xsd:long -> long >> xsd:QName -> javax.xml.namespace.QName >> xsd:short -> short >> xsd:string -> java.lang.String >> >> -ben >> >> >> >> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> So, I just went through and updated all of my services to follow the >>> new >>> Object inheritance system. It took 5 minutes :-) Turns out that >>> most of >>> my services only output "Object" anyway, so they don't need any work, >>> and the ones that output other things like DNASequence and GO_Term >>> were >>> already following the proposed API anyway, so... only TWO of my >>> services >>> actually were affected by the proposed change! I hope that others >>> have >>> the same experience. >>> >>> I did, however, notice a potential hiccup that we didn't foresee at >>> the >>> meeting. At the moment, binary data in MOBY is passed as a child of >>> base-64-encoded, which is a child of String. Under the new system, >>> we >>> can't have children of String, so do we then need a new primitive >>> class >>> for binary data? I think it still needs to be b64 encoded, but it >>> seems >>> to me that it does need its own primitive now. >>> >>> opinions anyone? >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>> >> http://bioinfo.icapture.ubc.ca/bgood >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> -- >> Mark Wilkinson >> ...on the road! >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > Some remarks about Primitives and ontology: > > First: Do you think that FF is an integer??? > > If you say no, then you are wrong because FF is a valid hexadecimal > REPRESENTATION of an integer number: 255 > > Reason: The client give the meaning for a message. Forany ordinary > human who achieved child school FF is not an integer but for a > computer IT CAN BE! Of course it is a bit extreme as an example. We > all agree, by convention, that integers are written with Arab figures. > > In France (I don't know how it is in the rest of Europe) floating > numbers are described as 3,1415 instead of 3.1415 (comma instead of > point) In this case also, we agree by convention, that floating > numbers use the american representation (integer part point fractional > part etc..) > > Did you know that a Unicode string was inherited from a string ??? to > display exotic but useful characters that does not exist in English (I > don't speak of the strange french characters but also for spanish > german etc..)!) and why not Bytes ??? after all a string is an array > of bytes so bytes should be the actual primitive (String is an object > has Byte) etc.. etc.. In java by default, all strings are unicode > strings (AFAIK) but not all language adopted this convention. > > Primitives are computer related problems. I don't think it is wise to > implement primitives inside the ontology because it is not in its > place! > > Primitives were intended to solve problems of performance in language > like Java (just see the superb mess between an Integer and an int both > speaks about the same mathematical object everybody knows BUT for > performance issues, it has been implemented this way poisoning life of > millions software enginner and writers - you don't find that kind of > issue in other languages -) > > As I understand from Moby and the ontology of Moby, we should not mix > computer related problems with "Business logic" related problems. > > did you know that in ADA (for strict type checking and overflow > control) you can actually subclass an integer in order to define the > precision you want in your numbers and it doesn't violate (in any > case) the object programming paragdim. > > For example: > > subtype Natural is Integer range 0.. Integer'Last; > subtype Positive is Integer range 1.. Integer'Last; > (I hope no one will have a heart attack on seeing these two lines :p) > > So if you want to know if an Integer is an integer CAST it (that what > I do in Python (for the object mapping with bioMoby XML) ) for example > with java use Integer.parse(etc) for Python use int(string) etc.. > etc.. > > These instructions tells the program that the content of the XML is an > integer (according to your language convention) > > I think I have been clear and hope I didn't bash anyone too hard :p > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From bmg at sfu.ca Thu May 26 07:35:17 2005 From: bmg at sfu.ca (Benjamin Good) Date: Thu May 26 07:28:17 2005 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429586AE.1080306@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> Message-ID: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Hi Yan, You make many good points (despite your anti-Java vibe!). The reason that we suggest keeping the primitives in their somewhat strange location within the object ontology is to provide the opportunity for low level services to be discovered in the same manner as all the other services. For example, say we want to post a service that does arithmetic operations or String concatenations or something. If we use the suggested approach, such services can be discovered using exactly the same mechanism that all other services can be discovered. If on the other hand we completely separate these primitives from the ontology, we will have to invent new discovery protocols for handling this use case. You are right, this is a strange beast of an ontology. Its principal purpose is to describe the nature of being a data-type. As such, including descriptions of what it means to be a primitive piece of a data-type does not seem wrong. I think that when we start using a more typical ontology in addition to this one, whose purpose is to describe the nature of the information represented by these data-types, the distinction will be more clear and the real utility of the Object ontology will be made less ambiguous. -Ben On May 26, 2005, at 4:19 AM, Yan Wong wrote: > mark wilkinson wrote: > >> Good idea! >> The reason they weren't implemented initially was simple lack of need. >> >> M >> >> -----Original Message----- >> From: Benjamin Good >> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >> , markw@illuminae.com >> Cc:mobydev >> Subject: Re: [MOBY-dev] a question and a comment about the new Object >> inheritance >> >> It might actually make sense to implement a few more primitives to >> facilitate WSDL interoperability. Below see a set of standard >> primitives from the Axis user-guide. (Primitives being the things in >> the xml message that easily bind to existing Java classes). I wasn't >> around when you picked the ones you did, so maybe there are reasons >> not to include all of these? >> >> Standard mappings from WSDL to Java >> xsd:base64Binary -> byte[] >> xsd:boolean -> boolean >> xsd:byte -> byte >> xsd:dateTime -> java.util.Calendar >> xsd:decimal -> java.math.BigDecimal >> xsd:double -> double >> xsd:float -> float >> xsd:hexBinary -> byte[] >> xsd:int -> int >> xsd:integer -> java.math.BigInteger >> xsd:long -> long >> xsd:QName -> javax.xml.namespace.QName >> xsd:short -> short >> xsd:string -> java.lang.String >> >> -ben >> >> >> >> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> So, I just went through and updated all of my services to follow the >>> new >>> Object inheritance system. It took 5 minutes :-) Turns out that >>> most of >>> my services only output "Object" anyway, so they don't need any work, >>> and the ones that output other things like DNASequence and GO_Term >>> were >>> already following the proposed API anyway, so... only TWO of my >>> services >>> actually were affected by the proposed change! I hope that others >>> have >>> the same experience. >>> >>> I did, however, notice a potential hiccup that we didn't foresee at >>> the >>> meeting. At the moment, binary data in MOBY is passed as a child of >>> base-64-encoded, which is a child of String. Under the new system, >>> we >>> can't have children of String, so do we then need a new primitive >>> class >>> for binary data? I think it still needs to be b64 encoded, but it >>> seems >>> to me that it does need its own primitive now. >>> >>> opinions anyone? >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>> >> http://bioinfo.icapture.ubc.ca/bgood >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> -- >> Mark Wilkinson >> ...on the road! >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > Some remarks about Primitives and ontology: > > First: Do you think that FF is an integer??? > > If you say no, then you are wrong because FF is a valid hexadecimal > REPRESENTATION of an integer number: 255 > > Reason: The client give the meaning for a message. Forany ordinary > human who achieved child school FF is not an integer but for a > computer IT CAN BE! Of course it is a bit extreme as an example. We > all agree, by convention, that integers are written with Arab figures. > > In France (I don't know how it is in the rest of Europe) floating > numbers are described as 3,1415 instead of 3.1415 (comma instead of > point) In this case also, we agree by convention, that floating > numbers use the american representation (integer part point fractional > part etc..) > > Did you know that a Unicode string was inherited from a string ??? to > display exotic but useful characters that does not exist in English (I > don't speak of the strange french characters but also for spanish > german etc..)!) and why not Bytes ??? after all a string is an array > of bytes so bytes should be the actual primitive (String is an object > has Byte) etc.. etc.. In java by default, all strings are unicode > strings (AFAIK) but not all language adopted this convention. > > Primitives are computer related problems. I don't think it is wise to > implement primitives inside the ontology because it is not in its > place! > > Primitives were intended to solve problems of performance in language > like Java (just see the superb mess between an Integer and an int both > speaks about the same mathematical object everybody knows BUT for > performance issues, it has been implemented this way poisoning life of > millions software enginner and writers - you don't find that kind of > issue in other languages -) > > As I understand from Moby and the ontology of Moby, we should not mix > computer related problems with "Business logic" related problems. > > did you know that in ADA (for strict type checking and overflow > control) you can actually subclass an integer in order to define the > precision you want in your numbers and it doesn't violate (in any > case) the object programming paragdim. > > For example: > > subtype Natural is Integer range 0.. Integer'Last; > subtype Positive is Integer range 1.. Integer'Last; > (I hope no one will have a heart attack on seeing these two lines :p) > > So if you want to know if an Integer is an integer CAST it (that what > I do in Python (for the object mapping with bioMoby XML) ) for example > with java use Integer.parse(etc) for Python use int(string) etc.. > etc.. > > These instructions tells the program that the content of the XML is an > integer (according to your language convention) > > I think I have been clear and hope I didn't bash anyone too hard :p > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From ywong at infobiogen.fr Thu May 26 11:04:17 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu May 26 10:56:36 2005 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Message-ID: <4295E571.5040602@infobiogen.fr> Benjamin Good wrote: > Hi Yan, > > You make many good points (despite your anti-Java vibe!). The reason > that we suggest keeping the primitives in their somewhat strange > location within the object ontology is to provide the opportunity for > low level services to be discovered in the same manner as all the > other services. For example, say we want to post a service that does > arithmetic operations or String concatenations or something. If we use > the suggested approach, such services can be discovered using exactly > the same mechanism that all other services can be discovered. If on > the other hand we completely separate these primitives from the > ontology, we will have to invent new discovery protocols for handling > this use case. > > You are right, this is a strange beast of an ontology. Its principal > purpose is to describe the nature of being a data-type. As such, > including descriptions of what it means to be a primitive piece of a > data-type does not seem wrong. I think that when we start using a more > typical ontology in addition to this one, whose purpose is to describe > the nature of the information represented by these data-types, the > distinction will be more clear and the real utility of the Object > ontology will be made less ambiguous. > > -Ben > > > On May 26, 2005, at 4:19 AM, Yan Wong wrote: > >> mark wilkinson wrote: >> >>> Good idea! >>> The reason they weren't implemented initially was simple lack of need. >>> >>> M >>> >>> -----Original Message----- >>> From: Benjamin Good >>> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >>> , markw@illuminae.com >>> Cc:mobydev >>> Subject: Re: [MOBY-dev] a question and a comment about the new Object >>> inheritance >>> >>> It might actually make sense to implement a few more primitives to >>> facilitate WSDL interoperability. Below see a set of standard >>> primitives from the Axis user-guide. (Primitives being the things in >>> the xml message that easily bind to existing Java classes). I wasn't >>> around when you picked the ones you did, so maybe there are reasons >>> not to include all of these? >>> >>> Standard mappings from WSDL to Java >>> xsd:base64Binary -> byte[] >>> xsd:boolean -> boolean >>> xsd:byte -> byte >>> xsd:dateTime -> java.util.Calendar >>> xsd:decimal -> java.math.BigDecimal >>> xsd:double -> double >>> xsd:float -> float >>> xsd:hexBinary -> byte[] >>> xsd:int -> int >>> xsd:integer -> java.math.BigInteger >>> xsd:long -> long >>> xsd:QName -> javax.xml.namespace.QName >>> xsd:short -> short >>> xsd:string -> java.lang.String >>> >>> -ben >>> >>> >>> >>> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >>> >>> >>>> Hi all, >>>> >>>> So, I just went through and updated all of my services to follow >>>> the new >>>> Object inheritance system. It took 5 minutes :-) Turns out that >>>> most of >>>> my services only output "Object" anyway, so they don't need any work, >>>> and the ones that output other things like DNASequence and GO_Term >>>> were >>>> already following the proposed API anyway, so... only TWO of my >>>> services >>>> actually were affected by the proposed change! I hope that others have >>>> the same experience. >>>> >>>> I did, however, notice a potential hiccup that we didn't foresee at >>>> the >>>> meeting. At the moment, binary data in MOBY is passed as a child of >>>> base-64-encoded, which is a child of String. Under the new system, we >>>> can't have children of String, so do we then need a new primitive >>>> class >>>> for binary data? I think it still needs to be b64 encoded, but it >>>> seems >>>> to me that it does need its own primitive now. >>>> >>>> opinions anyone? >>>> >>>> M >>>> >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev@biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >>> http://bioinfo.icapture.ubc.ca/bgood >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> -- >>> Mark Wilkinson >>> ...on the road! >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> Some remarks about Primitives and ontology: >> >> First: Do you think that FF is an integer??? >> >> If you say no, then you are wrong because FF is a valid hexadecimal >> REPRESENTATION of an integer number: 255 >> >> Reason: The client give the meaning for a message. Forany ordinary >> human who achieved child school FF is not an integer but for a >> computer IT CAN BE! Of course it is a bit extreme as an example. We >> all agree, by convention, that integers are written with Arab figures. >> >> In France (I don't know how it is in the rest of Europe) floating >> numbers are described as 3,1415 instead of 3.1415 (comma instead of >> point) In this case also, we agree by convention, that floating >> numbers use the american representation (integer part point >> fractional part etc..) >> >> Did you know that a Unicode string was inherited from a string ??? to >> display exotic but useful characters that does not exist in English >> (I don't speak of the strange french characters but also for spanish >> german etc..)!) and why not Bytes ??? after all a string is an array >> of bytes so bytes should be the actual primitive (String is an object >> has Byte) etc.. etc.. In java by default, all strings are unicode >> strings (AFAIK) but not all language adopted this convention. >> >> Primitives are computer related problems. I don't think it is wise to >> implement primitives inside the ontology because it is not in its place! >> >> Primitives were intended to solve problems of performance in language >> like Java (just see the superb mess between an Integer and an int >> both speaks about the same mathematical object everybody knows BUT >> for performance issues, it has been implemented this way poisoning >> life of millions software enginner and writers - you don't find that >> kind of issue in other languages -) >> >> As I understand from Moby and the ontology of Moby, we should not mix >> computer related problems with "Business logic" related problems. >> >> did you know that in ADA (for strict type checking and overflow >> control) you can actually subclass an integer in order to define the >> precision you want in your numbers and it doesn't violate (in any >> case) the object programming paragdim. >> >> For example: >> >> subtype Natural is Integer range 0.. Integer'Last; >> subtype Positive is Integer range 1.. Integer'Last; >> (I hope no one will have a heart attack on seeing these two lines :p) >> >> So if you want to know if an Integer is an integer CAST it (that what >> I do in Python (for the object mapping with bioMoby XML) ) for >> example with java use Integer.parse(etc) for Python use int(string) >> etc.. etc.. >> >> These instructions tells the program that the content of the XML is >> an integer (according to your language convention) >> >> I think I have been clear and hope I didn't bash anyone too hard :p >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > http://bioinfo.icapture.ubc.ca/bgood > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > I know that we must provide data type descriptions of a biological object. but the fact is that we must try to match the biological logic" as much as possible. Maybe one solution would be to link the "computer logic" (represented by datatypes) with the biological logic (represented by the ontology objects) However putting all the "computer related" informations inside the ontology is not a good idea. The ontology should remain the most "biological" as possible. There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? . So something like that could emerge: DNA Sequence associated with FASTA, EMBL, etc.. FASTA EMBL FASTA, EMBL, GFF and so on would be in another ontology (more specific to bioinformatic/computers) The idea is to clearly separate the "biological" logic and the "computer related" logic. So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." A biological object of the ontology could be linked to a (or several) data types thus low level operations (or better computer related services/operations) could be discovered in the same way as biological services. We would have biological ontology<-> bioinformatic ontology relationships that would map the biological logic to the computer logic. PS: The fact is I am not anti Java (as a language) after all, I used it every day since the Beta version (Oak for who can still remember the prehistoric details of Java :p who was designed to be a OS for your microwave oven ahahaha) However I still have a lot of frustrations on the java API because this stuff is a real nightmare and was the main drawback of Java for several years (try to implement a simple spreadsheet with Swing and you'll know what I mean all other GUI language beat Java 100% of the time. A dumber example: Do you remember what classes needed to open a file? I still need to copy paste my code pattern!) And I like Java for its philosophy: Code once, execute many (even if people, most of the time, do Java programming for Windows (95/98/NT/2000/XP) Multi plateform ahahaha) From markw at illuminae.com Thu May 26 11:29:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu May 26 11:25:11 2005 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <4295E571.5040602@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> <4295E571.5040602@infobiogen.fr> Message-ID: <1117121384.27775.70.camel@mobycentral.mrl.ubc.ca> Wow... what a discussion! I have to throw in my $0.02 I think the Object ontology is "logically" correct exactly as it stands. It describes the structure of the objects to a machine, while giving some human-intuitive sense of what the object is supposed to represent by using a human-intuitive name. Ben would argue (correct me if I get this wrong) that it is inappropriate to define particular *types* of strings in the object ontology because this goes over the line of conflating structure with semantics. I tend to disagree - a FASTA file is a particular type of file format, and it is that *format* that we are describing (i.e. the structure of the string) not its actual content or meaning. As such, it doesn't bother me one little bit that we inherit from String. And, as Yan points out, if you want to know if an Object is a String or an Int, then ask it - the inheritance will tell you. It strikes me that it is only laziness that creates the "need" not to inherit from the primitives; i.e. that it is simply easier to know if you have a primitive in-hand if the object in-hand is of a primitive type "by name", rather than a child of a primitive type where yo have to look-up its parentage. Inheriting from Primitives also solves a number of other problems v.v. rendering and such, but I don't want the utility to override the architecture, so I'll leave that discussion out of it. My *only* objection to the way things are today is that the serialization of derivative objects from primitives can end up having mixtures of XML and text as child nodes in the XML. This is widely considered "bad practice" (though not "illegal"), and it makes me a bit queasy in my stomach every time I see it. Nevertheless, this problem can be solved in ways other than preventing inheritance from primitives! Let's get to the root of the problem. Is the Java community (I finger you because you are the ones who are reporting this as a problem) really objecting to inheritance from primitives, or are you objecting to the way we serialize the ontology? I tried to type examples of both new solutions at the meeting, but neither of them seemed acceptable to anyone, so I gave up... I remain unconvinced. I agree that the serialization we have now is somewhat ugly in some cases, but creating a special class of Objects is even worse! If we can solve the Java programmers problem by serializing objects like this: content here then perhaps that's what we should do in preference to creating special types of Objects that wrap primitives but cannot have child types. ??? Mark From senger at ebi.ac.uk Thu May 26 11:50:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu May 26 11:42:17 2005 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1117121384.27775.70.camel@mobycentral.mrl.ubc.ca> Message-ID: Well, I myself is not the main player in this dicussion about inheriting from primitives but as far as I understand, this: > > content here > > is what everybody wanted in the meeting (the name "String" is arbitrary, the name "string" is mandatory). But maybe I am wrong. Cheers, 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 Fri May 27 11:48:14 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri May 27 11:40:24 2005 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: References: Message-ID: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > Well, I myself is not the main player in this dicussion about inheriting > from primitives but as far as I understand, this: > > > > > content here > > > > > is what everybody wanted in the meeting Ummmm... I think there was a lot of disagreement about what "everybody" wanted... By the looks of it now, everybody wanted something different, but were calling it the same thing :-) Unfortunately, when I asked for some example objects, nobody volunteered, so we couldn't sort it out at the time. I remember vividly, however, that when I tried to write that (above XML) on the screen, the room erupted in screams that I was making it all too complicated, so I don't think that is what people wanted. It may be that we have all had time to digest the issue a bit more deeply now and have come to the same conclusion? M From ywong at infobiogen.fr Fri May 27 13:55:18 2005 From: ywong at infobiogen.fr (ywong@infobiogen.fr) Date: Fri May 27 13:47:41 2005 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> References: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> Message-ID: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >> Well, I myself is not the main player in this dicussion about inheriting >> from primitives but as far as I understand, this: >> >> > >> > content here >> > >> > >> is what everybody wanted in the meeting > > Ummmm... I think there was a lot of disagreement about what "everybody" > wanted... By the looks of it now, everybody wanted something different, > but were calling it the same thing :-) Unfortunately, when I asked for > some example objects, nobody volunteered, so we couldn't sort it out at > the time. > > I remember vividly, however, that when I tried to write that (above XML) > on the screen, the room erupted in screams that I was making it all too > complicated, so I don't think that is what people wanted. It may be > that we have all had time to digest the issue a bit more deeply now and > have come to the same conclusion? > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Sorry I could reply earlier, all our network is in a quagmire... An alternative I would accept: blablablablablablalbalbalblablalbalba An attribute is optional, we keep the actual version without killing everything (adding a subnode and all serializers/deserializers would have to be rewritten!) People using Java will know what is the type of the data by reading this attribute. If it doesn't exist, they should assume that by default, it is a string. Example of DNASequence: ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... 152 Then we should agree of what "primitives" we have: -string -float -int maybe are there others? It is a quick and dirty solution however it is IMHO cleaner than what I saw in the last example. It has the advantage to keep the "old" object layout but add informations that will greatly help people who implements type sensible clients. Greetings Yan From edward.kawas at gmail.com Fri May 27 14:06:38 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri May 27 13:58:53 2005 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> Message-ID: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> I like Yans idea, but what happens if the object doesn't inherit from String, isn't an int or a float? What if the object was a schematikonMotifID that inherits from SchematikonSegmentID that inherits from Object. What would the data:type be in this case? Ed > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of > ywong@infobiogen.fr > Sent: Friday, May 27, 2005 10:55 AM > To: markw@illuminae.com; Core developer announcements > Subject: Re: [moby] Re: [MOBY-dev] a question and a > comment about the new Objectinheritance > > > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > >> Well, I myself is not the main player in this dicussion > about inheriting > >> from primitives but as far as I understand, this: > >> > >> > > >> > content here > >> > > >> > > >> is what everybody wanted in the meeting > > > > Ummmm... I think there was a lot of disagreement about > what "everybody" > > wanted... By the looks of it now, everybody wanted > something different, > > but were calling it the same thing :-) Unfortunately, > when I asked for > > some example objects, nobody volunteered, so we couldn't > sort it out at > > the time. > > > > I remember vividly, however, that when I tried to write > that (above XML) > > on the screen, the room erupted in screams that I was > making it all too > > complicated, so I don't think that is what people wanted. > It may be > > that we have all had time to digest the issue a bit more > deeply now and > > have come to the same conclusion? > > > > M > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > Sorry I could reply earlier, all our network is in a > quagmire... > > An alternative I would accept: > > > blablablablablablalbalbalblablalbalba > > > An attribute is optional, we keep the actual version > without killing > everything (adding a subnode and all > serializers/deserializers would > have to be rewritten!) > > People using Java will know what is the type of the data > by reading this > attribute. If it doesn't exist, they should assume that by > default, it > is a string. > > Example of DNASequence: > > > > > ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... > > data:type="int">152 > > > Then we should agree of what "primitives" we have: > -string > -float > -int > > maybe are there others? > > It is a quick and dirty solution however it is IMHO > cleaner than what I > saw in the last example. It has the advantage to keep the > "old" object > layout but add informations that will greatly help people > who implements > type sensible clients. > > Greetings > > Yan > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri May 27 14:49:14 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri May 27 14:41:26 2005 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> References: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> Message-ID: <1117219754.30771.33.camel@mobycentral.mrl.ubc.ca> I guess it would be type='null' or something like that. I agree that this is the only case where Yan's proposal breaks. We do, actually, have quite a few Objects that inherit from Object without going through a primitive, and therefore have no content at all and should not be assumed to default to type="sting" I don't think we can (nor should) require that our final solution doesn't break anything. It is more important to get it right in the 1.0 spec than to salvage legacy services. As such, I'm not so concerned about having a default state - if we are going to go this route, then I think it should be a requirement to have a type='' attribute. The other advantage of Yan's solution is that it is much more XML-like, and we can use the XML type attributes exactly as they are! I like that!! How do the Java crowd feel about this? M On Fri, 2005-05-27 at 11:06 -0700, Eddie Kawas wrote: > I like Yans idea, but what happens if the object doesn't > inherit from String, isn't an int or a float? What if the > object was a schematikonMotifID that inherits from > SchematikonSegmentID that inherits from Object. What would > the data:type be in this case? > > > > > > Ed > > > > > -----Original Message----- > > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > > dev-bounces@portal.open-bio.org] On Behalf Of > > ywong@infobiogen.fr > > Sent: Friday, May 27, 2005 10:55 AM > > To: markw@illuminae.com; Core developer announcements > > Subject: Re: [moby] Re: [MOBY-dev] a question and a > > comment about the new Objectinheritance > > > > > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > > >> Well, I myself is not the main player in this dicussion > > about inheriting > > >> from primitives but as far as I understand, this: > > >> > > >> > > > >> > content here > > >> > > > >> > > > >> is what everybody wanted in the meeting > > > > > > Ummmm... I think there was a lot of disagreement about > > what "everybody" > > > wanted... By the looks of it now, everybody wanted > > something different, > > > but were calling it the same thing :-) Unfortunately, > > when I asked for > > > some example objects, nobody volunteered, so we couldn't > > sort it out at > > > the time. > > > > > > I remember vividly, however, that when I tried to write > > that (above XML) > > > on the screen, the room erupted in screams that I was > > making it all too > > > complicated, so I don't think that is what people > wanted. > > It may be > > > that we have all had time to digest the issue a bit more > > deeply now and > > > have come to the same conclusion? > > > > > > M > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev@biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Sorry I could reply earlier, all our network is in a > > quagmire... > > > > An alternative I would accept: > > > > > > blablablablablablalbalbalblablalbalba > > > > > > An attribute is optional, we keep the actual version > > without killing > > everything (adding a subnode and all > > serializers/deserializers would > > have to be rewritten!) > > > > People using Java will know what is the type of the data > > by reading this > > attribute. If it doesn't exist, they should assume that by > > default, it > > is a string. > > > > Example of DNASequence: > > > > > > > > > > ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... > > > > > data:type="int">152 > > > > > > Then we should agree of what "primitives" we have: > > -string > > -float > > -int > > > > maybe are there others? > > > > It is a quick and dirty solution however it is IMHO > > cleaner than what I > > saw in the last example. It has the advantage to keep the > > "old" object > > layout but add informations that will greatly help people > > who implements > > type sensible clients. > > > > Greetings > > > > Yan > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri May 27 15:05:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri May 27 14:58:06 2005 Subject: [MOBY-dev] Notes from working group 'B' Message-ID: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> Hi all, Unfortunately, all of my notes from my working group at the MOBY meeting were stolen along with my laptop just a few days after the meeting ended. I have tried to recall everything that we decided, and I compile it below. If I have made any errors, or forgotten anything, please post to the list. Report from Working Group B Issues: Registry mirrors, Service mirrors, Async services, Service testing metadata, standardized LSID provision Decisions: Registry Mirrors registry mirroring will be accomplished by synchronizing the SignatureURL?s among a set of registries. Each registry will have an agent that can (at its discretion) visit any or all of the signature URL?s to retrieve the service signatures and update its own registry. Someone ____________ is going to look into the various ways of synchronizing this list (LDAP, DNS, other?) Service Mirrors Mark will change the MOBY Central API such that multiple endponts can be registered/returned in a service search. This will affect the registerService and findService API calls. The implication of registering multiple endpoints is that the *identical* service is running in all indicated locations, with the same database and same software version. These endpoints all share the same Service Signature metadata, so they had better be identical! Async services a few details have to be worked out (I think the Spanish contingent took on the task of fleshing this out completely), but the upshot is that, when a service is registered, it will be assumed to have four ?method? calls: 1) The name of the service (e.g. doBlastAnalysis) 2) The name with _async appended (e.g. doBlastAnalysis_async) 3) The name with _poll appended (e.g. doBlastAnalysis_poll) 4) The name with _result appended (e.g. doBlastAnalyis_result) The service registration is identical to what it is now, methods 2,3,4 are optional and are not explicitly registered. (the ability of a service to run asynchronously can be determined by querying the RDF metadata through LSID resolution predicates TBD). Calling the service by name executes the service synchronously exactly as it does currently. If a service refuses to run synchronously, it returns an empty response (this is a valid behaviour, and will not break ?old? clients). Calling the xxx_async method will return a MOBY Object representing a ?ticket?- the namespace should be unique to your async service. The ticket can be used to poll the service using the xxx_poll method (API TBD) , and the same ticket can be used to retrieve the result using the xxx_result method. Service Testing Metadata it was generally agreed that it is desirable to have a sample input such that a service can be tested. This will be made available by the service providers as a string literal in their Service Signature (this is retrieved by LSID resolution). The string should be a complete MOBY message (?..) representing a sample input to that service that will ALWAYS work; where ?work? means generate an output of the Object type registered in the Service Signature and in MOBY Central. This input is to be used for testing that a service is running, but not for validating the output. Standardized LSID provision I have updated the online API documents to show how LSID?s will be derived from MOBY Central messages. Generally speaking, in the response message from MOBY Central, any XML tag whose content represents an entry in one of the ontologies, or a service instance, will have an attribute lsid=?nnn?, where nnn can be resolved to metadata describing that entity. For the MOBY Ontologies, this metadata is the RDF describing the ontology node. For service signatures, this metadata is the RDF of the service signature (taken as a GET directly from the service providers machine through the usual LSID resolution process using their registered SignatureURL as the GET URL). As soon as I get a few minutes free I will implement this new part of the API. I?m sure there are things I have missed? please make your additions and comments to the list. From ywong at infobiogen.fr Fri May 27 15:43:10 2005 From: ywong at infobiogen.fr (ywong@infobiogen.fr) Date: Fri May 27 15:35:21 2005 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> References: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> Message-ID: <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> > I like Yans idea, but what happens if the object doesn't > inherit from String, isn't an int or a float? What if the > object was a schematikonMotifID that inherits from > SchematikonSegmentID that inherits from Object. What would > the data:type be in this case? > > > > > > Ed > > > >> -----Original Message----- >> From: moby-dev-bounces@portal.open-bio.org [mailto:moby- >> dev-bounces@portal.open-bio.org] On Behalf Of >> ywong@infobiogen.fr >> Sent: Friday, May 27, 2005 10:55 AM >> To: markw@illuminae.com; Core developer announcements >> Subject: Re: [moby] Re: [MOBY-dev] a question and a >> comment about the new Objectinheritance >> >> > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >> >> Well, I myself is not the main player in this dicussion >> about inheriting >> >> from primitives but as far as I understand, this: >> >> >> >> > >> >> > content here >> >> > >> >> > >> >> is what everybody wanted in the meeting >> > >> > Ummmm... I think there was a lot of disagreement about >> what "everybody" >> > wanted... By the looks of it now, everybody wanted >> something different, >> > but were calling it the same thing :-) Unfortunately, >> when I asked for >> > some example objects, nobody volunteered, so we couldn't >> sort it out at >> > the time. >> > >> > I remember vividly, however, that when I tried to write >> that (above XML) >> > on the screen, the room erupted in screams that I was >> making it all too >> > complicated, so I don't think that is what people > wanted. >> It may be >> > that we have all had time to digest the issue a bit more >> deeply now and >> > have come to the same conclusion? >> > >> > M >> > >> > >> > _______________________________________________ >> > MOBY-dev mailing list >> > MOBY-dev@biomoby.org >> > http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> Sorry I could reply earlier, all our network is in a >> quagmire... >> >> An alternative I would accept: >> >> >> blablablablablablalbalbalblablalbalba >> >> >> An attribute is optional, we keep the actual version >> without killing >> everything (adding a subnode and all >> serializers/deserializers would >> have to be rewritten!) >> >> People using Java will know what is the type of the data >> by reading this >> attribute. If it doesn't exist, they should assume that by >> default, it >> is a string. >> >> Example of DNASequence: >> >> >> >> >> ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... >> >> > data:type="int">152 >> >> >> Then we should agree of what "primitives" we have: >> -string >> -float >> -int >> >> maybe are there others? >> >> It is a quick and dirty solution however it is IMHO >> cleaner than what I >> saw in the last example. It has the advantage to keep the >> "old" object >> layout but add informations that will greatly help people >> who implements >> type sensible clients. >> >> Greetings >> >> Yan >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Simple: data:type only apply to the content of the tag if it exists so: The line above means that the content of Object (here nothing) should be an integer, but it is void so the line above describes an invalid integer... no data:type attribute and no content so we should deal this object as we did before. 152 no data:type but a content, so the client must treat the content as a string 152 the data:type indicates that the content is an integer. From markw at illuminae.com Fri May 27 15:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri May 27 15:49:12 2005 Subject: [MOBY-dev] weeding out the "dead" services Message-ID: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Hi all, so, it's about time we finally switch this RDF Agent on... again... :-) As we did last time, can I request that you visit the RDF Signature Generator (http://mobycentral.cbr.nrc.ca:8090/servlets/forms/getSignatureForm) retrieve your Service Signatures, then make them available at whatever signatureURL you indicate on that web form. Running the RDF Signature Generator more than once will simply over- write your signature URL with whatever new signature URL you enter, so it is perfectly safe to do this. Thanks! M From simont at mcw.edu Fri May 27 16:23:41 2005 From: simont at mcw.edu (Twigger Simon) Date: Fri May 27 16:17:30 2005 Subject: [MOBY-dev] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> References: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Message-ID: Hi Mark, Just so I understand how this should work: I can go to the form, select my domain, leave the instance name field blank so I get every service, fill in a signature URL (should this point to a directory or to a file?) and click Submit. Back comes the RDF which I move to the location specified in the signature URL and then I can throw away all the old signature files with a clean conscience? I was hoping I could leave the service instance blank, specify one file name in the signature URL and then that would give me back one RDF document for all services so I can just throw that one file on the server and ditch the old files. Is this correct? Simon. On May 27, 2005, at 2:57 PM, Mark Wilkinson wrote: > Hi all, > > so, it's about time we finally switch this RDF Agent on... > again... :-) > > As we did last time, can I request that you visit the RDF Signature > Generator > (http://mobycentral.cbr.nrc.ca:8090/servlets/forms/getSignatureForm) > retrieve your Service Signatures, then make them available at whatever > signatureURL you indicate on that web form. > > Running the RDF Signature Generator more than once will simply over- > write your signature URL with whatever new signature URL you enter, so > it is perfectly safe to do this. > > Thanks! > > M > > > _______________________________________________ > 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 AIM/iChat: simontatmcw From edward.kawas at gmail.com Fri May 27 16:30:02 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri May 27 16:22:25 2005 Subject: [MOBY-dev] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: Message-ID: <4297834d.5b52e37c.787e.ffff930c@mx.gmail.com> Hi, > should this point to a directory or to a file? Points to the rdf *file* returned to you, accessible through the url that you enter. So if you were to enter http://www.mydomin.com/rdfs/myDoc.rdf then you would place the document in /rdfs/ and name the file myDoc.rdf. > I was hoping I could leave the service instance blank, >specify one file name in the signature URL and then that >would give me back one RDF document for all services so I >can just throw that one file on the server and ditch the >old files. Hopefully, this is what happens ;-) Eddie From bmg at sfu.ca Fri May 27 16:42:14 2005 From: bmg at sfu.ca (Benjamin Good) Date: Fri May 27 16:34:33 2005 Subject: [MOBY-dev] 2 ontologies Message-ID: <319d32e74261b6c9a729acd780bd53db@sfu.ca> From Yan: "There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? ." -Ben -> I agree with this thinking and in fact that was what I was trying to suggest. However, I think that you have things reversed in the following statement. Yan: "So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." -> Ben As I understand it, the BioMOBY object ontology is meant to describe data-types, not biological logic. It does a nice job of the former but I would say not the latter. My suggestion is to introduce a separate ontology that does describe the biology of the things represented by the data-types (that would NOT include things like "FASTA formatted sequence"!). I think this may happen by default when moby-central merges with Grimoire/Feta, but this list needs to pay attention! I think that it is very important to rectify this confusion between syntax and semantics as soon as we can. What happens when the tools are written that create bioMoby services automatically from websites get going? I think you will quickly see that the moby object ontology loses any notion of "biological logic" as it rapidly becomes populated by perfectly syntactically valid machine produced Objects - and this is GOOD. We WANT thousands of services in there and they may require thousands of new objects! Its important to keep in mind the underlying goals of these things. The Object ontology exists to ensure interoperability - not integration. To me, that means that I can easily consume any service that uses objects from this ontology and it ensures (only helps actually) that the data types produced by service providers are sensible. These SYNTACTIC problems are solved quite nicely by the Object ontology - regardless of the specific serialization you end up choosing and regardless of the name you give to your objects. The SEMANTIC problems associated with INTEGRATION are different, large and growing and will need different solutions. rant over. -Ben http://bioinfo.icapture.ubc.ca/bgood From markw at illuminae.com Fri May 27 17:03:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri May 27 16:55:09 2005 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: References: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Message-ID: <1117227780.30771.71.camel@mobycentral.mrl.ubc.ca> On Fri, 2005-05-27 at 15:23 -0500, Twigger Simon wrote: > RDF document for all services so I can just throw that one file on > the server and ditch the old files. > > Is this correct? That is correct (if Eddie has done his job properly ;-) ) M From jmfernandez at cnb.uam.es Fri May 27 17:23:19 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXogR29uesOhbGV6?=) Date: Fri May 27 17:19:22 2005 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> Message-ID: <42978FC7.7030805@cnb.uam.es> Hi Mark & the MOBYfiers 8-), > Service Mirrors Mark will change the MOBY Central API such that > multiple endponts can be registered/returned in a service search. This > will affect the registerService and findService API calls. The > implication of registering multiple endpoints is that the *identical* > service is running in all indicated locations, with the same database > and same software version. These endpoints all share the same Service > Signature metadata, so they had better be identical! > Also, I can remember we talked about storing updated QoS information, doesn't it? Thinking on replicated services, each one should have its own QoS information. > > Async services a few details have to be worked out (I think the Spanish > contingent took on the task of fleshing this out completely), but the > upshot is that, when a service is registered, it will be assumed to have > four ?method? calls: > 1) The name of the service (e.g. doBlastAnalysis) > 2) The name with _async appended (e.g. doBlastAnalysis_async) > 3) The name with _poll appended (e.g. doBlastAnalysis_poll) > 4) The name with _result appended (e.g. doBlastAnalyis_result) > > The service registration is identical to what it is now, methods 2,3,4 > are optional and are not explicitly registered. (the ability of a > service to run asynchronously can be determined by querying the RDF > metadata through LSID resolution predicates TBD). Calling the service > by name executes the service synchronously exactly as it does currently. > If a service refuses to run synchronously, it returns an empty response > (this is a valid behaviour, and will not break ?old? clients). Calling > the xxx_async method will return a MOBY Object representing a ?ticket?- > the namespace should be unique to your async service. The ticket can be > used to poll the service using the xxx_poll method (API TBD) , and the > same ticket can be used to retrieve the result using the xxx_result > method. > I have been reading the above description about asynchronous services, and there is at least one loose points. You can imagine an scenario where we have a replicated service, and that service is asynchronous. A client would choose one of them, but it would be technically difficult to assure the obtained ticked is useable in *each* one of the replicated services. INB guys have at least two huge computer facilities, and they are geographically disperse, which makes difficult to share the same job identifier namespace. Therefore, either each replicated service should have its unique namespace or clients should tie to the chosen services at the beginning. > > Service Testing Metadata it was generally agreed that it is desirable > to have a sample input such that a service can be tested. This will be > made available by the service providers as a string literal in their > Service Signature (this is retrieved by LSID resolution). The string > should be a complete MOBY message (?..) representing a > sample input to that service that will ALWAYS work; where ?work? means > generate an output of the Object type registered in the Service > Signature and in MOBY Central. This input is to be used for testing > that a service is running, but not for validating the output. > Please, don't forget detailed textual descriptions of the services (long description, input & output parameters, examples, external & internal links), objects (long description, what it means each HAS and HASA element, examples, links), and perhaps namespaces, as they should have their place in RDF. Providers are the only responsible to fill these optional, but useful, information fields/tags. Have a nice weekend, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From r.bruskiewich at cgiar.org Sun May 29 20:00:23 2005 From: r.bruskiewich at cgiar.org (Bruskiewich, Richard (IRRI)) Date: Sun May 29 19:52:45 2005 Subject: [MOBY-dev] RE: [MOBY-l] 2 ontologies Message-ID: <2A491C94FFBC5843A212A69CBEA5CEC7021FBC9F@IRRIMAIL.IRRI.CGIARAD.ORG> If by "biological logic" you mean *real* semantics, then I would hazard to say that the domain modeling activity of the Generation Challenge Programme is going in that direction, at least, for crop/plant science (though some of the semantics is generic to all biology, of necessity). It is interesting to note that human beings construct domain models, not machines. Domain models cannot be autogenerated. Real semantics is what sets human beings apart from (practically) the rest of the animal kingdom, let alone, the stupid (but ultra fast) machines that we've created in this era. Richard "Daisy, daaaissy, ...." -----Original Message----- From: Benjamin Good [mailto:bmg@sfu.ca] Sent: Saturday, 2005 May 28 4:42 AM To: mobydev; mobyl Subject: [MOBY-l] 2 ontologies From Yan: "There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? ." -Ben -> I agree with this thinking and in fact that was what I was trying to suggest. However, I think that you have things reversed in the following statement. Yan: "So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." -> Ben As I understand it, the BioMOBY object ontology is meant to describe data-types, not biological logic. It does a nice job of the former but I would say not the latter. My suggestion is to introduce a separate ontology that does describe the biology of the things represented by the data-types (that would NOT include things like "FASTA formatted sequence"!). I think this may happen by default when moby-central merges with Grimoire/Feta, but this list needs to pay attention! I think that it is very important to rectify this confusion between syntax and semantics as soon as we can. What happens when the tools are written that create bioMoby services automatically from websites get going? I think you will quickly see that the moby object ontology loses any notion of "biological logic" as it rapidly becomes populated by perfectly syntactically valid machine produced Objects - and this is GOOD. We WANT thousands of services in there and they may require thousands of new objects! Its important to keep in mind the underlying goals of these things. The Object ontology exists to ensure interoperability - not integration. To me, that means that I can easily consume any service that uses objects from this ontology and it ensures (only helps actually) that the data types produced by service providers are sensible. These SYNTACTIC problems are solved quite nicely by the Object ontology - regardless of the specific serialization you end up choosing and regardless of the name you give to your objects. The SEMANTIC problems associated with INTEGRATION are different, large and growing and will need different solutions. rant over. -Ben http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ moby-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l From Pieter.Neerincx at wur.nl Mon May 30 05:55:40 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon May 30 05:48:06 2005 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> References: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> Message-ID: <2fc226a7fb27830bbeeef667b47a0ce3@wur.nl> On 27 May, 2005, at 21:43, ywong@infobiogen.fr wrote: >> I like Yans idea, but what happens if the object doesn't >> inherit from String, isn't an int or a float? What if the >> object was a schematikonMotifID that inherits from >> SchematikonSegmentID that inherits from Object. What would >> the data:type be in this case? >> >> >> >> >> >> Ed >> >> >> >>> -----Original Message----- >>> From: moby-dev-bounces@portal.open-bio.org [mailto:moby- >>> dev-bounces@portal.open-bio.org] On Behalf Of >>> ywong@infobiogen.fr >>> Sent: Friday, May 27, 2005 10:55 AM >>> To: markw@illuminae.com; Core developer announcements >>> Subject: Re: [moby] Re: [MOBY-dev] a question and a >>> comment about the new Objectinheritance >>> >>>> On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >>>>> Well, I myself is not the main player in this dicussion >>> about inheriting >>>>> from primitives but as far as I understand, this: >>>>> >>>>>> >>>>>> content here >>>>>> >>>>>> >>>>> is what everybody wanted in the meeting >>>> >>>> Ummmm... I think there was a lot of disagreement about >>> what "everybody" >>>> wanted... By the looks of it now, everybody wanted >>> something different, >>>> but were calling it the same thing :-) Unfortunately, >>> when I asked for >>>> some example objects, nobody volunteered, so we couldn't >>> sort it out at >>>> the time. >>>> >>>> I remember vividly, however, that when I tried to write >>> that (above XML) >>>> on the screen, the room erupted in screams that I was >>> making it all too >>>> complicated, so I don't think that is what people >> wanted. >>> It may be >>>> that we have all had time to digest the issue a bit more >>> deeply now and >>>> have come to the same conclusion? >>>> >>>> M >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev@biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>> Sorry I could reply earlier, all our network is in a >>> quagmire... >>> >>> An alternative I would accept: >>> >>> >>> blablablablablablalbalbalblablalbalba >>> >>> >>> An attribute is optional, we keep the actual version >>> without killing >>> everything (adding a subnode and all >>> serializers/deserializers would >>> have to be rewritten!) >>> >>> People using Java will know what is the type of the data >>> by reading this >>> attribute. If it doesn't exist, they should assume that by >>> default, it >>> is a string. >>> >>> Example of DNASequence: >>> >>> >>> >>> >>> ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... >>> >>> >> data:type="int">152 >>> >>> >>> Then we should agree of what "primitives" we have: >>> -string >>> -float >>> -int >>> >>> maybe are there others? >>> >>> It is a quick and dirty solution however it is IMHO >>> cleaner than what I >>> saw in the last example. It has the advantage to keep the >>> "old" object >>> layout but add informations that will greatly help people >>> who implements >>> type sensible clients. >>> >>> Greetings >>> >>> Yan >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > > Simple: > data:type only apply to the content of the tag if it exists so: > > > > The line above means that the content of Object (here nothing) > should be > an integer, but it is void so the line above describes an invalid > integer... > > > > > > > > no data:type attribute and no content so we should deal this object as > we > did before. > > 152 > > no data:type but a content, so the client must treat the content as a > string Like Mark, I really like Yan's proposal for a data:type attribute, but I do think it should not be optional. If the people that use Java have to rely on this attribute to figure out what data type they are parsing, the example object above should be invalid. If 152 would be treated as string by a Java client and as integer by a client written in Perl, parsing BioMOBY data would no longer be language independent and that would be a very bad thing. If we would introduce a data:type attribute, having the element name indicating the same thing is a bit redundant. Furthermore I think it is makes more sense to identify an element based on it's name as compared to having multiple elements with the same name and then using the articleName attribute to figure out what is what. If we have a data:type attribute the element names no longer have to be String, Integer, etc. and we actually completely forget the articleName attribute. This would break a lot of the stuff that is already running though... Cheers, Pieter > > 152 > > the data:type indicates that the content is an integer. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From Pieter.Neerincx at wur.nl Mon May 30 06:14:49 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon May 30 06:09:38 2005 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <42978FC7.7030805@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030805@cnb.uam.es> Message-ID: On 27 May, 2005, at 23:23, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi Mark & the MOBYfiers 8-), > > > >> Service Mirrors Mark will change the MOBY Central API such that >> multiple endponts can be registered/returned in a service search. >> This >> will affect the registerService and findService API calls. The >> implication of registering multiple endpoints is that the *identical* >> service is running in all indicated locations, with the same database >> and same software version. These endpoints all share the same Service >> Signature metadata, so they had better be identical! >> > > Also, I can remember we talked about storing updated QoS information, > doesn't it? Thinking on replicated services, each one should have its > own QoS information. > >> >> Async services a few details have to be worked out (I think the >> Spanish >> contingent took on the task of fleshing this out completely), but the >> upshot is that, when a service is registered, it will be assumed to >> have >> four ?method? calls: >> 1) The name of the service (e.g. doBlastAnalysis) >> 2) The name with _async appended (e.g. doBlastAnalysis_async) >> 3) The name with _poll appended (e.g. doBlastAnalysis_poll) >> 4) The name with _result appended (e.g. doBlastAnalyis_result) >> >> The service registration is identical to what it is now, methods 2,3,4 >> are optional and are not explicitly registered. (the ability of a >> service to run asynchronously can be determined by querying the RDF >> metadata through LSID resolution predicates TBD). Calling the >> service >> by name executes the service synchronously exactly as it does >> currently. >> If a service refuses to run synchronously, it returns an empty >> response >> (this is a valid behaviour, and will not break ?old? clients). >> Calling >> the xxx_async method will return a MOBY Object representing a >> ?ticket?- >> the namespace should be unique to your async service. The ticket can >> be >> used to poll the service using the xxx_poll method (API TBD) , and the >> same ticket can be used to retrieve the result using the xxx_result >> method. >> > > I have been reading the above description about asynchronous services, > and there is at least one loose points. You can imagine an scenario > where we have a replicated service, and that service is asynchronous. A > client would choose one of them, but it would be technically difficult > to assure the obtained ticked is useable in *each* one of the > replicated > services. INB guys have at least two huge computer facilities, and they > are geographically disperse, which makes difficult to share the same > job > identifier namespace. Therefore, either each replicated service should > have its unique namespace or clients should tie to the chosen services > at the beginning. If these replicated services share the same namespace, but are served by different service authorities, then a client can simply bind to a single service by it's authority. A combination if service name, service authority and job ID / ticket should be enough to poll a service and get the result back from the same service. Or is too simple and am I missing something... > >> >> Service Testing Metadata it was generally agreed that it is desirable >> to have a sample input such that a service can be tested. This will >> be >> made available by the service providers as a string literal in their >> Service Signature (this is retrieved by LSID resolution). The string >> should be a complete MOBY message (?..) representing a >> sample input to that service that will ALWAYS work; where ?work? means >> generate an output of the Object type registered in the Service >> Signature and in MOBY Central. This input is to be used for testing >> that a service is running, but not for validating the output. >> > > Please, don't forget detailed textual descriptions of the services > (long > description, input & output parameters, examples, external & internal > links), objects (long description, what it means each HAS and HASA > element, examples, links), and perhaps namespaces, as they should have > their place in RDF. Providers are the only responsible to fill these > optional, but useful, information fields/tags. Yes! That would make life much easier. I am currently testing some stuff where I have an async service that has an additional help call. This service is a wrapper for a commandline tool. If you call the service with an empty Moby object it returns an object "ServiceOptions" which HASA String that contains the info which you would normally get form --help on the commandline along with some info about which databases are available and when they were updated. Putting this kind of info in the service signature would make more sense though. Cheers, Pieter > > Have a nice weekend, > Jos? Mar?a > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Mon May 30 10:00:59 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon May 30 09:53:12 2005 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030805@cnb.uam.es> Message-ID: <429B1C9B.2060105@illuminae.com> > Yes! That would make life much easier. I am currently testing some > stuff where I have an async service that has an additional help call. > This service is a wrapper for a commandline tool. If you call the > service with an empty Moby object it returns an object > "ServiceOptions" which HASA String that contains the info which you > would normally get form --help on the commandline along with some info > about which databases are available and when they were updated. > Putting this kind of info in the service signature would make more > sense though. Would make more sense, and wouldn't break the API ;-) M From jmfernandez at cnb.uam.es Mon May 30 10:48:32 2005 From: jmfernandez at cnb.uam.es (=?windows-1252?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Mon May 30 10:40:43 2005 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca><42978FC7.7030 805@cnb.uam.es> Message-ID: <429B27C0.6070406@cnb.uam.es> Hi everybody, > > If these replicated services share the same namespace, but are served by > different service authorities, then a client can simply bind to a single > service by it's authority. A combination if service name, service > authority and job ID / ticket should be enough to poll a service and get > the result back from the same service. Or is too simple and am I missing > something... > Well, as far as I can remember from the meeting we agreed that replicated services would be declared as non-replicated ones, but with more than one URL, so all of them share the same (authURI,serviceName) pair. Am I wrong, Mark, Heiko, Dirk? -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From markw at illuminae.com Mon May 30 11:10:01 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon May 30 11:02:06 2005 Subject: [moby] Re: [MOBY-dev] Notes from working group 'B' In-Reply-To: <429B27C0.6070406@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> Message-ID: <1117465801.29183.31.camel@mobycentral.mrl.ubc.ca> On Mon, 2005-05-30 at 16:48 +0200, Jos? Mar?a Fern?ndez wrote: > Well, as far as I can remember from the meeting we agreed that > replicated services would be declared as non-replicated ones, but with > more than one URL, so all of them share the same (authURI,serviceName) > pair. Am I wrong, Mark, Heiko, Dirk? That's correct - multiple URL's associated with the same authURI and serviceName. The service metadata can presumably be associated independently with each URL,though we have not yet decided on the predicates/structure we will use. If they are different authorities (this is not the same as saying different URL's) then they have different signatures and are independent registrations in the registry. M -- -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From Pieter.Neerincx at wur.nl Mon May 30 11:30:01 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon May 30 11:24:28 2005 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <429B27C0.6070406@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca><42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> Message-ID: <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> Hello again, On 30 May, 2005, at 16:48, Jos? Mar?a Fern?ndez wrote: > Hi everybody, > > > >> >> If these replicated services share the same namespace, but are served >> by >> different service authorities, then a client can simply bind to a >> single >> service by it's authority. A combination if service name, service >> authority and job ID / ticket should be enough to poll a service and >> get >> the result back from the same service. Or is too simple and am I >> missing >> something... >> > > Well, as far as I can remember from the meeting we agreed that > replicated services would be declared as non-replicated ones, but with > more than one URL, so all of them share the same (authURI,serviceName) > pair. Am I wrong, Mark, Heiko, Dirk? Ok, I wasn't able to attend the meeting, so I definitely missed something :(. Anyway, if replicated services will be declared with multiple URLs for the same (authURI,serviceName) combination, then the combination of (authURI,serviceName,URL) will uniquely identify a service. I don't know about the other APIs but with the current Perl API I can already search for the one service that has such a unique combo. So that should be enough for a client to retrieve results from the same async service to which it submitted a job/query :) Is that correct? Cheers, Pieter > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Mon May 30 11:39:05 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon May 30 11:31:10 2005 Subject: [moby] Re: [MOBY-dev] Notes from working group 'B' In-Reply-To: <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> Message-ID: <1117467545.29183.35.camel@mobycentral.mrl.ubc.ca> On Mon, 2005-05-30 at 17:30 +0200, Pieter Neerincx wrote: > service. I don't know about the other APIs but with the current Perl > API I can already search for the one service that has such a unique > combo. So that should be enough for a client to retrieve results from > the same async service to which it submitted a job/query :) Is that > correct? Actually, I think this is still an issue. At the moment, and under the proposed API, there is no defined way for a client to interact with the same (replicated) service when it calls an async service as it does when it retrieves the result. The burden of remembering which replicated service it called may have to be client-side unless we can come up with a creative alternative. M -- -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From markw at illuminae.com Mon May 30 17:39:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon May 30 17:31:18 2005 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429B758F.5020903@cnb.uam.es> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> Message-ID: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Hiya, We're looking into using mod_jk to do this kind of auto-forwarding of tomcat requests through port 80. I've never done it, and Eddie has only done it on Windows. Once we have played with it a few times and figured out a standard, stable way to do it, we'll add this to the documentation. M On Mon, 2005-05-30 at 22:20 +0200, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi everybody, > I have a different problem. CNB machines are behind a firewall which > doesn't allow a connection to 'strange' ports like 8090 (we have a very > restrictive security policy). I can solve it talking to CNB's sysadmins > (and signing a liability sheet), but it could be an annoyance if we had > to do it for many addresses and/or ports. > > With this annoyance, I'm concerned by those services which live on a > different port from HTTP and HTTPS ones. Those BioMOBY users behind a > firewall (like us) won't be able to use those services, and so they > could think the services are not working. I think we should include some > sort of warning about this potencial problem, and also we should > recommend MOBY service creators to use standard HTTP/HTTPS ports for > their services. > > Best regards, > Jos? Mar?a > > Mark Wilkinson wrote: > > try now. > > > > Sorry about that > > > > M > > > > > > On Wed, 2005-05-18 at 15:07 +0200, David Baux wrote: > > > >>hello, > >>i'd like to use the biomoby tool "Applet to retrieve the RDF Signature > >>of your service" to generate the RDF file of my service. But when I fill > >>in the form with the right Domain and URL, the browser prints: > >> > >> > >> Unable to update your information > >> > >> > >> Make sure that you specify a valid signature url! This field looks > >> like the following: > >> http://myAuthority.domain/path/to/rdf/for/service. Also make sure > >> that you have specified the right case-sensitive service name, if > >> applicable. > >> > >>while the url is: http://tropgenedb.cirad.fr/cgi-bin/biomoby > >> > >>Does somebody know what to do? > >> > >>thanks for your answers > >> > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l@biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l > > > > > -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From tmo at ebi.ac.uk Mon May 30 18:32:58 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon May 30 18:25:06 2005 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429B949A.60101@ebi.ac.uk> Mark Wilkinson wrote: > Hiya, > > We're looking into using mod_jk to do this kind of auto-forwarding of > tomcat requests through port 80. You could do what the EBI does and use the ProxyPass directive in Apache - I don't believe we use any of the mod_jk style connectors at all in our web architecture and it all appears to work well enough. You do occasionally get slightly hard to debug behaviour if something goes wrong but it's a whole lot less hassle to configure and doesn't need any new software. Services we're running such as Martin's SoapLab are exposed like this and it all appears happy. Tom From tmo at ebi.ac.uk Mon May 30 18:32:58 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon May 30 18:25:10 2005 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429B949A.60101@ebi.ac.uk> Mark Wilkinson wrote: > Hiya, > > We're looking into using mod_jk to do this kind of auto-forwarding of > tomcat requests through port 80. You could do what the EBI does and use the ProxyPass directive in Apache - I don't believe we use any of the mod_jk style connectors at all in our web architecture and it all appears to work well enough. You do occasionally get slightly hard to debug behaviour if something goes wrong but it's a whole lot less hassle to configure and doesn't need any new software. Services we're running such as Martin's SoapLab are exposed like this and it all appears happy. Tom From gss at ncgr.org Tue May 31 11:05:32 2005 From: gss at ncgr.org (Gary Schiltz) Date: Tue May 31 11:57:48 2005 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429C7D3C.1050602@ncgr.org> About a year ago, I looked at connecting Tomcat (5.x) and the Apache HTTP Server (2.x) with little success. If I remember correctly, I got it to work under Windows, but could never get the two to talk under Linux (Red Hat 9). One of Lincoln Stein's students suggested Resin (www.caucho.com) as a Servlet container, and it was very easy to get working with Apache. There is an open source version, which seems fine as far as performance goes. I ended up using Resin for the Semantic MOBY site. // Gary Mark Wilkinson wrote: >Hiya, > >We're looking into using mod_jk to do this kind of auto-forwarding of >tomcat requests through port 80. > >I've never done it, and Eddie has only done it on Windows. Once we have >played with it a few times and figured out a standard, stable way to do >it, we'll add this to the documentation. > >M > > > >>> >>> From jmfernandez at cnb.uam.es Tue May 31 14:26:00 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXo=?=) Date: Tue May 31 14:20:51 2005 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429C7D3C.1050602@ncgr.org> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@moby central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org> Message-ID: <429CAC38.5020609@cnb.uam.es> I have been talking to our webmasters about our Apache configuration, and they showed me the way to configure Apache to map Tomcat services. It is like this one: ProxyPass /thePath http://other.machine/otherPath ProxyPassReverse /thePath http://other.machine/otherPath As you can see, you have to write *twice* the equivalence, but with different commands. The first one (ProxyPass) tells Apache that all queries to /thePath and its subpaths should be rewritten as http://other.machine/otherPath (and its subpaths). The second command (ProxyPassReverse) tells Apache that it must work as a reverse proxy for that path, instead of redirecting the queries with a HTTP 305 code. It is obvius ProxyPass/ProxyPassReverse works because current application servers handle HTTP requests. Tomcat 4 and above *must* do that because they follow the 2.3 servlet specification, which tells that the application server must handle and understand HTTP requests. Best Regards, Jos? Mar?a Gary Schiltz wrote: > About a year ago, I looked at connecting Tomcat (5.x) and the Apache > HTTP Server (2.x) with little success. If I remember correctly, I got it > to work under Windows, but could never get the two to talk under Linux > (Red Hat 9). One of Lincoln Stein's students suggested Resin > (www.caucho.com) as a Servlet container, and it was very easy to get > working with Apache. There is an open source version, which seems fine > as far as performance goes. I ended up using Resin for the Semantic MOBY > site. > > // Gary > > Mark Wilkinson wrote: > >> Hiya, >> We're looking into using mod_jk to do this kind of auto-forwarding of >> tomcat requests through port 80. >> >> I've never done it, and Eddie has only done it on Windows. Once we have >> played with it a few times and figured out a standard, stable way to do >> it, we'll add this to the documentation. >> >> M >> >> >> >>>> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From gss at ncgr.org Tue May 31 14:44:39 2005 From: gss at ncgr.org (Gary Schiltz) Date: Tue May 31 14:36:44 2005 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429CAC38.5020609@cnb.uam.es> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@moby central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org> <429CAC38.5020609@cnb.uam.es> Message-ID: <429CB097.3030407@ncgr.org> Thanks Jos? Mar?a for the information on Apache configuration. That approach would work if you want Tomcat to handle everything under a given path, including HTML, images, etc. However, if you want Apache to handle all HTTP requests, including Perl CGI requests, sessions, etc. and only use Tomcat to handle Servlets and JSP, then I believe you still need to use mod_jk, mod_jk2, or a similar adapter. For example, if you have /foo/bigdoc.html, /foo/hugeimage.jpg, and /foo/index.jsp, you would probably want Apache to deliver bigdoc.html and hugeimage.jpg, but would want Apache to delegate execution of index.jsp to Tomcat. Again, I couldn't get this to work under Red Hat 9, so I used Resin, which works very well with Apache. // Gary Jos? Mar?a Fern?ndez wrote: > I have been talking to our webmasters about our Apache configuration, > and they showed me the way to configure Apache to map Tomcat services. > It is like this one: > > ProxyPass /thePath http://other.machine/otherPath > ProxyPassReverse /thePath http://other.machine/otherPath > > As you can see, you have to write *twice* the equivalence, but with > different commands. The first one (ProxyPass) tells Apache that all > queries to /thePath and its subpaths should be rewritten as > http://other.machine/otherPath (and its subpaths). The second command > (ProxyPassReverse) tells Apache that it must work as a reverse proxy for > that path, instead of redirecting the queries with a HTTP 305 code. > > It is obvius ProxyPass/ProxyPassReverse works because current > application servers handle HTTP requests. Tomcat 4 and above *must* do > that because they follow the 2.3 servlet specification, which tells that > the application server must handle and understand HTTP requests. > > Best Regards, > Jos? Mar?a From jmfernandez at cnb.uam.es Tue May 31 15:42:38 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXogR29uesOhbGV6?=) Date: Tue May 31 15:35:14 2005 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429CB097.3030407@ncgr.org> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@mob y central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org><429CAC38.5020609@cnb.uam. es> <429CB097.3030407@ncgr.org> Message-ID: <429CBE2E.2000706@cnb.uam.es> (Mainly offtopic?) Maybe I'm wrong, but Tomcat already does it inside. Apache only forwards the HTTP query, and Tomcat works as expected with JSPs, because it is its default behaviour when any HTTP query arrives (unless you have reconfigured it). JK modules are dedicated to communicate Apache and Tomcat, so Apache serves static content (which does very well) and Tomcat handles dynamic content (servlets, jsps). When you have a heavy used directory with a mixure of static content files/pages and dynamic content and servlets, then Apache+Tomcat+JK is unbeatable, because even if you need it you can apply some load-balancing techniques (one Apache/many Tomcat workers) in an easy way. The advantages of ProxyPass/ProxyPassReverse are the simplicity and the decoupling effect, because Apache and Tomcat can be started, stopped, managed, upgraded, etc..., with no software dependency (no mod_jk2 to be compiled), and each one is free from the other. Old incarnations of JK modules (mod_webapps) had some problems when Tomcat wasn't running on Apache startup, or when Tomcat was restarted (very common two years ago in a Tomcat development environment). I don't know how well is JK implementation, but our webmaster didn't want more problems than the unavoidable ones, so they are using ProxyPass/ProxyPassReverse). Best Regards, Jos? Mar?a Gary Schiltz wrote: > Thanks Jos? Mar?a for the information on Apache configuration. That > approach would work if you want Tomcat to handle everything under a > given path, including HTML, images, etc. However, if you want Apache to > handle all HTTP requests, including Perl CGI requests, sessions, etc. > and only use Tomcat to handle Servlets and JSP, then I believe you still > need to use mod_jk, mod_jk2, or a similar adapter. For example, if you > have /foo/bigdoc.html, /foo/hugeimage.jpg, and /foo/index.jsp, you would > probably want Apache to deliver bigdoc.html and hugeimage.jpg, but would > want Apache to delegate execution of index.jsp to Tomcat. Again, I > couldn't get this to work under Red Hat 9, so I used Resin, which works > very well with Apache. > > // Gary > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From Pieter.Neerincx at wur.nl Mon May 2 11:36:08 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 2 May 2005 17:36:08 +0200 Subject: [MOBY-dev] SQL dump In-Reply-To: <20050419091628.GN17377@parrot.ebi.ac.uk> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> Message-ID: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Hi all, I'm trying to get an SQL dump from the BioMOBY central. I tried MOBY::CLient::Central::DUMP() from the perl API and a raw SOAP call, but all I get is: 500 Internal Server Error. With SOAP::Lite + 'trace' I also get: ...snip... can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. ...snip... For the complete trace see below. Anyone got an idea what I'm missing here? Any feedback would be appreciated. Cheers, Pieter -------------------------------------------------- SOAP::Lite trace: MOBY Central Data Dump: SOAP::Transport::new: () SOAP::Serializer::new: () SOAP::Deserializer::new: () SOAP::Parser::new: () SOAP::Lite::new: () SOAP::Transport::HTTP::Client::new: () SOAP::Lite::call: () SOAP::Serializer::envelope: () SOAP::Serializer::envelope: DUMP SOAP::Data::new: () SOAP::Data::new: () SOAP::Data::new: () SOAP::Data::new: () SOAP::Transport::HTTP::Client::send_receive: HTTP::Request=HASH(0x8475a84) SOAP::Transport::HTTP::Client::send_receive: POST http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl HTTP/1.1 Accept: text/xml Accept: multipart/* Content-Length: 466 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x8628038) SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error Connection: close Date: Mon, 02 May 2005 15:16:45 GMT Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 Content-Length: 600 Content-Type: text/xml; charset=utf-8 Client-Date: Mon, 02 May 2005 15:16:45 GMT Client-Peer: 198.166.4.225:80 Client-Response-Num: 1 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Servercan't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. SOAP::Deserializer::deserialize: () SOAP::Parser::decode: () 500 Internal Server Error at ./GetDumpRawSOAP.pl line 52 SOAP::Lite::DESTROY: () SOAP::Deserializer::DESTROY: () SOAP::Serializer::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Transport::DESTROY: () SOAP::Transport::HTTP::Client::DESTROY: () SOAP::Parser::DESTROY: () From senger at ebi.ac.uk Mon May 2 13:04:21 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 2 May 2005 18:04:21 +0100 (BST) Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: > For the complete trace see below. Anyone got an idea what I'm missing > here? Any feedback would be appreciated. > I can confirm the same problem using Java client. This is what I am sending: POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1 Host: mobycentral.cbr.nrc.ca:9999 Cache-Control: no-cache Pragma: no-cache SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" Content-Length: 402 And I am getting the same error message as with the Perl client: HTTP/1.0 500 Internal Server Error Date: Mon, 02 May 2005 17:03:53 GMT Content-Length: 600 Content-Type: text/xml; charset=utf-8 Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Server can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. Cheers, 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 senger at ebi.ac.uk Mon May 2 13:04:21 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 2 May 2005 18:04:21 +0100 (BST) Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: > For the complete trace see below. Anyone got an idea what I'm missing > here? Any feedback would be appreciated. > I can confirm the same problem using Java client. This is what I am sending: POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1 Host: mobycentral.cbr.nrc.ca:9999 Cache-Control: no-cache Pragma: no-cache SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" Content-Length: 402 And I am getting the same error message as with the Perl client: HTTP/1.0 500 Internal Server Error Date: Mon, 02 May 2005 17:03:53 GMT Content-Length: 600 Content-Type: text/xml; charset=utf-8 Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Server can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. Cheers, 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 Mon May 2 14:11:32 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 02 May 2005 11:11:32 -0700 Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: <42766D54.2060602@illuminae.com> fixed From markw at illuminae.com Mon May 2 14:11:32 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 02 May 2005 11:11:32 -0700 Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: <42766D54.2060602@illuminae.com> fixed From senger at ebi.ac.uk Mon May 2 14:16:32 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 2 May 2005 19:16:32 +0100 (BST) Subject: [MOBY-dev] SQL dump In-Reply-To: <42766D54.2060602@illuminae.com> Message-ID: > fixed > Confirmed. 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 senger at ebi.ac.uk Mon May 2 14:16:32 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 2 May 2005 19:16:32 +0100 (BST) Subject: [MOBY-dev] SQL dump In-Reply-To: <42766D54.2060602@illuminae.com> Message-ID: > fixed > Confirmed. 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 Pieter.Neerincx at wur.nl Tue May 3 07:51:32 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 3 May 2005 13:51:32 +0200 Subject: [MOBY-dev] SQL dump In-Reply-To: References: Message-ID: <818098468df1567f6549a31c365fd008@wur.nl> On 2 May, 2005, at 20:16, Martin Senger wrote: >> fixed >> > Confirmed. > Martin Check, works here again as well with Perl API. Thanx for the fast fix Mark! Cheers, Pieter From senger at ebi.ac.uk Tue May 17 10:36:19 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 17 May 2005 15:36:19 +0100 (BST) Subject: [MOBY-dev] how to get LSID of the registered service In-Reply-To: <1116254505.13769.68.camel@mobycentral.mrl.ubc.ca> Message-ID: Mark, Quite a long time ago we have discussed the inconsistency in the returned names from the registry. Recently Mathieu asked me how to get an LSID of a service (in order to ask for metadata etc.) so I have looked at the names again. It seems that: 1) One cannot get an LSID - using the registry API. The findService method seems to return only the simple service name. 2) The extended API (the rules for getting URLs returning RDF documents) is not yet in place. And more, my pretty old RDF document (so this may not be true anymore) does not show LSIDs either. 3) Regarding the names of data types, the situation is better (because one *can* get an LSID of a data type) - but not consistent: the method retriveObjectNames returns simple names and the method retrieveObjectDefinition returns LSIDs. I think that we should fix/solve/explain this asap. Any plans or suggestions for it? Cheers, Martin PS. It would also help if you explain in BioMoby API an official way how to get these RDF documents. I know that you mentioned that there was "an XML standard way" but I doubt that it was clear to most of us :-). Thanks. M. -- 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 May 17 11:13:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 17 May 2005 08:13:09 -0700 Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: References: Message-ID: <1116342789.19327.21.camel@mobycentral.mrl.ubc.ca> Hi Martin, I've been thinking about that problem quite a bit, actually. I know that the existing system is a bit of a mish-mash, and needs to be cleaned up. My suggested solution is as follows: for every XML tag in an outgoing MOBY Central API message, where the content of the tag is an element in one of the four MOBY ontologies, there should be an attribute lsid='xxx' indicating the LSID corresponding to the human-readable content of the XML tag. e.g. Service_Ontology_Term 1 moby your at email.addy.here http://service.endpoint.here/scriptname ObjectOntologyTerm NamespaceTerm ObjectOntologyTerm NamespaceTerm I suspect that we will eventually need to make the same true for inbound MOBY Central API messages, since we now have distributed ontologies so I cannot be sure if the object named GeneClass is part of the biomoby cenral object ontolgy, or one of the distributed ontologies... and as such, a lookup on that object by its human readable name might be a disaster! On the other hand, the human readable names are so friendly that I think we would be shooting ourselves in the foot if we discarded them altogether... Does that solution suit everyone? Are there any objections? I will be sure to make it entirely consistent such that the LSID is NOT present in the content of the XML tag, but only in the attribute. Let me know if there are any objections to this, and if not, I will try to implement this before next week. M On Tue, 2005-05-17 at 15:36 +0100, Martin Senger wrote: > Mark, > Quite a long time ago we have discussed the inconsistency in the > returned names from the registry. Recently Mathieu asked me how to get an > LSID of a service (in order to ask for metadata etc.) so I have looked at > the names again. It seems that: > > 1) One cannot get an LSID - using the registry API. The findService > method seems to return only the simple service name. > > 2) The extended API (the rules for getting URLs returning RDF > documents) is not yet in place. And more, my pretty old RDF document (so > this may not be true anymore) does not show LSIDs either. > > 3) Regarding the names of data types, the situation is better (because > one *can* get an LSID of a data type) - but not consistent: the method > retriveObjectNames returns simple names and the method > retrieveObjectDefinition returns LSIDs. > > I think that we should fix/solve/explain this asap. Any plans or > suggestions for it? > > Cheers, > Martin > > PS. It would also help if you explain in BioMoby API an official way how > to get these RDF documents. I know that you mentioned that there was "an > XML standard way" but I doubt that it was clear to most of us :-). > Thanks. M. > From senger at ebi.ac.uk Tue May 17 11:39:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 17 May 2005 16:39:31 +0100 (BST) Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: <1116342789.19327.21.camel@mobycentral.mrl.ubc.ca> Message-ID: Hi, > My suggested solution is as follows: for every XML tag in an outgoing > MOBY Central API message, where the content of the tag is an element in > one of the four MOBY ontologies, there should be an attribute lsid='xxx' > indicating the LSID corresponding to the human-readable content of the > XML tag. > This seems quite a good and reasonable solution to me. > I suspect that we will eventually need to make the same true for inbound > MOBY Central API messages, since we now have distributed ontologies so I > cannot be sure if the object named GeneClass is part of the biomoby > cenral object ontolgy, or one of the distributed ontologies... > I know that you keep repeating this, and I keep repeating that it is an implementation detail :-) I truly believe that you are confusing us by talking about various ontologies without changing the Central API. As long as the API does not change we *do not see" any distributed ontologies - so for us, the mortals, there is no difference between "the biomoby central object ontology" and any distributed ontology. Is this true or am I still missing anything? > On the other hand, the human readable names are so friendly that I think > we would be shooting ourselves in the foot if we discarded them > altogether... > Correct, I agree. I think that for inbound messages the simple names are fine. The users can keep the LSIDs only for calling the BioMoby LSID resolution service. That reminds me: is the LSID resolution service already running - or it is a work in progress? > Let me know if there are any objections to this, and if not, I will try > to implement this before next week. > This is a fantastic time plan! Could you perhaps add first the changes into the API document - and let us know - so we can change in advance also our libraries (in jMoby in my case)? Cheers, 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 May 17 11:50:27 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 17 May 2005 08:50:27 -0700 Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: References: Message-ID: <1116345027.19327.42.camel@mobycentral.mrl.ubc.ca> On Tue, 2005-05-17 at 16:39 +0100, Martin Senger wrote: > This seems quite a good and reasonable solution to me. Super - any objections from others? > I know that you keep repeating this, and I keep repeating that it is an > implementation detail :-) I truly believe that you are confusing us by > talking about various ontologies without changing the Central API. As long > as the API does not change we *do not see" any distributed ontologies - so > for us, the mortals, there is no difference between "the biomoby central > object ontology" and any distributed ontology. Is this true or am I still > missing anything? Well... there is the API, and then there is the reality. There are currently 3 MOBY Centrals (that I know about) that are interacting *exclusively* with their local ontologies, despite the fact that this is not officially supported by the API. I grant you that this is "not our problem"... but at the end of the day it IS our problem, since it shows that the behaviour and desire of the community we are serving is to have distributed ontologies. As such, the faster I make the official API compatible with what the user community is already doing, the faster we will all be able to work together again :-) > That reminds me: is the LSID resolution service already running - or it > is a work in progress? It is running - metadata resolution only for Namespaces, Services, Objects, and ServiceInstances. > This is a fantastic time plan! I'm feeling ambitious ;-) > Could you perhaps add first the changes into the API document - and let > us know - so we can change in advance also our libraries (in jMoby in my > case)? OK. Unless I hear any objections over the next day or two I will work on these code changes when I get back from California on Sunday... ...oh... oops! Perhaps it will be delayed longer than that... I forgot that my laptop was stolen last week, so I don't have a way to code from home anymore :-/ (also, all of my notes from the working group session were stolen along with it... if anyone has notes about what was decided can you post them to the list? thanks!) Anyway, I will get the API updated and the code updated ASAP. M From senger at ebi.ac.uk Tue May 17 11:56:34 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 17 May 2005 16:56:34 +0100 (BST) Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: <1116345027.19327.42.camel@mobycentral.mrl.ubc.ca> Message-ID: > As such, the faster I make the official API compatible with what the > user community is already doing, the faster we will all be able to work > together again :-) > That's exactly what I wish to have. I see that you are listening to my "voice in the desert". Thanks. > that my laptop was stolen last week > My condolences - that's must be awfull! Cheers, 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 Thu May 19 15:17:19 2005 From: simont at mcw.edu (Twigger Simon) Date: Thu, 19 May 2005 14:17:19 -0500 Subject: [MOBY-dev] last weeks issue of science Message-ID: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> Did people see last week's edition of Science with a special section on distributed computing? Lots of stuff on web services, etc. Im still reading it but havent see a mention of MOBY in there as yet. I wonder if there is scope for a follow up letter to Science commenting on this special edition and emphasizing the benefits of MOBY, its scope so far, goals, etc. Might not fly but then again you never know. Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From duncan.hull at cs.man.ac.uk Fri May 20 05:25:30 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri, 20 May 2005 10:25:30 +0100 Subject: [MOBY-dev] last weeks issue of science In-Reply-To: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> References: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> Message-ID: <428DAD0A.8090104@cs.man.ac.uk> Hi Simon Twigger Simon wrote: > Did people see last week's edition of Science with a special section > on distributed computing? There are two articles in Science issue on Distributed computing that mention myGrid, which uses biomoby services. If you write them a letter it would be worth pointing this out. Cyberinfrastructure for e-Science Tony Hey and Anne E. Trefethen http://www.sciencemag.org/cgi/content/abstract/308/5723/817?etoc p. 817 Cyberinfrastructure: Empowering a "Third Way" in Biomedical Research Kenneth H. Buetow http://www.sciencemag.org/cgi/content/abstract/308/5723/821?etoc p. 821 Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From senger at ebi.ac.uk Tue May 24 11:19:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 24 May 2005 16:19:12 +0100 (BST) Subject: [MOBY-dev] jMoby actions from the Vancouver meeting Message-ID: Dear moby-ers, I have commited changes (thanks to help by Eddie, Ben, Paul and others) we have discussed in Vancouver regarding the Java code base ("jMoby"). Please look at the new jMoby documentation (http://www.biomoby.org/moby-live/Java/docs/index.html) which is now being updated every few hours automatically. Which means - when you add new code or documentation into 'moby-live/Java' it will soon appear on the main biomoby pages. Please feel free to comment on the way how we create and share Java code base - because that is important for all us, Java developers in Moby world. Regards, 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 May 24 19:47:15 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 24 May 2005 16:47:15 -0700 Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Well... the time has come :-( We need to break many of the existing services in order to make this last change leading to the 1.0 API. The conclusion we came to at the meeting is that inheriting from the MOBY primitives was bad bad bad. As such, all primitives will continue to be MOBY objects, but nothing can inherit from them. Objects that require content (e.g. our Genbank Flat file object) will now be re- defined to HASA String rather than ISA string. Comically, this change in the API doesn't require any changes to the code, but nevertheless it will break many services out there! We just had a lab meeting and we made some decisions about how we think the new objects should look. The plan for the moment is to change the ISA's to HASA's when an object inherits from a primitive, and to make the HASA articleName be the same as the parent object type. Therefore the existing MOBY Object: Content Here will become: Content Here It's a shame to break so many services just when the latest paper has come out and people are madly playing with MOBY, but... it's all for the best! This change to the API will make things much easier in the long run. If anyone has any objections to this please voice them ASAP. It would be good to make this change before the end of the month if at all possible. Cheers! Mark From senger at ebi.ac.uk Wed May 25 03:49:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 08:49:41 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Message-ID: > Content Here > > > will become: > > > Content > Here > > Just a question: where do the 'ns' and 'id' in come from? 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 senger at ebi.ac.uk Wed May 25 03:49:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 08:49:41 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Message-ID: > Content Here > > > will become: > > > Content > Here > > Just a question: where do the 'ns' and 'id' in come from? 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 rebecca.ernst at gsf.de Wed May 25 03:56:26 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed, 25 May 2005 09:56:26 +0200 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <42942FAA.8030008@gsf.de> I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From rebecca.ernst at gsf.de Wed May 25 03:56:26 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed, 25 May 2005 09:56:26 +0200 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <42942FAA.8030008@gsf.de> I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Wed May 25 09:41:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed, 25 May 2005 13:41:47 +0000 GMT Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> We briefly said that, but discarded the idea almost immediately. Primitives must be objects in moby so that services can operate on primitives (and be discoverable). So, yes, ns and I'd come from Object. Objections? Alternatives? M -----Original Message----- From: Rebecca Ernst Date: Wed, 25 May 2005 09:56:26 To:Core developer announcements Cc:mobydev , markw at illuminae.com Subject: Re: [MOBY-dev] Breakin' the services for the final API I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Wed May 25 09:41:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed, 25 May 2005 13:41:47 +0000 GMT Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> We briefly said that, but discarded the idea almost immediately. Primitives must be objects in moby so that services can operate on primitives (and be discoverable). So, yes, ns and I'd come from Object. Objections? Alternatives? M -----Original Message----- From: Rebecca Ernst Date: Wed, 25 May 2005 09:56:26 To:Core developer announcements Cc:mobydev , markw at illuminae.com Subject: Re: [MOBY-dev] Breakin' the services for the final API I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Wed May 25 09:50:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 14:50:41 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> Message-ID: > So, yes, ns and I'd come from Object. > Well, it means that we have the same 'ns' and 'id' on two places now. Why? I understand that a primitive object must have 'ns' and 'id' if a service operates on that primitive. But if the primitive is in HASA? 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 senger at ebi.ac.uk Wed May 25 09:50:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 14:50:41 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> Message-ID: > So, yes, ns and I'd come from Object. > Well, it means that we have the same 'ns' and 'id' on two places now. Why? I understand that a primitive object must have 'ns' and 'id' if a service operates on that primitive. But if the primitive is in HASA? 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 Wed May 25 10:08:42 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 25 May 2005 07:08:42 -0700 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> On Wed, 2005-05-25 at 14:50 +0100, Martin Senger wrote: > Well, it means that we have the same 'ns' and 'id' on two places now. No. Just like any other object, the namespace and id are associated with whichever object is most appropriate, and may be blank. Nothing has changed in that regard. > Why? I understand that a primitive object must have 'ns' and 'id' if a > service operates on that primitive. But if the primitive is in HASA? This is just like any other HASA. AnnotatedSequence HASA Sequence -> Both the AnnotatedSequence and the Sequence object it contains have their own namespace and id, and these are not identical in intent nor meaning. The AnnotatedSequence might have a namespace representing the annotating body, and the Sequence it contains may have a namespace representing the authority from which that sequence was derived. M From senger at ebi.ac.uk Wed May 25 10:15:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 15:15:49 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> Message-ID: > No. Just like any other object, the namespace and id are associated > with whichever object is most appropriate, and may be blank. Nothing > has changed in that regard. > Generally speaking, you are right. But I was not speaking generally, I was referring to the case when we convert a current object (that inherits from a primitive) into a new object with a primitive type in its HASA. In this case we do not have more than one 'ns' and 'id' so if we put it into HASA mamber it must be the same as in the upper level. That's why I said that we have the 'ns' and 'id' same in two places - and we do not need it I still think. Am I right? 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 senger at ebi.ac.uk Wed May 25 10:15:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 15:15:49 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> Message-ID: > No. Just like any other object, the namespace and id are associated > with whichever object is most appropriate, and may be blank. Nothing > has changed in that regard. > Generally speaking, you are right. But I was not speaking generally, I was referring to the case when we convert a current object (that inherits from a primitive) into a new object with a primitive type in its HASA. In this case we do not have more than one 'ns' and 'id' so if we put it into HASA mamber it must be the same as in the upper level. That's why I said that we have the 'ns' and 'id' same in two places - and we do not need it I still think. Am I right? 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 Wed May 25 10:21:54 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 25 May 2005 07:21:54 -0700 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <1117030914.25071.23.camel@mobycentral.mrl.ubc.ca> I am assuming that the ns and id of the contained object (the primitive) will be blank, unless there is a good reason to put something in there. This is quite typical MOBYesque behaviour. M On Wed, 2005-05-25 at 15:15 +0100, Martin Senger wrote: > > No. Just like any other object, the namespace and id are associated > > with whichever object is most appropriate, and may be blank. Nothing > > has changed in that regard. > > > Generally speaking, you are right. > But I was not speaking generally, I was referring to the case when we > convert a current object (that inherits from a primitive) into a new > object with a primitive type in its HASA. In this case we do not have more > than one 'ns' and 'id' so if we put it into HASA mamber it must be the > same as in the upper level. That's why I said that we have the 'ns' and > 'id' same in two places - and we do not need it I still think. Am I right? > > Martin > From markw at illuminae.com Wed May 25 12:32:54 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 25 May 2005 09:32:54 -0700 Subject: [MOBY-dev] a question and a comment about the new Object inheritance Message-ID: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Hi all, So, I just went through and updated all of my services to follow the new Object inheritance system. It took 5 minutes :-) Turns out that most of my services only output "Object" anyway, so they don't need any work, and the ones that output other things like DNASequence and GO_Term were already following the proposed API anyway, so... only TWO of my services actually were affected by the proposed change! I hope that others have the same experience. I did, however, notice a potential hiccup that we didn't foresee at the meeting. At the moment, binary data in MOBY is passed as a child of base-64-encoded, which is a child of String. Under the new system, we can't have children of String, so do we then need a new primitive class for binary data? I think it still needs to be b64 encoded, but it seems to me that it does need its own primitive now. opinions anyone? M From bmg at sfu.ca Wed May 25 21:03:12 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed, 25 May 2005 21:03:12 -0400 Subject: [MOBY-dev] a question and a comment about the new Object inheritance In-Reply-To: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> References: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Message-ID: It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From bmg at sfu.ca Wed May 25 21:03:12 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed, 25 May 2005 21:03:12 -0400 Subject: [MOBY-dev] a question and a comment about the new Object inheritance In-Reply-To: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> References: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Message-ID: It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From markw at illuminae.com Wed May 25 21:05:14 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 26 May 2005 01:05:14 +0000 GMT Subject: [MOBY-dev] a question and a comment about the new Objectinheritance Message-ID: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Good idea! The reason they weren't implemented initially was simple lack of need. M -----Original Message----- From: Benjamin Good Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements , markw at illuminae.com Cc:mobydev Subject: Re: [MOBY-dev] a question and a comment about the new Object inheritance It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Wed May 25 21:05:14 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 26 May 2005 01:05:14 +0000 GMT Subject: [MOBY-dev] a question and a comment about the new Objectinheritance Message-ID: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Good idea! The reason they weren't implemented initially was simple lack of need. M -----Original Message----- From: Benjamin Good Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements , markw at illuminae.com Cc:mobydev Subject: Re: [MOBY-dev] a question and a comment about the new Object inheritance It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From ywong at infobiogen.fr Thu May 26 04:19:58 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu, 26 May 2005 10:19:58 +0200 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Message-ID: <429586AE.1080306@infobiogen.fr> mark wilkinson wrote: >Good idea! > >The reason they weren't implemented initially was simple lack of need. > >M > >-----Original Message----- >From: Benjamin Good >Date: Wed, 25 May 2005 21:03:12 >To:Core developer announcements , markw at illuminae.com >Cc:mobydev >Subject: Re: [MOBY-dev] a question and a comment about the new Object > inheritance > >It might actually make sense to implement a few more primitives to >facilitate WSDL interoperability. Below see a set of standard >primitives from the Axis user-guide. (Primitives being the things in >the xml message that easily bind to existing Java classes). I wasn't >around when you picked the ones you did, so maybe there are reasons not >to include all of these? > >Standard mappings from WSDL to Java >xsd:base64Binary -> byte[] >xsd:boolean -> boolean >xsd:byte -> byte >xsd:dateTime -> java.util.Calendar >xsd:decimal -> java.math.BigDecimal >xsd:double -> double >xsd:float -> float >xsd:hexBinary -> byte[] >xsd:int -> int >xsd:integer -> java.math.BigInteger >xsd:long -> long >xsd:QName -> javax.xml.namespace.QName >xsd:short -> short >xsd:string -> java.lang.String > >-ben > > > >On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > > > >>Hi all, >> >>So, I just went through and updated all of my services to follow the >>new >>Object inheritance system. It took 5 minutes :-) Turns out that most >>of >>my services only output "Object" anyway, so they don't need any work, >>and the ones that output other things like DNASequence and GO_Term were >>already following the proposed API anyway, so... only TWO of my >>services >>actually were affected by the proposed change! I hope that others have >>the same experience. >> >>I did, however, notice a potential hiccup that we didn't foresee at the >>meeting. At the moment, binary data in MOBY is passed as a child of >>base-64-encoded, which is a child of String. Under the new system, we >>can't have children of String, so do we then need a new primitive class >>for binary data? I think it still needs to be b64 encoded, but it >>seems >>to me that it does need its own primitive now. >> >>opinions anyone? >> >>M >> >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> >> >http://bioinfo.icapture.ubc.ca/bgood >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > >-- >Mark Wilkinson >...on the road! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > Some remarks about Primitives and ontology: First: Do you think that FF is an integer??? If you say no, then you are wrong because FF is a valid hexadecimal REPRESENTATION of an integer number: 255 Reason: The client give the meaning for a message. Forany ordinary human who achieved child school FF is not an integer but for a computer IT CAN BE! Of course it is a bit extreme as an example. We all agree, by convention, that integers are written with Arab figures. In France (I don't know how it is in the rest of Europe) floating numbers are described as 3,1415 instead of 3.1415 (comma instead of point) In this case also, we agree by convention, that floating numbers use the american representation (integer part point fractional part etc..) Did you know that a Unicode string was inherited from a string ??? to display exotic but useful characters that does not exist in English (I don't speak of the strange french characters but also for spanish german etc..)!) and why not Bytes ??? after all a string is an array of bytes so bytes should be the actual primitive (String is an object has Byte) etc.. etc.. In java by default, all strings are unicode strings (AFAIK) but not all language adopted this convention. Primitives are computer related problems. I don't think it is wise to implement primitives inside the ontology because it is not in its place! Primitives were intended to solve problems of performance in language like Java (just see the superb mess between an Integer and an int both speaks about the same mathematical object everybody knows BUT for performance issues, it has been implemented this way poisoning life of millions software enginner and writers - you don't find that kind of issue in other languages -) As I understand from Moby and the ontology of Moby, we should not mix computer related problems with "Business logic" related problems. did you know that in ADA (for strict type checking and overflow control) you can actually subclass an integer in order to define the precision you want in your numbers and it doesn't violate (in any case) the object programming paragdim. For example: subtype Natural is Integer range 0.. Integer'Last; subtype Positive is Integer range 1.. Integer'Last; (I hope no one will have a heart attack on seeing these two lines :p) So if you want to know if an Integer is an integer CAST it (that what I do in Python (for the object mapping with bioMoby XML) ) for example with java use Integer.parse(etc) for Python use int(string) etc.. etc.. These instructions tells the program that the content of the XML is an integer (according to your language convention) I think I have been clear and hope I didn't bash anyone too hard :p From ywong at infobiogen.fr Thu May 26 04:19:58 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu, 26 May 2005 10:19:58 +0200 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Message-ID: <429586AE.1080306@infobiogen.fr> mark wilkinson wrote: >Good idea! > >The reason they weren't implemented initially was simple lack of need. > >M > >-----Original Message----- >From: Benjamin Good >Date: Wed, 25 May 2005 21:03:12 >To:Core developer announcements , markw at illuminae.com >Cc:mobydev >Subject: Re: [MOBY-dev] a question and a comment about the new Object > inheritance > >It might actually make sense to implement a few more primitives to >facilitate WSDL interoperability. Below see a set of standard >primitives from the Axis user-guide. (Primitives being the things in >the xml message that easily bind to existing Java classes). I wasn't >around when you picked the ones you did, so maybe there are reasons not >to include all of these? > >Standard mappings from WSDL to Java >xsd:base64Binary -> byte[] >xsd:boolean -> boolean >xsd:byte -> byte >xsd:dateTime -> java.util.Calendar >xsd:decimal -> java.math.BigDecimal >xsd:double -> double >xsd:float -> float >xsd:hexBinary -> byte[] >xsd:int -> int >xsd:integer -> java.math.BigInteger >xsd:long -> long >xsd:QName -> javax.xml.namespace.QName >xsd:short -> short >xsd:string -> java.lang.String > >-ben > > > >On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > > > >>Hi all, >> >>So, I just went through and updated all of my services to follow the >>new >>Object inheritance system. It took 5 minutes :-) Turns out that most >>of >>my services only output "Object" anyway, so they don't need any work, >>and the ones that output other things like DNASequence and GO_Term were >>already following the proposed API anyway, so... only TWO of my >>services >>actually were affected by the proposed change! I hope that others have >>the same experience. >> >>I did, however, notice a potential hiccup that we didn't foresee at the >>meeting. At the moment, binary data in MOBY is passed as a child of >>base-64-encoded, which is a child of String. Under the new system, we >>can't have children of String, so do we then need a new primitive class >>for binary data? I think it still needs to be b64 encoded, but it >>seems >>to me that it does need its own primitive now. >> >>opinions anyone? >> >>M >> >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> >> >http://bioinfo.icapture.ubc.ca/bgood >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > >-- >Mark Wilkinson >...on the road! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > Some remarks about Primitives and ontology: First: Do you think that FF is an integer??? If you say no, then you are wrong because FF is a valid hexadecimal REPRESENTATION of an integer number: 255 Reason: The client give the meaning for a message. Forany ordinary human who achieved child school FF is not an integer but for a computer IT CAN BE! Of course it is a bit extreme as an example. We all agree, by convention, that integers are written with Arab figures. In France (I don't know how it is in the rest of Europe) floating numbers are described as 3,1415 instead of 3.1415 (comma instead of point) In this case also, we agree by convention, that floating numbers use the american representation (integer part point fractional part etc..) Did you know that a Unicode string was inherited from a string ??? to display exotic but useful characters that does not exist in English (I don't speak of the strange french characters but also for spanish german etc..)!) and why not Bytes ??? after all a string is an array of bytes so bytes should be the actual primitive (String is an object has Byte) etc.. etc.. In java by default, all strings are unicode strings (AFAIK) but not all language adopted this convention. Primitives are computer related problems. I don't think it is wise to implement primitives inside the ontology because it is not in its place! Primitives were intended to solve problems of performance in language like Java (just see the superb mess between an Integer and an int both speaks about the same mathematical object everybody knows BUT for performance issues, it has been implemented this way poisoning life of millions software enginner and writers - you don't find that kind of issue in other languages -) As I understand from Moby and the ontology of Moby, we should not mix computer related problems with "Business logic" related problems. did you know that in ADA (for strict type checking and overflow control) you can actually subclass an integer in order to define the precision you want in your numbers and it doesn't violate (in any case) the object programming paragdim. For example: subtype Natural is Integer range 0.. Integer'Last; subtype Positive is Integer range 1.. Integer'Last; (I hope no one will have a heart attack on seeing these two lines :p) So if you want to know if an Integer is an integer CAST it (that what I do in Python (for the object mapping with bioMoby XML) ) for example with java use Integer.parse(etc) for Python use int(string) etc.. etc.. These instructions tells the program that the content of the XML is an integer (according to your language convention) I think I have been clear and hope I didn't bash anyone too hard :p From bmg at sfu.ca Thu May 26 07:35:17 2005 From: bmg at sfu.ca (Benjamin Good) Date: Thu, 26 May 2005 07:35:17 -0400 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429586AE.1080306@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> Message-ID: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Hi Yan, You make many good points (despite your anti-Java vibe!). The reason that we suggest keeping the primitives in their somewhat strange location within the object ontology is to provide the opportunity for low level services to be discovered in the same manner as all the other services. For example, say we want to post a service that does arithmetic operations or String concatenations or something. If we use the suggested approach, such services can be discovered using exactly the same mechanism that all other services can be discovered. If on the other hand we completely separate these primitives from the ontology, we will have to invent new discovery protocols for handling this use case. You are right, this is a strange beast of an ontology. Its principal purpose is to describe the nature of being a data-type. As such, including descriptions of what it means to be a primitive piece of a data-type does not seem wrong. I think that when we start using a more typical ontology in addition to this one, whose purpose is to describe the nature of the information represented by these data-types, the distinction will be more clear and the real utility of the Object ontology will be made less ambiguous. -Ben On May 26, 2005, at 4:19 AM, Yan Wong wrote: > mark wilkinson wrote: > >> Good idea! >> The reason they weren't implemented initially was simple lack of need. >> >> M >> >> -----Original Message----- >> From: Benjamin Good >> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >> , markw at illuminae.com >> Cc:mobydev >> Subject: Re: [MOBY-dev] a question and a comment about the new Object >> inheritance >> >> It might actually make sense to implement a few more primitives to >> facilitate WSDL interoperability. Below see a set of standard >> primitives from the Axis user-guide. (Primitives being the things in >> the xml message that easily bind to existing Java classes). I wasn't >> around when you picked the ones you did, so maybe there are reasons >> not to include all of these? >> >> Standard mappings from WSDL to Java >> xsd:base64Binary -> byte[] >> xsd:boolean -> boolean >> xsd:byte -> byte >> xsd:dateTime -> java.util.Calendar >> xsd:decimal -> java.math.BigDecimal >> xsd:double -> double >> xsd:float -> float >> xsd:hexBinary -> byte[] >> xsd:int -> int >> xsd:integer -> java.math.BigInteger >> xsd:long -> long >> xsd:QName -> javax.xml.namespace.QName >> xsd:short -> short >> xsd:string -> java.lang.String >> >> -ben >> >> >> >> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> So, I just went through and updated all of my services to follow the >>> new >>> Object inheritance system. It took 5 minutes :-) Turns out that >>> most of >>> my services only output "Object" anyway, so they don't need any work, >>> and the ones that output other things like DNASequence and GO_Term >>> were >>> already following the proposed API anyway, so... only TWO of my >>> services >>> actually were affected by the proposed change! I hope that others >>> have >>> the same experience. >>> >>> I did, however, notice a potential hiccup that we didn't foresee at >>> the >>> meeting. At the moment, binary data in MOBY is passed as a child of >>> base-64-encoded, which is a child of String. Under the new system, >>> we >>> can't have children of String, so do we then need a new primitive >>> class >>> for binary data? I think it still needs to be b64 encoded, but it >>> seems >>> to me that it does need its own primitive now. >>> >>> opinions anyone? >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>> >> http://bioinfo.icapture.ubc.ca/bgood >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> -- >> Mark Wilkinson >> ...on the road! >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > Some remarks about Primitives and ontology: > > First: Do you think that FF is an integer??? > > If you say no, then you are wrong because FF is a valid hexadecimal > REPRESENTATION of an integer number: 255 > > Reason: The client give the meaning for a message. Forany ordinary > human who achieved child school FF is not an integer but for a > computer IT CAN BE! Of course it is a bit extreme as an example. We > all agree, by convention, that integers are written with Arab figures. > > In France (I don't know how it is in the rest of Europe) floating > numbers are described as 3,1415 instead of 3.1415 (comma instead of > point) In this case also, we agree by convention, that floating > numbers use the american representation (integer part point fractional > part etc..) > > Did you know that a Unicode string was inherited from a string ??? to > display exotic but useful characters that does not exist in English (I > don't speak of the strange french characters but also for spanish > german etc..)!) and why not Bytes ??? after all a string is an array > of bytes so bytes should be the actual primitive (String is an object > has Byte) etc.. etc.. In java by default, all strings are unicode > strings (AFAIK) but not all language adopted this convention. > > Primitives are computer related problems. I don't think it is wise to > implement primitives inside the ontology because it is not in its > place! > > Primitives were intended to solve problems of performance in language > like Java (just see the superb mess between an Integer and an int both > speaks about the same mathematical object everybody knows BUT for > performance issues, it has been implemented this way poisoning life of > millions software enginner and writers - you don't find that kind of > issue in other languages -) > > As I understand from Moby and the ontology of Moby, we should not mix > computer related problems with "Business logic" related problems. > > did you know that in ADA (for strict type checking and overflow > control) you can actually subclass an integer in order to define the > precision you want in your numbers and it doesn't violate (in any > case) the object programming paragdim. > > For example: > > subtype Natural is Integer range 0.. Integer'Last; > subtype Positive is Integer range 1.. Integer'Last; > (I hope no one will have a heart attack on seeing these two lines :p) > > So if you want to know if an Integer is an integer CAST it (that what > I do in Python (for the object mapping with bioMoby XML) ) for example > with java use Integer.parse(etc) for Python use int(string) etc.. > etc.. > > These instructions tells the program that the content of the XML is an > integer (according to your language convention) > > I think I have been clear and hope I didn't bash anyone too hard :p > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From bmg at sfu.ca Thu May 26 07:35:17 2005 From: bmg at sfu.ca (Benjamin Good) Date: Thu, 26 May 2005 07:35:17 -0400 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429586AE.1080306@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> Message-ID: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Hi Yan, You make many good points (despite your anti-Java vibe!). The reason that we suggest keeping the primitives in their somewhat strange location within the object ontology is to provide the opportunity for low level services to be discovered in the same manner as all the other services. For example, say we want to post a service that does arithmetic operations or String concatenations or something. If we use the suggested approach, such services can be discovered using exactly the same mechanism that all other services can be discovered. If on the other hand we completely separate these primitives from the ontology, we will have to invent new discovery protocols for handling this use case. You are right, this is a strange beast of an ontology. Its principal purpose is to describe the nature of being a data-type. As such, including descriptions of what it means to be a primitive piece of a data-type does not seem wrong. I think that when we start using a more typical ontology in addition to this one, whose purpose is to describe the nature of the information represented by these data-types, the distinction will be more clear and the real utility of the Object ontology will be made less ambiguous. -Ben On May 26, 2005, at 4:19 AM, Yan Wong wrote: > mark wilkinson wrote: > >> Good idea! >> The reason they weren't implemented initially was simple lack of need. >> >> M >> >> -----Original Message----- >> From: Benjamin Good >> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >> , markw at illuminae.com >> Cc:mobydev >> Subject: Re: [MOBY-dev] a question and a comment about the new Object >> inheritance >> >> It might actually make sense to implement a few more primitives to >> facilitate WSDL interoperability. Below see a set of standard >> primitives from the Axis user-guide. (Primitives being the things in >> the xml message that easily bind to existing Java classes). I wasn't >> around when you picked the ones you did, so maybe there are reasons >> not to include all of these? >> >> Standard mappings from WSDL to Java >> xsd:base64Binary -> byte[] >> xsd:boolean -> boolean >> xsd:byte -> byte >> xsd:dateTime -> java.util.Calendar >> xsd:decimal -> java.math.BigDecimal >> xsd:double -> double >> xsd:float -> float >> xsd:hexBinary -> byte[] >> xsd:int -> int >> xsd:integer -> java.math.BigInteger >> xsd:long -> long >> xsd:QName -> javax.xml.namespace.QName >> xsd:short -> short >> xsd:string -> java.lang.String >> >> -ben >> >> >> >> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> So, I just went through and updated all of my services to follow the >>> new >>> Object inheritance system. It took 5 minutes :-) Turns out that >>> most of >>> my services only output "Object" anyway, so they don't need any work, >>> and the ones that output other things like DNASequence and GO_Term >>> were >>> already following the proposed API anyway, so... only TWO of my >>> services >>> actually were affected by the proposed change! I hope that others >>> have >>> the same experience. >>> >>> I did, however, notice a potential hiccup that we didn't foresee at >>> the >>> meeting. At the moment, binary data in MOBY is passed as a child of >>> base-64-encoded, which is a child of String. Under the new system, >>> we >>> can't have children of String, so do we then need a new primitive >>> class >>> for binary data? I think it still needs to be b64 encoded, but it >>> seems >>> to me that it does need its own primitive now. >>> >>> opinions anyone? >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>> >> http://bioinfo.icapture.ubc.ca/bgood >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> -- >> Mark Wilkinson >> ...on the road! >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > Some remarks about Primitives and ontology: > > First: Do you think that FF is an integer??? > > If you say no, then you are wrong because FF is a valid hexadecimal > REPRESENTATION of an integer number: 255 > > Reason: The client give the meaning for a message. Forany ordinary > human who achieved child school FF is not an integer but for a > computer IT CAN BE! Of course it is a bit extreme as an example. We > all agree, by convention, that integers are written with Arab figures. > > In France (I don't know how it is in the rest of Europe) floating > numbers are described as 3,1415 instead of 3.1415 (comma instead of > point) In this case also, we agree by convention, that floating > numbers use the american representation (integer part point fractional > part etc..) > > Did you know that a Unicode string was inherited from a string ??? to > display exotic but useful characters that does not exist in English (I > don't speak of the strange french characters but also for spanish > german etc..)!) and why not Bytes ??? after all a string is an array > of bytes so bytes should be the actual primitive (String is an object > has Byte) etc.. etc.. In java by default, all strings are unicode > strings (AFAIK) but not all language adopted this convention. > > Primitives are computer related problems. I don't think it is wise to > implement primitives inside the ontology because it is not in its > place! > > Primitives were intended to solve problems of performance in language > like Java (just see the superb mess between an Integer and an int both > speaks about the same mathematical object everybody knows BUT for > performance issues, it has been implemented this way poisoning life of > millions software enginner and writers - you don't find that kind of > issue in other languages -) > > As I understand from Moby and the ontology of Moby, we should not mix > computer related problems with "Business logic" related problems. > > did you know that in ADA (for strict type checking and overflow > control) you can actually subclass an integer in order to define the > precision you want in your numbers and it doesn't violate (in any > case) the object programming paragdim. > > For example: > > subtype Natural is Integer range 0.. Integer'Last; > subtype Positive is Integer range 1.. Integer'Last; > (I hope no one will have a heart attack on seeing these two lines :p) > > So if you want to know if an Integer is an integer CAST it (that what > I do in Python (for the object mapping with bioMoby XML) ) for example > with java use Integer.parse(etc) for Python use int(string) etc.. > etc.. > > These instructions tells the program that the content of the XML is an > integer (according to your language convention) > > I think I have been clear and hope I didn't bash anyone too hard :p > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From ywong at infobiogen.fr Thu May 26 11:04:17 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu, 26 May 2005 17:04:17 +0200 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Message-ID: <4295E571.5040602@infobiogen.fr> Benjamin Good wrote: > Hi Yan, > > You make many good points (despite your anti-Java vibe!). The reason > that we suggest keeping the primitives in their somewhat strange > location within the object ontology is to provide the opportunity for > low level services to be discovered in the same manner as all the > other services. For example, say we want to post a service that does > arithmetic operations or String concatenations or something. If we use > the suggested approach, such services can be discovered using exactly > the same mechanism that all other services can be discovered. If on > the other hand we completely separate these primitives from the > ontology, we will have to invent new discovery protocols for handling > this use case. > > You are right, this is a strange beast of an ontology. Its principal > purpose is to describe the nature of being a data-type. As such, > including descriptions of what it means to be a primitive piece of a > data-type does not seem wrong. I think that when we start using a more > typical ontology in addition to this one, whose purpose is to describe > the nature of the information represented by these data-types, the > distinction will be more clear and the real utility of the Object > ontology will be made less ambiguous. > > -Ben > > > On May 26, 2005, at 4:19 AM, Yan Wong wrote: > >> mark wilkinson wrote: >> >>> Good idea! >>> The reason they weren't implemented initially was simple lack of need. >>> >>> M >>> >>> -----Original Message----- >>> From: Benjamin Good >>> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >>> , markw at illuminae.com >>> Cc:mobydev >>> Subject: Re: [MOBY-dev] a question and a comment about the new Object >>> inheritance >>> >>> It might actually make sense to implement a few more primitives to >>> facilitate WSDL interoperability. Below see a set of standard >>> primitives from the Axis user-guide. (Primitives being the things in >>> the xml message that easily bind to existing Java classes). I wasn't >>> around when you picked the ones you did, so maybe there are reasons >>> not to include all of these? >>> >>> Standard mappings from WSDL to Java >>> xsd:base64Binary -> byte[] >>> xsd:boolean -> boolean >>> xsd:byte -> byte >>> xsd:dateTime -> java.util.Calendar >>> xsd:decimal -> java.math.BigDecimal >>> xsd:double -> double >>> xsd:float -> float >>> xsd:hexBinary -> byte[] >>> xsd:int -> int >>> xsd:integer -> java.math.BigInteger >>> xsd:long -> long >>> xsd:QName -> javax.xml.namespace.QName >>> xsd:short -> short >>> xsd:string -> java.lang.String >>> >>> -ben >>> >>> >>> >>> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >>> >>> >>>> Hi all, >>>> >>>> So, I just went through and updated all of my services to follow >>>> the new >>>> Object inheritance system. It took 5 minutes :-) Turns out that >>>> most of >>>> my services only output "Object" anyway, so they don't need any work, >>>> and the ones that output other things like DNASequence and GO_Term >>>> were >>>> already following the proposed API anyway, so... only TWO of my >>>> services >>>> actually were affected by the proposed change! I hope that others have >>>> the same experience. >>>> >>>> I did, however, notice a potential hiccup that we didn't foresee at >>>> the >>>> meeting. At the moment, binary data in MOBY is passed as a child of >>>> base-64-encoded, which is a child of String. Under the new system, we >>>> can't have children of String, so do we then need a new primitive >>>> class >>>> for binary data? I think it still needs to be b64 encoded, but it >>>> seems >>>> to me that it does need its own primitive now. >>>> >>>> opinions anyone? >>>> >>>> M >>>> >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >>> http://bioinfo.icapture.ubc.ca/bgood >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> -- >>> Mark Wilkinson >>> ...on the road! >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> Some remarks about Primitives and ontology: >> >> First: Do you think that FF is an integer??? >> >> If you say no, then you are wrong because FF is a valid hexadecimal >> REPRESENTATION of an integer number: 255 >> >> Reason: The client give the meaning for a message. Forany ordinary >> human who achieved child school FF is not an integer but for a >> computer IT CAN BE! Of course it is a bit extreme as an example. We >> all agree, by convention, that integers are written with Arab figures. >> >> In France (I don't know how it is in the rest of Europe) floating >> numbers are described as 3,1415 instead of 3.1415 (comma instead of >> point) In this case also, we agree by convention, that floating >> numbers use the american representation (integer part point >> fractional part etc..) >> >> Did you know that a Unicode string was inherited from a string ??? to >> display exotic but useful characters that does not exist in English >> (I don't speak of the strange french characters but also for spanish >> german etc..)!) and why not Bytes ??? after all a string is an array >> of bytes so bytes should be the actual primitive (String is an object >> has Byte) etc.. etc.. In java by default, all strings are unicode >> strings (AFAIK) but not all language adopted this convention. >> >> Primitives are computer related problems. I don't think it is wise to >> implement primitives inside the ontology because it is not in its place! >> >> Primitives were intended to solve problems of performance in language >> like Java (just see the superb mess between an Integer and an int >> both speaks about the same mathematical object everybody knows BUT >> for performance issues, it has been implemented this way poisoning >> life of millions software enginner and writers - you don't find that >> kind of issue in other languages -) >> >> As I understand from Moby and the ontology of Moby, we should not mix >> computer related problems with "Business logic" related problems. >> >> did you know that in ADA (for strict type checking and overflow >> control) you can actually subclass an integer in order to define the >> precision you want in your numbers and it doesn't violate (in any >> case) the object programming paragdim. >> >> For example: >> >> subtype Natural is Integer range 0.. Integer'Last; >> subtype Positive is Integer range 1.. Integer'Last; >> (I hope no one will have a heart attack on seeing these two lines :p) >> >> So if you want to know if an Integer is an integer CAST it (that what >> I do in Python (for the object mapping with bioMoby XML) ) for >> example with java use Integer.parse(etc) for Python use int(string) >> etc.. etc.. >> >> These instructions tells the program that the content of the XML is >> an integer (according to your language convention) >> >> I think I have been clear and hope I didn't bash anyone too hard :p >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > http://bioinfo.icapture.ubc.ca/bgood > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > I know that we must provide data type descriptions of a biological object. but the fact is that we must try to match the biological logic" as much as possible. Maybe one solution would be to link the "computer logic" (represented by datatypes) with the biological logic (represented by the ontology objects) However putting all the "computer related" informations inside the ontology is not a good idea. The ontology should remain the most "biological" as possible. There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? . So something like that could emerge: DNA Sequence associated with FASTA, EMBL, etc.. FASTA EMBL FASTA, EMBL, GFF and so on would be in another ontology (more specific to bioinformatic/computers) The idea is to clearly separate the "biological" logic and the "computer related" logic. So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." A biological object of the ontology could be linked to a (or several) data types thus low level operations (or better computer related services/operations) could be discovered in the same way as biological services. We would have biological ontology<-> bioinformatic ontology relationships that would map the biological logic to the computer logic. PS: The fact is I am not anti Java (as a language) after all, I used it every day since the Beta version (Oak for who can still remember the prehistoric details of Java :p who was designed to be a OS for your microwave oven ahahaha) However I still have a lot of frustrations on the java API because this stuff is a real nightmare and was the main drawback of Java for several years (try to implement a simple spreadsheet with Swing and you'll know what I mean all other GUI language beat Java 100% of the time. A dumber example: Do you remember what classes needed to open a file? I still need to copy paste my code pattern!) And I like Java for its philosophy: Code once, execute many (even if people, most of the time, do Java programming for Windows (95/98/NT/2000/XP) Multi plateform ahahaha) From markw at illuminae.com Thu May 26 11:29:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 May 2005 08:29:44 -0700 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <4295E571.5040602@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> <4295E571.5040602@infobiogen.fr> Message-ID: <1117121384.27775.70.camel@mobycentral.mrl.ubc.ca> Wow... what a discussion! I have to throw in my $0.02 I think the Object ontology is "logically" correct exactly as it stands. It describes the structure of the objects to a machine, while giving some human-intuitive sense of what the object is supposed to represent by using a human-intuitive name. Ben would argue (correct me if I get this wrong) that it is inappropriate to define particular *types* of strings in the object ontology because this goes over the line of conflating structure with semantics. I tend to disagree - a FASTA file is a particular type of file format, and it is that *format* that we are describing (i.e. the structure of the string) not its actual content or meaning. As such, it doesn't bother me one little bit that we inherit from String. And, as Yan points out, if you want to know if an Object is a String or an Int, then ask it - the inheritance will tell you. It strikes me that it is only laziness that creates the "need" not to inherit from the primitives; i.e. that it is simply easier to know if you have a primitive in-hand if the object in-hand is of a primitive type "by name", rather than a child of a primitive type where yo have to look-up its parentage. Inheriting from Primitives also solves a number of other problems v.v. rendering and such, but I don't want the utility to override the architecture, so I'll leave that discussion out of it. My *only* objection to the way things are today is that the serialization of derivative objects from primitives can end up having mixtures of XML and text as child nodes in the XML. This is widely considered "bad practice" (though not "illegal"), and it makes me a bit queasy in my stomach every time I see it. Nevertheless, this problem can be solved in ways other than preventing inheritance from primitives! Let's get to the root of the problem. Is the Java community (I finger you because you are the ones who are reporting this as a problem) really objecting to inheritance from primitives, or are you objecting to the way we serialize the ontology? I tried to type examples of both new solutions at the meeting, but neither of them seemed acceptable to anyone, so I gave up... I remain unconvinced. I agree that the serialization we have now is somewhat ugly in some cases, but creating a special class of Objects is even worse! If we can solve the Java programmers problem by serializing objects like this: content here then perhaps that's what we should do in preference to creating special types of Objects that wrap primitives but cannot have child types. ??? Mark From senger at ebi.ac.uk Thu May 26 11:50:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 26 May 2005 16:50:01 +0100 (BST) Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1117121384.27775.70.camel@mobycentral.mrl.ubc.ca> Message-ID: Well, I myself is not the main player in this dicussion about inheriting from primitives but as far as I understand, this: > > content here > > is what everybody wanted in the meeting (the name "String" is arbitrary, the name "string" is mandatory). But maybe I am wrong. Cheers, 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 Fri May 27 11:48:14 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 08:48:14 -0700 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: References: Message-ID: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > Well, I myself is not the main player in this dicussion about inheriting > from primitives but as far as I understand, this: > > > > > content here > > > > > is what everybody wanted in the meeting Ummmm... I think there was a lot of disagreement about what "everybody" wanted... By the looks of it now, everybody wanted something different, but were calling it the same thing :-) Unfortunately, when I asked for some example objects, nobody volunteered, so we couldn't sort it out at the time. I remember vividly, however, that when I tried to write that (above XML) on the screen, the room erupted in screams that I was making it all too complicated, so I don't think that is what people wanted. It may be that we have all had time to digest the issue a bit more deeply now and have come to the same conclusion? M From ywong at infobiogen.fr Fri May 27 13:55:18 2005 From: ywong at infobiogen.fr (ywong@infobiogen.fr) Date: Fri, 27 May 2005 19:55:18 +0200 (CEST) Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> References: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> Message-ID: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >> Well, I myself is not the main player in this dicussion about inheriting >> from primitives but as far as I understand, this: >> >> > >> > content here >> > >> > >> is what everybody wanted in the meeting > > Ummmm... I think there was a lot of disagreement about what "everybody" > wanted... By the looks of it now, everybody wanted something different, > but were calling it the same thing :-) Unfortunately, when I asked for > some example objects, nobody volunteered, so we couldn't sort it out at > the time. > > I remember vividly, however, that when I tried to write that (above XML) > on the screen, the room erupted in screams that I was making it all too > complicated, so I don't think that is what people wanted. It may be > that we have all had time to digest the issue a bit more deeply now and > have come to the same conclusion? > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Sorry I could reply earlier, all our network is in a quagmire... An alternative I would accept: blablablablablablalbalbalblablalbalba An attribute is optional, we keep the actual version without killing everything (adding a subnode and all serializers/deserializers would have to be rewritten!) People using Java will know what is the type of the data by reading this attribute. If it doesn't exist, they should assume that by default, it is a string. Example of DNASequence: ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... 152 Then we should agree of what "primitives" we have: -string -float -int maybe are there others? It is a quick and dirty solution however it is IMHO cleaner than what I saw in the last example. It has the advantage to keep the "old" object layout but add informations that will greatly help people who implements type sensible clients. Greetings Yan From edward.kawas at gmail.com Fri May 27 14:06:38 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 27 May 2005 11:06:38 -0700 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> Message-ID: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> I like Yans idea, but what happens if the object doesn't inherit from String, isn't an int or a float? What if the object was a schematikonMotifID that inherits from SchematikonSegmentID that inherits from Object. What would the data:type be in this case? Ed > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of > ywong at infobiogen.fr > Sent: Friday, May 27, 2005 10:55 AM > To: markw at illuminae.com; Core developer announcements > Subject: Re: [moby] Re: [MOBY-dev] a question and a > comment about the new Objectinheritance > > > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > >> Well, I myself is not the main player in this dicussion > about inheriting > >> from primitives but as far as I understand, this: > >> > >> > > >> > content here > >> > > >> > > >> is what everybody wanted in the meeting > > > > Ummmm... I think there was a lot of disagreement about > what "everybody" > > wanted... By the looks of it now, everybody wanted > something different, > > but were calling it the same thing :-) Unfortunately, > when I asked for > > some example objects, nobody volunteered, so we couldn't > sort it out at > > the time. > > > > I remember vividly, however, that when I tried to write > that (above XML) > > on the screen, the room erupted in screams that I was > making it all too > > complicated, so I don't think that is what people wanted. > It may be > > that we have all had time to digest the issue a bit more > deeply now and > > have come to the same conclusion? > > > > M > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > Sorry I could reply earlier, all our network is in a > quagmire... > > An alternative I would accept: > > > blablablablablablalbalbalblablalbalba > > > An attribute is optional, we keep the actual version > without killing > everything (adding a subnode and all > serializers/deserializers would > have to be rewritten!) > > People using Java will know what is the type of the data > by reading this > attribute. If it doesn't exist, they should assume that by > default, it > is a string. > > Example of DNASequence: > > > > > ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... > > data:type="int">152 > > > Then we should agree of what "primitives" we have: > -string > -float > -int > > maybe are there others? > > It is a quick and dirty solution however it is IMHO > cleaner than what I > saw in the last example. It has the advantage to keep the > "old" object > layout but add informations that will greatly help people > who implements > type sensible clients. > > Greetings > > Yan > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri May 27 14:49:14 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 11:49:14 -0700 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> References: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> Message-ID: <1117219754.30771.33.camel@mobycentral.mrl.ubc.ca> I guess it would be type='null' or something like that. I agree that this is the only case where Yan's proposal breaks. We do, actually, have quite a few Objects that inherit from Object without going through a primitive, and therefore have no content at all and should not be assumed to default to type="sting" I don't think we can (nor should) require that our final solution doesn't break anything. It is more important to get it right in the 1.0 spec than to salvage legacy services. As such, I'm not so concerned about having a default state - if we are going to go this route, then I think it should be a requirement to have a type='' attribute. The other advantage of Yan's solution is that it is much more XML-like, and we can use the XML type attributes exactly as they are! I like that!! How do the Java crowd feel about this? M On Fri, 2005-05-27 at 11:06 -0700, Eddie Kawas wrote: > I like Yans idea, but what happens if the object doesn't > inherit from String, isn't an int or a float? What if the > object was a schematikonMotifID that inherits from > SchematikonSegmentID that inherits from Object. What would > the data:type be in this case? > > > > > > Ed > > > > > -----Original Message----- > > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > > dev-bounces at portal.open-bio.org] On Behalf Of > > ywong at infobiogen.fr > > Sent: Friday, May 27, 2005 10:55 AM > > To: markw at illuminae.com; Core developer announcements > > Subject: Re: [moby] Re: [MOBY-dev] a question and a > > comment about the new Objectinheritance > > > > > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > > >> Well, I myself is not the main player in this dicussion > > about inheriting > > >> from primitives but as far as I understand, this: > > >> > > >> > > > >> > content here > > >> > > > >> > > > >> is what everybody wanted in the meeting > > > > > > Ummmm... I think there was a lot of disagreement about > > what "everybody" > > > wanted... By the looks of it now, everybody wanted > > something different, > > > but were calling it the same thing :-) Unfortunately, > > when I asked for > > > some example objects, nobody volunteered, so we couldn't > > sort it out at > > > the time. > > > > > > I remember vividly, however, that when I tried to write > > that (above XML) > > > on the screen, the room erupted in screams that I was > > making it all too > > > complicated, so I don't think that is what people > wanted. > > It may be > > > that we have all had time to digest the issue a bit more > > deeply now and > > > have come to the same conclusion? > > > > > > M > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Sorry I could reply earlier, all our network is in a > > quagmire... > > > > An alternative I would accept: > > > > > > blablablablablablalbalbalblablalbalba > > > > > > An attribute is optional, we keep the actual version > > without killing > > everything (adding a subnode and all > > serializers/deserializers would > > have to be rewritten!) > > > > People using Java will know what is the type of the data > > by reading this > > attribute. If it doesn't exist, they should assume that by > > default, it > > is a string. > > > > Example of DNASequence: > > > > > > > > > > ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... > > > > > data:type="int">152 > > > > > > Then we should agree of what "primitives" we have: > > -string > > -float > > -int > > > > maybe are there others? > > > > It is a quick and dirty solution however it is IMHO > > cleaner than what I > > saw in the last example. It has the advantage to keep the > > "old" object > > layout but add informations that will greatly help people > > who implements > > type sensible clients. > > > > Greetings > > > > Yan > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri May 27 15:05:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 12:05:57 -0700 Subject: [MOBY-dev] Notes from working group 'B' Message-ID: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> Hi all, Unfortunately, all of my notes from my working group at the MOBY meeting were stolen along with my laptop just a few days after the meeting ended. I have tried to recall everything that we decided, and I compile it below. If I have made any errors, or forgotten anything, please post to the list. Report from Working Group B Issues: Registry mirrors, Service mirrors, Async services, Service testing metadata, standardized LSID provision Decisions: Registry Mirrors registry mirroring will be accomplished by synchronizing the SignatureURL?s among a set of registries. Each registry will have an agent that can (at its discretion) visit any or all of the signature URL?s to retrieve the service signatures and update its own registry. Someone ____________ is going to look into the various ways of synchronizing this list (LDAP, DNS, other?) Service Mirrors Mark will change the MOBY Central API such that multiple endponts can be registered/returned in a service search. This will affect the registerService and findService API calls. The implication of registering multiple endpoints is that the *identical* service is running in all indicated locations, with the same database and same software version. These endpoints all share the same Service Signature metadata, so they had better be identical! Async services a few details have to be worked out (I think the Spanish contingent took on the task of fleshing this out completely), but the upshot is that, when a service is registered, it will be assumed to have four ?method? calls: 1) The name of the service (e.g. doBlastAnalysis) 2) The name with _async appended (e.g. doBlastAnalysis_async) 3) The name with _poll appended (e.g. doBlastAnalysis_poll) 4) The name with _result appended (e.g. doBlastAnalyis_result) The service registration is identical to what it is now, methods 2,3,4 are optional and are not explicitly registered. (the ability of a service to run asynchronously can be determined by querying the RDF metadata through LSID resolution predicates TBD). Calling the service by name executes the service synchronously exactly as it does currently. If a service refuses to run synchronously, it returns an empty response (this is a valid behaviour, and will not break ?old? clients). Calling the xxx_async method will return a MOBY Object representing a ?ticket?- the namespace should be unique to your async service. The ticket can be used to poll the service using the xxx_poll method (API TBD) , and the same ticket can be used to retrieve the result using the xxx_result method. Service Testing Metadata it was generally agreed that it is desirable to have a sample input such that a service can be tested. This will be made available by the service providers as a string literal in their Service Signature (this is retrieved by LSID resolution). The string should be a complete MOBY message (?..) representing a sample input to that service that will ALWAYS work; where ?work? means generate an output of the Object type registered in the Service Signature and in MOBY Central. This input is to be used for testing that a service is running, but not for validating the output. Standardized LSID provision I have updated the online API documents to show how LSID?s will be derived from MOBY Central messages. Generally speaking, in the response message from MOBY Central, any XML tag whose content represents an entry in one of the ontologies, or a service instance, will have an attribute lsid=?nnn?, where nnn can be resolved to metadata describing that entity. For the MOBY Ontologies, this metadata is the RDF describing the ontology node. For service signatures, this metadata is the RDF of the service signature (taken as a GET directly from the service providers machine through the usual LSID resolution process using their registered SignatureURL as the GET URL). As soon as I get a few minutes free I will implement this new part of the API. I?m sure there are things I have missed? please make your additions and comments to the list. From ywong at infobiogen.fr Fri May 27 15:43:10 2005 From: ywong at infobiogen.fr (ywong@infobiogen.fr) Date: Fri, 27 May 2005 21:43:10 +0200 (CEST) Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> References: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> Message-ID: <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> > I like Yans idea, but what happens if the object doesn't > inherit from String, isn't an int or a float? What if the > object was a schematikonMotifID that inherits from > SchematikonSegmentID that inherits from Object. What would > the data:type be in this case? > > > > > > Ed > > > >> -----Original Message----- >> From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >> dev-bounces at portal.open-bio.org] On Behalf Of >> ywong at infobiogen.fr >> Sent: Friday, May 27, 2005 10:55 AM >> To: markw at illuminae.com; Core developer announcements >> Subject: Re: [moby] Re: [MOBY-dev] a question and a >> comment about the new Objectinheritance >> >> > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >> >> Well, I myself is not the main player in this dicussion >> about inheriting >> >> from primitives but as far as I understand, this: >> >> >> >> > >> >> > content here >> >> > >> >> > >> >> is what everybody wanted in the meeting >> > >> > Ummmm... I think there was a lot of disagreement about >> what "everybody" >> > wanted... By the looks of it now, everybody wanted >> something different, >> > but were calling it the same thing :-) Unfortunately, >> when I asked for >> > some example objects, nobody volunteered, so we couldn't >> sort it out at >> > the time. >> > >> > I remember vividly, however, that when I tried to write >> that (above XML) >> > on the screen, the room erupted in screams that I was >> making it all too >> > complicated, so I don't think that is what people > wanted. >> It may be >> > that we have all had time to digest the issue a bit more >> deeply now and >> > have come to the same conclusion? >> > >> > M >> > >> > >> > _______________________________________________ >> > MOBY-dev mailing list >> > MOBY-dev at biomoby.org >> > http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> Sorry I could reply earlier, all our network is in a >> quagmire... >> >> An alternative I would accept: >> >> >> blablablablablablalbalbalblablalbalba >> >> >> An attribute is optional, we keep the actual version >> without killing >> everything (adding a subnode and all >> serializers/deserializers would >> have to be rewritten!) >> >> People using Java will know what is the type of the data >> by reading this >> attribute. If it doesn't exist, they should assume that by >> default, it >> is a string. >> >> Example of DNASequence: >> >> >> >> >> ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... >> >> > data:type="int">152 >> >> >> Then we should agree of what "primitives" we have: >> -string >> -float >> -int >> >> maybe are there others? >> >> It is a quick and dirty solution however it is IMHO >> cleaner than what I >> saw in the last example. It has the advantage to keep the >> "old" object >> layout but add informations that will greatly help people >> who implements >> type sensible clients. >> >> Greetings >> >> Yan >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Simple: data:type only apply to the content of the tag if it exists so: The line above means that the content of Object (here nothing) should be an integer, but it is void so the line above describes an invalid integer... no data:type attribute and no content so we should deal this object as we did before. 152 no data:type but a content, so the client must treat the content as a string 152 the data:type indicates that the content is an integer. From markw at illuminae.com Fri May 27 15:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 12:57:02 -0700 Subject: [MOBY-dev] weeding out the "dead" services Message-ID: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Hi all, so, it's about time we finally switch this RDF Agent on... again... :-) As we did last time, can I request that you visit the RDF Signature Generator (http://mobycentral.cbr.nrc.ca:8090/servlets/forms/getSignatureForm) retrieve your Service Signatures, then make them available at whatever signatureURL you indicate on that web form. Running the RDF Signature Generator more than once will simply over- write your signature URL with whatever new signature URL you enter, so it is perfectly safe to do this. Thanks! M From simont at mcw.edu Fri May 27 16:23:41 2005 From: simont at mcw.edu (Twigger Simon) Date: Fri, 27 May 2005 15:23:41 -0500 Subject: [MOBY-dev] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> References: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Message-ID: Hi Mark, Just so I understand how this should work: I can go to the form, select my domain, leave the instance name field blank so I get every service, fill in a signature URL (should this point to a directory or to a file?) and click Submit. Back comes the RDF which I move to the location specified in the signature URL and then I can throw away all the old signature files with a clean conscience? I was hoping I could leave the service instance blank, specify one file name in the signature URL and then that would give me back one RDF document for all services so I can just throw that one file on the server and ditch the old files. Is this correct? Simon. On May 27, 2005, at 2:57 PM, Mark Wilkinson wrote: > Hi all, > > so, it's about time we finally switch this RDF Agent on... > again... :-) > > As we did last time, can I request that you visit the RDF Signature > Generator > (http://mobycentral.cbr.nrc.ca:8090/servlets/forms/getSignatureForm) > retrieve your Service Signatures, then make them available at whatever > signatureURL you indicate on that web form. > > Running the RDF Signature Generator more than once will simply over- > write your signature URL with whatever new signature URL you enter, so > it is perfectly safe to do this. > > Thanks! > > M > > > _______________________________________________ > 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 AIM/iChat: simontatmcw From edward.kawas at gmail.com Fri May 27 16:30:02 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 27 May 2005 13:30:02 -0700 Subject: [MOBY-dev] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: Message-ID: <4297834d.5b52e37c.787e.ffff930c@mx.gmail.com> Hi, > should this point to a directory or to a file? Points to the rdf *file* returned to you, accessible through the url that you enter. So if you were to enter http://www.mydomin.com/rdfs/myDoc.rdf then you would place the document in /rdfs/ and name the file myDoc.rdf. > I was hoping I could leave the service instance blank, >specify one file name in the signature URL and then that >would give me back one RDF document for all services so I >can just throw that one file on the server and ditch the >old files. Hopefully, this is what happens ;-) Eddie From bmg at sfu.ca Fri May 27 16:42:14 2005 From: bmg at sfu.ca (Benjamin Good) Date: Fri, 27 May 2005 16:42:14 -0400 Subject: [MOBY-dev] 2 ontologies Message-ID: <319d32e74261b6c9a729acd780bd53db@sfu.ca> From Yan: "There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? ." -Ben -> I agree with this thinking and in fact that was what I was trying to suggest. However, I think that you have things reversed in the following statement. Yan: "So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." -> Ben As I understand it, the BioMOBY object ontology is meant to describe data-types, not biological logic. It does a nice job of the former but I would say not the latter. My suggestion is to introduce a separate ontology that does describe the biology of the things represented by the data-types (that would NOT include things like "FASTA formatted sequence"!). I think this may happen by default when moby-central merges with Grimoire/Feta, but this list needs to pay attention! I think that it is very important to rectify this confusion between syntax and semantics as soon as we can. What happens when the tools are written that create bioMoby services automatically from websites get going? I think you will quickly see that the moby object ontology loses any notion of "biological logic" as it rapidly becomes populated by perfectly syntactically valid machine produced Objects - and this is GOOD. We WANT thousands of services in there and they may require thousands of new objects! Its important to keep in mind the underlying goals of these things. The Object ontology exists to ensure interoperability - not integration. To me, that means that I can easily consume any service that uses objects from this ontology and it ensures (only helps actually) that the data types produced by service providers are sensible. These SYNTACTIC problems are solved quite nicely by the Object ontology - regardless of the specific serialization you end up choosing and regardless of the name you give to your objects. The SEMANTIC problems associated with INTEGRATION are different, large and growing and will need different solutions. rant over. -Ben http://bioinfo.icapture.ubc.ca/bgood From markw at illuminae.com Fri May 27 17:03:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 14:03:00 -0700 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: References: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Message-ID: <1117227780.30771.71.camel@mobycentral.mrl.ubc.ca> On Fri, 2005-05-27 at 15:23 -0500, Twigger Simon wrote: > RDF document for all services so I can just throw that one file on > the server and ditch the old files. > > Is this correct? That is correct (if Eddie has done his job properly ;-) ) M From jmfernandez at cnb.uam.es Fri May 27 17:23:19 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXogR29uesOhbGV6?=) Date: Fri, 27 May 2005 23:23:19 +0200 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> Message-ID: <42978FC7.7030805@cnb.uam.es> Hi Mark & the MOBYfiers 8-), > Service Mirrors Mark will change the MOBY Central API such that > multiple endponts can be registered/returned in a service search. This > will affect the registerService and findService API calls. The > implication of registering multiple endpoints is that the *identical* > service is running in all indicated locations, with the same database > and same software version. These endpoints all share the same Service > Signature metadata, so they had better be identical! > Also, I can remember we talked about storing updated QoS information, doesn't it? Thinking on replicated services, each one should have its own QoS information. > > Async services a few details have to be worked out (I think the Spanish > contingent took on the task of fleshing this out completely), but the > upshot is that, when a service is registered, it will be assumed to have > four ?method? calls: > 1) The name of the service (e.g. doBlastAnalysis) > 2) The name with _async appended (e.g. doBlastAnalysis_async) > 3) The name with _poll appended (e.g. doBlastAnalysis_poll) > 4) The name with _result appended (e.g. doBlastAnalyis_result) > > The service registration is identical to what it is now, methods 2,3,4 > are optional and are not explicitly registered. (the ability of a > service to run asynchronously can be determined by querying the RDF > metadata through LSID resolution predicates TBD). Calling the service > by name executes the service synchronously exactly as it does currently. > If a service refuses to run synchronously, it returns an empty response > (this is a valid behaviour, and will not break ?old? clients). Calling > the xxx_async method will return a MOBY Object representing a ?ticket?- > the namespace should be unique to your async service. The ticket can be > used to poll the service using the xxx_poll method (API TBD) , and the > same ticket can be used to retrieve the result using the xxx_result > method. > I have been reading the above description about asynchronous services, and there is at least one loose points. You can imagine an scenario where we have a replicated service, and that service is asynchronous. A client would choose one of them, but it would be technically difficult to assure the obtained ticked is useable in *each* one of the replicated services. INB guys have at least two huge computer facilities, and they are geographically disperse, which makes difficult to share the same job identifier namespace. Therefore, either each replicated service should have its unique namespace or clients should tie to the chosen services at the beginning. > > Service Testing Metadata it was generally agreed that it is desirable > to have a sample input such that a service can be tested. This will be > made available by the service providers as a string literal in their > Service Signature (this is retrieved by LSID resolution). The string > should be a complete MOBY message (?..) representing a > sample input to that service that will ALWAYS work; where ?work? means > generate an output of the Object type registered in the Service > Signature and in MOBY Central. This input is to be used for testing > that a service is running, but not for validating the output. > Please, don't forget detailed textual descriptions of the services (long description, input & output parameters, examples, external & internal links), objects (long description, what it means each HAS and HASA element, examples, links), and perhaps namespaces, as they should have their place in RDF. Providers are the only responsible to fill these optional, but useful, information fields/tags. Have a nice weekend, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From r.bruskiewich at cgiar.org Sun May 29 20:00:23 2005 From: r.bruskiewich at cgiar.org (Bruskiewich, Richard (IRRI)) Date: Sun, 29 May 2005 17:00:23 -0700 Subject: [MOBY-dev] RE: [MOBY-l] 2 ontologies Message-ID: <2A491C94FFBC5843A212A69CBEA5CEC7021FBC9F@IRRIMAIL.IRRI.CGIARAD.ORG> If by "biological logic" you mean *real* semantics, then I would hazard to say that the domain modeling activity of the Generation Challenge Programme is going in that direction, at least, for crop/plant science (though some of the semantics is generic to all biology, of necessity). It is interesting to note that human beings construct domain models, not machines. Domain models cannot be autogenerated. Real semantics is what sets human beings apart from (practically) the rest of the animal kingdom, let alone, the stupid (but ultra fast) machines that we've created in this era. Richard "Daisy, daaaissy, ...." -----Original Message----- From: Benjamin Good [mailto:bmg at sfu.ca] Sent: Saturday, 2005 May 28 4:42 AM To: mobydev; mobyl Subject: [MOBY-l] 2 ontologies From Yan: "There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? ." -Ben -> I agree with this thinking and in fact that was what I was trying to suggest. However, I think that you have things reversed in the following statement. Yan: "So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." -> Ben As I understand it, the BioMOBY object ontology is meant to describe data-types, not biological logic. It does a nice job of the former but I would say not the latter. My suggestion is to introduce a separate ontology that does describe the biology of the things represented by the data-types (that would NOT include things like "FASTA formatted sequence"!). I think this may happen by default when moby-central merges with Grimoire/Feta, but this list needs to pay attention! I think that it is very important to rectify this confusion between syntax and semantics as soon as we can. What happens when the tools are written that create bioMoby services automatically from websites get going? I think you will quickly see that the moby object ontology loses any notion of "biological logic" as it rapidly becomes populated by perfectly syntactically valid machine produced Objects - and this is GOOD. We WANT thousands of services in there and they may require thousands of new objects! Its important to keep in mind the underlying goals of these things. The Object ontology exists to ensure interoperability - not integration. To me, that means that I can easily consume any service that uses objects from this ontology and it ensures (only helps actually) that the data types produced by service providers are sensible. These SYNTACTIC problems are solved quite nicely by the Object ontology - regardless of the specific serialization you end up choosing and regardless of the name you give to your objects. The SEMANTIC problems associated with INTEGRATION are different, large and growing and will need different solutions. rant over. -Ben http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l From Pieter.Neerincx at wur.nl Mon May 30 05:55:40 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 May 2005 11:55:40 +0200 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> References: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> Message-ID: <2fc226a7fb27830bbeeef667b47a0ce3@wur.nl> On 27 May, 2005, at 21:43, ywong at infobiogen.fr wrote: >> I like Yans idea, but what happens if the object doesn't >> inherit from String, isn't an int or a float? What if the >> object was a schematikonMotifID that inherits from >> SchematikonSegmentID that inherits from Object. What would >> the data:type be in this case? >> >> >> >> >> >> Ed >> >> >> >>> -----Original Message----- >>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >>> dev-bounces at portal.open-bio.org] On Behalf Of >>> ywong at infobiogen.fr >>> Sent: Friday, May 27, 2005 10:55 AM >>> To: markw at illuminae.com; Core developer announcements >>> Subject: Re: [moby] Re: [MOBY-dev] a question and a >>> comment about the new Objectinheritance >>> >>>> On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >>>>> Well, I myself is not the main player in this dicussion >>> about inheriting >>>>> from primitives but as far as I understand, this: >>>>> >>>>>> >>>>>> content here >>>>>> >>>>>> >>>>> is what everybody wanted in the meeting >>>> >>>> Ummmm... I think there was a lot of disagreement about >>> what "everybody" >>>> wanted... By the looks of it now, everybody wanted >>> something different, >>>> but were calling it the same thing :-) Unfortunately, >>> when I asked for >>>> some example objects, nobody volunteered, so we couldn't >>> sort it out at >>>> the time. >>>> >>>> I remember vividly, however, that when I tried to write >>> that (above XML) >>>> on the screen, the room erupted in screams that I was >>> making it all too >>>> complicated, so I don't think that is what people >> wanted. >>> It may be >>>> that we have all had time to digest the issue a bit more >>> deeply now and >>>> have come to the same conclusion? >>>> >>>> M >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>> Sorry I could reply earlier, all our network is in a >>> quagmire... >>> >>> An alternative I would accept: >>> >>> >>> blablablablablablalbalbalblablalbalba >>> >>> >>> An attribute is optional, we keep the actual version >>> without killing >>> everything (adding a subnode and all >>> serializers/deserializers would >>> have to be rewritten!) >>> >>> People using Java will know what is the type of the data >>> by reading this >>> attribute. If it doesn't exist, they should assume that by >>> default, it >>> is a string. >>> >>> Example of DNASequence: >>> >>> >>> >>> >>> ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... >>> >>> >> data:type="int">152 >>> >>> >>> Then we should agree of what "primitives" we have: >>> -string >>> -float >>> -int >>> >>> maybe are there others? >>> >>> It is a quick and dirty solution however it is IMHO >>> cleaner than what I >>> saw in the last example. It has the advantage to keep the >>> "old" object >>> layout but add informations that will greatly help people >>> who implements >>> type sensible clients. >>> >>> Greetings >>> >>> Yan >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > > Simple: > data:type only apply to the content of the tag if it exists so: > > > > The line above means that the content of Object (here nothing) > should be > an integer, but it is void so the line above describes an invalid > integer... > > > > > > > > no data:type attribute and no content so we should deal this object as > we > did before. > > 152 > > no data:type but a content, so the client must treat the content as a > string Like Mark, I really like Yan's proposal for a data:type attribute, but I do think it should not be optional. If the people that use Java have to rely on this attribute to figure out what data type they are parsing, the example object above should be invalid. If 152 would be treated as string by a Java client and as integer by a client written in Perl, parsing BioMOBY data would no longer be language independent and that would be a very bad thing. If we would introduce a data:type attribute, having the element name indicating the same thing is a bit redundant. Furthermore I think it is makes more sense to identify an element based on it's name as compared to having multiple elements with the same name and then using the articleName attribute to figure out what is what. If we have a data:type attribute the element names no longer have to be String, Integer, etc. and we actually completely forget the articleName attribute. This would break a lot of the stuff that is already running though... Cheers, Pieter > > 152 > > the data:type indicates that the content is an integer. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From Pieter.Neerincx at wur.nl Mon May 30 06:14:49 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 May 2005 12:14:49 +0200 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <42978FC7.7030805@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030805@cnb.uam.es> Message-ID: On 27 May, 2005, at 23:23, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi Mark & the MOBYfiers 8-), > > > >> Service Mirrors Mark will change the MOBY Central API such that >> multiple endponts can be registered/returned in a service search. >> This >> will affect the registerService and findService API calls. The >> implication of registering multiple endpoints is that the *identical* >> service is running in all indicated locations, with the same database >> and same software version. These endpoints all share the same Service >> Signature metadata, so they had better be identical! >> > > Also, I can remember we talked about storing updated QoS information, > doesn't it? Thinking on replicated services, each one should have its > own QoS information. > >> >> Async services a few details have to be worked out (I think the >> Spanish >> contingent took on the task of fleshing this out completely), but the >> upshot is that, when a service is registered, it will be assumed to >> have >> four ?method? calls: >> 1) The name of the service (e.g. doBlastAnalysis) >> 2) The name with _async appended (e.g. doBlastAnalysis_async) >> 3) The name with _poll appended (e.g. doBlastAnalysis_poll) >> 4) The name with _result appended (e.g. doBlastAnalyis_result) >> >> The service registration is identical to what it is now, methods 2,3,4 >> are optional and are not explicitly registered. (the ability of a >> service to run asynchronously can be determined by querying the RDF >> metadata through LSID resolution predicates TBD). Calling the >> service >> by name executes the service synchronously exactly as it does >> currently. >> If a service refuses to run synchronously, it returns an empty >> response >> (this is a valid behaviour, and will not break ?old? clients). >> Calling >> the xxx_async method will return a MOBY Object representing a >> ?ticket?- >> the namespace should be unique to your async service. The ticket can >> be >> used to poll the service using the xxx_poll method (API TBD) , and the >> same ticket can be used to retrieve the result using the xxx_result >> method. >> > > I have been reading the above description about asynchronous services, > and there is at least one loose points. You can imagine an scenario > where we have a replicated service, and that service is asynchronous. A > client would choose one of them, but it would be technically difficult > to assure the obtained ticked is useable in *each* one of the > replicated > services. INB guys have at least two huge computer facilities, and they > are geographically disperse, which makes difficult to share the same > job > identifier namespace. Therefore, either each replicated service should > have its unique namespace or clients should tie to the chosen services > at the beginning. If these replicated services share the same namespace, but are served by different service authorities, then a client can simply bind to a single service by it's authority. A combination if service name, service authority and job ID / ticket should be enough to poll a service and get the result back from the same service. Or is too simple and am I missing something... > >> >> Service Testing Metadata it was generally agreed that it is desirable >> to have a sample input such that a service can be tested. This will >> be >> made available by the service providers as a string literal in their >> Service Signature (this is retrieved by LSID resolution). The string >> should be a complete MOBY message (?..) representing a >> sample input to that service that will ALWAYS work; where ?work? means >> generate an output of the Object type registered in the Service >> Signature and in MOBY Central. This input is to be used for testing >> that a service is running, but not for validating the output. >> > > Please, don't forget detailed textual descriptions of the services > (long > description, input & output parameters, examples, external & internal > links), objects (long description, what it means each HAS and HASA > element, examples, links), and perhaps namespaces, as they should have > their place in RDF. Providers are the only responsible to fill these > optional, but useful, information fields/tags. Yes! That would make life much easier. I am currently testing some stuff where I have an async service that has an additional help call. This service is a wrapper for a commandline tool. If you call the service with an empty Moby object it returns an object "ServiceOptions" which HASA String that contains the info which you would normally get form --help on the commandline along with some info about which databases are available and when they were updated. Putting this kind of info in the service signature would make more sense though. Cheers, Pieter > > Have a nice weekend, > Jos? Mar?a > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Mon May 30 10:00:59 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 May 2005 07:00:59 -0700 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030805@cnb.uam.es> Message-ID: <429B1C9B.2060105@illuminae.com> > Yes! That would make life much easier. I am currently testing some > stuff where I have an async service that has an additional help call. > This service is a wrapper for a commandline tool. If you call the > service with an empty Moby object it returns an object > "ServiceOptions" which HASA String that contains the info which you > would normally get form --help on the commandline along with some info > about which databases are available and when they were updated. > Putting this kind of info in the service signature would make more > sense though. Would make more sense, and wouldn't break the API ;-) M From jmfernandez at cnb.uam.es Mon May 30 10:48:32 2005 From: jmfernandez at cnb.uam.es (=?windows-1252?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Mon, 30 May 2005 16:48:32 +0200 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca><42978FC7.7030 805@cnb.uam.es> Message-ID: <429B27C0.6070406@cnb.uam.es> Hi everybody, > > If these replicated services share the same namespace, but are served by > different service authorities, then a client can simply bind to a single > service by it's authority. A combination if service name, service > authority and job ID / ticket should be enough to poll a service and get > the result back from the same service. Or is too simple and am I missing > something... > Well, as far as I can remember from the meeting we agreed that replicated services would be declared as non-replicated ones, but with more than one URL, so all of them share the same (authURI,serviceName) pair. Am I wrong, Mark, Heiko, Dirk? -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From markw at illuminae.com Mon May 30 11:10:01 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 May 2005 08:10:01 -0700 Subject: [moby] Re: [MOBY-dev] Notes from working group 'B' In-Reply-To: <429B27C0.6070406@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> Message-ID: <1117465801.29183.31.camel@mobycentral.mrl.ubc.ca> On Mon, 2005-05-30 at 16:48 +0200, Jos? Mar?a Fern?ndez wrote: > Well, as far as I can remember from the meeting we agreed that > replicated services would be declared as non-replicated ones, but with > more than one URL, so all of them share the same (authURI,serviceName) > pair. Am I wrong, Mark, Heiko, Dirk? That's correct - multiple URL's associated with the same authURI and serviceName. The service metadata can presumably be associated independently with each URL,though we have not yet decided on the predicates/structure we will use. If they are different authorities (this is not the same as saying different URL's) then they have different signatures and are independent registrations in the registry. M -- -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From Pieter.Neerincx at wur.nl Mon May 30 11:30:01 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 May 2005 17:30:01 +0200 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <429B27C0.6070406@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca><42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> Message-ID: <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> Hello again, On 30 May, 2005, at 16:48, Jos? Mar?a Fern?ndez wrote: > Hi everybody, > > > >> >> If these replicated services share the same namespace, but are served >> by >> different service authorities, then a client can simply bind to a >> single >> service by it's authority. A combination if service name, service >> authority and job ID / ticket should be enough to poll a service and >> get >> the result back from the same service. Or is too simple and am I >> missing >> something... >> > > Well, as far as I can remember from the meeting we agreed that > replicated services would be declared as non-replicated ones, but with > more than one URL, so all of them share the same (authURI,serviceName) > pair. Am I wrong, Mark, Heiko, Dirk? Ok, I wasn't able to attend the meeting, so I definitely missed something :(. Anyway, if replicated services will be declared with multiple URLs for the same (authURI,serviceName) combination, then the combination of (authURI,serviceName,URL) will uniquely identify a service. I don't know about the other APIs but with the current Perl API I can already search for the one service that has such a unique combo. So that should be enough for a client to retrieve results from the same async service to which it submitted a job/query :) Is that correct? Cheers, Pieter > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Mon May 30 11:39:05 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 May 2005 08:39:05 -0700 Subject: [moby] Re: [MOBY-dev] Notes from working group 'B' In-Reply-To: <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> Message-ID: <1117467545.29183.35.camel@mobycentral.mrl.ubc.ca> On Mon, 2005-05-30 at 17:30 +0200, Pieter Neerincx wrote: > service. I don't know about the other APIs but with the current Perl > API I can already search for the one service that has such a unique > combo. So that should be enough for a client to retrieve results from > the same async service to which it submitted a job/query :) Is that > correct? Actually, I think this is still an issue. At the moment, and under the proposed API, there is no defined way for a client to interact with the same (replicated) service when it calls an async service as it does when it retrieves the result. The burden of remembering which replicated service it called may have to be client-side unless we can come up with a creative alternative. M -- -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From markw at illuminae.com Mon May 30 17:39:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 May 2005 14:39:09 -0700 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429B758F.5020903@cnb.uam.es> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> Message-ID: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Hiya, We're looking into using mod_jk to do this kind of auto-forwarding of tomcat requests through port 80. I've never done it, and Eddie has only done it on Windows. Once we have played with it a few times and figured out a standard, stable way to do it, we'll add this to the documentation. M On Mon, 2005-05-30 at 22:20 +0200, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi everybody, > I have a different problem. CNB machines are behind a firewall which > doesn't allow a connection to 'strange' ports like 8090 (we have a very > restrictive security policy). I can solve it talking to CNB's sysadmins > (and signing a liability sheet), but it could be an annoyance if we had > to do it for many addresses and/or ports. > > With this annoyance, I'm concerned by those services which live on a > different port from HTTP and HTTPS ones. Those BioMOBY users behind a > firewall (like us) won't be able to use those services, and so they > could think the services are not working. I think we should include some > sort of warning about this potencial problem, and also we should > recommend MOBY service creators to use standard HTTP/HTTPS ports for > their services. > > Best regards, > Jos? Mar?a > > Mark Wilkinson wrote: > > try now. > > > > Sorry about that > > > > M > > > > > > On Wed, 2005-05-18 at 15:07 +0200, David Baux wrote: > > > >>hello, > >>i'd like to use the biomoby tool "Applet to retrieve the RDF Signature > >>of your service" to generate the RDF file of my service. But when I fill > >>in the form with the right Domain and URL, the browser prints: > >> > >> > >> Unable to update your information > >> > >> > >> Make sure that you specify a valid signature url! This field looks > >> like the following: > >> http://myAuthority.domain/path/to/rdf/for/service. Also make sure > >> that you have specified the right case-sensitive service name, if > >> applicable. > >> > >>while the url is: http://tropgenedb.cirad.fr/cgi-bin/biomoby > >> > >>Does somebody know what to do? > >> > >>thanks for your answers > >> > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l > > > > > -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From tmo at ebi.ac.uk Mon May 30 18:32:58 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 30 May 2005 23:32:58 +0100 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429B949A.60101@ebi.ac.uk> Mark Wilkinson wrote: > Hiya, > > We're looking into using mod_jk to do this kind of auto-forwarding of > tomcat requests through port 80. You could do what the EBI does and use the ProxyPass directive in Apache - I don't believe we use any of the mod_jk style connectors at all in our web architecture and it all appears to work well enough. You do occasionally get slightly hard to debug behaviour if something goes wrong but it's a whole lot less hassle to configure and doesn't need any new software. Services we're running such as Martin's SoapLab are exposed like this and it all appears happy. Tom From tmo at ebi.ac.uk Mon May 30 18:32:58 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 30 May 2005 23:32:58 +0100 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429B949A.60101@ebi.ac.uk> Mark Wilkinson wrote: > Hiya, > > We're looking into using mod_jk to do this kind of auto-forwarding of > tomcat requests through port 80. You could do what the EBI does and use the ProxyPass directive in Apache - I don't believe we use any of the mod_jk style connectors at all in our web architecture and it all appears to work well enough. You do occasionally get slightly hard to debug behaviour if something goes wrong but it's a whole lot less hassle to configure and doesn't need any new software. Services we're running such as Martin's SoapLab are exposed like this and it all appears happy. Tom From gss at ncgr.org Tue May 31 11:05:32 2005 From: gss at ncgr.org (Gary Schiltz) Date: Tue, 31 May 2005 10:05:32 -0500 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429C7D3C.1050602@ncgr.org> About a year ago, I looked at connecting Tomcat (5.x) and the Apache HTTP Server (2.x) with little success. If I remember correctly, I got it to work under Windows, but could never get the two to talk under Linux (Red Hat 9). One of Lincoln Stein's students suggested Resin (www.caucho.com) as a Servlet container, and it was very easy to get working with Apache. There is an open source version, which seems fine as far as performance goes. I ended up using Resin for the Semantic MOBY site. // Gary Mark Wilkinson wrote: >Hiya, > >We're looking into using mod_jk to do this kind of auto-forwarding of >tomcat requests through port 80. > >I've never done it, and Eddie has only done it on Windows. Once we have >played with it a few times and figured out a standard, stable way to do >it, we'll add this to the documentation. > >M > > > >>> >>> From jmfernandez at cnb.uam.es Tue May 31 14:26:00 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXo=?=) Date: Tue, 31 May 2005 20:26:00 +0200 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429C7D3C.1050602@ncgr.org> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@moby central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org> Message-ID: <429CAC38.5020609@cnb.uam.es> I have been talking to our webmasters about our Apache configuration, and they showed me the way to configure Apache to map Tomcat services. It is like this one: ProxyPass /thePath http://other.machine/otherPath ProxyPassReverse /thePath http://other.machine/otherPath As you can see, you have to write *twice* the equivalence, but with different commands. The first one (ProxyPass) tells Apache that all queries to /thePath and its subpaths should be rewritten as http://other.machine/otherPath (and its subpaths). The second command (ProxyPassReverse) tells Apache that it must work as a reverse proxy for that path, instead of redirecting the queries with a HTTP 305 code. It is obvius ProxyPass/ProxyPassReverse works because current application servers handle HTTP requests. Tomcat 4 and above *must* do that because they follow the 2.3 servlet specification, which tells that the application server must handle and understand HTTP requests. Best Regards, Jos? Mar?a Gary Schiltz wrote: > About a year ago, I looked at connecting Tomcat (5.x) and the Apache > HTTP Server (2.x) with little success. If I remember correctly, I got it > to work under Windows, but could never get the two to talk under Linux > (Red Hat 9). One of Lincoln Stein's students suggested Resin > (www.caucho.com) as a Servlet container, and it was very easy to get > working with Apache. There is an open source version, which seems fine > as far as performance goes. I ended up using Resin for the Semantic MOBY > site. > > // Gary > > Mark Wilkinson wrote: > >> Hiya, >> We're looking into using mod_jk to do this kind of auto-forwarding of >> tomcat requests through port 80. >> >> I've never done it, and Eddie has only done it on Windows. Once we have >> played with it a few times and figured out a standard, stable way to do >> it, we'll add this to the documentation. >> >> M >> >> >> >>>> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From gss at ncgr.org Tue May 31 14:44:39 2005 From: gss at ncgr.org (Gary Schiltz) Date: Tue, 31 May 2005 13:44:39 -0500 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429CAC38.5020609@cnb.uam.es> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@moby central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org> <429CAC38.5020609@cnb.uam.es> Message-ID: <429CB097.3030407@ncgr.org> Thanks Jos? Mar?a for the information on Apache configuration. That approach would work if you want Tomcat to handle everything under a given path, including HTML, images, etc. However, if you want Apache to handle all HTTP requests, including Perl CGI requests, sessions, etc. and only use Tomcat to handle Servlets and JSP, then I believe you still need to use mod_jk, mod_jk2, or a similar adapter. For example, if you have /foo/bigdoc.html, /foo/hugeimage.jpg, and /foo/index.jsp, you would probably want Apache to deliver bigdoc.html and hugeimage.jpg, but would want Apache to delegate execution of index.jsp to Tomcat. Again, I couldn't get this to work under Red Hat 9, so I used Resin, which works very well with Apache. // Gary Jos? Mar?a Fern?ndez wrote: > I have been talking to our webmasters about our Apache configuration, > and they showed me the way to configure Apache to map Tomcat services. > It is like this one: > > ProxyPass /thePath http://other.machine/otherPath > ProxyPassReverse /thePath http://other.machine/otherPath > > As you can see, you have to write *twice* the equivalence, but with > different commands. The first one (ProxyPass) tells Apache that all > queries to /thePath and its subpaths should be rewritten as > http://other.machine/otherPath (and its subpaths). The second command > (ProxyPassReverse) tells Apache that it must work as a reverse proxy for > that path, instead of redirecting the queries with a HTTP 305 code. > > It is obvius ProxyPass/ProxyPassReverse works because current > application servers handle HTTP requests. Tomcat 4 and above *must* do > that because they follow the 2.3 servlet specification, which tells that > the application server must handle and understand HTTP requests. > > Best Regards, > Jos? Mar?a From jmfernandez at cnb.uam.es Tue May 31 15:42:38 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXogR29uesOhbGV6?=) Date: Tue, 31 May 2005 21:42:38 +0200 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429CB097.3030407@ncgr.org> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@mob y central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org><429CAC38.5020609@cnb.uam. es> <429CB097.3030407@ncgr.org> Message-ID: <429CBE2E.2000706@cnb.uam.es> (Mainly offtopic?) Maybe I'm wrong, but Tomcat already does it inside. Apache only forwards the HTTP query, and Tomcat works as expected with JSPs, because it is its default behaviour when any HTTP query arrives (unless you have reconfigured it). JK modules are dedicated to communicate Apache and Tomcat, so Apache serves static content (which does very well) and Tomcat handles dynamic content (servlets, jsps). When you have a heavy used directory with a mixure of static content files/pages and dynamic content and servlets, then Apache+Tomcat+JK is unbeatable, because even if you need it you can apply some load-balancing techniques (one Apache/many Tomcat workers) in an easy way. The advantages of ProxyPass/ProxyPassReverse are the simplicity and the decoupling effect, because Apache and Tomcat can be started, stopped, managed, upgraded, etc..., with no software dependency (no mod_jk2 to be compiled), and each one is free from the other. Old incarnations of JK modules (mod_webapps) had some problems when Tomcat wasn't running on Apache startup, or when Tomcat was restarted (very common two years ago in a Tomcat development environment). I don't know how well is JK implementation, but our webmaster didn't want more problems than the unavoidable ones, so they are using ProxyPass/ProxyPassReverse). Best Regards, Jos? Mar?a Gary Schiltz wrote: > Thanks Jos? Mar?a for the information on Apache configuration. That > approach would work if you want Tomcat to handle everything under a > given path, including HTML, images, etc. However, if you want Apache to > handle all HTTP requests, including Perl CGI requests, sessions, etc. > and only use Tomcat to handle Servlets and JSP, then I believe you still > need to use mod_jk, mod_jk2, or a similar adapter. For example, if you > have /foo/bigdoc.html, /foo/hugeimage.jpg, and /foo/index.jsp, you would > probably want Apache to deliver bigdoc.html and hugeimage.jpg, but would > want Apache to delegate execution of index.jsp to Tomcat. Again, I > couldn't get this to work under Red Hat 9, so I used Resin, which works > very well with Apache. > > // Gary > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From Pieter.Neerincx at wur.nl Mon May 2 15:36:08 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 2 May 2005 17:36:08 +0200 Subject: [MOBY-dev] SQL dump In-Reply-To: <20050419091628.GN17377@parrot.ebi.ac.uk> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> Message-ID: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Hi all, I'm trying to get an SQL dump from the BioMOBY central. I tried MOBY::CLient::Central::DUMP() from the perl API and a raw SOAP call, but all I get is: 500 Internal Server Error. With SOAP::Lite + 'trace' I also get: ...snip... can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. ...snip... For the complete trace see below. Anyone got an idea what I'm missing here? Any feedback would be appreciated. Cheers, Pieter -------------------------------------------------- SOAP::Lite trace: MOBY Central Data Dump: SOAP::Transport::new: () SOAP::Serializer::new: () SOAP::Deserializer::new: () SOAP::Parser::new: () SOAP::Lite::new: () SOAP::Transport::HTTP::Client::new: () SOAP::Lite::call: () SOAP::Serializer::envelope: () SOAP::Serializer::envelope: DUMP SOAP::Data::new: () SOAP::Data::new: () SOAP::Data::new: () SOAP::Data::new: () SOAP::Transport::HTTP::Client::send_receive: HTTP::Request=HASH(0x8475a84) SOAP::Transport::HTTP::Client::send_receive: POST http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl HTTP/1.1 Accept: text/xml Accept: multipart/* Content-Length: 466 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x8628038) SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error Connection: close Date: Mon, 02 May 2005 15:16:45 GMT Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 Content-Length: 600 Content-Type: text/xml; charset=utf-8 Client-Date: Mon, 02 May 2005 15:16:45 GMT Client-Peer: 198.166.4.225:80 Client-Response-Num: 1 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Servercan't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. SOAP::Deserializer::deserialize: () SOAP::Parser::decode: () 500 Internal Server Error at ./GetDumpRawSOAP.pl line 52 SOAP::Lite::DESTROY: () SOAP::Deserializer::DESTROY: () SOAP::Serializer::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Data::DESTROY: () SOAP::Transport::DESTROY: () SOAP::Transport::HTTP::Client::DESTROY: () SOAP::Parser::DESTROY: () From senger at ebi.ac.uk Mon May 2 17:04:21 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 2 May 2005 18:04:21 +0100 (BST) Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: > For the complete trace see below. Anyone got an idea what I'm missing > here? Any feedback would be appreciated. > I can confirm the same problem using Java client. This is what I am sending: POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1 Host: mobycentral.cbr.nrc.ca:9999 Cache-Control: no-cache Pragma: no-cache SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" Content-Length: 402 And I am getting the same error message as with the Perl client: HTTP/1.0 500 Internal Server Error Date: Mon, 02 May 2005 17:03:53 GMT Content-Length: 600 Content-Type: text/xml; charset=utf-8 Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Server can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. Cheers, 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 senger at ebi.ac.uk Mon May 2 17:04:21 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 2 May 2005 18:04:21 +0100 (BST) Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: > For the complete trace see below. Anyone got an idea what I'm missing > here? Any feedback would be appreciated. > I can confirm the same problem using Java client. This is what I am sending: POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1 Host: mobycentral.cbr.nrc.ca:9999 Cache-Control: no-cache Pragma: no-cache SOAPAction: "http://mobycentral.cbr.nrc.ca/MOBY/Central#DUMP" Content-Length: 402 And I am getting the same error message as with the Perl client: HTTP/1.0 500 Internal Server Error Date: Mon, 02 May 2005 17:03:53 GMT Content-Length: 600 Content-Type: text/xml; charset=utf-8 Server: Apache/2.0.53 (Unix) mod_perl/1.999.21 Perl/v5.8.5 SOAPServer: SOAP::Lite/Perl/0.60 SOAP-ENV:Server can't open mobycentral for dumping at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 2921, line 36. Cheers, 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 Mon May 2 18:11:32 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 02 May 2005 11:11:32 -0700 Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: <42766D54.2060602@illuminae.com> fixed From markw at illuminae.com Mon May 2 18:11:32 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 02 May 2005 11:11:32 -0700 Subject: [MOBY-dev] SQL dump In-Reply-To: <6dd90221082e2e4d39130e5c478a6662@wur.nl> References: <20050120175859.GA7254@parrot.ebi.ac.uk> <20050419091628.GN17377@parrot.ebi.ac.uk> <6dd90221082e2e4d39130e5c478a6662@wur.nl> Message-ID: <42766D54.2060602@illuminae.com> fixed From senger at ebi.ac.uk Mon May 2 18:16:32 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 2 May 2005 19:16:32 +0100 (BST) Subject: [MOBY-dev] SQL dump In-Reply-To: <42766D54.2060602@illuminae.com> Message-ID: > fixed > Confirmed. 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 senger at ebi.ac.uk Mon May 2 18:16:32 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 2 May 2005 19:16:32 +0100 (BST) Subject: [MOBY-dev] SQL dump In-Reply-To: <42766D54.2060602@illuminae.com> Message-ID: > fixed > Confirmed. 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 Pieter.Neerincx at wur.nl Tue May 3 11:51:32 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 3 May 2005 13:51:32 +0200 Subject: [MOBY-dev] SQL dump In-Reply-To: References: Message-ID: <818098468df1567f6549a31c365fd008@wur.nl> On 2 May, 2005, at 20:16, Martin Senger wrote: >> fixed >> > Confirmed. > Martin Check, works here again as well with Perl API. Thanx for the fast fix Mark! Cheers, Pieter From senger at ebi.ac.uk Tue May 17 14:36:19 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 17 May 2005 15:36:19 +0100 (BST) Subject: [MOBY-dev] how to get LSID of the registered service In-Reply-To: <1116254505.13769.68.camel@mobycentral.mrl.ubc.ca> Message-ID: Mark, Quite a long time ago we have discussed the inconsistency in the returned names from the registry. Recently Mathieu asked me how to get an LSID of a service (in order to ask for metadata etc.) so I have looked at the names again. It seems that: 1) One cannot get an LSID - using the registry API. The findService method seems to return only the simple service name. 2) The extended API (the rules for getting URLs returning RDF documents) is not yet in place. And more, my pretty old RDF document (so this may not be true anymore) does not show LSIDs either. 3) Regarding the names of data types, the situation is better (because one *can* get an LSID of a data type) - but not consistent: the method retriveObjectNames returns simple names and the method retrieveObjectDefinition returns LSIDs. I think that we should fix/solve/explain this asap. Any plans or suggestions for it? Cheers, Martin PS. It would also help if you explain in BioMoby API an official way how to get these RDF documents. I know that you mentioned that there was "an XML standard way" but I doubt that it was clear to most of us :-). Thanks. M. -- 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 May 17 15:13:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 17 May 2005 08:13:09 -0700 Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: References: Message-ID: <1116342789.19327.21.camel@mobycentral.mrl.ubc.ca> Hi Martin, I've been thinking about that problem quite a bit, actually. I know that the existing system is a bit of a mish-mash, and needs to be cleaned up. My suggested solution is as follows: for every XML tag in an outgoing MOBY Central API message, where the content of the tag is an element in one of the four MOBY ontologies, there should be an attribute lsid='xxx' indicating the LSID corresponding to the human-readable content of the XML tag. e.g. Service_Ontology_Term 1 moby your at email.addy.here http://service.endpoint.here/scriptname ObjectOntologyTerm NamespaceTerm ObjectOntologyTerm NamespaceTerm I suspect that we will eventually need to make the same true for inbound MOBY Central API messages, since we now have distributed ontologies so I cannot be sure if the object named GeneClass is part of the biomoby cenral object ontolgy, or one of the distributed ontologies... and as such, a lookup on that object by its human readable name might be a disaster! On the other hand, the human readable names are so friendly that I think we would be shooting ourselves in the foot if we discarded them altogether... Does that solution suit everyone? Are there any objections? I will be sure to make it entirely consistent such that the LSID is NOT present in the content of the XML tag, but only in the attribute. Let me know if there are any objections to this, and if not, I will try to implement this before next week. M On Tue, 2005-05-17 at 15:36 +0100, Martin Senger wrote: > Mark, > Quite a long time ago we have discussed the inconsistency in the > returned names from the registry. Recently Mathieu asked me how to get an > LSID of a service (in order to ask for metadata etc.) so I have looked at > the names again. It seems that: > > 1) One cannot get an LSID - using the registry API. The findService > method seems to return only the simple service name. > > 2) The extended API (the rules for getting URLs returning RDF > documents) is not yet in place. And more, my pretty old RDF document (so > this may not be true anymore) does not show LSIDs either. > > 3) Regarding the names of data types, the situation is better (because > one *can* get an LSID of a data type) - but not consistent: the method > retriveObjectNames returns simple names and the method > retrieveObjectDefinition returns LSIDs. > > I think that we should fix/solve/explain this asap. Any plans or > suggestions for it? > > Cheers, > Martin > > PS. It would also help if you explain in BioMoby API an official way how > to get these RDF documents. I know that you mentioned that there was "an > XML standard way" but I doubt that it was clear to most of us :-). > Thanks. M. > From senger at ebi.ac.uk Tue May 17 15:39:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 17 May 2005 16:39:31 +0100 (BST) Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: <1116342789.19327.21.camel@mobycentral.mrl.ubc.ca> Message-ID: Hi, > My suggested solution is as follows: for every XML tag in an outgoing > MOBY Central API message, where the content of the tag is an element in > one of the four MOBY ontologies, there should be an attribute lsid='xxx' > indicating the LSID corresponding to the human-readable content of the > XML tag. > This seems quite a good and reasonable solution to me. > I suspect that we will eventually need to make the same true for inbound > MOBY Central API messages, since we now have distributed ontologies so I > cannot be sure if the object named GeneClass is part of the biomoby > cenral object ontolgy, or one of the distributed ontologies... > I know that you keep repeating this, and I keep repeating that it is an implementation detail :-) I truly believe that you are confusing us by talking about various ontologies without changing the Central API. As long as the API does not change we *do not see" any distributed ontologies - so for us, the mortals, there is no difference between "the biomoby central object ontology" and any distributed ontology. Is this true or am I still missing anything? > On the other hand, the human readable names are so friendly that I think > we would be shooting ourselves in the foot if we discarded them > altogether... > Correct, I agree. I think that for inbound messages the simple names are fine. The users can keep the LSIDs only for calling the BioMoby LSID resolution service. That reminds me: is the LSID resolution service already running - or it is a work in progress? > Let me know if there are any objections to this, and if not, I will try > to implement this before next week. > This is a fantastic time plan! Could you perhaps add first the changes into the API document - and let us know - so we can change in advance also our libraries (in jMoby in my case)? Cheers, 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 May 17 15:50:27 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 17 May 2005 08:50:27 -0700 Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: References: Message-ID: <1116345027.19327.42.camel@mobycentral.mrl.ubc.ca> On Tue, 2005-05-17 at 16:39 +0100, Martin Senger wrote: > This seems quite a good and reasonable solution to me. Super - any objections from others? > I know that you keep repeating this, and I keep repeating that it is an > implementation detail :-) I truly believe that you are confusing us by > talking about various ontologies without changing the Central API. As long > as the API does not change we *do not see" any distributed ontologies - so > for us, the mortals, there is no difference between "the biomoby central > object ontology" and any distributed ontology. Is this true or am I still > missing anything? Well... there is the API, and then there is the reality. There are currently 3 MOBY Centrals (that I know about) that are interacting *exclusively* with their local ontologies, despite the fact that this is not officially supported by the API. I grant you that this is "not our problem"... but at the end of the day it IS our problem, since it shows that the behaviour and desire of the community we are serving is to have distributed ontologies. As such, the faster I make the official API compatible with what the user community is already doing, the faster we will all be able to work together again :-) > That reminds me: is the LSID resolution service already running - or it > is a work in progress? It is running - metadata resolution only for Namespaces, Services, Objects, and ServiceInstances. > This is a fantastic time plan! I'm feeling ambitious ;-) > Could you perhaps add first the changes into the API document - and let > us know - so we can change in advance also our libraries (in jMoby in my > case)? OK. Unless I hear any objections over the next day or two I will work on these code changes when I get back from California on Sunday... ...oh... oops! Perhaps it will be delayed longer than that... I forgot that my laptop was stolen last week, so I don't have a way to code from home anymore :-/ (also, all of my notes from the working group session were stolen along with it... if anyone has notes about what was decided can you post them to the list? thanks!) Anyway, I will get the API updated and the code updated ASAP. M From senger at ebi.ac.uk Tue May 17 15:56:34 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 17 May 2005 16:56:34 +0100 (BST) Subject: [MOBY-dev] Re: how to get LSID of the registered service In-Reply-To: <1116345027.19327.42.camel@mobycentral.mrl.ubc.ca> Message-ID: > As such, the faster I make the official API compatible with what the > user community is already doing, the faster we will all be able to work > together again :-) > That's exactly what I wish to have. I see that you are listening to my "voice in the desert". Thanks. > that my laptop was stolen last week > My condolences - that's must be awfull! Cheers, 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 Thu May 19 19:17:19 2005 From: simont at mcw.edu (Twigger Simon) Date: Thu, 19 May 2005 14:17:19 -0500 Subject: [MOBY-dev] last weeks issue of science Message-ID: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> Did people see last week's edition of Science with a special section on distributed computing? Lots of stuff on web services, etc. Im still reading it but havent see a mention of MOBY in there as yet. I wonder if there is scope for a follow up letter to Science commenting on this special edition and emphasizing the benefits of MOBY, its scope so far, goals, etc. Might not fly but then again you never know. Simon. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From duncan.hull at cs.man.ac.uk Fri May 20 09:25:30 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri, 20 May 2005 10:25:30 +0100 Subject: [MOBY-dev] last weeks issue of science In-Reply-To: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> References: <918684B2-E555-42E5-9432-3DF1FBF3DA19@mcw.edu> Message-ID: <428DAD0A.8090104@cs.man.ac.uk> Hi Simon Twigger Simon wrote: > Did people see last week's edition of Science with a special section > on distributed computing? There are two articles in Science issue on Distributed computing that mention myGrid, which uses biomoby services. If you write them a letter it would be worth pointing this out. Cyberinfrastructure for e-Science Tony Hey and Anne E. Trefethen http://www.sciencemag.org/cgi/content/abstract/308/5723/817?etoc p. 817 Cyberinfrastructure: Empowering a "Third Way" in Biomedical Research Kenneth H. Buetow http://www.sciencemag.org/cgi/content/abstract/308/5723/821?etoc p. 821 Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From senger at ebi.ac.uk Tue May 24 15:19:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 24 May 2005 16:19:12 +0100 (BST) Subject: [MOBY-dev] jMoby actions from the Vancouver meeting Message-ID: Dear moby-ers, I have commited changes (thanks to help by Eddie, Ben, Paul and others) we have discussed in Vancouver regarding the Java code base ("jMoby"). Please look at the new jMoby documentation (http://www.biomoby.org/moby-live/Java/docs/index.html) which is now being updated every few hours automatically. Which means - when you add new code or documentation into 'moby-live/Java' it will soon appear on the main biomoby pages. Please feel free to comment on the way how we create and share Java code base - because that is important for all us, Java developers in Moby world. Regards, 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 May 24 23:47:15 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 24 May 2005 16:47:15 -0700 Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Well... the time has come :-( We need to break many of the existing services in order to make this last change leading to the 1.0 API. The conclusion we came to at the meeting is that inheriting from the MOBY primitives was bad bad bad. As such, all primitives will continue to be MOBY objects, but nothing can inherit from them. Objects that require content (e.g. our Genbank Flat file object) will now be re- defined to HASA String rather than ISA string. Comically, this change in the API doesn't require any changes to the code, but nevertheless it will break many services out there! We just had a lab meeting and we made some decisions about how we think the new objects should look. The plan for the moment is to change the ISA's to HASA's when an object inherits from a primitive, and to make the HASA articleName be the same as the parent object type. Therefore the existing MOBY Object: Content Here will become: Content Here It's a shame to break so many services just when the latest paper has come out and people are madly playing with MOBY, but... it's all for the best! This change to the API will make things much easier in the long run. If anyone has any objections to this please voice them ASAP. It would be good to make this change before the end of the month if at all possible. Cheers! Mark From senger at ebi.ac.uk Wed May 25 07:49:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 08:49:41 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Message-ID: > Content Here > > > will become: > > > Content > Here > > Just a question: where do the 'ns' and 'id' in come from? 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 senger at ebi.ac.uk Wed May 25 07:49:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 08:49:41 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1116978435.1325.76.camel@mobycentral.mrl.ubc.ca> Message-ID: > Content Here > > > will become: > > > Content > Here > > Just a question: where do the 'ns' and 'id' in come from? 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 rebecca.ernst at gsf.de Wed May 25 07:56:26 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed, 25 May 2005 09:56:26 +0200 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <42942FAA.8030008@gsf.de> I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From rebecca.ernst at gsf.de Wed May 25 07:56:26 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed, 25 May 2005 09:56:26 +0200 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <42942FAA.8030008@gsf.de> I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Wed May 25 13:41:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed, 25 May 2005 13:41:47 +0000 GMT Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> We briefly said that, but discarded the idea almost immediately. Primitives must be objects in moby so that services can operate on primitives (and be discoverable). So, yes, ns and I'd come from Object. Objections? Alternatives? M -----Original Message----- From: Rebecca Ernst Date: Wed, 25 May 2005 09:56:26 To:Core developer announcements Cc:mobydev , markw at illuminae.com Subject: Re: [MOBY-dev] Breakin' the services for the final API I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Wed May 25 13:41:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed, 25 May 2005 13:41:47 +0000 GMT Subject: [MOBY-dev] Breakin' the services for the final API Message-ID: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> We briefly said that, but discarded the idea almost immediately. Primitives must be objects in moby so that services can operate on primitives (and be discoverable). So, yes, ns and I'd come from Object. Objections? Alternatives? M -----Original Message----- From: Rebecca Ernst Date: Wed, 25 May 2005 09:56:26 To:Core developer announcements Cc:mobydev , markw at illuminae.com Subject: Re: [MOBY-dev] Breakin' the services for the final API I guess they are coming from the the base moby object as Mark told that primitives will still be moby objects.. mmmh... I don't want to bring it all up again but didn't we say that primitives should NOT be Moby objects at all? Rebecca Martin Senger wrote: >>Content Here >> >> >>will become: >> >> >> Content >>Here >> >> >> >> > Just a question: where do the 'ns' and 'id' in come from? > > Martin > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Wed May 25 13:50:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 14:50:41 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> Message-ID: > So, yes, ns and I'd come from Object. > Well, it means that we have the same 'ns' and 'id' on two places now. Why? I understand that a primitive object must have 'ns' and 'id' if a service operates on that primitive. But if the primitive is in HASA? 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 senger at ebi.ac.uk Wed May 25 13:50:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 14:50:41 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1067728662-1117028549-cardhu_blackberry.rim.net-13781-@engine09-cell01> Message-ID: > So, yes, ns and I'd come from Object. > Well, it means that we have the same 'ns' and 'id' on two places now. Why? I understand that a primitive object must have 'ns' and 'id' if a service operates on that primitive. But if the primitive is in HASA? 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 Wed May 25 14:08:42 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 25 May 2005 07:08:42 -0700 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> On Wed, 2005-05-25 at 14:50 +0100, Martin Senger wrote: > Well, it means that we have the same 'ns' and 'id' on two places now. No. Just like any other object, the namespace and id are associated with whichever object is most appropriate, and may be blank. Nothing has changed in that regard. > Why? I understand that a primitive object must have 'ns' and 'id' if a > service operates on that primitive. But if the primitive is in HASA? This is just like any other HASA. AnnotatedSequence HASA Sequence -> Both the AnnotatedSequence and the Sequence object it contains have their own namespace and id, and these are not identical in intent nor meaning. The AnnotatedSequence might have a namespace representing the annotating body, and the Sequence it contains may have a namespace representing the authority from which that sequence was derived. M From senger at ebi.ac.uk Wed May 25 14:15:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 15:15:49 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> Message-ID: > No. Just like any other object, the namespace and id are associated > with whichever object is most appropriate, and may be blank. Nothing > has changed in that regard. > Generally speaking, you are right. But I was not speaking generally, I was referring to the case when we convert a current object (that inherits from a primitive) into a new object with a primitive type in its HASA. In this case we do not have more than one 'ns' and 'id' so if we put it into HASA mamber it must be the same as in the upper level. That's why I said that we have the 'ns' and 'id' same in two places - and we do not need it I still think. Am I right? 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 senger at ebi.ac.uk Wed May 25 14:15:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 25 May 2005 15:15:49 +0100 (BST) Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: <1117030122.25071.18.camel@mobycentral.mrl.ubc.ca> Message-ID: > No. Just like any other object, the namespace and id are associated > with whichever object is most appropriate, and may be blank. Nothing > has changed in that regard. > Generally speaking, you are right. But I was not speaking generally, I was referring to the case when we convert a current object (that inherits from a primitive) into a new object with a primitive type in its HASA. In this case we do not have more than one 'ns' and 'id' so if we put it into HASA mamber it must be the same as in the upper level. That's why I said that we have the 'ns' and 'id' same in two places - and we do not need it I still think. Am I right? 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 Wed May 25 14:21:54 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 25 May 2005 07:21:54 -0700 Subject: [MOBY-dev] Breakin' the services for the final API In-Reply-To: References: Message-ID: <1117030914.25071.23.camel@mobycentral.mrl.ubc.ca> I am assuming that the ns and id of the contained object (the primitive) will be blank, unless there is a good reason to put something in there. This is quite typical MOBYesque behaviour. M On Wed, 2005-05-25 at 15:15 +0100, Martin Senger wrote: > > No. Just like any other object, the namespace and id are associated > > with whichever object is most appropriate, and may be blank. Nothing > > has changed in that regard. > > > Generally speaking, you are right. > But I was not speaking generally, I was referring to the case when we > convert a current object (that inherits from a primitive) into a new > object with a primitive type in its HASA. In this case we do not have more > than one 'ns' and 'id' so if we put it into HASA mamber it must be the > same as in the upper level. That's why I said that we have the 'ns' and > 'id' same in two places - and we do not need it I still think. Am I right? > > Martin > From markw at illuminae.com Wed May 25 16:32:54 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 25 May 2005 09:32:54 -0700 Subject: [MOBY-dev] a question and a comment about the new Object inheritance Message-ID: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Hi all, So, I just went through and updated all of my services to follow the new Object inheritance system. It took 5 minutes :-) Turns out that most of my services only output "Object" anyway, so they don't need any work, and the ones that output other things like DNASequence and GO_Term were already following the proposed API anyway, so... only TWO of my services actually were affected by the proposed change! I hope that others have the same experience. I did, however, notice a potential hiccup that we didn't foresee at the meeting. At the moment, binary data in MOBY is passed as a child of base-64-encoded, which is a child of String. Under the new system, we can't have children of String, so do we then need a new primitive class for binary data? I think it still needs to be b64 encoded, but it seems to me that it does need its own primitive now. opinions anyone? M From bmg at sfu.ca Thu May 26 01:03:12 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed, 25 May 2005 21:03:12 -0400 Subject: [MOBY-dev] a question and a comment about the new Object inheritance In-Reply-To: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> References: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Message-ID: It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From bmg at sfu.ca Thu May 26 01:03:12 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed, 25 May 2005 21:03:12 -0400 Subject: [MOBY-dev] a question and a comment about the new Object inheritance In-Reply-To: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> References: <1117038774.25071.85.camel@mobycentral.mrl.ubc.ca> Message-ID: It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From markw at illuminae.com Thu May 26 01:05:14 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 26 May 2005 01:05:14 +0000 GMT Subject: [MOBY-dev] a question and a comment about the new Objectinheritance Message-ID: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Good idea! The reason they weren't implemented initially was simple lack of need. M -----Original Message----- From: Benjamin Good Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements , markw at illuminae.com Cc:mobydev Subject: Re: [MOBY-dev] a question and a comment about the new Object inheritance It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Thu May 26 01:05:14 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 26 May 2005 01:05:14 +0000 GMT Subject: [MOBY-dev] a question and a comment about the new Objectinheritance Message-ID: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Good idea! The reason they weren't implemented initially was simple lack of need. M -----Original Message----- From: Benjamin Good Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements , markw at illuminae.com Cc:mobydev Subject: Re: [MOBY-dev] a question and a comment about the new Object inheritance It might actually make sense to implement a few more primitives to facilitate WSDL interoperability. Below see a set of standard primitives from the Axis user-guide. (Primitives being the things in the xml message that easily bind to existing Java classes). I wasn't around when you picked the ones you did, so maybe there are reasons not to include all of these? Standard mappings from WSDL to Java xsd:base64Binary -> byte[] xsd:boolean -> boolean xsd:byte -> byte xsd:dateTime -> java.util.Calendar xsd:decimal -> java.math.BigDecimal xsd:double -> double xsd:float -> float xsd:hexBinary -> byte[] xsd:int -> int xsd:integer -> java.math.BigInteger xsd:long -> long xsd:QName -> javax.xml.namespace.QName xsd:short -> short xsd:string -> java.lang.String -ben On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > Hi all, > > So, I just went through and updated all of my services to follow the > new > Object inheritance system. It took 5 minutes :-) Turns out that most > of > my services only output "Object" anyway, so they don't need any work, > and the ones that output other things like DNASequence and GO_Term were > already following the proposed API anyway, so... only TWO of my > services > actually were affected by the proposed change! I hope that others have > the same experience. > > I did, however, notice a potential hiccup that we didn't foresee at the > meeting. At the moment, binary data in MOBY is passed as a child of > base-64-encoded, which is a child of String. Under the new system, we > can't have children of String, so do we then need a new primitive class > for binary data? I think it still needs to be b64 encoded, but it > seems > to me that it does need its own primitive now. > > opinions anyone? > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From ywong at infobiogen.fr Thu May 26 08:19:58 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu, 26 May 2005 10:19:58 +0200 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Message-ID: <429586AE.1080306@infobiogen.fr> mark wilkinson wrote: >Good idea! > >The reason they weren't implemented initially was simple lack of need. > >M > >-----Original Message----- >From: Benjamin Good >Date: Wed, 25 May 2005 21:03:12 >To:Core developer announcements , markw at illuminae.com >Cc:mobydev >Subject: Re: [MOBY-dev] a question and a comment about the new Object > inheritance > >It might actually make sense to implement a few more primitives to >facilitate WSDL interoperability. Below see a set of standard >primitives from the Axis user-guide. (Primitives being the things in >the xml message that easily bind to existing Java classes). I wasn't >around when you picked the ones you did, so maybe there are reasons not >to include all of these? > >Standard mappings from WSDL to Java >xsd:base64Binary -> byte[] >xsd:boolean -> boolean >xsd:byte -> byte >xsd:dateTime -> java.util.Calendar >xsd:decimal -> java.math.BigDecimal >xsd:double -> double >xsd:float -> float >xsd:hexBinary -> byte[] >xsd:int -> int >xsd:integer -> java.math.BigInteger >xsd:long -> long >xsd:QName -> javax.xml.namespace.QName >xsd:short -> short >xsd:string -> java.lang.String > >-ben > > > >On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > > > >>Hi all, >> >>So, I just went through and updated all of my services to follow the >>new >>Object inheritance system. It took 5 minutes :-) Turns out that most >>of >>my services only output "Object" anyway, so they don't need any work, >>and the ones that output other things like DNASequence and GO_Term were >>already following the proposed API anyway, so... only TWO of my >>services >>actually were affected by the proposed change! I hope that others have >>the same experience. >> >>I did, however, notice a potential hiccup that we didn't foresee at the >>meeting. At the moment, binary data in MOBY is passed as a child of >>base-64-encoded, which is a child of String. Under the new system, we >>can't have children of String, so do we then need a new primitive class >>for binary data? I think it still needs to be b64 encoded, but it >>seems >>to me that it does need its own primitive now. >> >>opinions anyone? >> >>M >> >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> >> >http://bioinfo.icapture.ubc.ca/bgood >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > >-- >Mark Wilkinson >...on the road! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > Some remarks about Primitives and ontology: First: Do you think that FF is an integer??? If you say no, then you are wrong because FF is a valid hexadecimal REPRESENTATION of an integer number: 255 Reason: The client give the meaning for a message. Forany ordinary human who achieved child school FF is not an integer but for a computer IT CAN BE! Of course it is a bit extreme as an example. We all agree, by convention, that integers are written with Arab figures. In France (I don't know how it is in the rest of Europe) floating numbers are described as 3,1415 instead of 3.1415 (comma instead of point) In this case also, we agree by convention, that floating numbers use the american representation (integer part point fractional part etc..) Did you know that a Unicode string was inherited from a string ??? to display exotic but useful characters that does not exist in English (I don't speak of the strange french characters but also for spanish german etc..)!) and why not Bytes ??? after all a string is an array of bytes so bytes should be the actual primitive (String is an object has Byte) etc.. etc.. In java by default, all strings are unicode strings (AFAIK) but not all language adopted this convention. Primitives are computer related problems. I don't think it is wise to implement primitives inside the ontology because it is not in its place! Primitives were intended to solve problems of performance in language like Java (just see the superb mess between an Integer and an int both speaks about the same mathematical object everybody knows BUT for performance issues, it has been implemented this way poisoning life of millions software enginner and writers - you don't find that kind of issue in other languages -) As I understand from Moby and the ontology of Moby, we should not mix computer related problems with "Business logic" related problems. did you know that in ADA (for strict type checking and overflow control) you can actually subclass an integer in order to define the precision you want in your numbers and it doesn't violate (in any case) the object programming paragdim. For example: subtype Natural is Integer range 0.. Integer'Last; subtype Positive is Integer range 1.. Integer'Last; (I hope no one will have a heart attack on seeing these two lines :p) So if you want to know if an Integer is an integer CAST it (that what I do in Python (for the object mapping with bioMoby XML) ) for example with java use Integer.parse(etc) for Python use int(string) etc.. etc.. These instructions tells the program that the content of the XML is an integer (according to your language convention) I think I have been clear and hope I didn't bash anyone too hard :p From ywong at infobiogen.fr Thu May 26 08:19:58 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu, 26 May 2005 10:19:58 +0200 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> Message-ID: <429586AE.1080306@infobiogen.fr> mark wilkinson wrote: >Good idea! > >The reason they weren't implemented initially was simple lack of need. > >M > >-----Original Message----- >From: Benjamin Good >Date: Wed, 25 May 2005 21:03:12 >To:Core developer announcements , markw at illuminae.com >Cc:mobydev >Subject: Re: [MOBY-dev] a question and a comment about the new Object > inheritance > >It might actually make sense to implement a few more primitives to >facilitate WSDL interoperability. Below see a set of standard >primitives from the Axis user-guide. (Primitives being the things in >the xml message that easily bind to existing Java classes). I wasn't >around when you picked the ones you did, so maybe there are reasons not >to include all of these? > >Standard mappings from WSDL to Java >xsd:base64Binary -> byte[] >xsd:boolean -> boolean >xsd:byte -> byte >xsd:dateTime -> java.util.Calendar >xsd:decimal -> java.math.BigDecimal >xsd:double -> double >xsd:float -> float >xsd:hexBinary -> byte[] >xsd:int -> int >xsd:integer -> java.math.BigInteger >xsd:long -> long >xsd:QName -> javax.xml.namespace.QName >xsd:short -> short >xsd:string -> java.lang.String > >-ben > > > >On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: > > > >>Hi all, >> >>So, I just went through and updated all of my services to follow the >>new >>Object inheritance system. It took 5 minutes :-) Turns out that most >>of >>my services only output "Object" anyway, so they don't need any work, >>and the ones that output other things like DNASequence and GO_Term were >>already following the proposed API anyway, so... only TWO of my >>services >>actually were affected by the proposed change! I hope that others have >>the same experience. >> >>I did, however, notice a potential hiccup that we didn't foresee at the >>meeting. At the moment, binary data in MOBY is passed as a child of >>base-64-encoded, which is a child of String. Under the new system, we >>can't have children of String, so do we then need a new primitive class >>for binary data? I think it still needs to be b64 encoded, but it >>seems >>to me that it does need its own primitive now. >> >>opinions anyone? >> >>M >> >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> >> >http://bioinfo.icapture.ubc.ca/bgood >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > >-- >Mark Wilkinson >...on the road! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > Some remarks about Primitives and ontology: First: Do you think that FF is an integer??? If you say no, then you are wrong because FF is a valid hexadecimal REPRESENTATION of an integer number: 255 Reason: The client give the meaning for a message. Forany ordinary human who achieved child school FF is not an integer but for a computer IT CAN BE! Of course it is a bit extreme as an example. We all agree, by convention, that integers are written with Arab figures. In France (I don't know how it is in the rest of Europe) floating numbers are described as 3,1415 instead of 3.1415 (comma instead of point) In this case also, we agree by convention, that floating numbers use the american representation (integer part point fractional part etc..) Did you know that a Unicode string was inherited from a string ??? to display exotic but useful characters that does not exist in English (I don't speak of the strange french characters but also for spanish german etc..)!) and why not Bytes ??? after all a string is an array of bytes so bytes should be the actual primitive (String is an object has Byte) etc.. etc.. In java by default, all strings are unicode strings (AFAIK) but not all language adopted this convention. Primitives are computer related problems. I don't think it is wise to implement primitives inside the ontology because it is not in its place! Primitives were intended to solve problems of performance in language like Java (just see the superb mess between an Integer and an int both speaks about the same mathematical object everybody knows BUT for performance issues, it has been implemented this way poisoning life of millions software enginner and writers - you don't find that kind of issue in other languages -) As I understand from Moby and the ontology of Moby, we should not mix computer related problems with "Business logic" related problems. did you know that in ADA (for strict type checking and overflow control) you can actually subclass an integer in order to define the precision you want in your numbers and it doesn't violate (in any case) the object programming paragdim. For example: subtype Natural is Integer range 0.. Integer'Last; subtype Positive is Integer range 1.. Integer'Last; (I hope no one will have a heart attack on seeing these two lines :p) So if you want to know if an Integer is an integer CAST it (that what I do in Python (for the object mapping with bioMoby XML) ) for example with java use Integer.parse(etc) for Python use int(string) etc.. etc.. These instructions tells the program that the content of the XML is an integer (according to your language convention) I think I have been clear and hope I didn't bash anyone too hard :p From bmg at sfu.ca Thu May 26 11:35:17 2005 From: bmg at sfu.ca (Benjamin Good) Date: Thu, 26 May 2005 07:35:17 -0400 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429586AE.1080306@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> Message-ID: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Hi Yan, You make many good points (despite your anti-Java vibe!). The reason that we suggest keeping the primitives in their somewhat strange location within the object ontology is to provide the opportunity for low level services to be discovered in the same manner as all the other services. For example, say we want to post a service that does arithmetic operations or String concatenations or something. If we use the suggested approach, such services can be discovered using exactly the same mechanism that all other services can be discovered. If on the other hand we completely separate these primitives from the ontology, we will have to invent new discovery protocols for handling this use case. You are right, this is a strange beast of an ontology. Its principal purpose is to describe the nature of being a data-type. As such, including descriptions of what it means to be a primitive piece of a data-type does not seem wrong. I think that when we start using a more typical ontology in addition to this one, whose purpose is to describe the nature of the information represented by these data-types, the distinction will be more clear and the real utility of the Object ontology will be made less ambiguous. -Ben On May 26, 2005, at 4:19 AM, Yan Wong wrote: > mark wilkinson wrote: > >> Good idea! >> The reason they weren't implemented initially was simple lack of need. >> >> M >> >> -----Original Message----- >> From: Benjamin Good >> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >> , markw at illuminae.com >> Cc:mobydev >> Subject: Re: [MOBY-dev] a question and a comment about the new Object >> inheritance >> >> It might actually make sense to implement a few more primitives to >> facilitate WSDL interoperability. Below see a set of standard >> primitives from the Axis user-guide. (Primitives being the things in >> the xml message that easily bind to existing Java classes). I wasn't >> around when you picked the ones you did, so maybe there are reasons >> not to include all of these? >> >> Standard mappings from WSDL to Java >> xsd:base64Binary -> byte[] >> xsd:boolean -> boolean >> xsd:byte -> byte >> xsd:dateTime -> java.util.Calendar >> xsd:decimal -> java.math.BigDecimal >> xsd:double -> double >> xsd:float -> float >> xsd:hexBinary -> byte[] >> xsd:int -> int >> xsd:integer -> java.math.BigInteger >> xsd:long -> long >> xsd:QName -> javax.xml.namespace.QName >> xsd:short -> short >> xsd:string -> java.lang.String >> >> -ben >> >> >> >> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> So, I just went through and updated all of my services to follow the >>> new >>> Object inheritance system. It took 5 minutes :-) Turns out that >>> most of >>> my services only output "Object" anyway, so they don't need any work, >>> and the ones that output other things like DNASequence and GO_Term >>> were >>> already following the proposed API anyway, so... only TWO of my >>> services >>> actually were affected by the proposed change! I hope that others >>> have >>> the same experience. >>> >>> I did, however, notice a potential hiccup that we didn't foresee at >>> the >>> meeting. At the moment, binary data in MOBY is passed as a child of >>> base-64-encoded, which is a child of String. Under the new system, >>> we >>> can't have children of String, so do we then need a new primitive >>> class >>> for binary data? I think it still needs to be b64 encoded, but it >>> seems >>> to me that it does need its own primitive now. >>> >>> opinions anyone? >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>> >> http://bioinfo.icapture.ubc.ca/bgood >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> -- >> Mark Wilkinson >> ...on the road! >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > Some remarks about Primitives and ontology: > > First: Do you think that FF is an integer??? > > If you say no, then you are wrong because FF is a valid hexadecimal > REPRESENTATION of an integer number: 255 > > Reason: The client give the meaning for a message. Forany ordinary > human who achieved child school FF is not an integer but for a > computer IT CAN BE! Of course it is a bit extreme as an example. We > all agree, by convention, that integers are written with Arab figures. > > In France (I don't know how it is in the rest of Europe) floating > numbers are described as 3,1415 instead of 3.1415 (comma instead of > point) In this case also, we agree by convention, that floating > numbers use the american representation (integer part point fractional > part etc..) > > Did you know that a Unicode string was inherited from a string ??? to > display exotic but useful characters that does not exist in English (I > don't speak of the strange french characters but also for spanish > german etc..)!) and why not Bytes ??? after all a string is an array > of bytes so bytes should be the actual primitive (String is an object > has Byte) etc.. etc.. In java by default, all strings are unicode > strings (AFAIK) but not all language adopted this convention. > > Primitives are computer related problems. I don't think it is wise to > implement primitives inside the ontology because it is not in its > place! > > Primitives were intended to solve problems of performance in language > like Java (just see the superb mess between an Integer and an int both > speaks about the same mathematical object everybody knows BUT for > performance issues, it has been implemented this way poisoning life of > millions software enginner and writers - you don't find that kind of > issue in other languages -) > > As I understand from Moby and the ontology of Moby, we should not mix > computer related problems with "Business logic" related problems. > > did you know that in ADA (for strict type checking and overflow > control) you can actually subclass an integer in order to define the > precision you want in your numbers and it doesn't violate (in any > case) the object programming paragdim. > > For example: > > subtype Natural is Integer range 0.. Integer'Last; > subtype Positive is Integer range 1.. Integer'Last; > (I hope no one will have a heart attack on seeing these two lines :p) > > So if you want to know if an Integer is an integer CAST it (that what > I do in Python (for the object mapping with bioMoby XML) ) for example > with java use Integer.parse(etc) for Python use int(string) etc.. > etc.. > > These instructions tells the program that the content of the XML is an > integer (according to your language convention) > > I think I have been clear and hope I didn't bash anyone too hard :p > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From bmg at sfu.ca Thu May 26 11:35:17 2005 From: bmg at sfu.ca (Benjamin Good) Date: Thu, 26 May 2005 07:35:17 -0400 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429586AE.1080306@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> Message-ID: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Hi Yan, You make many good points (despite your anti-Java vibe!). The reason that we suggest keeping the primitives in their somewhat strange location within the object ontology is to provide the opportunity for low level services to be discovered in the same manner as all the other services. For example, say we want to post a service that does arithmetic operations or String concatenations or something. If we use the suggested approach, such services can be discovered using exactly the same mechanism that all other services can be discovered. If on the other hand we completely separate these primitives from the ontology, we will have to invent new discovery protocols for handling this use case. You are right, this is a strange beast of an ontology. Its principal purpose is to describe the nature of being a data-type. As such, including descriptions of what it means to be a primitive piece of a data-type does not seem wrong. I think that when we start using a more typical ontology in addition to this one, whose purpose is to describe the nature of the information represented by these data-types, the distinction will be more clear and the real utility of the Object ontology will be made less ambiguous. -Ben On May 26, 2005, at 4:19 AM, Yan Wong wrote: > mark wilkinson wrote: > >> Good idea! >> The reason they weren't implemented initially was simple lack of need. >> >> M >> >> -----Original Message----- >> From: Benjamin Good >> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >> , markw at illuminae.com >> Cc:mobydev >> Subject: Re: [MOBY-dev] a question and a comment about the new Object >> inheritance >> >> It might actually make sense to implement a few more primitives to >> facilitate WSDL interoperability. Below see a set of standard >> primitives from the Axis user-guide. (Primitives being the things in >> the xml message that easily bind to existing Java classes). I wasn't >> around when you picked the ones you did, so maybe there are reasons >> not to include all of these? >> >> Standard mappings from WSDL to Java >> xsd:base64Binary -> byte[] >> xsd:boolean -> boolean >> xsd:byte -> byte >> xsd:dateTime -> java.util.Calendar >> xsd:decimal -> java.math.BigDecimal >> xsd:double -> double >> xsd:float -> float >> xsd:hexBinary -> byte[] >> xsd:int -> int >> xsd:integer -> java.math.BigInteger >> xsd:long -> long >> xsd:QName -> javax.xml.namespace.QName >> xsd:short -> short >> xsd:string -> java.lang.String >> >> -ben >> >> >> >> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> So, I just went through and updated all of my services to follow the >>> new >>> Object inheritance system. It took 5 minutes :-) Turns out that >>> most of >>> my services only output "Object" anyway, so they don't need any work, >>> and the ones that output other things like DNASequence and GO_Term >>> were >>> already following the proposed API anyway, so... only TWO of my >>> services >>> actually were affected by the proposed change! I hope that others >>> have >>> the same experience. >>> >>> I did, however, notice a potential hiccup that we didn't foresee at >>> the >>> meeting. At the moment, binary data in MOBY is passed as a child of >>> base-64-encoded, which is a child of String. Under the new system, >>> we >>> can't have children of String, so do we then need a new primitive >>> class >>> for binary data? I think it still needs to be b64 encoded, but it >>> seems >>> to me that it does need its own primitive now. >>> >>> opinions anyone? >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>> >> http://bioinfo.icapture.ubc.ca/bgood >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> -- >> Mark Wilkinson >> ...on the road! >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > Some remarks about Primitives and ontology: > > First: Do you think that FF is an integer??? > > If you say no, then you are wrong because FF is a valid hexadecimal > REPRESENTATION of an integer number: 255 > > Reason: The client give the meaning for a message. Forany ordinary > human who achieved child school FF is not an integer but for a > computer IT CAN BE! Of course it is a bit extreme as an example. We > all agree, by convention, that integers are written with Arab figures. > > In France (I don't know how it is in the rest of Europe) floating > numbers are described as 3,1415 instead of 3.1415 (comma instead of > point) In this case also, we agree by convention, that floating > numbers use the american representation (integer part point fractional > part etc..) > > Did you know that a Unicode string was inherited from a string ??? to > display exotic but useful characters that does not exist in English (I > don't speak of the strange french characters but also for spanish > german etc..)!) and why not Bytes ??? after all a string is an array > of bytes so bytes should be the actual primitive (String is an object > has Byte) etc.. etc.. In java by default, all strings are unicode > strings (AFAIK) but not all language adopted this convention. > > Primitives are computer related problems. I don't think it is wise to > implement primitives inside the ontology because it is not in its > place! > > Primitives were intended to solve problems of performance in language > like Java (just see the superb mess between an Integer and an int both > speaks about the same mathematical object everybody knows BUT for > performance issues, it has been implemented this way poisoning life of > millions software enginner and writers - you don't find that kind of > issue in other languages -) > > As I understand from Moby and the ontology of Moby, we should not mix > computer related problems with "Business logic" related problems. > > did you know that in ADA (for strict type checking and overflow > control) you can actually subclass an integer in order to define the > precision you want in your numbers and it doesn't violate (in any > case) the object programming paragdim. > > For example: > > subtype Natural is Integer range 0.. Integer'Last; > subtype Positive is Integer range 1.. Integer'Last; > (I hope no one will have a heart attack on seeing these two lines :p) > > So if you want to know if an Integer is an integer CAST it (that what > I do in Python (for the object mapping with bioMoby XML) ) for example > with java use Integer.parse(etc) for Python use int(string) etc.. > etc.. > > These instructions tells the program that the content of the XML is an > integer (according to your language convention) > > I think I have been clear and hope I didn't bash anyone too hard :p > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > http://bioinfo.icapture.ubc.ca/bgood From ywong at infobiogen.fr Thu May 26 15:04:17 2005 From: ywong at infobiogen.fr (Yan Wong) Date: Thu, 26 May 2005 17:04:17 +0200 Subject: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> Message-ID: <4295E571.5040602@infobiogen.fr> Benjamin Good wrote: > Hi Yan, > > You make many good points (despite your anti-Java vibe!). The reason > that we suggest keeping the primitives in their somewhat strange > location within the object ontology is to provide the opportunity for > low level services to be discovered in the same manner as all the > other services. For example, say we want to post a service that does > arithmetic operations or String concatenations or something. If we use > the suggested approach, such services can be discovered using exactly > the same mechanism that all other services can be discovered. If on > the other hand we completely separate these primitives from the > ontology, we will have to invent new discovery protocols for handling > this use case. > > You are right, this is a strange beast of an ontology. Its principal > purpose is to describe the nature of being a data-type. As such, > including descriptions of what it means to be a primitive piece of a > data-type does not seem wrong. I think that when we start using a more > typical ontology in addition to this one, whose purpose is to describe > the nature of the information represented by these data-types, the > distinction will be more clear and the real utility of the Object > ontology will be made less ambiguous. > > -Ben > > > On May 26, 2005, at 4:19 AM, Yan Wong wrote: > >> mark wilkinson wrote: >> >>> Good idea! >>> The reason they weren't implemented initially was simple lack of need. >>> >>> M >>> >>> -----Original Message----- >>> From: Benjamin Good >>> Date: Wed, 25 May 2005 21:03:12 To:Core developer announcements >>> , markw at illuminae.com >>> Cc:mobydev >>> Subject: Re: [MOBY-dev] a question and a comment about the new Object >>> inheritance >>> >>> It might actually make sense to implement a few more primitives to >>> facilitate WSDL interoperability. Below see a set of standard >>> primitives from the Axis user-guide. (Primitives being the things in >>> the xml message that easily bind to existing Java classes). I wasn't >>> around when you picked the ones you did, so maybe there are reasons >>> not to include all of these? >>> >>> Standard mappings from WSDL to Java >>> xsd:base64Binary -> byte[] >>> xsd:boolean -> boolean >>> xsd:byte -> byte >>> xsd:dateTime -> java.util.Calendar >>> xsd:decimal -> java.math.BigDecimal >>> xsd:double -> double >>> xsd:float -> float >>> xsd:hexBinary -> byte[] >>> xsd:int -> int >>> xsd:integer -> java.math.BigInteger >>> xsd:long -> long >>> xsd:QName -> javax.xml.namespace.QName >>> xsd:short -> short >>> xsd:string -> java.lang.String >>> >>> -ben >>> >>> >>> >>> On May 25, 2005, at 12:32 PM, Mark Wilkinson wrote: >>> >>> >>>> Hi all, >>>> >>>> So, I just went through and updated all of my services to follow >>>> the new >>>> Object inheritance system. It took 5 minutes :-) Turns out that >>>> most of >>>> my services only output "Object" anyway, so they don't need any work, >>>> and the ones that output other things like DNASequence and GO_Term >>>> were >>>> already following the proposed API anyway, so... only TWO of my >>>> services >>>> actually were affected by the proposed change! I hope that others have >>>> the same experience. >>>> >>>> I did, however, notice a potential hiccup that we didn't foresee at >>>> the >>>> meeting. At the moment, binary data in MOBY is passed as a child of >>>> base-64-encoded, which is a child of String. Under the new system, we >>>> can't have children of String, so do we then need a new primitive >>>> class >>>> for binary data? I think it still needs to be b64 encoded, but it >>>> seems >>>> to me that it does need its own primitive now. >>>> >>>> opinions anyone? >>>> >>>> M >>>> >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >>> http://bioinfo.icapture.ubc.ca/bgood >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> -- >>> Mark Wilkinson >>> ...on the road! >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> Some remarks about Primitives and ontology: >> >> First: Do you think that FF is an integer??? >> >> If you say no, then you are wrong because FF is a valid hexadecimal >> REPRESENTATION of an integer number: 255 >> >> Reason: The client give the meaning for a message. Forany ordinary >> human who achieved child school FF is not an integer but for a >> computer IT CAN BE! Of course it is a bit extreme as an example. We >> all agree, by convention, that integers are written with Arab figures. >> >> In France (I don't know how it is in the rest of Europe) floating >> numbers are described as 3,1415 instead of 3.1415 (comma instead of >> point) In this case also, we agree by convention, that floating >> numbers use the american representation (integer part point >> fractional part etc..) >> >> Did you know that a Unicode string was inherited from a string ??? to >> display exotic but useful characters that does not exist in English >> (I don't speak of the strange french characters but also for spanish >> german etc..)!) and why not Bytes ??? after all a string is an array >> of bytes so bytes should be the actual primitive (String is an object >> has Byte) etc.. etc.. In java by default, all strings are unicode >> strings (AFAIK) but not all language adopted this convention. >> >> Primitives are computer related problems. I don't think it is wise to >> implement primitives inside the ontology because it is not in its place! >> >> Primitives were intended to solve problems of performance in language >> like Java (just see the superb mess between an Integer and an int >> both speaks about the same mathematical object everybody knows BUT >> for performance issues, it has been implemented this way poisoning >> life of millions software enginner and writers - you don't find that >> kind of issue in other languages -) >> >> As I understand from Moby and the ontology of Moby, we should not mix >> computer related problems with "Business logic" related problems. >> >> did you know that in ADA (for strict type checking and overflow >> control) you can actually subclass an integer in order to define the >> precision you want in your numbers and it doesn't violate (in any >> case) the object programming paragdim. >> >> For example: >> >> subtype Natural is Integer range 0.. Integer'Last; >> subtype Positive is Integer range 1.. Integer'Last; >> (I hope no one will have a heart attack on seeing these two lines :p) >> >> So if you want to know if an Integer is an integer CAST it (that what >> I do in Python (for the object mapping with bioMoby XML) ) for >> example with java use Integer.parse(etc) for Python use int(string) >> etc.. etc.. >> >> These instructions tells the program that the content of the XML is >> an integer (according to your language convention) >> >> I think I have been clear and hope I didn't bash anyone too hard :p >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > http://bioinfo.icapture.ubc.ca/bgood > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > I know that we must provide data type descriptions of a biological object. but the fact is that we must try to match the biological logic" as much as possible. Maybe one solution would be to link the "computer logic" (represented by datatypes) with the biological logic (represented by the ontology objects) However putting all the "computer related" informations inside the ontology is not a good idea. The ontology should remain the most "biological" as possible. There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? . So something like that could emerge: DNA Sequence associated with FASTA, EMBL, etc.. FASTA EMBL FASTA, EMBL, GFF and so on would be in another ontology (more specific to bioinformatic/computers) The idea is to clearly separate the "biological" logic and the "computer related" logic. So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." A biological object of the ontology could be linked to a (or several) data types thus low level operations (or better computer related services/operations) could be discovered in the same way as biological services. We would have biological ontology<-> bioinformatic ontology relationships that would map the biological logic to the computer logic. PS: The fact is I am not anti Java (as a language) after all, I used it every day since the Beta version (Oak for who can still remember the prehistoric details of Java :p who was designed to be a OS for your microwave oven ahahaha) However I still have a lot of frustrations on the java API because this stuff is a real nightmare and was the main drawback of Java for several years (try to implement a simple spreadsheet with Swing and you'll know what I mean all other GUI language beat Java 100% of the time. A dumber example: Do you remember what classes needed to open a file? I still need to copy paste my code pattern!) And I like Java for its philosophy: Code once, execute many (even if people, most of the time, do Java programming for Windows (95/98/NT/2000/XP) Multi plateform ahahaha) From markw at illuminae.com Thu May 26 15:29:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 May 2005 08:29:44 -0700 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <4295E571.5040602@infobiogen.fr> References: <1329640418-1117069557-cardhu_blackberry.rim.net-31751-@engine09-cell01> <429586AE.1080306@infobiogen.fr> <267e5e8b6bc8a1a865e27f8881335ca1@sfu.ca> <4295E571.5040602@infobiogen.fr> Message-ID: <1117121384.27775.70.camel@mobycentral.mrl.ubc.ca> Wow... what a discussion! I have to throw in my $0.02 I think the Object ontology is "logically" correct exactly as it stands. It describes the structure of the objects to a machine, while giving some human-intuitive sense of what the object is supposed to represent by using a human-intuitive name. Ben would argue (correct me if I get this wrong) that it is inappropriate to define particular *types* of strings in the object ontology because this goes over the line of conflating structure with semantics. I tend to disagree - a FASTA file is a particular type of file format, and it is that *format* that we are describing (i.e. the structure of the string) not its actual content or meaning. As such, it doesn't bother me one little bit that we inherit from String. And, as Yan points out, if you want to know if an Object is a String or an Int, then ask it - the inheritance will tell you. It strikes me that it is only laziness that creates the "need" not to inherit from the primitives; i.e. that it is simply easier to know if you have a primitive in-hand if the object in-hand is of a primitive type "by name", rather than a child of a primitive type where yo have to look-up its parentage. Inheriting from Primitives also solves a number of other problems v.v. rendering and such, but I don't want the utility to override the architecture, so I'll leave that discussion out of it. My *only* objection to the way things are today is that the serialization of derivative objects from primitives can end up having mixtures of XML and text as child nodes in the XML. This is widely considered "bad practice" (though not "illegal"), and it makes me a bit queasy in my stomach every time I see it. Nevertheless, this problem can be solved in ways other than preventing inheritance from primitives! Let's get to the root of the problem. Is the Java community (I finger you because you are the ones who are reporting this as a problem) really objecting to inheritance from primitives, or are you objecting to the way we serialize the ontology? I tried to type examples of both new solutions at the meeting, but neither of them seemed acceptable to anyone, so I gave up... I remain unconvinced. I agree that the serialization we have now is somewhat ugly in some cases, but creating a special class of Objects is even worse! If we can solve the Java programmers problem by serializing objects like this: content here then perhaps that's what we should do in preference to creating special types of Objects that wrap primitives but cannot have child types. ??? Mark From senger at ebi.ac.uk Thu May 26 15:50:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 26 May 2005 16:50:01 +0100 (BST) Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1117121384.27775.70.camel@mobycentral.mrl.ubc.ca> Message-ID: Well, I myself is not the main player in this dicussion about inheriting from primitives but as far as I understand, this: > > content here > > is what everybody wanted in the meeting (the name "String" is arbitrary, the name "string" is mandatory). But maybe I am wrong. Cheers, 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 Fri May 27 15:48:14 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 08:48:14 -0700 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: References: Message-ID: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > Well, I myself is not the main player in this dicussion about inheriting > from primitives but as far as I understand, this: > > > > > content here > > > > > is what everybody wanted in the meeting Ummmm... I think there was a lot of disagreement about what "everybody" wanted... By the looks of it now, everybody wanted something different, but were calling it the same thing :-) Unfortunately, when I asked for some example objects, nobody volunteered, so we couldn't sort it out at the time. I remember vividly, however, that when I tried to write that (above XML) on the screen, the room erupted in screams that I was making it all too complicated, so I don't think that is what people wanted. It may be that we have all had time to digest the issue a bit more deeply now and have come to the same conclusion? M From ywong at infobiogen.fr Fri May 27 17:55:18 2005 From: ywong at infobiogen.fr (ywong at infobiogen.fr) Date: Fri, 27 May 2005 19:55:18 +0200 (CEST) Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> References: <1117208894.30239.73.camel@mobycentral.mrl.ubc.ca> Message-ID: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >> Well, I myself is not the main player in this dicussion about inheriting >> from primitives but as far as I understand, this: >> >> > >> > content here >> > >> > >> is what everybody wanted in the meeting > > Ummmm... I think there was a lot of disagreement about what "everybody" > wanted... By the looks of it now, everybody wanted something different, > but were calling it the same thing :-) Unfortunately, when I asked for > some example objects, nobody volunteered, so we couldn't sort it out at > the time. > > I remember vividly, however, that when I tried to write that (above XML) > on the screen, the room erupted in screams that I was making it all too > complicated, so I don't think that is what people wanted. It may be > that we have all had time to digest the issue a bit more deeply now and > have come to the same conclusion? > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Sorry I could reply earlier, all our network is in a quagmire... An alternative I would accept: blablablablablablalbalbalblablalbalba An attribute is optional, we keep the actual version without killing everything (adding a subnode and all serializers/deserializers would have to be rewritten!) People using Java will know what is the type of the data by reading this attribute. If it doesn't exist, they should assume that by default, it is a string. Example of DNASequence: ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... 152 Then we should agree of what "primitives" we have: -string -float -int maybe are there others? It is a quick and dirty solution however it is IMHO cleaner than what I saw in the last example. It has the advantage to keep the "old" object layout but add informations that will greatly help people who implements type sensible clients. Greetings Yan From edward.kawas at gmail.com Fri May 27 18:06:38 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 27 May 2005 11:06:38 -0700 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> Message-ID: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> I like Yans idea, but what happens if the object doesn't inherit from String, isn't an int or a float? What if the object was a schematikonMotifID that inherits from SchematikonSegmentID that inherits from Object. What would the data:type be in this case? Ed > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of > ywong at infobiogen.fr > Sent: Friday, May 27, 2005 10:55 AM > To: markw at illuminae.com; Core developer announcements > Subject: Re: [moby] Re: [MOBY-dev] a question and a > comment about the new Objectinheritance > > > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > >> Well, I myself is not the main player in this dicussion > about inheriting > >> from primitives but as far as I understand, this: > >> > >> > > >> > content here > >> > > >> > > >> is what everybody wanted in the meeting > > > > Ummmm... I think there was a lot of disagreement about > what "everybody" > > wanted... By the looks of it now, everybody wanted > something different, > > but were calling it the same thing :-) Unfortunately, > when I asked for > > some example objects, nobody volunteered, so we couldn't > sort it out at > > the time. > > > > I remember vividly, however, that when I tried to write > that (above XML) > > on the screen, the room erupted in screams that I was > making it all too > > complicated, so I don't think that is what people wanted. > It may be > > that we have all had time to digest the issue a bit more > deeply now and > > have come to the same conclusion? > > > > M > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > Sorry I could reply earlier, all our network is in a > quagmire... > > An alternative I would accept: > > > blablablablablablalbalbalblablalbalba > > > An attribute is optional, we keep the actual version > without killing > everything (adding a subnode and all > serializers/deserializers would > have to be rewritten!) > > People using Java will know what is the type of the data > by reading this > attribute. If it doesn't exist, they should assume that by > default, it > is a string. > > Example of DNASequence: > > > > > ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... > > data:type="int">152 > > > Then we should agree of what "primitives" we have: > -string > -float > -int > > maybe are there others? > > It is a quick and dirty solution however it is IMHO > cleaner than what I > saw in the last example. It has the advantage to keep the > "old" object > layout but add informations that will greatly help people > who implements > type sensible clients. > > Greetings > > Yan > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri May 27 18:49:14 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 11:49:14 -0700 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> References: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> Message-ID: <1117219754.30771.33.camel@mobycentral.mrl.ubc.ca> I guess it would be type='null' or something like that. I agree that this is the only case where Yan's proposal breaks. We do, actually, have quite a few Objects that inherit from Object without going through a primitive, and therefore have no content at all and should not be assumed to default to type="sting" I don't think we can (nor should) require that our final solution doesn't break anything. It is more important to get it right in the 1.0 spec than to salvage legacy services. As such, I'm not so concerned about having a default state - if we are going to go this route, then I think it should be a requirement to have a type='' attribute. The other advantage of Yan's solution is that it is much more XML-like, and we can use the XML type attributes exactly as they are! I like that!! How do the Java crowd feel about this? M On Fri, 2005-05-27 at 11:06 -0700, Eddie Kawas wrote: > I like Yans idea, but what happens if the object doesn't > inherit from String, isn't an int or a float? What if the > object was a schematikonMotifID that inherits from > SchematikonSegmentID that inherits from Object. What would > the data:type be in this case? > > > > > > Ed > > > > > -----Original Message----- > > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > > dev-bounces at portal.open-bio.org] On Behalf Of > > ywong at infobiogen.fr > > Sent: Friday, May 27, 2005 10:55 AM > > To: markw at illuminae.com; Core developer announcements > > Subject: Re: [moby] Re: [MOBY-dev] a question and a > > comment about the new Objectinheritance > > > > > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: > > >> Well, I myself is not the main player in this dicussion > > about inheriting > > >> from primitives but as far as I understand, this: > > >> > > >> > > > >> > content here > > >> > > > >> > > > >> is what everybody wanted in the meeting > > > > > > Ummmm... I think there was a lot of disagreement about > > what "everybody" > > > wanted... By the looks of it now, everybody wanted > > something different, > > > but were calling it the same thing :-) Unfortunately, > > when I asked for > > > some example objects, nobody volunteered, so we couldn't > > sort it out at > > > the time. > > > > > > I remember vividly, however, that when I tried to write > > that (above XML) > > > on the screen, the room erupted in screams that I was > > making it all too > > > complicated, so I don't think that is what people > wanted. > > It may be > > > that we have all had time to digest the issue a bit more > > deeply now and > > > have come to the same conclusion? > > > > > > M > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Sorry I could reply earlier, all our network is in a > > quagmire... > > > > An alternative I would accept: > > > > > > blablablablablablalbalbalblablalbalba > > > > > > An attribute is optional, we keep the actual version > > without killing > > everything (adding a subnode and all > > serializers/deserializers would > > have to be rewritten!) > > > > People using Java will know what is the type of the data > > by reading this > > attribute. If it doesn't exist, they should assume that by > > default, it > > is a string. > > > > Example of DNASequence: > > > > > > > > > > ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... > > > > > data:type="int">152 > > > > > > Then we should agree of what "primitives" we have: > > -string > > -float > > -int > > > > maybe are there others? > > > > It is a quick and dirty solution however it is IMHO > > cleaner than what I > > saw in the last example. It has the advantage to keep the > > "old" object > > layout but add informations that will greatly help people > > who implements > > type sensible clients. > > > > Greetings > > > > Yan > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri May 27 19:05:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 12:05:57 -0700 Subject: [MOBY-dev] Notes from working group 'B' Message-ID: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> Hi all, Unfortunately, all of my notes from my working group at the MOBY meeting were stolen along with my laptop just a few days after the meeting ended. I have tried to recall everything that we decided, and I compile it below. If I have made any errors, or forgotten anything, please post to the list. Report from Working Group B Issues: Registry mirrors, Service mirrors, Async services, Service testing metadata, standardized LSID provision Decisions: Registry Mirrors registry mirroring will be accomplished by synchronizing the SignatureURL?s among a set of registries. Each registry will have an agent that can (at its discretion) visit any or all of the signature URL?s to retrieve the service signatures and update its own registry. Someone ____________ is going to look into the various ways of synchronizing this list (LDAP, DNS, other?) Service Mirrors Mark will change the MOBY Central API such that multiple endponts can be registered/returned in a service search. This will affect the registerService and findService API calls. The implication of registering multiple endpoints is that the *identical* service is running in all indicated locations, with the same database and same software version. These endpoints all share the same Service Signature metadata, so they had better be identical! Async services a few details have to be worked out (I think the Spanish contingent took on the task of fleshing this out completely), but the upshot is that, when a service is registered, it will be assumed to have four ?method? calls: 1) The name of the service (e.g. doBlastAnalysis) 2) The name with _async appended (e.g. doBlastAnalysis_async) 3) The name with _poll appended (e.g. doBlastAnalysis_poll) 4) The name with _result appended (e.g. doBlastAnalyis_result) The service registration is identical to what it is now, methods 2,3,4 are optional and are not explicitly registered. (the ability of a service to run asynchronously can be determined by querying the RDF metadata through LSID resolution predicates TBD). Calling the service by name executes the service synchronously exactly as it does currently. If a service refuses to run synchronously, it returns an empty response (this is a valid behaviour, and will not break ?old? clients). Calling the xxx_async method will return a MOBY Object representing a ?ticket?- the namespace should be unique to your async service. The ticket can be used to poll the service using the xxx_poll method (API TBD) , and the same ticket can be used to retrieve the result using the xxx_result method. Service Testing Metadata it was generally agreed that it is desirable to have a sample input such that a service can be tested. This will be made available by the service providers as a string literal in their Service Signature (this is retrieved by LSID resolution). The string should be a complete MOBY message (?..) representing a sample input to that service that will ALWAYS work; where ?work? means generate an output of the Object type registered in the Service Signature and in MOBY Central. This input is to be used for testing that a service is running, but not for validating the output. Standardized LSID provision I have updated the online API documents to show how LSID?s will be derived from MOBY Central messages. Generally speaking, in the response message from MOBY Central, any XML tag whose content represents an entry in one of the ontologies, or a service instance, will have an attribute lsid=?nnn?, where nnn can be resolved to metadata describing that entity. For the MOBY Ontologies, this metadata is the RDF describing the ontology node. For service signatures, this metadata is the RDF of the service signature (taken as a GET directly from the service providers machine through the usual LSID resolution process using their registered SignatureURL as the GET URL). As soon as I get a few minutes free I will implement this new part of the API. I?m sure there are things I have missed? please make your additions and comments to the list. From ywong at infobiogen.fr Fri May 27 19:43:10 2005 From: ywong at infobiogen.fr (ywong at infobiogen.fr) Date: Fri, 27 May 2005 21:43:10 +0200 (CEST) Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> References: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> Message-ID: <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> > I like Yans idea, but what happens if the object doesn't > inherit from String, isn't an int or a float? What if the > object was a schematikonMotifID that inherits from > SchematikonSegmentID that inherits from Object. What would > the data:type be in this case? > > > > > > Ed > > > >> -----Original Message----- >> From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >> dev-bounces at portal.open-bio.org] On Behalf Of >> ywong at infobiogen.fr >> Sent: Friday, May 27, 2005 10:55 AM >> To: markw at illuminae.com; Core developer announcements >> Subject: Re: [moby] Re: [MOBY-dev] a question and a >> comment about the new Objectinheritance >> >> > On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >> >> Well, I myself is not the main player in this dicussion >> about inheriting >> >> from primitives but as far as I understand, this: >> >> >> >> > >> >> > content here >> >> > >> >> > >> >> is what everybody wanted in the meeting >> > >> > Ummmm... I think there was a lot of disagreement about >> what "everybody" >> > wanted... By the looks of it now, everybody wanted >> something different, >> > but were calling it the same thing :-) Unfortunately, >> when I asked for >> > some example objects, nobody volunteered, so we couldn't >> sort it out at >> > the time. >> > >> > I remember vividly, however, that when I tried to write >> that (above XML) >> > on the screen, the room erupted in screams that I was >> making it all too >> > complicated, so I don't think that is what people > wanted. >> It may be >> > that we have all had time to digest the issue a bit more >> deeply now and >> > have come to the same conclusion? >> > >> > M >> > >> > >> > _______________________________________________ >> > MOBY-dev mailing list >> > MOBY-dev at biomoby.org >> > http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> Sorry I could reply earlier, all our network is in a >> quagmire... >> >> An alternative I would accept: >> >> >> blablablablablablalbalbalblablalbalba >> >> >> An attribute is optional, we keep the actual version >> without killing >> everything (adding a subnode and all >> serializers/deserializers would >> have to be rewritten!) >> >> People using Java will know what is the type of the data >> by reading this >> attribute. If it doesn't exist, they should assume that by >> default, it >> is a string. >> >> Example of DNASequence: >> >> >> >> >> ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... >> >> > data:type="int">152 >> >> >> Then we should agree of what "primitives" we have: >> -string >> -float >> -int >> >> maybe are there others? >> >> It is a quick and dirty solution however it is IMHO >> cleaner than what I >> saw in the last example. It has the advantage to keep the >> "old" object >> layout but add informations that will greatly help people >> who implements >> type sensible clients. >> >> Greetings >> >> Yan >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Simple: data:type only apply to the content of the tag if it exists so: The line above means that the content of Object (here nothing) should be an integer, but it is void so the line above describes an invalid integer... no data:type attribute and no content so we should deal this object as we did before. 152 no data:type but a content, so the client must treat the content as a string 152 the data:type indicates that the content is an integer. From markw at illuminae.com Fri May 27 19:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 12:57:02 -0700 Subject: [MOBY-dev] weeding out the "dead" services Message-ID: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Hi all, so, it's about time we finally switch this RDF Agent on... again... :-) As we did last time, can I request that you visit the RDF Signature Generator (http://mobycentral.cbr.nrc.ca:8090/servlets/forms/getSignatureForm) retrieve your Service Signatures, then make them available at whatever signatureURL you indicate on that web form. Running the RDF Signature Generator more than once will simply over- write your signature URL with whatever new signature URL you enter, so it is perfectly safe to do this. Thanks! M From simont at mcw.edu Fri May 27 20:23:41 2005 From: simont at mcw.edu (Twigger Simon) Date: Fri, 27 May 2005 15:23:41 -0500 Subject: [MOBY-dev] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> References: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Message-ID: Hi Mark, Just so I understand how this should work: I can go to the form, select my domain, leave the instance name field blank so I get every service, fill in a signature URL (should this point to a directory or to a file?) and click Submit. Back comes the RDF which I move to the location specified in the signature URL and then I can throw away all the old signature files with a clean conscience? I was hoping I could leave the service instance blank, specify one file name in the signature URL and then that would give me back one RDF document for all services so I can just throw that one file on the server and ditch the old files. Is this correct? Simon. On May 27, 2005, at 2:57 PM, Mark Wilkinson wrote: > Hi all, > > so, it's about time we finally switch this RDF Agent on... > again... :-) > > As we did last time, can I request that you visit the RDF Signature > Generator > (http://mobycentral.cbr.nrc.ca:8090/servlets/forms/getSignatureForm) > retrieve your Service Signatures, then make them available at whatever > signatureURL you indicate on that web form. > > Running the RDF Signature Generator more than once will simply over- > write your signature URL with whatever new signature URL you enter, so > it is perfectly safe to do this. > > Thanks! > > M > > > _______________________________________________ > 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 AIM/iChat: simontatmcw From edward.kawas at gmail.com Fri May 27 20:30:02 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 27 May 2005 13:30:02 -0700 Subject: [MOBY-dev] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: Message-ID: <4297834d.5b52e37c.787e.ffff930c@mx.gmail.com> Hi, > should this point to a directory or to a file? Points to the rdf *file* returned to you, accessible through the url that you enter. So if you were to enter http://www.mydomin.com/rdfs/myDoc.rdf then you would place the document in /rdfs/ and name the file myDoc.rdf. > I was hoping I could leave the service instance blank, >specify one file name in the signature URL and then that >would give me back one RDF document for all services so I >can just throw that one file on the server and ditch the >old files. Hopefully, this is what happens ;-) Eddie From bmg at sfu.ca Fri May 27 20:42:14 2005 From: bmg at sfu.ca (Benjamin Good) Date: Fri, 27 May 2005 16:42:14 -0400 Subject: [MOBY-dev] 2 ontologies Message-ID: <319d32e74261b6c9a729acd780bd53db@sfu.ca> From Yan: "There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? ." -Ben -> I agree with this thinking and in fact that was what I was trying to suggest. However, I think that you have things reversed in the following statement. Yan: "So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." -> Ben As I understand it, the BioMOBY object ontology is meant to describe data-types, not biological logic. It does a nice job of the former but I would say not the latter. My suggestion is to introduce a separate ontology that does describe the biology of the things represented by the data-types (that would NOT include things like "FASTA formatted sequence"!). I think this may happen by default when moby-central merges with Grimoire/Feta, but this list needs to pay attention! I think that it is very important to rectify this confusion between syntax and semantics as soon as we can. What happens when the tools are written that create bioMoby services automatically from websites get going? I think you will quickly see that the moby object ontology loses any notion of "biological logic" as it rapidly becomes populated by perfectly syntactically valid machine produced Objects - and this is GOOD. We WANT thousands of services in there and they may require thousands of new objects! Its important to keep in mind the underlying goals of these things. The Object ontology exists to ensure interoperability - not integration. To me, that means that I can easily consume any service that uses objects from this ontology and it ensures (only helps actually) that the data types produced by service providers are sensible. These SYNTACTIC problems are solved quite nicely by the Object ontology - regardless of the specific serialization you end up choosing and regardless of the name you give to your objects. The SEMANTIC problems associated with INTEGRATION are different, large and growing and will need different solutions. rant over. -Ben http://bioinfo.icapture.ubc.ca/bgood From markw at illuminae.com Fri May 27 21:03:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 May 2005 14:03:00 -0700 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] weeding out the "dead" services In-Reply-To: References: <1117223822.30771.66.camel@mobycentral.mrl.ubc.ca> Message-ID: <1117227780.30771.71.camel@mobycentral.mrl.ubc.ca> On Fri, 2005-05-27 at 15:23 -0500, Twigger Simon wrote: > RDF document for all services so I can just throw that one file on > the server and ditch the old files. > > Is this correct? That is correct (if Eddie has done his job properly ;-) ) M From jmfernandez at cnb.uam.es Fri May 27 21:23:19 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXogR29uesOhbGV6?=) Date: Fri, 27 May 2005 23:23:19 +0200 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> Message-ID: <42978FC7.7030805@cnb.uam.es> Hi Mark & the MOBYfiers 8-), > Service Mirrors Mark will change the MOBY Central API such that > multiple endponts can be registered/returned in a service search. This > will affect the registerService and findService API calls. The > implication of registering multiple endpoints is that the *identical* > service is running in all indicated locations, with the same database > and same software version. These endpoints all share the same Service > Signature metadata, so they had better be identical! > Also, I can remember we talked about storing updated QoS information, doesn't it? Thinking on replicated services, each one should have its own QoS information. > > Async services a few details have to be worked out (I think the Spanish > contingent took on the task of fleshing this out completely), but the > upshot is that, when a service is registered, it will be assumed to have > four ?method? calls: > 1) The name of the service (e.g. doBlastAnalysis) > 2) The name with _async appended (e.g. doBlastAnalysis_async) > 3) The name with _poll appended (e.g. doBlastAnalysis_poll) > 4) The name with _result appended (e.g. doBlastAnalyis_result) > > The service registration is identical to what it is now, methods 2,3,4 > are optional and are not explicitly registered. (the ability of a > service to run asynchronously can be determined by querying the RDF > metadata through LSID resolution predicates TBD). Calling the service > by name executes the service synchronously exactly as it does currently. > If a service refuses to run synchronously, it returns an empty response > (this is a valid behaviour, and will not break ?old? clients). Calling > the xxx_async method will return a MOBY Object representing a ?ticket?- > the namespace should be unique to your async service. The ticket can be > used to poll the service using the xxx_poll method (API TBD) , and the > same ticket can be used to retrieve the result using the xxx_result > method. > I have been reading the above description about asynchronous services, and there is at least one loose points. You can imagine an scenario where we have a replicated service, and that service is asynchronous. A client would choose one of them, but it would be technically difficult to assure the obtained ticked is useable in *each* one of the replicated services. INB guys have at least two huge computer facilities, and they are geographically disperse, which makes difficult to share the same job identifier namespace. Therefore, either each replicated service should have its unique namespace or clients should tie to the chosen services at the beginning. > > Service Testing Metadata it was generally agreed that it is desirable > to have a sample input such that a service can be tested. This will be > made available by the service providers as a string literal in their > Service Signature (this is retrieved by LSID resolution). The string > should be a complete MOBY message (?..) representing a > sample input to that service that will ALWAYS work; where ?work? means > generate an output of the Object type registered in the Service > Signature and in MOBY Central. This input is to be used for testing > that a service is running, but not for validating the output. > Please, don't forget detailed textual descriptions of the services (long description, input & output parameters, examples, external & internal links), objects (long description, what it means each HAS and HASA element, examples, links), and perhaps namespaces, as they should have their place in RDF. Providers are the only responsible to fill these optional, but useful, information fields/tags. Have a nice weekend, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From r.bruskiewich at cgiar.org Mon May 30 00:00:23 2005 From: r.bruskiewich at cgiar.org (Bruskiewich, Richard (IRRI)) Date: Sun, 29 May 2005 17:00:23 -0700 Subject: [MOBY-dev] RE: [MOBY-l] 2 ontologies Message-ID: <2A491C94FFBC5843A212A69CBEA5CEC7021FBC9F@IRRIMAIL.IRRI.CGIARAD.ORG> If by "biological logic" you mean *real* semantics, then I would hazard to say that the domain modeling activity of the Generation Challenge Programme is going in that direction, at least, for crop/plant science (though some of the semantics is generic to all biology, of necessity). It is interesting to note that human beings construct domain models, not machines. Domain models cannot be autogenerated. Real semantics is what sets human beings apart from (practically) the rest of the animal kingdom, let alone, the stupid (but ultra fast) machines that we've created in this era. Richard "Daisy, daaaissy, ...." -----Original Message----- From: Benjamin Good [mailto:bmg at sfu.ca] Sent: Saturday, 2005 May 28 4:42 AM To: mobydev; mobyl Subject: [MOBY-l] 2 ontologies From Yan: "There is another solution instead which I think is more elegant: Associate biological objects with computer data types. For Example: a DNA Sequence is the biological object but FASTA, EMBL and all the fancy bioinformatic formats are its computer representation? ." -Ben -> I agree with this thinking and in fact that was what I was trying to suggest. However, I think that you have things reversed in the following statement. Yan: "So as I see things, we have two ontologies representing two logics: -The biologocial logic represented by the bioMoby ontology -A data type logic which should be represented by a separated ontology with of course our "primitives String/Float/Bytes etc.." -> Ben As I understand it, the BioMOBY object ontology is meant to describe data-types, not biological logic. It does a nice job of the former but I would say not the latter. My suggestion is to introduce a separate ontology that does describe the biology of the things represented by the data-types (that would NOT include things like "FASTA formatted sequence"!). I think this may happen by default when moby-central merges with Grimoire/Feta, but this list needs to pay attention! I think that it is very important to rectify this confusion between syntax and semantics as soon as we can. What happens when the tools are written that create bioMoby services automatically from websites get going? I think you will quickly see that the moby object ontology loses any notion of "biological logic" as it rapidly becomes populated by perfectly syntactically valid machine produced Objects - and this is GOOD. We WANT thousands of services in there and they may require thousands of new objects! Its important to keep in mind the underlying goals of these things. The Object ontology exists to ensure interoperability - not integration. To me, that means that I can easily consume any service that uses objects from this ontology and it ensures (only helps actually) that the data types produced by service providers are sensible. These SYNTACTIC problems are solved quite nicely by the Object ontology - regardless of the specific serialization you end up choosing and regardless of the name you give to your objects. The SEMANTIC problems associated with INTEGRATION are different, large and growing and will need different solutions. rant over. -Ben http://bioinfo.icapture.ubc.ca/bgood _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l From Pieter.Neerincx at wur.nl Mon May 30 09:55:40 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 May 2005 11:55:40 +0200 Subject: [moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance In-Reply-To: <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> References: <1118.82.66.216.27.1117216518.squirrel@82.66.216.27> <429761b1.1f518dae.6ef0.ffff84a9@mx.gmail.com> <1258.82.66.216.27.1117222990.squirrel@82.66.216.27> Message-ID: <2fc226a7fb27830bbeeef667b47a0ce3@wur.nl> On 27 May, 2005, at 21:43, ywong at infobiogen.fr wrote: >> I like Yans idea, but what happens if the object doesn't >> inherit from String, isn't an int or a float? What if the >> object was a schematikonMotifID that inherits from >> SchematikonSegmentID that inherits from Object. What would >> the data:type be in this case? >> >> >> >> >> >> Ed >> >> >> >>> -----Original Message----- >>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >>> dev-bounces at portal.open-bio.org] On Behalf Of >>> ywong at infobiogen.fr >>> Sent: Friday, May 27, 2005 10:55 AM >>> To: markw at illuminae.com; Core developer announcements >>> Subject: Re: [moby] Re: [MOBY-dev] a question and a >>> comment about the new Objectinheritance >>> >>>> On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote: >>>>> Well, I myself is not the main player in this dicussion >>> about inheriting >>>>> from primitives but as far as I understand, this: >>>>> >>>>>> >>>>>> content here >>>>>> >>>>>> >>>>> is what everybody wanted in the meeting >>>> >>>> Ummmm... I think there was a lot of disagreement about >>> what "everybody" >>>> wanted... By the looks of it now, everybody wanted >>> something different, >>>> but were calling it the same thing :-) Unfortunately, >>> when I asked for >>>> some example objects, nobody volunteered, so we couldn't >>> sort it out at >>>> the time. >>>> >>>> I remember vividly, however, that when I tried to write >>> that (above XML) >>>> on the screen, the room erupted in screams that I was >>> making it all too >>>> complicated, so I don't think that is what people >> wanted. >>> It may be >>>> that we have all had time to digest the issue a bit more >>> deeply now and >>>> have come to the same conclusion? >>>> >>>> M >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>> Sorry I could reply earlier, all our network is in a >>> quagmire... >>> >>> An alternative I would accept: >>> >>> >>> blablablablablablalbalbalblablalbalba >>> >>> >>> An attribute is optional, we keep the actual version >>> without killing >>> everything (adding a subnode and all >>> serializers/deserializers would >>> have to be rewritten!) >>> >>> People using Java will know what is the type of the data >>> by reading this >>> attribute. If it doesn't exist, they should assume that by >>> default, it >>> is a string. >>> >>> Example of DNASequence: >>> >>> >>> >>> >>> ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT.... >>> >>> >> data:type="int">152 >>> >>> >>> Then we should agree of what "primitives" we have: >>> -string >>> -float >>> -int >>> >>> maybe are there others? >>> >>> It is a quick and dirty solution however it is IMHO >>> cleaner than what I >>> saw in the last example. It has the advantage to keep the >>> "old" object >>> layout but add informations that will greatly help people >>> who implements >>> type sensible clients. >>> >>> Greetings >>> >>> Yan >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > > Simple: > data:type only apply to the content of the tag if it exists so: > > > > The line above means that the content of Object (here nothing) > should be > an integer, but it is void so the line above describes an invalid > integer... > > > > > > > > no data:type attribute and no content so we should deal this object as > we > did before. > > 152 > > no data:type but a content, so the client must treat the content as a > string Like Mark, I really like Yan's proposal for a data:type attribute, but I do think it should not be optional. If the people that use Java have to rely on this attribute to figure out what data type they are parsing, the example object above should be invalid. If 152 would be treated as string by a Java client and as integer by a client written in Perl, parsing BioMOBY data would no longer be language independent and that would be a very bad thing. If we would introduce a data:type attribute, having the element name indicating the same thing is a bit redundant. Furthermore I think it is makes more sense to identify an element based on it's name as compared to having multiple elements with the same name and then using the articleName attribute to figure out what is what. If we have a data:type attribute the element names no longer have to be String, Integer, etc. and we actually completely forget the articleName attribute. This would break a lot of the stuff that is already running though... Cheers, Pieter > > 152 > > the data:type indicates that the content is an integer. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From Pieter.Neerincx at wur.nl Mon May 30 10:14:49 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 May 2005 12:14:49 +0200 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <42978FC7.7030805@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030805@cnb.uam.es> Message-ID: On 27 May, 2005, at 23:23, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi Mark & the MOBYfiers 8-), > > > >> Service Mirrors Mark will change the MOBY Central API such that >> multiple endponts can be registered/returned in a service search. >> This >> will affect the registerService and findService API calls. The >> implication of registering multiple endpoints is that the *identical* >> service is running in all indicated locations, with the same database >> and same software version. These endpoints all share the same Service >> Signature metadata, so they had better be identical! >> > > Also, I can remember we talked about storing updated QoS information, > doesn't it? Thinking on replicated services, each one should have its > own QoS information. > >> >> Async services a few details have to be worked out (I think the >> Spanish >> contingent took on the task of fleshing this out completely), but the >> upshot is that, when a service is registered, it will be assumed to >> have >> four ?method? calls: >> 1) The name of the service (e.g. doBlastAnalysis) >> 2) The name with _async appended (e.g. doBlastAnalysis_async) >> 3) The name with _poll appended (e.g. doBlastAnalysis_poll) >> 4) The name with _result appended (e.g. doBlastAnalyis_result) >> >> The service registration is identical to what it is now, methods 2,3,4 >> are optional and are not explicitly registered. (the ability of a >> service to run asynchronously can be determined by querying the RDF >> metadata through LSID resolution predicates TBD). Calling the >> service >> by name executes the service synchronously exactly as it does >> currently. >> If a service refuses to run synchronously, it returns an empty >> response >> (this is a valid behaviour, and will not break ?old? clients). >> Calling >> the xxx_async method will return a MOBY Object representing a >> ?ticket?- >> the namespace should be unique to your async service. The ticket can >> be >> used to poll the service using the xxx_poll method (API TBD) , and the >> same ticket can be used to retrieve the result using the xxx_result >> method. >> > > I have been reading the above description about asynchronous services, > and there is at least one loose points. You can imagine an scenario > where we have a replicated service, and that service is asynchronous. A > client would choose one of them, but it would be technically difficult > to assure the obtained ticked is useable in *each* one of the > replicated > services. INB guys have at least two huge computer facilities, and they > are geographically disperse, which makes difficult to share the same > job > identifier namespace. Therefore, either each replicated service should > have its unique namespace or clients should tie to the chosen services > at the beginning. If these replicated services share the same namespace, but are served by different service authorities, then a client can simply bind to a single service by it's authority. A combination if service name, service authority and job ID / ticket should be enough to poll a service and get the result back from the same service. Or is too simple and am I missing something... > >> >> Service Testing Metadata it was generally agreed that it is desirable >> to have a sample input such that a service can be tested. This will >> be >> made available by the service providers as a string literal in their >> Service Signature (this is retrieved by LSID resolution). The string >> should be a complete MOBY message (?..) representing a >> sample input to that service that will ALWAYS work; where ?work? means >> generate an output of the Object type registered in the Service >> Signature and in MOBY Central. This input is to be used for testing >> that a service is running, but not for validating the output. >> > > Please, don't forget detailed textual descriptions of the services > (long > description, input & output parameters, examples, external & internal > links), objects (long description, what it means each HAS and HASA > element, examples, links), and perhaps namespaces, as they should have > their place in RDF. Providers are the only responsible to fill these > optional, but useful, information fields/tags. Yes! That would make life much easier. I am currently testing some stuff where I have an async service that has an additional help call. This service is a wrapper for a commandline tool. If you call the service with an empty Moby object it returns an object "ServiceOptions" which HASA String that contains the info which you would normally get form --help on the commandline along with some info about which databases are available and when they were updated. Putting this kind of info in the service signature would make more sense though. Cheers, Pieter > > Have a nice weekend, > Jos? Mar?a > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Mon May 30 14:00:59 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 May 2005 07:00:59 -0700 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030805@cnb.uam.es> Message-ID: <429B1C9B.2060105@illuminae.com> > Yes! That would make life much easier. I am currently testing some > stuff where I have an async service that has an additional help call. > This service is a wrapper for a commandline tool. If you call the > service with an empty Moby object it returns an object > "ServiceOptions" which HASA String that contains the info which you > would normally get form --help on the commandline along with some info > about which databases are available and when they were updated. > Putting this kind of info in the service signature would make more > sense though. Would make more sense, and wouldn't break the API ;-) M From jmfernandez at cnb.uam.es Mon May 30 14:48:32 2005 From: jmfernandez at cnb.uam.es (=?windows-1252?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Mon, 30 May 2005 16:48:32 +0200 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca><42978FC7.7030 805@cnb.uam.es> Message-ID: <429B27C0.6070406@cnb.uam.es> Hi everybody, > > If these replicated services share the same namespace, but are served by > different service authorities, then a client can simply bind to a single > service by it's authority. A combination if service name, service > authority and job ID / ticket should be enough to poll a service and get > the result back from the same service. Or is too simple and am I missing > something... > Well, as far as I can remember from the meeting we agreed that replicated services would be declared as non-replicated ones, but with more than one URL, so all of them share the same (authURI,serviceName) pair. Am I wrong, Mark, Heiko, Dirk? -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From markw at illuminae.com Mon May 30 15:10:01 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 May 2005 08:10:01 -0700 Subject: [moby] Re: [MOBY-dev] Notes from working group 'B' In-Reply-To: <429B27C0.6070406@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> Message-ID: <1117465801.29183.31.camel@mobycentral.mrl.ubc.ca> On Mon, 2005-05-30 at 16:48 +0200, Jos? Mar?a Fern?ndez wrote: > Well, as far as I can remember from the meeting we agreed that > replicated services would be declared as non-replicated ones, but with > more than one URL, so all of them share the same (authURI,serviceName) > pair. Am I wrong, Mark, Heiko, Dirk? That's correct - multiple URL's associated with the same authURI and serviceName. The service metadata can presumably be associated independently with each URL,though we have not yet decided on the predicates/structure we will use. If they are different authorities (this is not the same as saying different URL's) then they have different signatures and are independent registrations in the registry. M -- -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From Pieter.Neerincx at wur.nl Mon May 30 15:30:01 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 May 2005 17:30:01 +0200 Subject: [MOBY-dev] Notes from working group 'B' In-Reply-To: <429B27C0.6070406@cnb.uam.es> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca><42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> Message-ID: <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> Hello again, On 30 May, 2005, at 16:48, Jos? Mar?a Fern?ndez wrote: > Hi everybody, > > > >> >> If these replicated services share the same namespace, but are served >> by >> different service authorities, then a client can simply bind to a >> single >> service by it's authority. A combination if service name, service >> authority and job ID / ticket should be enough to poll a service and >> get >> the result back from the same service. Or is too simple and am I >> missing >> something... >> > > Well, as far as I can remember from the meeting we agreed that > replicated services would be declared as non-replicated ones, but with > more than one URL, so all of them share the same (authURI,serviceName) > pair. Am I wrong, Mark, Heiko, Dirk? Ok, I wasn't able to attend the meeting, so I definitely missed something :(. Anyway, if replicated services will be declared with multiple URLs for the same (authURI,serviceName) combination, then the combination of (authURI,serviceName,URL) will uniquely identify a service. I don't know about the other APIs but with the current Perl API I can already search for the one service that has such a unique combo. So that should be enough for a client to retrieve results from the same async service to which it submitted a job/query :) Is that correct? Cheers, Pieter > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Mon May 30 15:39:05 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 May 2005 08:39:05 -0700 Subject: [moby] Re: [MOBY-dev] Notes from working group 'B' In-Reply-To: <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> References: <1117220757.30771.43.camel@mobycentral.mrl.ubc.ca> <42978FC7.7030 805@cnb.uam.es> <429B27C0.6070406@cnb.uam.es> <59cc19418f55599d1b6f304aa24cb9b0@wur.nl> Message-ID: <1117467545.29183.35.camel@mobycentral.mrl.ubc.ca> On Mon, 2005-05-30 at 17:30 +0200, Pieter Neerincx wrote: > service. I don't know about the other APIs but with the current Perl > API I can already search for the one service that has such a unique > combo. So that should be enough for a client to retrieve results from > the same async service to which it submitted a job/query :) Is that > correct? Actually, I think this is still an issue. At the moment, and under the proposed API, there is no defined way for a client to interact with the same (replicated) service when it calls an async service as it does when it retrieves the result. The burden of remembering which replicated service it called may have to be client-side unless we can come up with a creative alternative. M -- -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From markw at illuminae.com Mon May 30 21:39:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 May 2005 14:39:09 -0700 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429B758F.5020903@cnb.uam.es> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> Message-ID: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Hiya, We're looking into using mod_jk to do this kind of auto-forwarding of tomcat requests through port 80. I've never done it, and Eddie has only done it on Windows. Once we have played with it a few times and figured out a standard, stable way to do it, we'll add this to the documentation. M On Mon, 2005-05-30 at 22:20 +0200, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi everybody, > I have a different problem. CNB machines are behind a firewall which > doesn't allow a connection to 'strange' ports like 8090 (we have a very > restrictive security policy). I can solve it talking to CNB's sysadmins > (and signing a liability sheet), but it could be an annoyance if we had > to do it for many addresses and/or ports. > > With this annoyance, I'm concerned by those services which live on a > different port from HTTP and HTTPS ones. Those BioMOBY users behind a > firewall (like us) won't be able to use those services, and so they > could think the services are not working. I think we should include some > sort of warning about this potencial problem, and also we should > recommend MOBY service creators to use standard HTTP/HTTPS ports for > their services. > > Best regards, > Jos? Mar?a > > Mark Wilkinson wrote: > > try now. > > > > Sorry about that > > > > M > > > > > > On Wed, 2005-05-18 at 15:07 +0200, David Baux wrote: > > > >>hello, > >>i'd like to use the biomoby tool "Applet to retrieve the RDF Signature > >>of your service" to generate the RDF file of my service. But when I fill > >>in the form with the right Domain and URL, the browser prints: > >> > >> > >> Unable to update your information > >> > >> > >> Make sure that you specify a valid signature url! This field looks > >> like the following: > >> http://myAuthority.domain/path/to/rdf/for/service. Also make sure > >> that you have specified the right case-sensitive service name, if > >> applicable. > >> > >>while the url is: http://tropgenedb.cirad.fr/cgi-bin/biomoby > >> > >>Does somebody know what to do? > >> > >>thanks for your answers > >> > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l > > > > > -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Vancouver, BC From tmo at ebi.ac.uk Mon May 30 22:32:58 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 30 May 2005 23:32:58 +0100 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429B949A.60101@ebi.ac.uk> Mark Wilkinson wrote: > Hiya, > > We're looking into using mod_jk to do this kind of auto-forwarding of > tomcat requests through port 80. You could do what the EBI does and use the ProxyPass directive in Apache - I don't believe we use any of the mod_jk style connectors at all in our web architecture and it all appears to work well enough. You do occasionally get slightly hard to debug behaviour if something goes wrong but it's a whole lot less hassle to configure and doesn't need any new software. Services we're running such as Martin's SoapLab are exposed like this and it all appears happy. Tom From tmo at ebi.ac.uk Mon May 30 22:32:58 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 30 May 2005 23:32:58 +0100 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429B949A.60101@ebi.ac.uk> Mark Wilkinson wrote: > Hiya, > > We're looking into using mod_jk to do this kind of auto-forwarding of > tomcat requests through port 80. You could do what the EBI does and use the ProxyPass directive in Apache - I don't believe we use any of the mod_jk style connectors at all in our web architecture and it all appears to work well enough. You do occasionally get slightly hard to debug behaviour if something goes wrong but it's a whole lot less hassle to configure and doesn't need any new software. Services we're running such as Martin's SoapLab are exposed like this and it all appears happy. Tom From gss at ncgr.org Tue May 31 15:05:32 2005 From: gss at ncgr.org (Gary Schiltz) Date: Tue, 31 May 2005 10:05:32 -0500 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentral.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es> <1117489149.29986.17.camel@mobycentral.mrl.ubc.ca> Message-ID: <429C7D3C.1050602@ncgr.org> About a year ago, I looked at connecting Tomcat (5.x) and the Apache HTTP Server (2.x) with little success. If I remember correctly, I got it to work under Windows, but could never get the two to talk under Linux (Red Hat 9). One of Lincoln Stein's students suggested Resin (www.caucho.com) as a Servlet container, and it was very easy to get working with Apache. There is an open source version, which seems fine as far as performance goes. I ended up using Resin for the Semantic MOBY site. // Gary Mark Wilkinson wrote: >Hiya, > >We're looking into using mod_jk to do this kind of auto-forwarding of >tomcat requests through port 80. > >I've never done it, and Eddie has only done it on Windows. Once we have >played with it a few times and figured out a standard, stable way to do >it, we'll add this to the documentation. > >M > > > >>> >>> From jmfernandez at cnb.uam.es Tue May 31 18:26:00 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXo=?=) Date: Tue, 31 May 2005 20:26:00 +0200 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429C7D3C.1050602@ncgr.org> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@moby central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org> Message-ID: <429CAC38.5020609@cnb.uam.es> I have been talking to our webmasters about our Apache configuration, and they showed me the way to configure Apache to map Tomcat services. It is like this one: ProxyPass /thePath http://other.machine/otherPath ProxyPassReverse /thePath http://other.machine/otherPath As you can see, you have to write *twice* the equivalence, but with different commands. The first one (ProxyPass) tells Apache that all queries to /thePath and its subpaths should be rewritten as http://other.machine/otherPath (and its subpaths). The second command (ProxyPassReverse) tells Apache that it must work as a reverse proxy for that path, instead of redirecting the queries with a HTTP 305 code. It is obvius ProxyPass/ProxyPassReverse works because current application servers handle HTTP requests. Tomcat 4 and above *must* do that because they follow the 2.3 servlet specification, which tells that the application server must handle and understand HTTP requests. Best Regards, Jos? Mar?a Gary Schiltz wrote: > About a year ago, I looked at connecting Tomcat (5.x) and the Apache > HTTP Server (2.x) with little success. If I remember correctly, I got it > to work under Windows, but could never get the two to talk under Linux > (Red Hat 9). One of Lincoln Stein's students suggested Resin > (www.caucho.com) as a Servlet container, and it was very easy to get > working with Apache. There is an open source version, which seems fine > as far as performance goes. I ended up using Resin for the Semantic MOBY > site. > > // Gary > > Mark Wilkinson wrote: > >> Hiya, >> We're looking into using mod_jk to do this kind of auto-forwarding of >> tomcat requests through port 80. >> >> I've never done it, and Eddie has only done it on Windows. Once we have >> played with it a few times and figured out a standard, stable way to do >> it, we'll add this to the documentation. >> >> M >> >> >> >>>> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From gss at ncgr.org Tue May 31 18:44:39 2005 From: gss at ncgr.org (Gary Schiltz) Date: Tue, 31 May 2005 13:44:39 -0500 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429CAC38.5020609@cnb.uam.es> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@moby central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org> <429CAC38.5020609@cnb.uam.es> Message-ID: <429CB097.3030407@ncgr.org> Thanks Jos? Mar?a for the information on Apache configuration. That approach would work if you want Tomcat to handle everything under a given path, including HTML, images, etc. However, if you want Apache to handle all HTTP requests, including Perl CGI requests, sessions, etc. and only use Tomcat to handle Servlets and JSP, then I believe you still need to use mod_jk, mod_jk2, or a similar adapter. For example, if you have /foo/bigdoc.html, /foo/hugeimage.jpg, and /foo/index.jsp, you would probably want Apache to deliver bigdoc.html and hugeimage.jpg, but would want Apache to delegate execution of index.jsp to Tomcat. Again, I couldn't get this to work under Red Hat 9, so I used Resin, which works very well with Apache. // Gary Jos? Mar?a Fern?ndez wrote: > I have been talking to our webmasters about our Apache configuration, > and they showed me the way to configure Apache to map Tomcat services. > It is like this one: > > ProxyPass /thePath http://other.machine/otherPath > ProxyPassReverse /thePath http://other.machine/otherPath > > As you can see, you have to write *twice* the equivalence, but with > different commands. The first one (ProxyPass) tells Apache that all > queries to /thePath and its subpaths should be rewritten as > http://other.machine/otherPath (and its subpaths). The second command > (ProxyPassReverse) tells Apache that it must work as a reverse proxy for > that path, instead of redirecting the queries with a HTTP 305 code. > > It is obvius ProxyPass/ProxyPassReverse works because current > application servers handle HTTP requests. Tomcat 4 and above *must* do > that because they follow the 2.3 servlet specification, which tells that > the application server must handle and understand HTTP requests. > > Best Regards, > Jos? Mar?a From jmfernandez at cnb.uam.es Tue May 31 19:42:38 2005 From: jmfernandez at cnb.uam.es (=?UTF-8?B?Sm9zw6kgTWFyw61hIEZlcm7DoW5kZXogR29uesOhbGV6?=) Date: Tue, 31 May 2005 21:42:38 +0200 Subject: [MOBY-dev] Re: [moby] Re: [MOBY-l] RDF file problem In-Reply-To: <429CB097.3030407@ncgr.org> References: <428B3E1C.8040100@cirad.fr> <1116428745.25744.17.camel@mobycentr al.mrl.ubc.ca> <429B758F.5020903@cnb.uam.es><1117489149.29986.17.camel@mob y central.mrl.ubc.ca> <429C7D3C.1050602@ncgr.org><429CAC38.5020609@cnb.uam. es> <429CB097.3030407@ncgr.org> Message-ID: <429CBE2E.2000706@cnb.uam.es> (Mainly offtopic?) Maybe I'm wrong, but Tomcat already does it inside. Apache only forwards the HTTP query, and Tomcat works as expected with JSPs, because it is its default behaviour when any HTTP query arrives (unless you have reconfigured it). JK modules are dedicated to communicate Apache and Tomcat, so Apache serves static content (which does very well) and Tomcat handles dynamic content (servlets, jsps). When you have a heavy used directory with a mixure of static content files/pages and dynamic content and servlets, then Apache+Tomcat+JK is unbeatable, because even if you need it you can apply some load-balancing techniques (one Apache/many Tomcat workers) in an easy way. The advantages of ProxyPass/ProxyPassReverse are the simplicity and the decoupling effect, because Apache and Tomcat can be started, stopped, managed, upgraded, etc..., with no software dependency (no mod_jk2 to be compiled), and each one is free from the other. Old incarnations of JK modules (mod_webapps) had some problems when Tomcat wasn't running on Apache startup, or when Tomcat was restarted (very common two years ago in a Tomcat development environment). I don't know how well is JK implementation, but our webmaster didn't want more problems than the unavoidable ones, so they are using ProxyPass/ProxyPassReverse). Best Regards, Jos? Mar?a Gary Schiltz wrote: > Thanks Jos? Mar?a for the information on Apache configuration. That > approach would work if you want Tomcat to handle everything under a > given path, including HTML, images, etc. However, if you want Apache to > handle all HTTP requests, including Perl CGI requests, sessions, etc. > and only use Tomcat to handle Servlets and JSP, then I believe you still > need to use mod_jk, mod_jk2, or a similar adapter. For example, if you > have /foo/bigdoc.html, /foo/hugeimage.jpg, and /foo/index.jsp, you would > probably want Apache to deliver bigdoc.html and hugeimage.jpg, but would > want Apache to delegate execution of index.jsp to Tomcat. Again, I > couldn't get this to work under Red Hat 9, so I used Resin, which works > very well with Apache. > > // Gary > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)