From hase at umbc.edu Mon Aug 1 23:30:31 2005 From: hase at umbc.edu (HASE) Date: Mon Aug 1 23:20:46 2005 Subject: [MOBY-dev] Bioinformatics Software Development Survey Message-ID: <2015.68.49.173.177.1122953431.squirrel@68.49.173.177> Hello, As part of our research at UMBC, we are studying the characteristics of software development in the bioinformatics domain. We believe that this study should be guided by the people who are actively involved in bioinformatics. This research is our first step towards enabling the production of high quality bioinformatics software with less time and effort. Therefore, your feedback is very important to us. We seek your input in the form of a survey questionnaire that will take around 15 minutes of your time. We solicit general demographic information, information about the products that you have developed, your work practices, and your software development process. So, if you are a bioinformatics professional doing software development or a software developer working in the bioinformatics domain, please provide us with your valuable input. We assure you that this information will be used only for academic purposes and will be completely confidential. Please follow the link below to start the survey: http://www.is.umbc.edu/bio-survey/ We appreciate your participation in advance. Regards, HASE (Human Aspects of Software Engineering) 1000 Hilltop Circle Department of Information Systems University of Maryland Baltimore County Baltimore, MD, 21250 hase@umbc.edu From senger at ebi.ac.uk Wed Aug 3 00:23:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 3 00:15:28 2005 Subject: [MOBY-dev] 0.85 codebase running on test server In-Reply-To: <1122672917.19643.31.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, These are good news. Things are moving forwards, that's great. One thing that I missed in your "in the pipelines" section is an implementation of an API giving back URLs of the various RESOURCES. I really needs this soon - so I can code various things using data in RDF (which is much faster than to get things one-by-obe from the registry by the traditional API calls). Would you consider to give it higher priority please? Thanks and regards, Martin -- Martin Senger martin.senger@gmail.com From senger at ebi.ac.uk Wed Aug 3 00:23:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 3 00:15:50 2005 Subject: [MOBY-dev] 0.85 codebase running on test server In-Reply-To: <1122672917.19643.31.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, These are good news. Things are moving forwards, that's great. One thing that I missed in your "in the pipelines" section is an implementation of an API giving back URLs of the various RESOURCES. I really needs this soon - so I can code various things using data in RDF (which is much faster than to get things one-by-obe from the registry by the traditional API calls). Would you consider to give it higher priority please? Thanks and regards, Martin -- Martin Senger martin.senger@gmail.com From markw at illuminae.com Thu Aug 4 05:31:15 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 05:21:20 2005 Subject: [MOBY-dev] articleName legacy cruft... Message-ID: <1123147875.42f1e06355b9f@webmail.illuminae.com> Hi all, the presence of "articleName" in the Simple/Collection and Secondary tags is really bothering me, given that it is used with a different meaning in the objects (this is legacy cruft that has now become fixed into the code!) It's a fairly significant modification to change this to "componentName"... but I am itching to do it! Given that we are about to break things anyway with the 1.0 release, should we break this at the same time? M From markw at illuminae.com Thu Aug 4 05:38:25 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 05:55:57 2005 Subject: [MOBY-dev] Changes in the 0.86API Message-ID: <1123148305.42f1e211565c7@webmail.illuminae.com> Hi all, A few changes to announce for the 0.86 API (this is not yet running on the production server): 1) *all* parameters going into a service must now be named (currently using the articleName attribute of the Simple/Collection/Parameter tag, but I want to migrate this to componentName if possible) 2) Inheritence from primitive classes is now forbidden and this is enforced by the MOBY Central code. 3) Collections may now only contain one type of Simple (I don't think anyone uses it any other way, so no worries) 4) a new method "retrieveResourceURLs" has been added to the API that provides you with a list of the URLs from which you can retrieve the RDF versions of all of the ontologies. I will be moving the production server to the new codebase next week sometime. Cheers! M From senger at ebi.ac.uk Thu Aug 4 09:16:57 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Aug 4 09:07:50 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: > 1) *all* parameters going into a service must now be named (currently using the > articleName attribute of the Simple/Collection/Parameter tag, but I want to > migrate this to componentName if possible) > Generally it is a good idea (to have things named). I also remember that we had asked for in in Vancouver. But the change, even though may not be big in the code, is big in the documentation, in the API description. I would rather see first an updated API documentation, read it and only then have here a discussion about it. This is mainly we used the name 'article' not only as an XML attribute, but we had/have also an XML tag called 'secondaryArticle', we often speak about 'parameters' (as you just done above) but we mean by that actually all input data... and so on. Other issue is that the biomoby.org now has API086 from the August 3. But it does not have the changes described in your last email - and the email is labeled 'changes in the 0.86' - so you are actually describing changes that will be in 0.87API? I am confused... The normal practice - which I strongly suggest - is to keep on biomoby.org an API which works currently - and to have a separate page, where we can see 'proposed API' - which is not yet implemented, even it is not yet approved by us/developers and it serves for these discussions. I know that it is boring to keep docs updated but that is one of the issues we discussed in V. when we said that the current biomoby does not have enough of the 'project management' :-) Back to article names: I remember that in Malaga the ICN people had talked about their incoming proposal for more decent error handling in biomoby messages. For that, the article names were mandatory (so it is good that we are thinking about it in the same way) - but I think that they wanted to name also individual Simples in Collection. So it may be worth to make sure that they are listening now... > 2) Inheritence from primitive classes is now forbidden and this is enforced by > the MOBY Central code. > Again, this need to be documented first... > 4) a new method "retrieveResourceURLs" has been added to the API that provides > you with a list of the URLs from which you can retrieve the RDF versions of all > of the ontologies. > Here comes my previous email (send only to Mark) about how to make these (BIG) RDF documents compressed. One solution is to allow registry providers to specify two URLs for each resource type, one for normal and one for zipped document. > I will be moving the production server to the new codebase next week sometime. > No, don't do it so soon... Please... Describe it first in the API in details... Martin -- Martin Senger martin.senger@gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Aug 4 09:16:57 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Aug 4 09:08:06 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: > 1) *all* parameters going into a service must now be named (currently using the > articleName attribute of the Simple/Collection/Parameter tag, but I want to > migrate this to componentName if possible) > Generally it is a good idea (to have things named). I also remember that we had asked for in in Vancouver. But the change, even though may not be big in the code, is big in the documentation, in the API description. I would rather see first an updated API documentation, read it and only then have here a discussion about it. This is mainly we used the name 'article' not only as an XML attribute, but we had/have also an XML tag called 'secondaryArticle', we often speak about 'parameters' (as you just done above) but we mean by that actually all input data... and so on. Other issue is that the biomoby.org now has API086 from the August 3. But it does not have the changes described in your last email - and the email is labeled 'changes in the 0.86' - so you are actually describing changes that will be in 0.87API? I am confused... The normal practice - which I strongly suggest - is to keep on biomoby.org an API which works currently - and to have a separate page, where we can see 'proposed API' - which is not yet implemented, even it is not yet approved by us/developers and it serves for these discussions. I know that it is boring to keep docs updated but that is one of the issues we discussed in V. when we said that the current biomoby does not have enough of the 'project management' :-) Back to article names: I remember that in Malaga the ICN people had talked about their incoming proposal for more decent error handling in biomoby messages. For that, the article names were mandatory (so it is good that we are thinking about it in the same way) - but I think that they wanted to name also individual Simples in Collection. So it may be worth to make sure that they are listening now... > 2) Inheritence from primitive classes is now forbidden and this is enforced by > the MOBY Central code. > Again, this need to be documented first... > 4) a new method "retrieveResourceURLs" has been added to the API that provides > you with a list of the URLs from which you can retrieve the RDF versions of all > of the ontologies. > Here comes my previous email (send only to Mark) about how to make these (BIG) RDF documents compressed. One solution is to allow registry providers to specify two URLs for each resource type, one for normal and one for zipped document. > I will be moving the production server to the new codebase next week sometime. > No, don't do it so soon... Please... Describe it first in the API in details... Martin -- Martin Senger martin.senger@gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From markw at illuminae.com Thu Aug 4 10:11:31 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 10:09:07 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <1123164691.42f222134a314@webmail.illuminae.com> Quoting Martin Senger : > Generally it is a good idea (to have things named). I also remember > that we had asked for in in Vancouver. But the change, even though may not > be big in the code, is big in the documentation, in the API description. I > would rather see first an updated API documentation, read it and only then > have here a discussion about it. This is mainly we used the name 'article' > not only as an XML attribute, but we had/have also an XML tag called > 'secondaryArticle', we often speak about 'parameters' (as you just done > above) but we mean by that actually all input data... and so on. > Other issue is that the biomoby.org now has API086 from the August > 3. But it does not have the changes described in your last email - and the > email is labeled 'changes in the 0.86' The changes I describe in my email are, in fact (I think??) documented in the 0.86 API that is on the website (see the change history at the bottom of the page), but you are correct that the current production server is not running the 0.86 API - it is running the 0.85 API. I have sent the main developers the endpoint of the instance of MOBY Central that is running the 0.86 codebase so that you can test it and begin the process of coding to it. I share your reservations about changing the articleName (in its "parameter" meaning) to componentName, given that we have many other tags in our XML messaging that use the word "Article" with the same intention. Perhaps it is better to change the MOBY Object articleName attribute to something else instead? That would likely require less changes in our code... One or the other of them really must go because they have two different meanings! > - so you are actually describing > changes that will be in 0.87API? I am confused... The normal practice - > which I strongly suggest - is to keep on biomoby.org an API which works > currently - and to have a separate page, where we can see 'proposed API' - > which is not yet implemented, even it is not yet approved by us/developers > and it serves for these discussions. This is a good idea... I will try to do that right now. I can get a diff of the current API versus the 0.85 API and then set up a second Twiki page from that diff. > I know that it is boring to keep docs > updated but that is one of the issues we discussed in V. when we said that > the current biomoby does not have enough of the 'project management' :-) It's not so much that it is boring (I actually enjoy documentation! What a pedantic nutter I am!), however it is really a matter of limited resourcing and time - it is rare for me to have so much time for coding, and as you have pointed out frequently, MOBY Central is currently a one-man-show for the most part, so when these moments arise I feel obligated to use it to push forward the codebase as far as possible rather than slowly and carefully as I would prefer :-/ I'm trying to keep you and the other core developers updated as to my activities, and I am similarly trying to limit my changes to those that were made in agreement with the attendees at the last meeting (i.e. that we have already discussed as a group), and to respond to those decisions as quickly as possible. Given the ten fingers I have, and the time constraints, that's the best I can manage... > Back to article names: I remember that in Malaga the ICN people had > talked about their incoming proposal for more decent error handling in > biomoby messages. For that, the article names were mandatory (so it is > good that we are thinking about it in the same way) - but I think that > they wanted to name also individual Simples in Collection. So it may be > worth to make sure that they are listening now... Eeek! I don't remember that... Can you recall why this was necessary? > > 2) Inheritence from primitive classes is now forbidden and this is > enforced by > > the MOBY Central code. > > > Again, this need to be documented first... It is, in the 0.86API. > > 4) a new method "retrieveResourceURLs" has been added to the API that > provides > > you with a list of the URLs from which you can retrieve the RDF versions of > all > > of the ontologies. > > > Here comes my previous email (send only to Mark) about how to make > these (BIG) RDF documents compressed. One solution is to allow registry > providers to specify two URLs for each resource type, one for normal and > one for zipped document. I guess the "safe" way to handle that would be to add a "type" attribute to the tag indicaing the MIME type of the document that is behind the URL (yeah... we could get that by calling HEAD, I guess...). It will be important to know this for software that needs to receive an ontology by calling the URL... > > I will be moving the production server to the new codebase next week > sometime. > > > No, don't do it so soon... Please... Describe it first in the API in > details... OK. The code is, however, up and running on the test server that I told you about yesterday. Cheers! M From gordonp at ucalgary.ca Thu Aug 4 10:56:22 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu Aug 4 10:46:37 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> References: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: <42F22C96.3050106@ucalgary.ca> >2) Inheritence from primitive classes is now forbidden and this is enforced by >the MOBY Central code. > > May I humbly suggest that Boolean be considered primitive? I registered this object last week. >3) Collections may now only contain one type of Simple (I don't think anyone >uses it any other way, so no worries) > > Let me understand this though, if I declare a Collection of Objects, I should still be able to shove anything in there. If I declare a Collection of VirtualSequences, I should be able to put AminoAcidSequences and DNASequences in it. Otherwise we break the operational transparency of inheritence... From gordonp at ucalgary.ca Thu Aug 4 10:56:22 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu Aug 4 10:46:39 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> References: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: <42F22C96.3050106@ucalgary.ca> >2) Inheritence from primitive classes is now forbidden and this is enforced by >the MOBY Central code. > > May I humbly suggest that Boolean be considered primitive? I registered this object last week. >3) Collections may now only contain one type of Simple (I don't think anyone >uses it any other way, so no worries) > > Let me understand this though, if I declare a Collection of Objects, I should still be able to shove anything in there. If I declare a Collection of VirtualSequences, I should be able to put AminoAcidSequences and DNASequences in it. Otherwise we break the operational transparency of inheritence... From senger at ebi.ac.uk Thu Aug 4 11:47:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Aug 4 11:38:02 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123164691.42f222134a314@webmail.illuminae.com> Message-ID: > > Back to article names: I remember that in Malaga the ICN people had > > talked about their incoming proposal for more decent error handling in > > ... > Eeek! I don't remember that... Can you recall why this was necessary? > no, you were not there - it was the last meeting when Eddie and me were involved; perhaps Eddie remembers their suggestion, or to whom contact abou it (afaik they have not sent it yet) > I guess the "safe" way to handle that would be to add a "type" attribute to the > tag indicaing the MIME type of the document that is behind the URL > yes; and to allow returning several tags for the same resource name but with a different type; (Contra my recent advise: could you make it - so I can added it to jmoby :-) ... btw, jMoby already has the current way, without any compression, but I will wait for your reply before committing it tomorrow.) Cheers, Martin -- Martin Senger martin.senger@gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From ots at ac.uma.es Thu Aug 4 12:03:34 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu Aug 4 11:53:44 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: from "Martin Senger" at Aug 04, 2005 04:47:59 PM Message-ID: <200508041603.SAA24534@algarrobo.ac.uma.es> HI, I am sorry, but I am having a nice time near Barcelona and perhaps I have lost some messages. one week ago -more or less- we submitt a short proposal for error-handling The point to be considered is how to inform about an incidence (warning or error) when processing a collection (as a set of simples not as a "unit"). In this case it is necessary to identify each simple. one way is by using the articleName (which could be automatically produced by the client -in the worse case) sds, O. > > > Back to article names: I remember that in Malaga the ICN people had > > > talked about their incoming proposal for more decent error handling in > > > ... > > Eeek! I don't remember that... Can you recall why this was necessary? > > > no, you were not there - it was the last meeting when Eddie and me were > involved; perhaps Eddie remembers their suggestion, or to whom contact > abou it (afaik they have not sent it yet) > > > I guess the "safe" way to handle that would be to add a "type" attribute to the > > tag indicaing the MIME type of the document that is behind the URL > > > yes; and to allow returning several tags for the same > resource name but with a different type; > (Contra my recent advise: could you make it - so I can added it to > jmoby :-) ... btw, jMoby already has the current way, without any > compression, but I will wait for your reply before committing it > tomorrow.) > > Cheers, > Martin > > -- > Martin Senger martin.senger@gmail.com > > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Thu Aug 4 12:03:34 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu Aug 4 11:53:45 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: from "Martin Senger" at Aug 04, 2005 04:47:59 PM Message-ID: <200508041603.SAA24534@algarrobo.ac.uma.es> HI, I am sorry, but I am having a nice time near Barcelona and perhaps I have lost some messages. one week ago -more or less- we submitt a short proposal for error-handling The point to be considered is how to inform about an incidence (warning or error) when processing a collection (as a set of simples not as a "unit"). In this case it is necessary to identify each simple. one way is by using the articleName (which could be automatically produced by the client -in the worse case) sds, O. > > > Back to article names: I remember that in Malaga the ICN people had > > > talked about their incoming proposal for more decent error handling in > > > ... > > Eeek! I don't remember that... Can you recall why this was necessary? > > > no, you were not there - it was the last meeting when Eddie and me were > involved; perhaps Eddie remembers their suggestion, or to whom contact > abou it (afaik they have not sent it yet) > > > I guess the "safe" way to handle that would be to add a "type" attribute to the > > tag indicaing the MIME type of the document that is behind the URL > > > yes; and to allow returning several tags for the same > resource name but with a different type; > (Contra my recent advise: could you make it - so I can added it to > jmoby :-) ... btw, jMoby already has the current way, without any > compression, but I will wait for your reply before committing it > tomorrow.) > > Cheers, > Martin > > -- > Martin Senger martin.senger@gmail.com > > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From jmrc at cnb.uam.es Thu Aug 4 12:28:34 2005 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Thu Aug 4 12:18:14 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <42F24232.30207@cnb.uam.es> Martin Senger wrote: > Back to article names: I remember that in Malaga the_ ICN people_ had >talked about their incoming proposal for more decent error handling in >biomoby messages. For that, the article names were mandatory (so it is >good that we are thinking about it in the same way) - but I think that >they wanted to name also individual Simples in Collection. So it may be >worth to make sure that they are listening now... > > > Sorry Martin, but we are *INB* people! :-) http://www.inab.org Cheers, Jos? Manuel. From jmrc at cnb.uam.es Thu Aug 4 12:28:34 2005 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Thu Aug 4 12:18:16 2005 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <42F24232.30207@cnb.uam.es> Martin Senger wrote: > Back to article names: I remember that in Malaga the_ ICN people_ had >talked about their incoming proposal for more decent error handling in >biomoby messages. For that, the article names were mandatory (so it is >good that we are thinking about it in the same way) - but I think that >they wanted to name also individual Simples in Collection. So it may be >worth to make sure that they are listening now... > > > Sorry Martin, but we are *INB* people! :-) http://www.inab.org Cheers, Jos? Manuel. From jmfernandez at cnb.uam.es Fri Aug 5 15:10:00 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri Aug 5 15:00:14 2005 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY Message-ID: <42F3B988.7020506@cnb.uam.es> Hi everybody, I don't like crossposting, but I don't know if the bug I have found today is from the Taverna 1.2 core or the MOBY plugin. The bug is pretty simple: if you create/load a workflow which has a service whose name in the workflow is different from the service name, Taverna does not use the official service name when it is invoked. Instead, it uses the name given to the service in the workflow! The same workflow works flawlessly when it is loaded and run in Taverna 1.1. I have discovered the bug with a MOBY service (see the sample workflow ja5.xml, and the reports taverna-1.1-report.xml and taverna-1.2-report.xml), so I don't know which has the blame... This bug should arise when one service is used more than once, which is very common in real workflows! Best Regards, Jos? Mar?a Fern?ndez -- 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: ja5.xml Type: text/xml Size: 1813 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050805/8e5996c3/ja5-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: taverna-1.1-report.xml Type: text/xml Size: 1796 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050805/8e5996c3/taverna-1.1-report-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: taverna-1.2-report.xml Type: text/xml Size: 4405 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050805/8e5996c3/taverna-1.2-report-0001.xml From senger at ebi.ac.uk Sun Aug 7 19:47:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun Aug 7 19:38:00 2005 Subject: [MOBY-dev] jMoby updated Message-ID: Two new methods were added to the Central.java interface: * getResourceRefs() returns a list of URLs of available resources of a BioMoby registry (a "resource" is an RDF document describing registered entities), and * getResource() returns contents of a particular resource The implementation (in CentralImpl.java) seems to work now - but it may be slightly changed later when Mark adds possibility to fetch resources also in a compressed form. The new methods are also reflected in the main jMoby command line client - type 'build/run/run-cmdline-client -help'. I have also updated the 'Acknowledgements' section in the main jMoby page (http://www.biomoby.org/moby-live/Java/docs/index.html). Please feel free to add there your own funding sources. With regards, Martin -- Martin Senger martin.senger@gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Mon Aug 8 09:42:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon Aug 8 09:33:34 2005 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F3B988.7020506@cnb.uam.es> Message-ID: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Hi, I think that that has been fixed. I actually noticed that bug when using the Planet workflows. So, like I said, it should be fixed. Out of curiosity, did you cvs build or download a prepackaged Taverna? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Friday, August 05, 2005 12:10 PM > To: taverna-users@lists.sourceforge.net; moby- > l@biomoby.org; mobydev; taverna- > hackers@lists.sourceforge.net > Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related > to BioMOBY > > Hi everybody, > I don't like crossposting, but I don't know if the > bug I have found > today is from the Taverna 1.2 core or the MOBY plugin. > > The bug is pretty simple: if you create/load a > workflow which has a > service whose name in the workflow is different from the > service name, > Taverna does not use the official service name when it is > invoked. > Instead, it uses the name given to the service in the > workflow! The same > workflow works flawlessly when it is loaded and run in > Taverna 1.1. > > I have discovered the bug with a MOBY service (see > the sample workflow > ja5.xml, and the reports taverna-1.1-report.xml and > taverna-1.2-report.xml), so I don't know which has the > blame... > > This bug should arise when one service is used more > than once, which is > very common in real workflows! > > Best Regards, > Jos? Mar?a Fern?ndez > -- > 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 edward.kawas at gmail.com Mon Aug 8 09:42:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon Aug 8 09:34:08 2005 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F3B988.7020506@cnb.uam.es> Message-ID: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Hi, I think that that has been fixed. I actually noticed that bug when using the Planet workflows. So, like I said, it should be fixed. Out of curiosity, did you cvs build or download a prepackaged Taverna? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Friday, August 05, 2005 12:10 PM > To: taverna-users@lists.sourceforge.net; moby- > l@biomoby.org; mobydev; taverna- > hackers@lists.sourceforge.net > Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related > to BioMOBY > > Hi everybody, > I don't like crossposting, but I don't know if the > bug I have found > today is from the Taverna 1.2 core or the MOBY plugin. > > The bug is pretty simple: if you create/load a > workflow which has a > service whose name in the workflow is different from the > service name, > Taverna does not use the official service name when it is > invoked. > Instead, it uses the name given to the service in the > workflow! The same > workflow works flawlessly when it is loaded and run in > Taverna 1.1. > > I have discovered the bug with a MOBY service (see > the sample workflow > ja5.xml, and the reports taverna-1.1-report.xml and > taverna-1.2-report.xml), so I don't know which has the > blame... > > This bug should arise when one service is used more > than once, which is > very common in real workflows! > > Best Regards, > Jos? Mar?a Fern?ndez > -- > 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 jmfernandez at cnb.uam.es Mon Aug 8 10:52:35 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon Aug 8 10:42:31 2005 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42f76179.195ac951.0c6c.100f@mx.gmail.com> References: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Message-ID: <42F771B3.8010600@cnb.uam.es> Hi Eddie, Edward Kawas wrote: > Hi, > > I think that that has been fixed. I actually noticed that > bug when using the Planet workflows. So, like I said, it > should be fixed. > Yes, Tom told me that on Friday. I was looking at CVS and as you have said, it seems it is fixed there. > Out of curiosity, did you cvs build or download a > prepackaged Taverna? > As you can imagine, I was working on a prepackaged Taverna 1.2 version :-(. We are working behind a firewall, and I was digging as an user how much functionality related to MOBY in Taverna 1.2 was affected by that fact. I realized that problem when I did a worflow with two branches, both branches with the same service and one of them had to be renamed. What I have seen is that object instances generated from the new object tree in BioMOBY scavenger use information from http://biomoby.org/RESOURCES/MOBY-S/Objects so those workflow branches with any of those object instantes stalled just inside them. I was digging on that URL, and I saw that all the rdf:about attributes (plus others, like rdf:resource in http://biomoby.org/RESOURCES/MOBY-S/Services) were referencing your Tomcat server at mobycentral.icapture.ubc.ca:8090. Is there some progress on MOBY Apache server with ProxyPass/ProxyPassReverse? Best Regards, 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 edward.kawas at gmail.com Mon Aug 8 10:54:20 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon Aug 8 10:44:41 2005 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F771B3.8010600@cnb.uam.es> Message-ID: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> Actually, give it a try now. It should work as Mark tweeked it! Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Monday, August 08, 2005 7:53 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] A bug in Taverna 1.2 perhaps > related to BioMOBY > > Hi Eddie, > > Edward Kawas wrote: > > Hi, > > > > I think that that has been fixed. I actually noticed > that > > bug when using the Planet workflows. So, like I said, it > > should be fixed. > > > > Yes, Tom told me that on Friday. I was looking at CVS and > as you have > said, it seems it is fixed there. > > > Out of curiosity, did you cvs build or download a > > prepackaged Taverna? > > > > As you can imagine, I was working on a prepackaged Taverna > 1.2 version > :-(. We are working behind a firewall, and I was digging > as an user how > much functionality related to MOBY in Taverna 1.2 was > affected by that > fact. I realized that problem when I did a worflow with > two branches, > both branches with the same service and one of them had to > be renamed. > > What I have seen is that object instances generated > from the new object > tree in BioMOBY scavenger use information from > > http://biomoby.org/RESOURCES/MOBY-S/Objects > > so those workflow branches with any of those object > instantes stalled > just inside them. I was digging on that URL, and I saw > that all the > rdf:about attributes (plus others, like rdf:resource in > http://biomoby.org/RESOURCES/MOBY-S/Services) were > referencing your > Tomcat server at mobycentral.icapture.ubc.ca:8090. Is > there some > progress on MOBY Apache server with > ProxyPass/ProxyPassReverse? > > Best Regards, > 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 Aug 8 11:52:46 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Mon Aug 8 12:00:31 2005 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> References: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> Message-ID: <1123516366.42f77fceb1a8f@webmail.illuminae.com> Quoting Edward Kawas : > Actually, give it a try now. It should work as Mark tweeked > it! > > Tomcat server at mobycentral.icapture.ubc.ca:8090. Is > > there some progress on MOBY Apache server with > > ProxyPass/ProxyPassReverse? Yes, I made those changes a few days ago. Please let me know ASAP if they aren't solving the problem. Greetings from (and goodbye to) Manchester! I'll be back in Vancouver on Wednesday. M From senger at ebi.ac.uk Wed Aug 10 21:10:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 10 21:00:22 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: This question is meant primarily for Java-based biomoby services, but a suggestion from Perl people can help me as well. I wonder what are the general rules for handling errors in biomoby services. The API is silent about it, and the only thing I remember from the discussions is that if there is an error the service will return an empty output object (still, of course, wrapped in a biomoby XML envelope). Is this really the only way how to handle all kinds of errors? I understand that this behaviour is reasonable when my input data does not produce any result (wrong id, non-existing id, etc.). But should I use the same mechanism for things like: * the input data does not come as String or base64 type, * the input XML does not conform to the Biomoby API, * my service cannot respond because of some limited internal resources, * etc. Any advise how you deal with these situations will be appreciated, and I thank you very much. With regards, Martin PS. Of course, you noticed that in my main email body above I have not mentioned how dissapointing the Biomoby API is if it does not deal with error handling :-) M. -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 12 15:38:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Aug 12 15:30:13 2005 Subject: [MOBY-dev] lease versus agent for registry updating Message-ID: <1123875523.15335.19.camel@bioinfo.icapture.ubc.ca> Hi all! Eddie and I are spending the day working on MOBY Central architecture issues. We've run into a question that has so many pros and cons that we decided to toss it out to the list for other opinions. Keeping MOBY Central up-to-date: Method 1: Agent An agent retrieves the list of SignatureURL's from the registry, and crawls around retrieving the RDF from each of those URLs. The RDF is compared to what is in the registry, and updates/deletions are made. Consequence to service provider: a service providers machine goes down, the service is deregistered (the agent can't retrieve the URL) and the service provider must then actively re-register their services Method 2: Lease Services have a time-stamp in the registry and expire after X time. They must then be actively re-registered. Consequence to service provider: Service providers must set up a cron (or whatever) that is aware of all of their *current* Signature URL's and can call MOBY Central to re-register their services on a regular basis. Both solutions seem to put an unwanted burden on the service providers, but the burdens are different in nature and frequency. Which of these seems preferable? Are there solutions we haven't thought of? ??? Mark & Eddie -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From boris.steipe at utoronto.ca Fri Aug 12 15:50:50 2005 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Fri Aug 12 15:40:51 2005 Subject: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123875523.15335.19.camel@bioinfo.icapture.ubc.ca> Message-ID: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Why not put the burden of the lease on the agent to combine the advantages of both models? I.e. if service is down for less then a specific time, it might not get deregistered but only flagged as temporarily unavailable ... then un-flagged as it comes up again, except if it's down for, say > 1week, then it gets deregistered. $0.02 Boris On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > Hi all! > > Eddie and I are spending the day working on MOBY Central architecture > issues. We've run into a question that has so many pros and cons that > we decided to toss it out to the list for other opinions. > > Keeping MOBY Central up-to-date: > > Method 1: Agent > > An agent retrieves the list of SignatureURL's from the registry, and > crawls around retrieving the RDF from each of those URLs. The RDF is > compared to what is in the registry, and updates/deletions are made. > > Consequence to service provider: a service providers machine goes down, > the service is deregistered (the agent can't retrieve the URL) and the > service provider must then actively re-register their services > > > Method 2: Lease > > Services have a time-stamp in the registry and expire after X time. > They must then be actively re-registered. > > Consequence to service provider: Service providers must set up a cron > (or whatever) that is aware of all of their *current* Signature URL's > and can call MOBY Central to re-register their services on a regular > basis. > > > Both solutions seem to put an unwanted burden on the service providers, > but the burdens are different in nature and frequency. > > Which of these seems preferable? Are there solutions we haven't > thought > of? > > ??? > > Mark & Eddie > > > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri Aug 12 15:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Aug 12 15:46:49 2005 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Message-ID: <1123876622.15335.25.camel@bioinfo.icapture.ubc.ca> Hi Boris! Thanks for the rapid reply! That is how we had initially planned to do it as well, however the consequence is that the registry (a) has to have a mechanism for recording the number of failure occurrences, and this might be handled differently by different underlying data stores, and (b) the registry KNOWS that it contains service instances that are likely non-functional but still reports them as being functional. ... Eddie just suggested an alternative to this alternative :-) The agent can deregister services that fail the URL lookup, but still retain the URL and try them a few more times just in case they come back up again. That way the registry is always reflecting the *best* information it can possibly know, but the burden of re-registering services still falls on the Registry as much as possible. That might be the way to go... Other opinions? M On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > Why not put the burden of the lease on the agent to combine the > advantages of both models? I.e. if service is down for less then a > specific time, it might not get deregistered but only flagged as > temporarily unavailable ... then un-flagged as it comes up again, > except if it's down for, say > 1week, then it gets deregistered. > > $0.02 > > Boris > > On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > > > Hi all! > > > > Eddie and I are spending the day working on MOBY Central architecture > > issues. We've run into a question that has so many pros and cons that > > we decided to toss it out to the list for other opinions. > > > > Keeping MOBY Central up-to-date: > > > > Method 1: Agent > > > > An agent retrieves the list of SignatureURL's from the registry, and > > crawls around retrieving the RDF from each of those URLs. The RDF is > > compared to what is in the registry, and updates/deletions are made. > > > > Consequence to service provider: a service providers machine goes down, > > the service is deregistered (the agent can't retrieve the URL) and the > > service provider must then actively re-register their services > > > > > > Method 2: Lease > > > > Services have a time-stamp in the registry and expire after X time. > > They must then be actively re-registered. > > > > Consequence to service provider: Service providers must set up a cron > > (or whatever) that is aware of all of their *current* Signature URL's > > and can call MOBY Central to re-register their services on a regular > > basis. > > > > > > Both solutions seem to put an unwanted burden on the service providers, > > but the burdens are different in nature and frequency. > > > > Which of these seems preferable? Are there solutions we haven't > > thought > > of? > > > > ??? > > > > Mark & Eddie > > > > > > -- > > "Ontologists do it with the edges!" > > > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > _______________________________________________ > > 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 -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From boris.steipe at utoronto.ca Fri Aug 12 16:04:34 2005 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Fri Aug 12 15:55:20 2005 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123876622.15335.25.camel@bioinfo.icapture.ubc.ca> Message-ID: <4D6827FD-0B6C-11DA-A8DF-000A9577512E@utoronto.ca> On Friday, Aug 12, 2005, at 16:57 Canada/Atlantic, Mark Wilkinson wrote: > The > agent can deregister services that fail the URL lookup, but still > retain > the URL and try them a few more times just in case they come back up > again. That way the registry is always reflecting the *best* > information it can possibly know, but the burden of re-registering > services still falls on the Registry as much as possible. If the agent then automatically re-registers when it succeeds, that's what I just said. (I think.) (Except you went like *this* (gestures handwave to the side, sort of)). :-) B. From markw at illuminae.com Fri Aug 12 16:41:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Aug 12 16:31:37 2005 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Message-ID: <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> Ah... I missed the bit about a service being flagged as "temporarily unavailable" rather than just flagged in general. The reason we are loathe to do that is it makes assumptions about the underlying data store being able to capture that information (or at least, forces queries on the underlying data store to then be passed through a post- retrieval "available" filter implemented by the data adaptor)... We're trying to make as few assumptions about the underlying store as possible - a minimum of information about the core functionality of a service (i.e. at this point, the overlap between the MOBY and the Feta data models) M On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > Why not put the burden of the lease on the agent to combine the > advantages of both models? I.e. if service is down for less then a > specific time, it might not get deregistered but only flagged as > temporarily unavailable ... then un-flagged as it comes up again, > except if it's down for, say > 1week, then it gets deregistered. > > $0.02 > > Boris > > On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > > > Hi all! > > > > Eddie and I are spending the day working on MOBY Central architecture > > issues. We've run into a question that has so many pros and cons that > > we decided to toss it out to the list for other opinions. > > > > Keeping MOBY Central up-to-date: > > > > Method 1: Agent > > > > An agent retrieves the list of SignatureURL's from the registry, and > > crawls around retrieving the RDF from each of those URLs. The RDF is > > compared to what is in the registry, and updates/deletions are made. > > > > Consequence to service provider: a service providers machine goes down, > > the service is deregistered (the agent can't retrieve the URL) and the > > service provider must then actively re-register their services > > > > > > Method 2: Lease > > > > Services have a time-stamp in the registry and expire after X time. > > They must then be actively re-registered. > > > > Consequence to service provider: Service providers must set up a cron > > (or whatever) that is aware of all of their *current* Signature URL's > > and can call MOBY Central to re-register their services on a regular > > basis. > > > > > > Both solutions seem to put an unwanted burden on the service providers, > > but the burdens are different in nature and frequency. > > > > Which of these seems preferable? Are there solutions we haven't > > thought > > of? > > > > ??? > > > > Mark & Eddie > > > > > > -- > > "Ontologists do it with the edges!" > > > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From gordonp at ucalgary.ca Fri Aug 12 17:23:46 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri Aug 12 17:14:27 2005 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> Message-ID: <42FD1362.8000107@ucalgary.ca> I would go for the server polling the RDFs option. In that way, there could potentially be more than one MOBY Central (e.g. private ones) that could simply get the provider RDF URL list from the "Master" MOBY Central, and replicate the service registry (in whatever underlying data store they like). Decentralizing is good. >Ah... I missed the bit about a service being flagged as "temporarily >unavailable" rather than just flagged in general. The reason we are >loathe to do that is it makes assumptions about the underlying data >store being able to capture that information (or at least, forces >queries on the underlying data store to then be passed through a post- >retrieval "available" filter implemented by the data adaptor)... > >We're trying to make as few assumptions about the underlying store as >possible - a minimum of information about the core functionality of a >service (i.e. at this point, the overlap between the MOBY and the Feta >data models) > >M > > >On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > > >>Why not put the burden of the lease on the agent to combine the >>advantages of both models? I.e. if service is down for less then a >>specific time, it might not get deregistered but only flagged as >>temporarily unavailable ... then un-flagged as it comes up again, >>except if it's down for, say > 1week, then it gets deregistered. >> >>$0.02 >> >>Boris >> >>On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: >> >> >> >>>Hi all! >>> >>>Eddie and I are spending the day working on MOBY Central architecture >>>issues. We've run into a question that has so many pros and cons that >>>we decided to toss it out to the list for other opinions. >>> >>>Keeping MOBY Central up-to-date: >>> >>>Method 1: Agent >>> >>>An agent retrieves the list of SignatureURL's from the registry, and >>>crawls around retrieving the RDF from each of those URLs. The RDF is >>>compared to what is in the registry, and updates/deletions are made. >>> >>>Consequence to service provider: a service providers machine goes down, >>>the service is deregistered (the agent can't retrieve the URL) and the >>>service provider must then actively re-register their services >>> >>> >>>Method 2: Lease >>> >>>Services have a time-stamp in the registry and expire after X time. >>>They must then be actively re-registered. >>> >>>Consequence to service provider: Service providers must set up a cron >>>(or whatever) that is aware of all of their *current* Signature URL's >>>and can call MOBY Central to re-register their services on a regular >>>basis. >>> >>> >>>Both solutions seem to put an unwanted burden on the service providers, >>>but the burdens are different in nature and frequency. >>> >>>Which of these seems preferable? Are there solutions we haven't >>>thought >>>of? >>> >>>??? >>> >>>Mark & Eddie >>> >>> >>>-- >>>"Ontologists do it with the edges!" >>> >>>Mark Wilkinson >>>Asst. Professor >>>Dept. of Medical Genetics >>>University of British Columbia >>>PI in Bioinformatics >>>iCAPTURE Centre >>>St. Paul's Hospital >>>Rm. 166, 1081 Burrard St. >>>Vancouver, BC, V6Z 1Y6 >>>tel: 604 682 2344 x62129 >>>fax: 604 806 9274 >>> >>>_______________________________________________ >>>MOBY-dev mailing list >>>MOBY-dev@biomoby.org >>>http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> From markw at illuminae.com Fri Aug 12 18:18:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Aug 12 18:08:21 2005 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <42FD1362.8000107@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> Message-ID: <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> We're certainly of like-mind at this end, though certain people ;-) at myGrid think that the agent is the wrong way to go... I just don't see it. IMO a leasing model would be akin to leasing space in Google! Anyway, we'll leave the question open for a couple of days and see if any more optimal solutions come up. M On Fri, 2005-08-12 at 15:23 -0600, Paul Gordon wrote: > I would go for the server polling the RDFs option. In that way, there > could potentially be more than one MOBY Central (e.g. private ones) that > could simply get the provider RDF URL list from the "Master" MOBY > Central, and replicate the service registry (in whatever underlying data > store they like). Decentralizing is good. > > > >Ah... I missed the bit about a service being flagged as "temporarily > >unavailable" rather than just flagged in general. The reason we are > >loathe to do that is it makes assumptions about the underlying data > >store being able to capture that information (or at least, forces > >queries on the underlying data store to then be passed through a post- > >retrieval "available" filter implemented by the data adaptor)... > > > >We're trying to make as few assumptions about the underlying store as > >possible - a minimum of information about the core functionality of a > >service (i.e. at this point, the overlap between the MOBY and the Feta > >data models) > > > >M > > > > > >On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > > > > > >>Why not put the burden of the lease on the agent to combine the > >>advantages of both models? I.e. if service is down for less then a > >>specific time, it might not get deregistered but only flagged as > >>temporarily unavailable ... then un-flagged as it comes up again, > >>except if it's down for, say > 1week, then it gets deregistered. > >> > >>$0.02 > >> > >>Boris > >> > >>On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > >> > >> > >> > >>>Hi all! > >>> > >>>Eddie and I are spending the day working on MOBY Central architecture > >>>issues. We've run into a question that has so many pros and cons that > >>>we decided to toss it out to the list for other opinions. > >>> > >>>Keeping MOBY Central up-to-date: > >>> > >>>Method 1: Agent > >>> > >>>An agent retrieves the list of SignatureURL's from the registry, and > >>>crawls around retrieving the RDF from each of those URLs. The RDF is > >>>compared to what is in the registry, and updates/deletions are made. > >>> > >>>Consequence to service provider: a service providers machine goes down, > >>>the service is deregistered (the agent can't retrieve the URL) and the > >>>service provider must then actively re-register their services > >>> > >>> > >>>Method 2: Lease > >>> > >>>Services have a time-stamp in the registry and expire after X time. > >>>They must then be actively re-registered. > >>> > >>>Consequence to service provider: Service providers must set up a cron > >>>(or whatever) that is aware of all of their *current* Signature URL's > >>>and can call MOBY Central to re-register their services on a regular > >>>basis. > >>> > >>> > >>>Both solutions seem to put an unwanted burden on the service providers, > >>>but the burdens are different in nature and frequency. > >>> > >>>Which of these seems preferable? Are there solutions we haven't > >>>thought > >>>of? > >>> > >>>??? > >>> > >>>Mark & Eddie > >>> > >>> > >>>-- > >>>"Ontologists do it with the edges!" > >>> > >>>Mark Wilkinson > >>>Asst. Professor > >>>Dept. of Medical Genetics > >>>University of British Columbia > >>>PI in Bioinformatics > >>>iCAPTURE Centre > >>>St. Paul's Hospital > >>>Rm. 166, 1081 Burrard St. > >>>Vancouver, BC, V6Z 1Y6 > >>>tel: 604 682 2344 x62129 > >>>fax: 604 806 9274 > >>> > >>>_______________________________________________ > >>>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 -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From ots at ac.uma.es Thu Aug 11 06:05:23 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Mon Aug 15 10:52:12 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: Message-ID: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Dear all, We sent a message (July 25) regarding error handling. I am not sure weather the message is in your hands, thus I am re-sending it for discussion. best regards Oswaldo -------------- ----- Original Message ----- From: "Oswaldo Trelles" To: "Eddie Kawas" Sent: Monday, July 25, 2005 6:43 PM Subject: Error handling proposal > Eddie, could you please circulate this message and made the document > available following your protocol? > thanks in advance > Oswaldo > > Please let me introduce myself. My name is Oswaldo Trelles and I work at the > Computer architecture Department of the University of Malaga, Spain (where > all of you are invited and welcomed). Our group is in charge of the > "Integrated Bioinformatics" aspects at the INB (National Institute of > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > meeting we are developing an integrated platform to deploy general and > specific services using BioMOBY as the underlying protocol. > > Thus we are quite concerned with BM specifications and we would like to > contribute in the development, extension and improvements in the protocol. > At this moment Roman has made a preliminary version and description of > Theseu project available. Now we would like to put over the table the error > handling issue. We have prepared a document, which represent an extension of > our current implementation. This proposal was discussed during the > INB-meeting here in Malaga (July 2005) and now is distributed as an open > document for further discussion. > > Please feel free to comment. > > best regards, Oswaldo + GNV5 team + INB team ----- Original Message ----- From: "Martin Senger" To: "Moby Developers" Sent: Thursday, August 11, 2005 3:10 AM Subject: [MOBY-dev] how to handle errors in a biomoby service? > This question is meant primarily for Java-based biomoby services, but a > suggestion from Perl people can help me as well. > > I wonder what are the general rules for handling errors in biomoby > services. The API is silent about it, and the only thing I remember from > the discussions is that if there is an error the service will return an > empty output object (still, of course, wrapped in a biomoby XML > envelope). Is this really the only way how to handle all kinds of > errors? > > I understand that this behaviour is reasonable when my input data does not > produce any result (wrong id, non-existing id, etc.). But should I use the > same mechanism for things like: > * the input data does not come as String or base64 type, > * the input XML does not conform to the Biomoby API, > * my service cannot respond because of some limited internal resources, > * etc. > > Any advise how you deal with these situations will be appreciated, and I > thank you very much. > > With regards, > Martin > > PS. Of course, you noticed that in my main email body above I have not > mentioned how dissapointing the Biomoby API is if it does not deal with > error handling :-) > > M. > > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: 0509GNV5-ErrorHandling-v034distributed.pdf Type: application/pdf Size: 338293 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050811/ec6846b9/0509GNV5-ErrorHandling-v034distributed-0002.pdf From ots at ac.uma.es Thu Aug 11 06:05:23 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Mon Aug 15 10:52:16 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: Message-ID: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Dear all, We sent a message (July 25) regarding error handling. I am not sure weather the message is in your hands, thus I am re-sending it for discussion. best regards Oswaldo -------------- ----- Original Message ----- From: "Oswaldo Trelles" To: "Eddie Kawas" Sent: Monday, July 25, 2005 6:43 PM Subject: Error handling proposal > Eddie, could you please circulate this message and made the document > available following your protocol? > thanks in advance > Oswaldo > > Please let me introduce myself. My name is Oswaldo Trelles and I work at the > Computer architecture Department of the University of Malaga, Spain (where > all of you are invited and welcomed). Our group is in charge of the > "Integrated Bioinformatics" aspects at the INB (National Institute of > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > meeting we are developing an integrated platform to deploy general and > specific services using BioMOBY as the underlying protocol. > > Thus we are quite concerned with BM specifications and we would like to > contribute in the development, extension and improvements in the protocol. > At this moment Roman has made a preliminary version and description of > Theseu project available. Now we would like to put over the table the error > handling issue. We have prepared a document, which represent an extension of > our current implementation. This proposal was discussed during the > INB-meeting here in Malaga (July 2005) and now is distributed as an open > document for further discussion. > > Please feel free to comment. > > best regards, Oswaldo + GNV5 team + INB team ----- Original Message ----- From: "Martin Senger" To: "Moby Developers" Sent: Thursday, August 11, 2005 3:10 AM Subject: [MOBY-dev] how to handle errors in a biomoby service? > This question is meant primarily for Java-based biomoby services, but a > suggestion from Perl people can help me as well. > > I wonder what are the general rules for handling errors in biomoby > services. The API is silent about it, and the only thing I remember from > the discussions is that if there is an error the service will return an > empty output object (still, of course, wrapped in a biomoby XML > envelope). Is this really the only way how to handle all kinds of > errors? > > I understand that this behaviour is reasonable when my input data does not > produce any result (wrong id, non-existing id, etc.). But should I use the > same mechanism for things like: > * the input data does not come as String or base64 type, > * the input XML does not conform to the Biomoby API, > * my service cannot respond because of some limited internal resources, > * etc. > > Any advise how you deal with these situations will be appreciated, and I > thank you very much. > > With regards, > Martin > > PS. Of course, you noticed that in my main email body above I have not > mentioned how dissapointing the Biomoby API is if it does not deal with > error handling :-) > > M. > > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: 0509GNV5-ErrorHandling-v034distributed.pdf Type: application/pdf Size: 338293 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050811/ec6846b9/0509GNV5-ErrorHandling-v034distributed-0003.pdf From edward.kawas at gmail.com Mon Aug 15 21:26:04 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Mon Aug 15 21:18:21 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Hi Oswaldo, Do you think that you could repost it to the list? Thanks, Eddie On 8/11/05, Oswaldo Trelles wrote: > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger@gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > From edward.kawas at gmail.com Mon Aug 15 21:26:04 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Mon Aug 15 21:18:29 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Hi Oswaldo, Do you think that you could repost it to the list? Thanks, Eddie On 8/11/05, Oswaldo Trelles wrote: > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger@gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > 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 ots at ac.uma.es Tue Aug 16 05:27:02 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue Aug 16 05:19:24 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: <000d01c5a244$aa5b8e90$346dd696@ac.uma.es> ----- Original Message ----- From: "Oswaldo Trelles" To: "Core developer announcements" ; "Moby Developers" Sent: Thursday, August 11, 2005 12:05 PM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger@gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Tue Aug 16 05:27:02 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue Aug 16 05:19:42 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: <000d01c5a244$aa5b8e90$346dd696@ac.uma.es> ----- Original Message ----- From: "Oswaldo Trelles" To: "Core developer announcements" ; "Moby Developers" Sent: Thursday, August 11, 2005 12:05 PM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger@gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Tue Aug 16 05:32:40 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue Aug 16 05:22:33 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <007d01c5a245$726a2810$346dd696@ac.uma.es> Hi Eddie, OK I have posted again the message regards, O. ----- Original Message ----- From: "Eddie Kawas" To: "Core developer announcements" Cc: "Moby Developers" Sent: Tuesday, August 16, 2005 3:26 AM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Hi Oswaldo, > > Do you think that you could repost it to the list? > > Thanks, > > Eddie > > On 8/11/05, Oswaldo Trelles wrote: > > Dear all, > > > > We sent a message (July 25) regarding error handling. I am not sure weather > > the message is in your hands, thus I am re-sending it for discussion. > > > > best regards > > > > Oswaldo > > > > > > > > > > > > -------------- > > > > > > ----- Original Message ----- > > From: "Oswaldo Trelles" > > To: "Eddie Kawas" > > Sent: Monday, July 25, 2005 6:43 PM > > Subject: Error handling proposal > > > > > > > Eddie, could you please circulate this message and made the document > > > available following your protocol? > > > thanks in advance > > > Oswaldo > > > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > > the > > > Computer architecture Department of the University of Malaga, Spain (where > > > all of you are invited and welcomed). Our group is in charge of the > > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > > meeting we are developing an integrated platform to deploy general and > > > specific services using BioMOBY as the underlying protocol. > > > > > > Thus we are quite concerned with BM specifications and we would like to > > > contribute in the development, extension and improvements in the protocol. > > > At this moment Roman has made a preliminary version and description of > > > Theseu project available. Now we would like to put over the table the > > error > > > handling issue. We have prepared a document, which represent an extension > > of > > > our current implementation. This proposal was discussed during the > > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > > document for further discussion. > > > > > > Please feel free to comment. > > > > > > best regards, Oswaldo + GNV5 team + INB team > > > > > > ----- Original Message ----- > > From: "Martin Senger" > > To: "Moby Developers" > > Sent: Thursday, August 11, 2005 3:10 AM > > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > > > > This question is meant primarily for Java-based biomoby services, but a > > > suggestion from Perl people can help me as well. > > > > > > I wonder what are the general rules for handling errors in biomoby > > > services. The API is silent about it, and the only thing I remember from > > > the discussions is that if there is an error the service will return an > > > empty output object (still, of course, wrapped in a biomoby XML > > > envelope). Is this really the only way how to handle all kinds of > > > errors? > > > > > > I understand that this behaviour is reasonable when my input data does not > > > produce any result (wrong id, non-existing id, etc.). But should I use the > > > same mechanism for things like: > > > * the input data does not come as String or base64 type, > > > * the input XML does not conform to the Biomoby API, > > > * my service cannot respond because of some limited internal resources, > > > * etc. > > > > > > Any advise how you deal with these situations will be appreciated, and I > > > thank you very much. > > > > > > With regards, > > > Martin > > > > > > PS. Of course, you noticed that in my main email body above I have not > > > mentioned how dissapointing the Biomoby API is if it does not deal with > > > error handling :-) > > > > > > M. > > > > > > > > > -- > > > Martin Senger > > > email: martin.senger@gmail.com > > > skype: martinsenger > > > International Rice Research Institute > > > Biometrics and Bioinformatics Unit > > > DAPO BOX 7777, Metro Manila > > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev@biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Aug 16 09:19:32 2005 From: d.haase at gsf.de (Dirk Haase) Date: Tue Aug 16 09:31:06 2005 Subject: [MOBY-dev] Taverna: moby_collection widget Message-ID: <200508161519.32949.d.haase@gsf.de> Hi! I just tried out the Create_a_moby_collection widget in the new Taverna (after CVS build, the package is still the buggy one I think...) but didn't have much fun with it. As soon as I use it in the workflow, the service invocation fails, a ClassCastException is reported. Failure is even before an http request is sent out. Can anybody confirm that the widget is working? One thing I noticed is that the widget output is typed only as text/plain not as text/xml like for example Create_moby_data does it. But I have no idea if this is relevant... I'll be thankful for any hints. Regards, dirk -- ---------------------------------------------------------- Dirk Haase phone +49 89 3187 3583 http://mips.gsf.de/~haase email d.haase@gsf.de From edward.kawas at gmail.com Tue Aug 16 12:16:40 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue Aug 16 12:07:37 2005 Subject: [MOBY-dev] Taverna: moby_collection widget In-Reply-To: <200508161519.32949.d.haase@gsf.de> References: <200508161519.32949.d.haase@gsf.de> Message-ID: Hi, The widget should work. I dont have a computer that could try it out (using dial-up) but as i recall, what one has to do is add the widget 'create_moby_collection' to a work flow and then add the various datatypes (DNASequence, Integer, etc) to the input ports and a properly formed collection should result and can be passed to the appropriate moby service. Out of curiousity, what was the class that caused the exception? Do you think that you could send me the error output? I am not sure how much help i can be for the next 2 weeks (no steady net connection) but i'll try! If you want to see how to use the collection, you could try the following workflow: http://bioinfo.icapture.ubc.ca/ekawas/workflow.xml with the following input: http://bioinfo.icapture.ubc.ca/ekawas/workflowInput.xml That workflow is known to work (actually, you will need to do a find/replace on the following string: find-> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl replace-> http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl and then it will work. Sorry about that!). Eddie On 8/16/05, Dirk Haase wrote: > Hi! > > I just tried out the Create_a_moby_collection widget in the new Taverna (after > CVS build, the package is still the buggy one I think...) but didn't have > much fun with it. As soon as I use it in the workflow, the service invocation > fails, a ClassCastException is reported. Failure is even before an http > request is sent out. > > Can anybody confirm that the widget is working? One thing I noticed is that > the widget output is typed only as text/plain not as text/xml like for > example Create_moby_data does it. But I have no idea if this is relevant... > > I'll be thankful for any hints. > > Regards, > dirk > > -- > > ---------------------------------------------------------- > Dirk Haase phone +49 89 3187 3583 > http://mips.gsf.de/~haase email d.haase@gsf.de > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Tue Aug 16 12:21:23 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Aug 16 12:11:33 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Hi all, Thanks for writing this up so clearly! I agree 100% that the current error-reporting system in BioMOBY is insufficient (it was never part of the initial proposal, and even that initial proposal was cut by 80%, so...) I am a bit wary of two aspects of the solution you propose, though I need more time to think about exactly why they make me nervous: 1) Mixing metadata (errors) into the data seems... well... wrong somehow. I would prefer a solution that somehow used the serviceNotes block as the place to put error messages, and added an attribute to teh mobyData, Collection, or Simple tags that Xref'ed a node in the serviceNotes block. I wasn't in Malaga for the discussion, so perhaps there is a strong argument for putting it there that I am unaware of? 2) overloading the articleName attribute in the Simple/Collection tag (and especially in the case where Simples are part of a Collection) would then give **three** different "meanings" to the articleName attribute!! It's bad enough that we already have two different uses for that attribute... I'm reluctant to add one more to the fray! :-) Let's create a new attribute instead of adding a new meaning to an existing one. I hope others will participate in this discussion - it's been pretty quiet out there! I have not thought deeply about error reporting, and I would prefer to leave the final decision to people who *have* thought deeply about it. I am perfectly happy to simply sign-off on whatever the expert group decides - I really do not want to be the arbiter of the final decision in this matter because I just don't have the full scope of the problem in my head! I am happy, however, to participate in the overall debate leading up to that decision. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Tue Aug 16 12:21:23 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Aug 16 12:11:38 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Hi all, Thanks for writing this up so clearly! I agree 100% that the current error-reporting system in BioMOBY is insufficient (it was never part of the initial proposal, and even that initial proposal was cut by 80%, so...) I am a bit wary of two aspects of the solution you propose, though I need more time to think about exactly why they make me nervous: 1) Mixing metadata (errors) into the data seems... well... wrong somehow. I would prefer a solution that somehow used the serviceNotes block as the place to put error messages, and added an attribute to teh mobyData, Collection, or Simple tags that Xref'ed a node in the serviceNotes block. I wasn't in Malaga for the discussion, so perhaps there is a strong argument for putting it there that I am unaware of? 2) overloading the articleName attribute in the Simple/Collection tag (and especially in the case where Simples are part of a Collection) would then give **three** different "meanings" to the articleName attribute!! It's bad enough that we already have two different uses for that attribute... I'm reluctant to add one more to the fray! :-) Let's create a new attribute instead of adding a new meaning to an existing one. I hope others will participate in this discussion - it's been pretty quiet out there! I have not thought deeply about error reporting, and I would prefer to leave the final decision to people who *have* thought deeply about it. I am perfectly happy to simply sign-off on whatever the expert group decides - I really do not want to be the arbiter of the final decision in this matter because I just don't have the full scope of the problem in my head! I am happy, however, to participate in the overall debate leading up to that decision. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From dgpisano at cnb.uam.es Wed Aug 17 07:12:16 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Wed Aug 17 07:12:47 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43031B90.4020802@cnb.uam.es> Hello, Mark Wilkinson escribi?: >Hi all, > >Thanks for writing this up so clearly! I agree 100% that the current >error-reporting system in BioMOBY is insufficient (it was never part of >the initial proposal, and even that initial proposal was cut by 80%, >so...) > >I am a bit wary of two aspects of the solution you propose, though I >need more time to think about exactly why they make me nervous: > >1) Mixing metadata (errors) into the data seems... well... wrong >somehow. I would prefer a solution that somehow used the serviceNotes >block as the place to put error messages, and added an attribute to teh >mobyData, Collection, or Simple tags that Xref'ed a node in the >serviceNotes block. I wasn't in Malaga for the discussion, so perhaps >there is a strong argument for putting it there that I am unaware of? > > > There were 2 proposals in the document and yes, the second one had the errors mixed with the data. We will write it again to clearly separate the moby data from the error information (like in the first proposal, that uses serviceNotes) and crossref them someway (see below) >2) overloading the articleName attribute in the Simple/Collection tag >(and especially in the case where Simples are part of a Collection) >would then give **three** different "meanings" to the articleName >attribute!! It's bad enough that we already have two different uses for >that attribute... I'm reluctant to add one more to the fray! :-) Let's >create a new attribute instead of adding a new meaning to an existing >one. > > > We understand that the articleName attribute in Simple / Collection tags is the "anchor point" we have to use to refer to that Simple / Collection. Referring to Simples / Collections / Simples into collection using articleNames give us more granularity than referring to mobyDatas using queryIDs. There is no need to create another additional "identifying" attribute if we can identify the entity we are reporting an error for. Probably we have to rewrite that part to clarify several points: - The error tag has to use an attribute to refer to the corresponding failing simple / collection. We can call this attribute exceptionRef, articleNameRef or something similar, to avoid using articleName again in a different context, but - We are referring to the erroneus entity using its articleName, and that's why the articleName has to be mandatory (note that this is a significant change in the bioMOBY specification, but we can't figure out any other way to report errors at this level) David >I hope others will participate in this discussion - it's been pretty >quiet out there! I have not thought deeply about error reporting, and I >would prefer to leave the final decision to people who *have* thought >deeply about it. I am perfectly happy to simply sign-off on whatever >the expert group decides - I really do not want to be the arbiter of the >final decision in this matter because I just don't have the full scope >of the problem in my head! I am happy, however, to participate in the >overall debate leading up to that decision. > >M > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050817/91cab6be/dgpisano.vcf From dgpisano at cnb.uam.es Wed Aug 17 07:12:16 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Wed Aug 17 07:13:21 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43031B90.4020802@cnb.uam.es> Hello, Mark Wilkinson escribi?: >Hi all, > >Thanks for writing this up so clearly! I agree 100% that the current >error-reporting system in BioMOBY is insufficient (it was never part of >the initial proposal, and even that initial proposal was cut by 80%, >so...) > >I am a bit wary of two aspects of the solution you propose, though I >need more time to think about exactly why they make me nervous: > >1) Mixing metadata (errors) into the data seems... well... wrong >somehow. I would prefer a solution that somehow used the serviceNotes >block as the place to put error messages, and added an attribute to teh >mobyData, Collection, or Simple tags that Xref'ed a node in the >serviceNotes block. I wasn't in Malaga for the discussion, so perhaps >there is a strong argument for putting it there that I am unaware of? > > > There were 2 proposals in the document and yes, the second one had the errors mixed with the data. We will write it again to clearly separate the moby data from the error information (like in the first proposal, that uses serviceNotes) and crossref them someway (see below) >2) overloading the articleName attribute in the Simple/Collection tag >(and especially in the case where Simples are part of a Collection) >would then give **three** different "meanings" to the articleName >attribute!! It's bad enough that we already have two different uses for >that attribute... I'm reluctant to add one more to the fray! :-) Let's >create a new attribute instead of adding a new meaning to an existing >one. > > > We understand that the articleName attribute in Simple / Collection tags is the "anchor point" we have to use to refer to that Simple / Collection. Referring to Simples / Collections / Simples into collection using articleNames give us more granularity than referring to mobyDatas using queryIDs. There is no need to create another additional "identifying" attribute if we can identify the entity we are reporting an error for. Probably we have to rewrite that part to clarify several points: - The error tag has to use an attribute to refer to the corresponding failing simple / collection. We can call this attribute exceptionRef, articleNameRef or something similar, to avoid using articleName again in a different context, but - We are referring to the erroneus entity using its articleName, and that's why the articleName has to be mandatory (note that this is a significant change in the bioMOBY specification, but we can't figure out any other way to report errors at this level) David >I hope others will participate in this discussion - it's been pretty >quiet out there! I have not thought deeply about error reporting, and I >would prefer to leave the final decision to people who *have* thought >deeply about it. I am perfectly happy to simply sign-off on whatever >the expert group decides - I really do not want to be the arbiter of the >final decision in this matter because I just don't have the full scope >of the problem in my head! I am happy, however, to participate in the >overall debate leading up to that decision. > >M > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050817/91cab6be/dgpisano-0001.vcf From markw at illuminae.com Wed Aug 17 12:17:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 17 12:36:08 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <43031B90.4020802@cnb.uam.es> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> <43031B90.4020802@cnb.uam.es> Message-ID: <1124295477.21293.18.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-17 at 13:12 +0200, David Gonz?lez Pisano wrote: > We understand that the articleName attribute in Simple / Collection tags > is the "anchor point" we have to use to refer to that Simple / > Collection. Referring to Simples / Collections / Simples into collection > using articleNames give us more granularity than referring to mobyDatas > using queryIDs. There is no need to create another additional > "identifying" attribute if we can identify the entity we are reporting > an error for. This is the only problematic part of the solution, since it requires a potentially troublesome change to the API. For this solution, you require all of the Simples in a Collection to have a unique articleName tag. At present, they likely have no tag at all (since this is not mandated by the API), and at best will all have the *same* tag even if we mandate that all output parameters must have an article name. If we make the value of this tag auto-generated (like an auto-increment field in a database), then it adds a new meaning to articleName, so let's just not pursue this possibility any further :-) Whatever solution we come up with, it cannot use articleName as its primary means of identifying the failed entity. > - The error tag has to use an attribute to refer to the corresponding > failing simple / collection. We can call this attribute exceptionRef, > articleNameRef or something similar, to avoid using articleName again in > a different context, but Super! > - We are referring to the erroneus entity using its articleName, and > that's why the articleName has to be mandatory (note that this is a > significant change in the bioMOBY specification, but we can't figure out > any other way to report errors at this level) I'm not sure why we need two ways of referring to the same entity? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Aug 18 17:27:16 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Aug 18 17:17:53 2005 Subject: [MOBY-dev] CORE DEVELOPERS please create a bugzilla account... Message-ID: <1124400436.25003.2.camel@bioinfo.icapture.ubc.ca> Hi all core developers, We had our first Bugzilla bug report today, but nobody has signed-up to be a debugger :-) Can I request that all core developers (anyone who has committed significant code to the repository, or anyone who wants to be a MOBY debugger) please sign-up so that bugs can be assigned to you with email notification. It would be a good idea if we started using this bug tracking system rather than relying on the mailing list. http://bugzilla.open-bio.org/createaccount.cgi Thanks! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 03:43:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 24 03:33:35 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Dear all, I am late with handling this email but it does not mean that I under-estimate the importance of th topic. It's actually crucial for claiming that we have a robust and interoperable technology. But we need it fast. I mean A decision should be made soon. i completely agree with Oswaldo that waiting for such important topic for several years now is a bit unfortunate. So let's face the problem... I read Oswaldo's proposal and I had opportunity to discuss it personaly. But actually I do not have a strong opinion HOW to handle errors if we handle them SOON. One missing piece (IMHO) there is not using the standard way for error handling in web services. I suspect that i know why it is not there - because there is not clear solution that would guarantee to work everywhere (now I am quoting the documenattion for the latest Apache Axis). However, I have tried it, and it works fine between perl and java (from both sides). So I think it is worth to use it. So now is my summary (and perhaps suggestion): 1) Critical errors. A service should raise an exception. So this level does not return any Moby specific data - everything is handled on SOAP level (sending back faultCode, faultString and such usuaal tags). In Java it is easy, in Perl as well (use SOAP::Fault). This does not bring any additional complexity to the client code - unless a client is badly written. What I want to say is that a good client even now should be prepared for transport exception (when a service is down completely, for example). So catching also a SOAP error produced by a service is trivial addition. To improve interoperability here, we should discuss the error strings etc. But there were suggestion in Osvaldo's proposal we can follow. The critical is a decision that we allow services to raise an exception in a critical situation. 2) "Your data are wrong" is the next level of errors. For this, both Oswaldo's sollution would work. As I said, I can go both ways IF we define what is an empty response. Does it mean an empty tag mobyData or an empty Object, or Simple... If we come to the end, what does an empty Integer mean? Does it mean always an error? Because an empry String can be a valid answer but empty Integer probably not. So the problems here are not that much where to put error strings (service notes or inside simples) but what "empty" means. 3) And we can talk about the third level - if we distinguish that sometimes simply your data are wrong and I cannot return you anything (above), or your data are partially wrong and I can retunr you at least something. but again, Oswaldo explained it already. So what should I put into my services? Please, Mark, tell us... Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 03:43:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 24 03:33:36 2005 Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Dear all, I am late with handling this email but it does not mean that I under-estimate the importance of th topic. It's actually crucial for claiming that we have a robust and interoperable technology. But we need it fast. I mean A decision should be made soon. i completely agree with Oswaldo that waiting for such important topic for several years now is a bit unfortunate. So let's face the problem... I read Oswaldo's proposal and I had opportunity to discuss it personaly. But actually I do not have a strong opinion HOW to handle errors if we handle them SOON. One missing piece (IMHO) there is not using the standard way for error handling in web services. I suspect that i know why it is not there - because there is not clear solution that would guarantee to work everywhere (now I am quoting the documenattion for the latest Apache Axis). However, I have tried it, and it works fine between perl and java (from both sides). So I think it is worth to use it. So now is my summary (and perhaps suggestion): 1) Critical errors. A service should raise an exception. So this level does not return any Moby specific data - everything is handled on SOAP level (sending back faultCode, faultString and such usuaal tags). In Java it is easy, in Perl as well (use SOAP::Fault). This does not bring any additional complexity to the client code - unless a client is badly written. What I want to say is that a good client even now should be prepared for transport exception (when a service is down completely, for example). So catching also a SOAP error produced by a service is trivial addition. To improve interoperability here, we should discuss the error strings etc. But there were suggestion in Osvaldo's proposal we can follow. The critical is a decision that we allow services to raise an exception in a critical situation. 2) "Your data are wrong" is the next level of errors. For this, both Oswaldo's sollution would work. As I said, I can go both ways IF we define what is an empty response. Does it mean an empty tag mobyData or an empty Object, or Simple... If we come to the end, what does an empty Integer mean? Does it mean always an error? Because an empry String can be a valid answer but empty Integer probably not. So the problems here are not that much where to put error strings (service notes or inside simples) but what "empty" means. 3) And we can talk about the third level - if we distinguish that sometimes simply your data are wrong and I cannot return you anything (above), or your data are partially wrong and I can retunr you at least something. but again, Oswaldo explained it already. So what should I put into my services? Please, Mark, tell us... Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 11:26:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 24 11:15:46 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> > So what should I put into my services? Please, Mark, tell us... If you read my earlier comments I have already refused to make these decisions - the are better left to people who have thought extensively about them. Once you have come to an agreement, YOU tell ME what to do, and I (or the new curator, Frank) will add it to the API. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 11:26:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 24 11:15:48 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> > So what should I put into my services? Please, Mark, tell us... If you read my earlier comments I have already refused to make these decisions - the are better left to people who have thought extensively about them. Once you have come to an agreement, YOU tell ME what to do, and I (or the new curator, Frank) will add it to the API. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 11:44:33 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 24 11:34:13 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> Message-ID: > If you read my earlier comments > I always read your comments... > I have already refused to make these decisions - the are better left > to people who have thought extensively about them. > That's nonsense. Sorry, Mark, but you put us into this mess because you had no time, mood or funding to make the error handling properly in the first place. Also, the current API - that does not define fully what "an empty result" means - is surely something you could /should think about it, and not let it completely on decision on other people. I am happy to discuss it, but at the end it will surely require changes in your code (perhaps not so much in registry, but surely in the library for service providers). So without your commitment to this topic it seems a bit of waste of time... The problem is not that you *have* to participate on every decision - but the problem is that we do not have (still) a procedure how to make changes in the API. Just "I or Frank will add it to the API" is not a proper process. And this process, in order to be successful, must be discussed with you as a PI and project manager. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 11:44:33 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 24 11:34:15 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> Message-ID: > If you read my earlier comments > I always read your comments... > I have already refused to make these decisions - the are better left > to people who have thought extensively about them. > That's nonsense. Sorry, Mark, but you put us into this mess because you had no time, mood or funding to make the error handling properly in the first place. Also, the current API - that does not define fully what "an empty result" means - is surely something you could /should think about it, and not let it completely on decision on other people. I am happy to discuss it, but at the end it will surely require changes in your code (perhaps not so much in registry, but surely in the library for service providers). So without your commitment to this topic it seems a bit of waste of time... The problem is not that you *have* to participate on every decision - but the problem is that we do not have (still) a procedure how to make changes in the API. Just "I or Frank will add it to the API" is not a proper process. And this process, in order to be successful, must be discussed with you as a PI and project manager. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 11:47:03 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 24 11:36:27 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 16:44 +0100, Martin Senger wrote: > is surely something you could /should think about > it, and not let it completely on decision on other people. I have offered to participate in the discussion, and am doing so. > I am happy to discuss it, but at the end it will surely require changes > in your code (perhaps not so much in registry, but surely in the library > for service providers). So without your commitment to this topic it seems > a bit of waste of time... And will make the necessary changes in the code once a decision has been reached. > The problem is not that you *have* to participate on every decision - > but the problem is that we do not have (still) a procedure how to make > changes in the API. Correct. > discussed with you as a PI and project manager. It is as we speak. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 11:47:03 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 24 11:36:28 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 16:44 +0100, Martin Senger wrote: > is surely something you could /should think about > it, and not let it completely on decision on other people. I have offered to participate in the discussion, and am doing so. > I am happy to discuss it, but at the end it will surely require changes > in your code (perhaps not so much in registry, but surely in the library > for service providers). So without your commitment to this topic it seems > a bit of waste of time... And will make the necessary changes in the code once a decision has been reached. > The problem is not that you *have* to participate on every decision - > but the problem is that we do not have (still) a procedure how to make > changes in the API. Correct. > discussed with you as a PI and project manager. It is as we speak. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 12:07:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 24 11:56:37 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > > but the problem is that we do not have (still) a procedure how to make > > changes in the API. > > Correct. > So how are we going to solve this? This is *a* solution (based on my experiences from the OMG process): 1) Anybody can make a suggestion to make a change in API (we can call it RFP - request for proposal, or RFC - request for comments, or whatever). An example of such thing are the proposals from Oswaldo and his collegues (eventhough I would not expect to have it always so perfectly written :-)). Important is that it must *say* this is a RFP/RFC, not just a wish in email. We will keep a place for it (bugzilla has wishlists?). 2) Then a calendar (deadline) must be attached to it. It can be suggested already by the author of the RFP/RFC, or a default value is attached. We need to say what is a default value. 3) The RFP can be considered only if the change is back-uped by two (three?) other developers. They do not need to fully agree with all details, their role is just to prevent overhelming number of small changes coming fast. 4) It is also considered only if somebody has resources to really implement the change. This should be also a part of the clendar ("when it can be done"). 5) Discussion on RFC, changes re-distributed, etc. In charge is the author of the original RFC. Deadline can be extended - don't be too formal here. 6) Now the tricky part: I think taht there should be only few people (major developers) who can vote on it. This is called an "Architecture Board" at OMG and guarantees that the changes are hopefully not breaking other things. 7) Then comes implementation, documenttaion etc. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 12:07:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 24 11:56:41 2005 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > > but the problem is that we do not have (still) a procedure how to make > > changes in the API. > > Correct. > So how are we going to solve this? This is *a* solution (based on my experiences from the OMG process): 1) Anybody can make a suggestion to make a change in API (we can call it RFP - request for proposal, or RFC - request for comments, or whatever). An example of such thing are the proposals from Oswaldo and his collegues (eventhough I would not expect to have it always so perfectly written :-)). Important is that it must *say* this is a RFP/RFC, not just a wish in email. We will keep a place for it (bugzilla has wishlists?). 2) Then a calendar (deadline) must be attached to it. It can be suggested already by the author of the RFP/RFC, or a default value is attached. We need to say what is a default value. 3) The RFP can be considered only if the change is back-uped by two (three?) other developers. They do not need to fully agree with all details, their role is just to prevent overhelming number of small changes coming fast. 4) It is also considered only if somebody has resources to really implement the change. This should be also a part of the clendar ("when it can be done"). 5) Discussion on RFC, changes re-distributed, etc. In charge is the author of the original RFC. Deadline can be extended - don't be too formal here. 6) Now the tricky part: I think taht there should be only few people (major developers) who can vote on it. This is called an "Architecture Board" at OMG and guarantees that the changes are hopefully not breaking other things. 7) Then comes implementation, documenttaion etc. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 12:24:10 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 24 12:14:02 2005 Subject: [personal] Re: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 17:07 +0100, Martin Senger wrote: > An example of such thing are the proposals from Oswaldo and his > collegues (eventhough I would not expect to have it always so perfectly > written :-)). Indeed! It was more of a work of art than an RFC :-) They have really set the bar for the rest of us... > Important is that it must *say* this is a RFP/RFC, not just > a wish in email. We will keep a place for it (bugzilla has wishlists?). Unfortunately not :-( I'm looking for something to use as an alternative, but coming up empty. I wonder if Simon's Wordpress could do something in this regard? TWiki has templates, and I suspect Wordpress has something similar... > 6) Now the tricky part: I think taht there should be only few people > (major developers) who can vote on it. This is called an "Architecture > Board" at OMG and guarantees that the changes are hopefully not breaking > other things. I think we know who those people are, for the most part, but I think it would be good to open up the floor for volunteers with the caveat that there *will be an expectation* of a ~significant time commitment from those who volunteer, and with a one-year tenure (so that people don't join just to get their favorite feature through the process and then disappear again). This should sufficiently self-regulate the membership that it wont get unwieldy, and selects those who are both committed, and knowledgeable. > 7) Then comes implementation, documenttaion etc. Is that the fun part? ;-) M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 12:29:55 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 24 12:19:26 2005 Subject: [personal] Re: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> References: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <1124900995.8181.57.camel@bioinfo.icapture.ubc.ca> This would also give us a clear basis for splitting-up the semi-annual developers meeting into the "core" developers and the "adherents". This is something I had hoped to do in the coming year anyway (assuming that we get funded at all... which is what I am currently working on! Fingers crossed!) M > > 6) Now the tricky part: I think taht there should be only few people > > (major developers) who can vote on it. This is called an "Architecture > > Board" at OMG and guarantees that the changes are hopefully not breaking > > other things. > > I think we know who those people are, for the most part, but I think it > would be good to open up the floor for volunteers with the caveat that > there *will be an expectation* of a ~significant time commitment from > those who volunteer, and with a one-year tenure (so that people don't > join just to get their favorite feature through the process and then > disappear again). This should sufficiently self-regulate the membership > that it wont get unwieldy, and selects those who are both committed, and > knowledgeable. -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From fgibbons at hms.harvard.edu Wed Aug 24 14:08:10 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Aug 24 13:57:46 2005 Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <200508241557.j7OFv1Tu013092@portal.open-bio.org> Message-ID: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Martin, At 11:57 AM 8/24/2005, moby-dev-request@portal.open-bio.org wrote: >This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). Thanks for that suggestion - that sounds very sensible to me. As to whether Bugzilla has wishlists, I can't find them. (I hold the distinction of being the first - and to my knowledge, only - user of MOBY's Bugzilla set up.) Still, I guess we could overload the definition of 'bug' as meaning anything that needs attention. SourceForge has trackers that can differentiate between at least these four categories: bugs, support-requests, patches, and features requests. I'm sure there are good reasons why it makes sense to put MOBY on open-bio, rather than SourceForge. Is there any way we (and by 'we' I mean whoever runs open-bio :) could 'upgrade' the features offered by bugzilla there, to distinguish between those different kinds of requests? It would also help if the link to bugzilla got moved to a more prominent position on the MOBY home page. I really agree with Martin, that we need to adopt a more formalized (but not necessarily formal) approach to developing MOBY, because it's becoming bigger, and more widely used. The unformalized communication based on email doesn't scale terribly well: * there's poor differentiation between feature requests and bugs; and no definitive process for making decisions on either one; * there's no permanent record of decisions taken (except by searching the mail archives - good luck with that!); * although it's possible to announce future directions for development, they soon get lost in the archives, since they're not tagged as such. There are already powerful tools to help manage distributed software development, and I'd like to see us use them more. Using them would not only be good for our internal development, it would be good for our image, because it would look like we know what we're doing, giving newbies more confidence to join. Just my opinion, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From gordonp at ucalgary.ca Wed Aug 24 14:28:18 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed Aug 24 14:19:27 2005 Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> References: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: <430CBC42.4040404@ucalgary.ca> At the very least, you can set the severity of a bug to "enhancement" in Bugzilla. It's a start... > * there's poor differentiation between feature requests and bugs; and > no definitive process for making decisions on either one; > * there's no permanent record of decisions taken (except by searching > the mail archives - good luck with that!); > * although it's possible to announce future directions for > development, they soon get lost in the archives, since they're not > tagged as such. From markw at illuminae.com Wed Aug 24 16:54:48 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 24 16:44:14 2005 Subject: [MOBY-dev] RFC management system? Message-ID: <1124916888.8181.115.camel@bioinfo.icapture.ubc.ca> Hi all, I'm looking into "RT" from http://www.bestpractical.com It is being used by the open-bio people for their request tracking, so if it serves our purposes we could easily piggy-back. if anyone knows about this, please send your opinion. I'm just starting to look at it now... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Thu Aug 25 18:04:34 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Thu Aug 25 17:53:57 2005 Subject: [MOBY-dev] question to ask References: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> <1124900995.8181.57.camel@bioinfo.icapture.ubc.ca> Message-ID: <430E4072.6010801@cpsc.ucalgary.ca> Hi Mark, I have a question to ask you: I made my service can take a large input sequences (1000 to 5000 DNA) in XML format. I use "./build/run/run-cmdline-client -scall search_Pfam ../../../JMOBY2/DNASEQ/input_1000" to test this service. The input_1000 contains 1000 DNA sequences in XML format. This service takes 3 mins and 34 seconds to parse the input file, and terminated after 3 mins and 41 seconds, then I got the error message as the following: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [string: null] Fault string: (0)null Fault code: {http://xml.apache.org/axis/}HTTP Fault actor: null When calling: http://moby.ucalgary.ca/cgi-bin/MobyEd_dispatcher.cgi =========== at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:196) at org.biomoby.client.CentralImpl.call(CentralImpl.java:1422) at MobyCmdLineClient.main(MobyCmdLineClient.java:641) =========== I thought the service got time out, so I changed "call.setTimeout(new Integer (0)" to "call.setTimeout(new Integer (600000)" in the "CentralImpl.java", then recompiled and I tested the service again, but still got same message. However, the big problem which I have right now is the service will be terminated after around 4 mins. I want to delay the timeout time. If you can, could you let me know is there anyway which I can solve this problem. Now I just tested on 800 and 1000 sequences. The 800 sequences worked fine, but not 1000 sequences. please help me if you can. I know you are very busy. Thanks so much! Joyce From markw at illuminae.com Thu Aug 25 18:04:55 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu Aug 25 17:54:54 2005 Subject: [MOBY-dev] question to ask Message-ID: <1142838580-1125007531-cardhu_blackberry.rim.net-21511-@engine09-cell01> This is for the Java guru's to answer... M -----Original Message----- From: Chunyan Wang Date: Thu, 25 Aug 2005 16:04:34 To:markw@illuminae.com, Core developer announcements Subject: [MOBY-dev] question to ask Hi Mark, I have a question to ask you: I made my service can take a large input sequences (1000 to 5000 DNA) in XML format. I use "./build/run/run-cmdline-client -scall search_Pfam ../../../JMOBY2/DNASEQ/input_1000" to test this service. The input_1000 contains 1000 DNA sequences in XML format. This service takes 3 mins and 34 seconds to parse the input file, and terminated after 3 mins and 41 seconds, then I got the error message as the following: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [string: null] Fault string: (0)null Fault code: {http://xml.apache.org/axis/}HTTP Fault actor: null When calling: http://moby.ucalgary.ca/cgi-bin/MobyEd_dispatcher.cgi =========== at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:196) at org.biomoby.client.CentralImpl.call(CentralImpl.java:1422) at MobyCmdLineClient.main(MobyCmdLineClient.java:641) =========== I thought the service got time out, so I changed "call.setTimeout(new Integer (0)" to "call.setTimeout(new Integer (600000)" in the "CentralImpl.java", then recompiled and I tested the service again, but still got same message. However, the big problem which I have right now is the service will be terminated after around 4 mins. I want to delay the timeout time. If you can, could you let me know is there anyway which I can solve this problem. Now I just tested on 800 and 1000 sequences. The 800 sequences worked fine, but not 1000 sequences. please help me if you can. I know you are very busy. Thanks so much! Joyce _______________________________________________ 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 Thu Aug 25 20:03:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Aug 25 19:53:57 2005 Subject: [MOBY-dev] question to ask In-Reply-To: <430E4072.6010801@cpsc.ucalgary.ca> Message-ID: Hi, I am afraid I do not have any good answer for you. When I tried the same service today (with a very short sequence) I have got timeout after several seconds. It said "(504)Proxy Timeout ( This operation returned because the timeout period expired.)", which seems exactly what you witnessed. My feeling is that the proxy mentioned in the message is on the service provider side. I think that the best would be to contact and ask the service provider. With regards, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Aug 26 03:52:34 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 26 03:42:05 2005 Subject: [MOBY-dev] changes in jMoby Message-ID: Dear all, I have made few (hopefully not breaking anything) in jMoby (the reason why will come apparent when I finish documenting my efforts over this weekend and send another email here). The most important is that you should call ./build.sh in order to get a newly added jar (alltools2.jar). This will probably download all libraries again - thats' because an updated time-stamp in the jar registry - but it wil happen just once (but do not do it on a slow modem :-)). Also I updated version of jdom.jar from beta to the 1.0. Everything compiled fine, but please check your code that nothing broke (it's really time to think seriously on jUnits - and I do think about it...). The directory src/Services was almost empty - and I moved the rest what was there into the more appropriate place src/main (the package name remained the same). Instead there is now src/samples where we can put examples, tutorial as etc. It does not compile by default - so it does not break the normal/main code. There is a bunch of new targets in Ant, such as samples-compile, samples-docs, samples-jar, samples-clean. There is also a directory src/samples-resources where you can put testing or demo files. All files here are utomatically loaded to the CLASSPATH so you can use getResource() to get them without troubles with their physical location (and there is a new method in Utils.java doing so in one line - readResource(). Please read docs/ChangeLog for few details what I did. Thank you, Paul, that you are contributing there. Have ever headrd about this file, Eddie? Eddie, could you reconsider directory 'org' that suddenl;y appeared in the main directory? It should be somewhere else... (let's discuss it offline). Please let me know if I broke anything. I apologize if I did (but I have checked many times before commiting my huge changes, so I hope everything is fine...). Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From wangch at cpsc.ucalgary.ca Fri Aug 26 11:55:03 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Fri Aug 26 11:45:26 2005 Subject: [MOBY-dev] question to ask References: Message-ID: <430F3B57.2040602@cpsc.ucalgary.ca> Thanks, Martin. You said you tried the same service, which service? Is that search_Pfam? This service is tested with up to 800 sequences; it worked fine by using command line, but not from the MOBY Browser (works fine with one sequence). Actually, this is another big problem I have right now. The another problem is : When a user submits a request to one of our services from the MOBY Browser, if our server is busy and the request needs to take more than a few minutes to finish, then the service gets timeout. For our services, we need them to be able to take mutiple input sequences (maybe up to 5000 sequences) and input with seconary input. I am not sure what these problems are. But I will look into them. If anyone can give me suggestions, please let me know. Thanks. Joyce Martin Senger wrote: >Hi, > I am afraid I do not have any good answer for you. When I tried the >same service today (with a very short sequence) I have got timeout after >several seconds. It said "(504)Proxy Timeout ( This operation returned >because the timeout period expired.)", which seems exactly what you >witnessed. My feeling is that the proxy mentioned in the message is on the >service provider side. I think that the best would be to contact and ask >the service provider. > > With regards, > Martin > > > From senger at ebi.ac.uk Fri Aug 26 12:40:54 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 26 12:30:39 2005 Subject: [MOBY-dev] question to ask In-Reply-To: <430F3B57.2040602@cpsc.ucalgary.ca> Message-ID: > You said you tried the same service, which service? Is that search_Pfam? > Yes, the search_Pfam. > needs to take more than a few minutes to finish, then the service gets > timeout. > We had the same (or similar) problem at EBI. The timeout can happen at several places. And one good candidate is a proxy server (I am saying good, because the error I got mentioned proxy). The proxy can be configured how long it waits before timeout. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 26 18:20:31 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Aug 26 18:11:00 2005 Subject: [MOBY-dev] Migration of database to new API Message-ID: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Hi all, As we move toward deploying the new API, there are some serious consequences on the underlying databases. Let me first re-cap the new API features that I am discussing and what effects they have on the databases: 1) Inheritence from primitives through ISA relationships is no longer allowed. e.g. plain-text ISA String is no longer allowed. To achieve the same result, you now create an object that inherits from Object and contains the primitive. e.g. plain-text ISA Object; plain-text HASA String. 2) All service inputs and outputs must now be named (articleName) ------ For case 1, I have written a migration script that does the following: a) identifies every object that inherits directly from a primitive b) creates a new object called OldObjectName_v2 that inherits from Object and contains that primitive type through a HASA relationship, with the contained articleName being the same as the original object name. e.g. plain-text ISA String results in a new object plain_text_v2 ISA Object; plain_text_v2 HASA String(plain_text) c) updates the description of the original object such that the description now reads "DEPRECATED - use plain_text_v2 instead" This is in the Database folder of the CVS. At present, this script only goes down one level of the object hierarchy, and does not explicitly deprecate, nor create new object types for, any children of now deprecated objects, nor for any objects that contain a deprecated object Q1: Should it do so ...or is this going to create mass confusion for people? Q2: How long should the deprecation period be before we refuse to support the old objects any longer? My feeling is that it should be quite limited... e.g. 2 months. If you can't update your service to use a new object type within two months, then it gets removed from the registry. I updated all ~20 of my services in about 5 minutes, so that gives you a sense of how much effort it is... -------- For case 2, I have not yet written a script. I am loathe to change people's service registrations at all! I would prefer that people update their RDF signatures and let the agent update their service registration (once we get the agent running - this has been postponed *yet again* in order to bring our service signature model in sync with the one that we just jointly developed with myGrid last month). What concerns me is that this might require a lot of hand-editing from those who have hundreds of services registered (e.g. soaplab), so...?? Would it be preferable for me to script this and just attach arbitrary names to your inputs/outputs in the database? This is going to be a painful API change no matter how we play it, but I want to be sure that we all know what the changes are going to be and have agreed on the path of least pain before we begin the process. It's all for the best! Honestly! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Fri Aug 26 20:53:22 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 26 20:42:43 2005 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Aug 26 20:53:22 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 26 20:42:45 2005 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 26 20:58:33 2005 From: markw at illuminae.com (mark wilkinson) Date: Fri Aug 26 20:48:34 2005 Subject: [MOBY-dev] Migration of database to new API Message-ID: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> There is no need for a name change again. The object will forever be called -v2 It's just an identifier... M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 01:53:22 To:markw@illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Fri Aug 26 20:58:33 2005 From: markw at illuminae.com (mark wilkinson) Date: Fri Aug 26 20:48:40 2005 Subject: [MOBY-dev] Migration of database to new API Message-ID: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> There is no need for a name change again. The object will forever be called -v2 It's just an identifier... M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 01:53:22 To:markw@illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Fri Aug 26 21:06:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 26 20:56:18 2005 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> Message-ID: > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Aug 26 21:06:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 26 20:56:23 2005 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> Message-ID: > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 26 21:12:53 2005 From: markw at illuminae.com (mark wilkinson) Date: Fri Aug 26 21:03:02 2005 Subject: [MOBY-dev] Migration of database to new API Message-ID: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> I strongly disagree in return :-) If I have an object called "sequence" there is no indication in the name that it is a fasta sequence or an embl sequence or a genbank sequence or whatever. The fact that it is called sequence-v2 is no more nor less confusing! (Ben is sitting here beside me in the pub chuckling about the dangers of mixing semantics meaning into names :-) ) M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 02:06:55 To:markw@illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Fri Aug 26 21:22:42 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 26 21:12:19 2005 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> Message-ID: > The fact that it is called sequence-v2 is no more nor less confusing! > Nonsense. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Aug 27 07:11:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat Aug 27 07:01:04 2005 Subject: [MOBY-dev] what are services LSIDs good for? Message-ID: Having an LSID of a service instance (as returned by 'findService' from a registry) I can do two things: ask for data and ask for metadata (connected to this LSID). The metadata is not the topic here (now). What if I ask for data? I can get nothing back, indicating that there is no data associated with this service instance. And I think that I would get nothing because looking at the LSID now it does not seem to indicate any data (it does not have any version etc., for example). I may be wrong, but let's assume, only hypotetically, that I am not wrong and that really I do not get back any data. That's a pity because I want to improve my cache-aware clients by storing LSID in my cache, then asking for a list of services, and by comparing what I have and what I get, I can update in my cache only services that changed. Two problems with that: 1) The list of services (method retrieveServices) does not return LSIDs. Bad luck. Mark, you sent an email saying that lsid attribute is now everywhere. Well, it is not... 2) LSID resolver does return nothing when asking for data (if my hophoteziz above is rigth). Can this be fixed please? Thanks you, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 07:15:15 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat Aug 27 07:05:33 2005 Subject: [MOBY-dev] what are services LSIDs good for? Message-ID: <1178247580-1125141356-cardhu_blackberry.rim.net-18035-@engine10-cell01> I think I said it was returned on the new codebase, which is only running on the test server - is that the one you are hitting? We thought about keeping trtack of versions and sending the WSDL of the service as the data, but the discussion bogged down on whether that was really what service data *should* be, so it never got resolved (excuse the pun!) M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 12:11:09 To:Moby Developers Subject: [MOBY-dev] what are services LSIDs good for? Having an LSID of a service instance (as returned by 'findService' from a registry) I can do two things: ask for data and ask for metadata (connected to this LSID). The metadata is not the topic here (now). What if I ask for data? I can get nothing back, indicating that there is no data associated with this service instance. And I think that I would get nothing because looking at the LSID now it does not seem to indicate any data (it does not have any version etc., for example). I may be wrong, but let's assume, only hypotetically, that I am not wrong and that really I do not get back any data. That's a pity because I want to improve my cache-aware clients by storing LSID in my cache, then asking for a list of services, and by comparing what I have and what I get, I can update in my cache only services that changed. Two problems with that: 1) The list of services (method retrieveServices) does not return LSIDs. Bad luck. Mark, you sent an email saying that lsid attribute is now everywhere. Well, it is not... 2) LSID resolver does return nothing when asking for data (if my hophoteziz above is rigth). Can this be fixed please? Thanks you, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Sat Aug 27 07:25:43 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat Aug 27 07:15:23 2005 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <1178247580-1125141356-cardhu_blackberry.rim.net-18035-@engine10-cell01> Message-ID: > I think I said it was returned on the new codebase, which is only > running on the test server - is that the one you are hitting? > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > We thought about keeping trtack of versions and sending the WSDL of > the service as the data, but the discussion bogged down on whether > that was really what service data *should* be, so it never got > resolved (excuse the pun!) > I know about this discussion. I actually do not care what will be returned back (at least not now), but I do care that the LSID of a registered service will chnage if I re-register the same service and I change something in it. That's what LSIDs are for, not? Can that be done? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 12:21:27 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat Aug 27 12:12:21 2005 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <43109307.70402@illuminae.com> Hit the test server: http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl We are planning to keep version numbers of services, but this is waiting on the agent, and the agent is waiting on the final decision on an RDF document format describing a service. Eddie is back from holiday on Monday and this is the first thing on his list, so it should all come together quickly from here on! M Martin Senger wrote: >>I think I said it was returned on the new codebase, which is only >>running on the test server - is that the one you are hitting? >> >> >> > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > > > >>We thought about keeping trtack of versions and sending the WSDL of >>the service as the data, but the discussion bogged down on whether >>that was really what service data *should* be, so it never got >>resolved (excuse the pun!) >> >> >> > I know about this discussion. I actually do not care what will be >returned back (at least not now), but I do care that the LSID of a >registered service will chnage if I re-register the same service and I >change something in it. That's what LSIDs are for, not? > Can that be done? > > Martin > > > From senger at ebi.ac.uk Sat Aug 27 12:30:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat Aug 27 12:20:12 2005 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <43109307.70402@illuminae.com> Message-ID: > Hit the test server: > > http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl > This has only two services and neither of them has an LSID as an attribute. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Aug 27 12:33:25 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat Aug 27 12:24:03 2005 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <43109307.70402@illuminae.com> Message-ID: > We are planning to keep version numbers of services > Good. Please keep in mind my suggestion *not* to return WSDL as service data (I told it to Eddie already in Malaga; there is no sense to duplicate this feature if we have it already in registry API) but returns instead a fingerprint of data that are registered. So if a provider re-register the LSID changes and people can se that a new version of a service is there. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From tmo at ebi.ac.uk Sat Aug 27 12:49:43 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Sat Aug 27 12:39:12 2005 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <431099A7.7000902@ebi.ac.uk> Martin Senger wrote: >>We are planning to keep version numbers of services >> > > Good. Please keep in mind my suggestion *not* to return WSDL as service > data (I told it to Eddie already in Malaga; there is no sense to duplicate > this feature if we have it already in registry API) but returns instead a > fingerprint of data that are registered. So if a provider re-register the > LSID changes and people can se that a new version of a service is there. Should there be anything returned as LSID data for a service? A service is an abstract entity, it doesn't have a physical existance so it's meaningless (according to the LSID specification) to return data for it. Something like a protein sequence has a real world entity which can have various literal representations (hence having an abstract root sequence object which referes in the metadata to various concrete LSIDs for each format) but in this case there is no real world object. LSIDs for services should only return metadata, they shouldn't return data in any form whatsoever. If you want to return metadata pointing to a servicedescription LSID (or whatever) and have the data for the servicedescription be a WSDL that would sound reasonable but the service itself is an abstract entity. It would be exactly as reasonable to return a bitmap image of the server hardware... Tom From senger at ebi.ac.uk Sat Aug 27 13:03:00 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat Aug 27 12:52:21 2005 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <431099A7.7000902@ebi.ac.uk> Message-ID: Tom, No, Tom, I disagree. There is no reason why abstract term/entities could not have a real data associated. And I gave a good reason how I would use such data. A "service instance" (an unfortunate name of a service fingerprint in a registry invented by a bilogist) is a real object in a registry, and I am asking to give LSID data to reflect the fact that it is important and useful to know whether such object in registry changed or not. Of course, and you are right, that the same can be achieved from metadata. But it would mean that if I need information about all services, I would need to go to all service providers (because they act as LSID metadata resolvers) - and not just to one place where this information is already stored. And, to be fair, where the API for such simple task is easy enough. As long as we have a central registry (and everytime I listen to Mark I have feeling that he is going as much as possible not to have it :-)) why not to use it efficiently for what it was designed (this time the same biologist had luckier hand). Nice to hear again from you, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 22:50:37 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat Aug 27 22:40:44 2005 Subject: [MOBY-dev] Migration of database to new API Message-ID: <17778361-1125197479-cardhu_blackberry.rim.net-5182-@engine08-cell01> I don't see how flipping names back and forth over different underlying structures is a "meaningful and consistent" strategy... ?!?!?!!!???! M -----Original Message----- From: Benjamin Good Date: Sat, 27 Aug 2005 15:37:26 To:markw@illuminae.com, Core developer announcements Subject: Re: [MOBY-dev] Migration of database to new API Jumping in since I was mentioned ... In the current version of moby, as I understand it at least, I have to side with Martin on this (sorry Mark, don't fire me!). Ahab, as well as other generic clients, benefits substantially from meaningful object and service names. Taking your (Mark's) argument further, we might as well eliminate human-readable names altogether and simply assign a unique number to each one - which is fine for the use as a machine name, but totally useless to an anonymous human user of the data-type. To be precise, in the current formulation of BioMoby, the ONLY semantics associated with the data-types are encoded in the names of the objects. Thus, until we have a consistent framework for encoding semantics in another more robust fashion, like a separate ontology that has nothing to do with syntax, we should at least attempt to encourage meaningful and consistent naming strategies. -Ben On Aug 26, 2005, at 6:12 PM, mark wilkinson wrote: > I strongly disagree in return :-) > > If I have an object called "sequence" there is no indication in the > name that it is a fasta sequence or an embl sequence or a genbank > sequence or whatever. The fact that it is called sequence-v2 is no > more nor less confusing! > > (Ben is sitting here beside me in the pub chuckling about the > dangers of mixing semantics meaning into names :-) ) > > M > > > -----Original Message----- > From: Martin Senger > Date: Sat, 27 Aug 2005 02:06:55 > To:markw@illuminae.com, Core developer announcements dev@portal.open-bio.org> > Cc:mobydev > Subject: Re: [MOBY-dev] Migration of database to new API > > >> There is no need for a name change again. The object will forever >> be called -v2 >> >> It's just an identifier... >> >> > Strongly disagree. The names are visible to people in many > clients that > list them. They should be named sensibly. Adding an artificial > suffix v2 > just without any compelling reasons is a bad design (and there is no > compelling reason for that). > I will better stop now (you got me agian!?)... > > Martin > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > >_______________________________________________ > 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 > > -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Mon Aug 29 10:32:30 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Aug 29 10:25:36 2005 Subject: [MOBY-dev] Moses - Moby Services Support In-Reply-To: <1476.82.66.216.27.1118945157.squirrel@82.66.216.27> Message-ID: Hi all, My first month at Philippines, at IRRI, is almost finished. So it's time to announce some progress :-) I have commited code and a lot of documentation helping to write Biomoby services in Java. The idea is to generate classes for all registered data types and then generate skeleton for a new service. Its developer can extend such skeleton , put there the business logic without worries about the Biomoby XML and about the SOAP itself. These things should be hidden. It is similar what Paul Gordon provides for the clients, but here you can use strongly-type approach (having all data types generated). Or, you can say, that we can have more ways to do the same, like in Perl :-) As (almost) a side-effect, the generated code, because it has rich API/javadoc comments, can be used as a primitive browser of the biomoby registry. Here you can see the API for all data types and for all services as they are today (when I find a place where I can run a cronjob, we can have this API up-to-date anytime you look): http://www.ebi.ac.uk/~senger/jMoby/APIservices/index.html The documentation is in jMoby and can be viewed at: http://biomoby.org/moby-live/Java/docs/Moses.html. I hope you'll enjoy it and I am happy to hear your suggestions, bug reports (remember there is also a bugzilla open now, but feel free to send emails direcly to me) and anything bout Moses. With regards, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From wangch at cpsc.ucalgary.ca Mon Aug 29 13:44:34 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Mon Aug 29 13:33:53 2005 Subject: [MOBY-dev] Question on parser References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43134982.4020503@cpsc.ucalgary.ca> Hi all, I have a question about the parser. I am working on making my service to take mutiple sequences (up to 5000 and more) input. When I tested on 800 sequences, the time to take the parser to parse a 800 sequences is about 3 mins and 32 seconds. It took 14 mins to parse a 2000 sequences. It seems to take longer time when the input sequence size increases. Is this normal? I think the time should not be too much difference for parsing different size sequence input. Could anybody explain this "problem" to me? Thanks. Joyce From markw at illuminae.com Mon Aug 29 13:45:55 2005 From: markw at illuminae.com (mark wilkinson) Date: Mon Aug 29 13:36:41 2005 Subject: [MOBY-dev] Re: Question on parser Message-ID: <1690593290-1125337603-cardhu_blackberry.rim.net-28949-@engine13-cell01> Define "parser"... What parser are you talking about? M -----Original Message----- From: Chunyan Wang Date: Mon, 29 Aug 2005 11:44:34 To:markw@illuminae.com, Core developer announcements Subject: Question on parser Hi all, I have a question about the parser. I am working on making my service to take mutiple sequences (up to 5000 and more) input. When I tested on 800 sequences, the time to take the parser to parse a 800 sequences is about 3 mins and 32 seconds. It took 14 mins to parse a 2000 sequences. It seems to take longer time when the input sequence size increases. Is this normal? I think the time should not be too much difference for parsing different size sequence input. Could anybody explain this "problem" to me? Thanks. Joyce -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Mon Aug 29 13:49:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Aug 29 13:39:14 2005 Subject: [MOBY-dev] Question on parser In-Reply-To: <43134982.4020503@cpsc.ucalgary.ca> Message-ID: > Could anybody explain this "problem" to me? Thanks. > What language are you using, what XML library in that language? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Aug 29 15:45:07 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Aug 29 15:34:27 2005 Subject: [moby] Re: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <1125344707.16473.17.camel@bioinfo.icapture.ubc.ca> On Sat, 2005-08-27 at 17:30 +0100, Martin Senger wrote: > This has only two services and neither of them has an LSID as an > attribute. I think they have an LSID attribute (or at least, they do when I make the call), but that attribute has no value. I have just added an LSID value into the database manually so that you have something to retrieve, but don't try to resolve it, because it isn't "real" M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Mon Aug 29 15:45:37 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Mon Aug 29 15:34:53 2005 Subject: [MOBY-dev] Question on parser References: Message-ID: <431365E1.7080800@cpsc.ucalgary.ca> Martin Senger wrote: >>Could anybody explain this "problem" to me? Thanks. >> >> >> > What language are you using, what XML library in that language? > I am using Perl and XML::DOM. I am using "genericServiceInputParser($data)" to parse the input sequence in my service. By the way, I want to let you know I fixed timeout problem. Thanks for your suggestion. Joyce > Martin > > > From senger at ebi.ac.uk Mon Aug 29 20:06:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Aug 29 19:55:26 2005 Subject: [moby] Re: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <1125344707.16473.17.camel@bioinfo.icapture.ubc.ca> Message-ID: > I think they have an LSID attribute (or at least, they do when I make > the call), but that attribute has no value. > Yes, that was also my observation. Hard to test if it is empty :-) > but don't try to resolve it, because it isn't "real" > Let us know please where things are real :-) Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Aug 29 19:36:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Aug 29 21:11:35 2005 Subject: [MOBY-dev] Production registry now running on new codebase Message-ID: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Mon Aug 29 22:08:44 2005 From: markw at illuminae.com (mark wilkinson) Date: Mon Aug 29 21:58:53 2005 Subject: [MOBY-dev] Moby central "Relationships" function is buggy Message-ID: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Hi all, Don't trust the output from "Relationships" in moby central. It seems to return only the immediate parent and root. I'm working on it. M -----Original Message----- From: Mark Wilkinson Date: Mon, 29 Aug 2005 16:36:34 To:mobydev Subject: [MOBY-dev] Production registry now running on new codebase Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 _______________________________________________ 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 Mon Aug 29 22:08:44 2005 From: markw at illuminae.com (mark wilkinson) Date: Mon Aug 29 21:58:57 2005 Subject: [MOBY-dev] Moby central "Relationships" function is buggy Message-ID: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Hi all, Don't trust the output from "Relationships" in moby central. It seems to return only the immediate parent and root. I'm working on it. M -----Original Message----- From: Mark Wilkinson Date: Mon, 29 Aug 2005 16:36:34 To:mobydev Subject: [MOBY-dev] Production registry now running on new codebase Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From carrere at toulouse.inra.fr Tue Aug 30 02:36:32 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Tue Aug 30 02:26:21 2005 Subject: [MOBY-dev] Question on parser In-Reply-To: <431365E1.7080800@cpsc.ucalgary.ca> References: <431365E1.7080800@cpsc.ucalgary.ca> Message-ID: <4313FE70.80308@toulouse.inra.fr> Hi all, I got the same problem when I wanted to parse huge XML files. That's why I have written a clone of CommonSub.pm using "xsltproc" to parse MOBY message. Then the parsing time problem was removed. However, how do you fixed timeout problem ? Sebastien Chunyan Wang wrote: > > > Martin Senger wrote: > >>> Could anybody explain this "problem" to me? Thanks. >>> >>> >> >> What language are you using, what XML library in that language? >> > I am using Perl and XML::DOM. I am using > "genericServiceInputParser($data)" to parse the input sequence in my > service. > By the way, I want to let you know I fixed timeout problem. Thanks for > your suggestion. > > Joyce > >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Tue Aug 30 11:01:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Aug 30 10:50:13 2005 Subject: [moby] Re: [MOBY-dev] Question on parser In-Reply-To: <4313FE70.80308@toulouse.inra.fr> References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> Message-ID: <1125414060.19194.26.camel@bioinfo.icapture.ubc.ca> On Tue, 2005-08-30 at 08:36 +0200, Sebastien Carrere wrote: > That's why I have written a clone of CommonSub.pm using "xsltproc" to > parse MOBY message. Would you be willing to add this to the CVS? > However, how do you fixed timeout problem ? In the 1.0 release we should have a spec for asynchronous services, so this problem will hopefully not be as severe... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Tue Aug 30 12:17:56 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Tue Aug 30 12:07:45 2005 Subject: [MOBY-dev] Question on parser References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> Message-ID: <431486B4.6060700@cpsc.ucalgary.ca> Hi, I changed TimeOut from default to 50000 in the Apache config to fix timeout problem. How big was your XML file when you had problem? Cheers, Joyce Sebastien Carrere wrote: > Hi all, > > I got the same problem when I wanted to parse huge XML files. > That's why I have written a clone of CommonSub.pm using "xsltproc" to > parse MOBY message. > Then the parsing time problem was removed. > > However, how do you fixed timeout problem ? > > Sebastien > > Chunyan Wang wrote: > >> >> >> Martin Senger wrote: >> >>>> Could anybody explain this "problem" to me? Thanks. >>>> >>>> >>> >>> >>> What language are you using, what XML library in that language? >>> >> I am using Perl and XML::DOM. I am using >> "genericServiceInputParser($data)" to parse the input sequence in my >> service. >> By the way, I want to let you know I fixed timeout problem. Thanks >> for your suggestion. >> >> Joyce >> >>> Martin >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > From leolxshen at gmail.com Tue Aug 30 17:03:43 2005 From: leolxshen at gmail.com (leo shen) Date: Tue Aug 30 16:52:55 2005 Subject: [MOBY-dev] xml schema generator for Moby object committed Message-ID: Hi all, The java codes of XML schema generator has been commited in org/biomoby/shared/schema Cheers From dgpisano at cnb.uam.es Thu Aug 25 08:36:01 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Tue Aug 30 18:55:44 2005 Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <430DBB31.8070009@cnb.uam.es> Dear all, Here you have the Exception (Errors) reporting Request for Comments document. We have included some interesting comments taken from discussions / lists and rewritten it to make it more clear. It presents only one proposal to deal with error information, although it has also presents an extension option to report errors related to Simples into Collections. That extension can be considerered optional (we in the INB will be using it anyways). Please feel free to comment / discuss about it. Also, please feel free to use the document as guinea pig if we set up a procedure to deal with RFPs/RFCs in the MOBY community ;-) Regards, David Martin Senger escribi?: >>>but the problem is that we do not have (still) a procedure how to make >>>changes in the API. >>> >>> >>Correct. >> >> >> > So how are we going to solve this? > This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). > > 2) Then a calendar (deadline) must be attached to it. It can be >suggested already by the author of the RFP/RFC, or a default value is >attached. We need to say what is a default value. > > 3) The RFP can be considered only if the change is back-uped by two >(three?) other developers. They do not need to fully agree with all >details, their role is just to prevent overhelming number of small >changes coming fast. > > 4) It is also considered only if somebody has resources to really >implement the change. This should be also a part of the clendar ("when it >can be done"). > > 5) Discussion on RFC, changes re-distributed, etc. In charge is the >author of the original RFC. Deadline can be extended - don't be too formal >here. > > 6) Now the tricky part: I think taht there should be only few people >(major developers) who can vote on it. This is called an "Architecture >Board" at OMG and guarantees that the changes are hopefully not breaking >other things. > > 7) Then comes implementation, documenttaion etc. > > Cheers, > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v1.5.doc Type: application/msword Size: 139776 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050825/8c0dd56f/0501INB-ExceptionReporting-v1.5-0002.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050825/8c0dd56f/dgpisano-0002.vcf From goodb at interchange.ubc.ca Sat Aug 27 18:37:26 2005 From: goodb at interchange.ubc.ca (Benjamin Good) Date: Tue Aug 30 18:55:49 2005 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> References: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> Message-ID: Jumping in since I was mentioned ... In the current version of moby, as I understand it at least, I have to side with Martin on this (sorry Mark, don't fire me!). Ahab, as well as other generic clients, benefits substantially from meaningful object and service names. Taking your (Mark's) argument further, we might as well eliminate human-readable names altogether and simply assign a unique number to each one - which is fine for the use as a machine name, but totally useless to an anonymous human user of the data-type. To be precise, in the current formulation of BioMoby, the ONLY semantics associated with the data-types are encoded in the names of the objects. Thus, until we have a consistent framework for encoding semantics in another more robust fashion, like a separate ontology that has nothing to do with syntax, we should at least attempt to encourage meaningful and consistent naming strategies. -Ben On Aug 26, 2005, at 6:12 PM, mark wilkinson wrote: > I strongly disagree in return :-) > > If I have an object called "sequence" there is no indication in the > name that it is a fasta sequence or an embl sequence or a genbank > sequence or whatever. The fact that it is called sequence-v2 is no > more nor less confusing! > > (Ben is sitting here beside me in the pub chuckling about the > dangers of mixing semantics meaning into names :-) ) > > M > > > -----Original Message----- > From: Martin Senger > Date: Sat, 27 Aug 2005 02:06:55 > To:markw@illuminae.com, Core developer announcements dev@portal.open-bio.org> > Cc:mobydev > Subject: Re: [MOBY-dev] Migration of database to new API > > >> There is no need for a name change again. The object will forever >> be called -v2 >> >> It's just an identifier... >> >> > Strongly disagree. The names are visible to people in many > clients that > list them. They should be named sensibly. Adding an artificial > suffix v2 > just without any compelling reasons is a bad design (and there is no > compelling reason for that). > I will better stop now (you got me agian!?)... > > Martin > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > > _______________________________________________ > 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 > > From dgpisano at cnb.uam.es Thu Aug 25 08:36:01 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Tue Aug 30 18:55:50 2005 Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <430DBB31.8070009@cnb.uam.es> Dear all, Here you have the Exception (Errors) reporting Request for Comments document. We have included some interesting comments taken from discussions / lists and rewritten it to make it more clear. It presents only one proposal to deal with error information, although it has also presents an extension option to report errors related to Simples into Collections. That extension can be considerered optional (we in the INB will be using it anyways). Please feel free to comment / discuss about it. Also, please feel free to use the document as guinea pig if we set up a procedure to deal with RFPs/RFCs in the MOBY community ;-) Regards, David Martin Senger escribi?: >>>but the problem is that we do not have (still) a procedure how to make >>>changes in the API. >>> >>> >>Correct. >> >> >> > So how are we going to solve this? > This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). > > 2) Then a calendar (deadline) must be attached to it. It can be >suggested already by the author of the RFP/RFC, or a default value is >attached. We need to say what is a default value. > > 3) The RFP can be considered only if the change is back-uped by two >(three?) other developers. They do not need to fully agree with all >details, their role is just to prevent overhelming number of small >changes coming fast. > > 4) It is also considered only if somebody has resources to really >implement the change. This should be also a part of the clendar ("when it >can be done"). > > 5) Discussion on RFC, changes re-distributed, etc. In charge is the >author of the original RFC. Deadline can be extended - don't be too formal >here. > > 6) Now the tricky part: I think taht there should be only few people >(major developers) who can vote on it. This is called an "Architecture >Board" at OMG and guarantees that the changes are hopefully not breaking >other things. > > 7) Then comes implementation, documenttaion etc. > > Cheers, > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v1.5.doc Type: application/msword Size: 139776 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050825/8c0dd56f/0501INB-ExceptionReporting-v1.5-0003.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20050825/8c0dd56f/dgpisano-0003.vcf From senger at ebi.ac.uk Tue Aug 30 21:38:51 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 30 21:28:46 2005 Subject: [MOBY-dev] Production registry now running on new codebase In-Reply-To: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Message-ID: I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger@gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 21:38:51 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 30 21:28:51 2005 Subject: [MOBY-dev] Production registry now running on new codebase In-Reply-To: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Message-ID: I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger@gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 21:23:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 30 21:33:10 2005 Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <430DBB31.8070009@cnb.uam.es> Message-ID: Thanks for the updated document. Before I express my comments to it here is a few bits regarding RFC procedure for this proposal (assuming that we agreed on an RFC procedure as, or close to, suggested in previous emails: 1) I second the proposal (so it can become an RFC) 2) I suggest to resolve it (accept or refuse) before September 15 (so this is an RFC calendar). Concretely, I propose that Mark will ask selected voters after this date to vote on it. (BTW, I like and support his idea to have a year-long tenure on the voting list (that's actually very close why OMG has its Architecture Board also with rotating, and *dedicated*, people). Now back to the proposal, here are my comments (I suggest that those comments that are acceptable by the INB authors, and that are not in contradiction with the email discussion, will be incorporate and a new draft will be circulated - perhaps already without reasoning). Generally, I like the proposal, my comments are only about details. 1) The attribute names 'Value' and 'Description' are not intuitive. They should express more what they are about. What about "errorCode" (or only "code") and "errorMessage" (or only "message")? 2) I know that the article name in Simples in Collection is an optional part of the proposal - but I agree with Mark that using there again the term "articleName" is bad (too overloaded). What about to use there a completely different tag, like "elementId"? >From this change (if accepted) follows at once that the attribute name in mobyException should not be "refArticleName" (because sometimes it refers to a non-article name) - so why not to call it just a "ref", or "refElement"? 3) I would like to have (in the exception API handling) a remark that the clients are obliged to be aware that a service can also raise an exception that will be delivered in the SOAP envelope (that is a standard way). As I said, good clients have to do it anyway (because your service does not have always full control what to return back) - so I would keep this option there. 4) Just to keep in synch with other software projects, I would add one more severity level - a simple "message" (so we would have, errors, warnings, messages). 5) The list of codes is not always clear: - should the sub-phrases in 201 be distinguish by a separate code? - 621 (service not available) means actually that the resources the service wishes to use are not available (because if it was a service itself, it would not have any chance to report it, that would be a soap exception mentioned above), - 622 (malformed Moby response) - what is a response here? - and anyway, this may be difficult to catch (I know in SOAP::Lite you do not get control only when the whole XML is parsed) - why do you call some codes "client-side detected errors"? - generally, I would put less codes and rather to define how service providers can expressed their own service-specific codes (by saying in which range they should put such specific codes) 6) Some typos: - articlename attribute should be articleName - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is something else in Biomoby API) 7) Attributes in mobyException (refArticleName, or whatever name we will agree on, and reqQuery) should be made optional - so an exception can refer to the whole response (or to a whole query if only reqQuery is present). With regards, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 21:23:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 30 21:33:15 2005 Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <430DBB31.8070009@cnb.uam.es> Message-ID: Thanks for the updated document. Before I express my comments to it here is a few bits regarding RFC procedure for this proposal (assuming that we agreed on an RFC procedure as, or close to, suggested in previous emails: 1) I second the proposal (so it can become an RFC) 2) I suggest to resolve it (accept or refuse) before September 15 (so this is an RFC calendar). Concretely, I propose that Mark will ask selected voters after this date to vote on it. (BTW, I like and support his idea to have a year-long tenure on the voting list (that's actually very close why OMG has its Architecture Board also with rotating, and *dedicated*, people). Now back to the proposal, here are my comments (I suggest that those comments that are acceptable by the INB authors, and that are not in contradiction with the email discussion, will be incorporate and a new draft will be circulated - perhaps already without reasoning). Generally, I like the proposal, my comments are only about details. 1) The attribute names 'Value' and 'Description' are not intuitive. They should express more what they are about. What about "errorCode" (or only "code") and "errorMessage" (or only "message")? 2) I know that the article name in Simples in Collection is an optional part of the proposal - but I agree with Mark that using there again the term "articleName" is bad (too overloaded). What about to use there a completely different tag, like "elementId"? >From this change (if accepted) follows at once that the attribute name in mobyException should not be "refArticleName" (because sometimes it refers to a non-article name) - so why not to call it just a "ref", or "refElement"? 3) I would like to have (in the exception API handling) a remark that the clients are obliged to be aware that a service can also raise an exception that will be delivered in the SOAP envelope (that is a standard way). As I said, good clients have to do it anyway (because your service does not have always full control what to return back) - so I would keep this option there. 4) Just to keep in synch with other software projects, I would add one more severity level - a simple "message" (so we would have, errors, warnings, messages). 5) The list of codes is not always clear: - should the sub-phrases in 201 be distinguish by a separate code? - 621 (service not available) means actually that the resources the service wishes to use are not available (because if it was a service itself, it would not have any chance to report it, that would be a soap exception mentioned above), - 622 (malformed Moby response) - what is a response here? - and anyway, this may be difficult to catch (I know in SOAP::Lite you do not get control only when the whole XML is parsed) - why do you call some codes "client-side detected errors"? - generally, I would put less codes and rather to define how service providers can expressed their own service-specific codes (by saying in which range they should put such specific codes) 6) Some typos: - articlename attribute should be articleName - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is something else in Biomoby API) 7) Attributes in mobyException (refArticleName, or whatever name we will agree on, and reqQuery) should be made optional - so an exception can refer to the whole response (or to a whole query if only reqQuery is present). With regards, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Tue Aug 30 21:40:20 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue Aug 30 21:35:44 2005 Subject: [MOBY-dev] Production registry now running on new codebase Message-ID: <1929607892-1125452470-cardhu_blackberry.rim.net-30717-@engine12-cell01> Let's use bugzilla rather than the list, though... M -----Original Message----- From: Martin Senger Date: Wed, 31 Aug 2005 02:38:51 To:markw@illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Production registry now running on new codebase I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger@gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Tue Aug 30 21:49:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 30 21:38:15 2005 Subject: [MOBY-dev] Moby central "Relationships" function is buggy In-Reply-To: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Message-ID: > Don't trust the output from "Relationships" in moby central. It seems > to return only the immediate parent and root. I'm working on it. > Actually, for me, it does not return anything, at all: METHOD CALL: Relationships ------------ GenericSequenceISAHASAHAS1 ------------ METHOD RETURN: ------------ Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 21:49:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 30 21:38:16 2005 Subject: [MOBY-dev] Moby central "Relationships" function is buggy In-Reply-To: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Message-ID: > Don't trust the output from "Relationships" in moby central. It seems > to return only the immediate parent and root. I'm working on it. > Actually, for me, it does not return anything, at all: METHOD CALL: Relationships ------------ GenericSequenceISAHASAHAS1 ------------ METHOD RETURN: ------------ Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 23:30:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 30 23:20:08 2005 Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: Frank, I am slowly starting to read your version of API. I am sorry that I have not read it whole, and that I am giving the comments step by step. The first few comments about the registry API: * I think that the first page (with a list of methods) should also have (even start with) a list of links to objects used by these methods, such as a query object. * I disagree with labelling the deregisteService as depracated. As far as I understood, it will be still around for quick resgiter/unregister cycle where I am not conceedrn about security (that somebody can deregister my service). So from the API point of view it is a normal method, not a deprecated one. Mark? * service protocol "moby" is actually a service category, not a protocol I think * I would move definition of a "A MOBY compliant service" to the section about services API (here may be just a link to it). As I said I am really concern that these two APIs are (or were before you enter the scene) confusing, so make them as separate as possible. * retrieveResourceURLs has a wrong description (something about providers) * some details have also categories cgi.soap, some not... I suggest to remove all cgi and sopa for now (we will have in in the CVS if we need it to re-introsduce it later; surely the 'soap' category bring nothing than a confusion (isn't it current moby based on soap? - I know how it is, but newbies perhaps not) * the notes starting the section " MOBY Central Procedure Call XML" shoulod be on the first page, or linked in the first page". And the last (but not an unimportant) general comment: the XML-based API should be expressed as DTD (which is more preferable in this context, XSD is not so human readable). Also the details about individual tags and attributes are quitel imited now. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 23:30:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 30 23:20:17 2005 Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: Frank, I am slowly starting to read your version of API. I am sorry that I have not read it whole, and that I am giving the comments step by step. The first few comments about the registry API: * I think that the first page (with a list of methods) should also have (even start with) a list of links to objects used by these methods, such as a query object. * I disagree with labelling the deregisteService as depracated. As far as I understood, it will be still around for quick resgiter/unregister cycle where I am not conceedrn about security (that somebody can deregister my service). So from the API point of view it is a normal method, not a deprecated one. Mark? * service protocol "moby" is actually a service category, not a protocol I think * I would move definition of a "A MOBY compliant service" to the section about services API (here may be just a link to it). As I said I am really concern that these two APIs are (or were before you enter the scene) confusing, so make them as separate as possible. * retrieveResourceURLs has a wrong description (something about providers) * some details have also categories cgi.soap, some not... I suggest to remove all cgi and sopa for now (we will have in in the CVS if we need it to re-introsduce it later; surely the 'soap' category bring nothing than a confusion (isn't it current moby based on soap? - I know how it is, but newbies perhaps not) * the notes starting the section " MOBY Central Procedure Call XML" shoulod be on the first page, or linked in the first page". And the last (but not an unimportant) general comment: the XML-based API should be expressed as DTD (which is more preferable in this context, XSD is not so human readable). Also the details about individual tags and attributes are quitel imited now. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From carrere at toulouse.inra.fr Wed Aug 31 02:46:36 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Wed Aug 31 02:50:07 2005 Subject: [MOBY-dev] Question on parser In-Reply-To: <431486B4.6060700@cpsc.ucalgary.ca> References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> <431486B4.6060700@cpsc.ucalgary.ca> Message-ID: <4315524C.6040307@toulouse.inra.fr> The MOBY message that I wanted to parse was a 12 Megabyte one. The web-service concerned is: name: ImgaGetTigrXMLEntriesFromKeyword uri: bioinfo.genopole-toulouse.prd.fr input: String Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /IMGA_Accession, as IMGA_Accession I think this is a little bit extreme, but it works fine now. Sebastien Chunyan Wang wrote: > Hi, > I changed TimeOut from default to 50000 in the Apache config to fix > timeout problem. > How big was your XML file when you had problem? > Cheers, > > Joyce > > Sebastien Carrere wrote: > >> Hi all, >> >> I got the same problem when I wanted to parse huge XML files. >> That's why I have written a clone of CommonSub.pm using "xsltproc" to >> parse MOBY message. >> Then the parsing time problem was removed. >> >> However, how do you fixed timeout problem ? >> >> Sebastien >> >> Chunyan Wang wrote: >> >>> >>> >>> Martin Senger wrote: >>> >>>>> Could anybody explain this "problem" to me? Thanks. >>>>> >>>>> >>>> >>>> >>>> >>>> What language are you using, what XML library in that language? >>>> >>> I am using Perl and XML::DOM. I am using >>> "genericServiceInputParser($data)" to parse the input sequence in my >>> service. >>> By the way, I want to let you know I fixed timeout problem. Thanks >>> for your suggestion. >>> >>> Joyce >>> >>>> Martin >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Wed Aug 31 15:39:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 31 15:58:36 2005 Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-31 at 02:23 +0100, Martin Senger wrote: > 2) I suggest to resolve it (accept or refuse) before September 15 (so > this is an RFC calendar). Concretely, I propose that Mark will ask > selected voters after this date to vote on it. OK. I will be on holiday that day in the mountains (likely with no net access even from my cell phone) so perhaps David or Martin can call the vote in my absence? > (BTW, I like and > support his idea to have a year-long tenure on the voting list (that's > actually very close why OMG has its Architecture Board also with > rotating, and *dedicated*, people). Super! I'll try to write-up a formal "constitution" document in the next few days... > 1) The attribute names 'Value' and 'Description' are not > intuitive. They should express more what they are about. What about > "errorCode" (or only "code") and "errorMessage" (or only "message")? I agree. > 2) I know that the article name in Simples in Collection is an > optional part of the proposal - but I agree with Mark that using there > again the term "articleName" is bad (too overloaded). What about to > use there a completely different tag, like "elementId"? I think I proposed this alternative as well. I do have a deeper concern, however, and I want to discuss this thoroughly before we make any decisions here. It isn't entirely clear to me that there is a need to throw errors on a specific Simple within a Collection. This is very complicated for me to explain clearly, but I will try... A collection is a "semantic unit" - it is the response to a ***single*** input. As such, it cannot be partially erroneous! It is either entirely erroneous, or entirely correct. To throw an error on a single sub-unit of a collection casts doubt on the validity of the entire collection (since you cannot interpret what the collection would have "looked like" had that error not been thrown) and thus the entire collection must be considered flawed. Imagine it this way: What would it mean to have a Blast report where certain HSP's within the Blast report contained error messages? Does it mean that there was a sequence in the underlying database that was somehow incorrectly formatted If so, then the blast provider should have caught that error and not reported that match at all rather than telling the client that there is a flakey sequence in their database. Does it mean that the software is buggy? If so, then the entire report is potentially flawed, and should not have been produced. Does it mean that (in some way) the input sequence was peculiar? If so, then again the entire output is suspect and not just a single HSP within that output. Do you see what I am getting at? The scenario we are trying to accommodate, in my opinion, is impossible if people are using Collections in the way they are intended to be used. > 3) I would like to have (in the exception API handling) a remark that > the clients are obliged to be aware that a service can also raise an > exception that will be delivered in the SOAP envelope (that is a > standard way). As I said, good clients have to do it anyway (because > your service does not have always full control what to return back) - > so I would keep this option there. Absolutely! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 31 15:39:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 31 15:58:41 2005 Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-31 at 02:23 +0100, Martin Senger wrote: > 2) I suggest to resolve it (accept or refuse) before September 15 (so > this is an RFC calendar). Concretely, I propose that Mark will ask > selected voters after this date to vote on it. OK. I will be on holiday that day in the mountains (likely with no net access even from my cell phone) so perhaps David or Martin can call the vote in my absence? > (BTW, I like and > support his idea to have a year-long tenure on the voting list (that's > actually very close why OMG has its Architecture Board also with > rotating, and *dedicated*, people). Super! I'll try to write-up a formal "constitution" document in the next few days... > 1) The attribute names 'Value' and 'Description' are not > intuitive. They should express more what they are about. What about > "errorCode" (or only "code") and "errorMessage" (or only "message")? I agree. > 2) I know that the article name in Simples in Collection is an > optional part of the proposal - but I agree with Mark that using there > again the term "articleName" is bad (too overloaded). What about to > use there a completely different tag, like "elementId"? I think I proposed this alternative as well. I do have a deeper concern, however, and I want to discuss this thoroughly before we make any decisions here. It isn't entirely clear to me that there is a need to throw errors on a specific Simple within a Collection. This is very complicated for me to explain clearly, but I will try... A collection is a "semantic unit" - it is the response to a ***single*** input. As such, it cannot be partially erroneous! It is either entirely erroneous, or entirely correct. To throw an error on a single sub-unit of a collection casts doubt on the validity of the entire collection (since you cannot interpret what the collection would have "looked like" had that error not been thrown) and thus the entire collection must be considered flawed. Imagine it this way: What would it mean to have a Blast report where certain HSP's within the Blast report contained error messages? Does it mean that there was a sequence in the underlying database that was somehow incorrectly formatted If so, then the blast provider should have caught that error and not reported that match at all rather than telling the client that there is a flakey sequence in their database. Does it mean that the software is buggy? If so, then the entire report is potentially flawed, and should not have been produced. Does it mean that (in some way) the input sequence was peculiar? If so, then again the entire output is suspect and not just a single HSP within that output. Do you see what I am getting at? The scenario we are trying to accommodate, in my opinion, is impossible if people are using Collections in the way they are intended to be used. > 3) I would like to have (in the exception API handling) a remark that > the clients are obliged to be aware that a service can also raise an > exception that will be delivered in the SOAP envelope (that is a > standard way). As I said, good clients have to do it anyway (because > your service does not have always full control what to return back) - > so I would keep this option there. Absolutely! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 31 20:10:39 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 31 20:07:33 2005 Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> Message-ID: > It isn't entirely clear to me that there is a need to throw errors on a > specific Simple within a Collection. > I quite like how Mark explained it, and it makes sense to me. I am just not too concerned because this part is just an optional part - so the only "mandatory" part in the API (regarding this issue) will/would be "...and ignore other possibly present attributes in the Simples in a Collection". But still, I am interested to hear David's argumentation againts Mark's explanation. David, do you have a real-life use-case where you expect to create such response? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 20:10:39 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 31 20:07:36 2005 Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> Message-ID: > It isn't entirely clear to me that there is a need to throw errors on a > specific Simple within a Collection. > I quite like how Mark explained it, and it makes sense to me. I am just not too concerned because this part is just an optional part - so the only "mandatory" part in the API (regarding this issue) will/would be "...and ignore other possibly present attributes in the Simples in a Collection". But still, I am interested to hear David's argumentation againts Mark's explanation. David, do you have a real-life use-case where you expect to create such response? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 21:19:25 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 31 21:08:39 2005 Subject: [MOBY-dev] jMoby: problems with Ant under Windows Message-ID: You are a pool of clever and experiences people - would anybody be able to help me to write (actually to fix) the current Ant's build.zml so it works fine also under Windows? I am desperately seeking an advise: 1) The command-line arguments when using target cannot remain empty (under Windows). For example, the command-line: java MosesGenerator -e "" -debug means (under Linux) a command-line with three arguments, but (under windows) a command-line with just two arguments (-e and -debug). Is there a solution for this, at all? 2) The target , when used with rich attributes (like bottom, headre etc.), does not work under windows. First I had to change double quotes into single quotes (okay, Ant should do it, but does not; but it's doable). Second I have to remove newlines from some XML elements - like the 'bottom' one (okay, doable, but annoying, again Any should do it - as it does for unix). But third: the line for javadoc is too long for windows. Well, if you have a windows running, try the current build.xml - try target 'docs' - and you will see what I am talking about, and perhaps you will kniw how to rectiry. Many thanks for your help, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Aug 31 21:24:35 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu Sep 1 01:32:13 2005 Subject: [MOBY-dev] jMoby: problems with Ant under Windows In-Reply-To: Message-ID: <43165859.64ac00f0.3259.3e66@mx.gmail.com> Don't yell at me, but all that windows needed was a good 'clean'ing. Thanks. Ed > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Martin > Senger > Sent: Wednesday, August 31, 2005 6:19 PM > To: Moby Developers > Subject: [MOBY-dev] jMoby: problems with Ant under Windows > > You are a pool of clever and experiences people - would > anybody be able to > help me to write (actually to fix) the current Ant's > build.zml so it works > fine also under Windows? I am desperately seeking an > advise: > > 1) The command-line arguments when using target > cannot remain empty > (under Windows). For example, the command-line: > java MosesGenerator -e "" -debug > means (under Linux) a command-line with three arguments, > but (under > windows) a command-line with just two arguments (-e and - > debug). Is there > a solution for this, at all? > > 2) The target , when used with rich attributes > (like bottom, > headre etc.), does not work under windows. First I had to > change double > quotes into single quotes (okay, Ant should do it, but > does not; but it's > doable). Second I have to remove newlines from some XML > elements - like > the 'bottom' one (okay, doable, but annoying, again Any > should do it - as > it does for unix). But third: the line for javadoc is too > long for > windows. Well, if you have a windows running, try the > current build.xml - > try target 'docs' - and you will see what I am talking > about, and perhaps > you will kniw how to rectiry. > > Many thanks for your help, > Martin > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From hase at umbc.edu Mon Aug 1 23:30:31 2005 From: hase at umbc.edu (HASE) Date: Mon, 1 Aug 2005 23:30:31 -0400 (EDT) Subject: [MOBY-dev] Bioinformatics Software Development Survey Message-ID: <2015.68.49.173.177.1122953431.squirrel@68.49.173.177> Hello, As part of our research at UMBC, we are studying the characteristics of software development in the bioinformatics domain. We believe that this study should be guided by the people who are actively involved in bioinformatics. This research is our first step towards enabling the production of high quality bioinformatics software with less time and effort. Therefore, your feedback is very important to us. We seek your input in the form of a survey questionnaire that will take around 15 minutes of your time. We solicit general demographic information, information about the products that you have developed, your work practices, and your software development process. So, if you are a bioinformatics professional doing software development or a software developer working in the bioinformatics domain, please provide us with your valuable input. We assure you that this information will be used only for academic purposes and will be completely confidential. Please follow the link below to start the survey: http://www.is.umbc.edu/bio-survey/ We appreciate your participation in advance. Regards, HASE (Human Aspects of Software Engineering) 1000 Hilltop Circle Department of Information Systems University of Maryland Baltimore County Baltimore, MD, 21250 hase at umbc.edu From senger at ebi.ac.uk Wed Aug 3 00:23:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 3 Aug 2005 05:23:29 +0100 (BST) Subject: [MOBY-dev] 0.85 codebase running on test server In-Reply-To: <1122672917.19643.31.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, These are good news. Things are moving forwards, that's great. One thing that I missed in your "in the pipelines" section is an implementation of an API giving back URLs of the various RESOURCES. I really needs this soon - so I can code various things using data in RDF (which is much faster than to get things one-by-obe from the registry by the traditional API calls). Would you consider to give it higher priority please? Thanks and regards, Martin -- Martin Senger martin.senger at gmail.com From senger at ebi.ac.uk Wed Aug 3 00:23:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 3 Aug 2005 05:23:29 +0100 (BST) Subject: [MOBY-dev] 0.85 codebase running on test server In-Reply-To: <1122672917.19643.31.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, These are good news. Things are moving forwards, that's great. One thing that I missed in your "in the pipelines" section is an implementation of an API giving back URLs of the various RESOURCES. I really needs this soon - so I can code various things using data in RDF (which is much faster than to get things one-by-obe from the registry by the traditional API calls). Would you consider to give it higher priority please? Thanks and regards, Martin -- Martin Senger martin.senger at gmail.com From markw at illuminae.com Thu Aug 4 05:31:15 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 05:31:15 -0400 Subject: [MOBY-dev] articleName legacy cruft... Message-ID: <1123147875.42f1e06355b9f@webmail.illuminae.com> Hi all, the presence of "articleName" in the Simple/Collection and Secondary tags is really bothering me, given that it is used with a different meaning in the objects (this is legacy cruft that has now become fixed into the code!) It's a fairly significant modification to change this to "componentName"... but I am itching to do it! Given that we are about to break things anyway with the 1.0 release, should we break this at the same time? M From markw at illuminae.com Thu Aug 4 05:38:25 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 05:38:25 -0400 Subject: [MOBY-dev] Changes in the 0.86API Message-ID: <1123148305.42f1e211565c7@webmail.illuminae.com> Hi all, A few changes to announce for the 0.86 API (this is not yet running on the production server): 1) *all* parameters going into a service must now be named (currently using the articleName attribute of the Simple/Collection/Parameter tag, but I want to migrate this to componentName if possible) 2) Inheritence from primitive classes is now forbidden and this is enforced by the MOBY Central code. 3) Collections may now only contain one type of Simple (I don't think anyone uses it any other way, so no worries) 4) a new method "retrieveResourceURLs" has been added to the API that provides you with a list of the URLs from which you can retrieve the RDF versions of all of the ontologies. I will be moving the production server to the new codebase next week sometime. Cheers! M From senger at ebi.ac.uk Thu Aug 4 09:16:57 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 4 Aug 2005 14:16:57 +0100 (BST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: > 1) *all* parameters going into a service must now be named (currently using the > articleName attribute of the Simple/Collection/Parameter tag, but I want to > migrate this to componentName if possible) > Generally it is a good idea (to have things named). I also remember that we had asked for in in Vancouver. But the change, even though may not be big in the code, is big in the documentation, in the API description. I would rather see first an updated API documentation, read it and only then have here a discussion about it. This is mainly we used the name 'article' not only as an XML attribute, but we had/have also an XML tag called 'secondaryArticle', we often speak about 'parameters' (as you just done above) but we mean by that actually all input data... and so on. Other issue is that the biomoby.org now has API086 from the August 3. But it does not have the changes described in your last email - and the email is labeled 'changes in the 0.86' - so you are actually describing changes that will be in 0.87API? I am confused... The normal practice - which I strongly suggest - is to keep on biomoby.org an API which works currently - and to have a separate page, where we can see 'proposed API' - which is not yet implemented, even it is not yet approved by us/developers and it serves for these discussions. I know that it is boring to keep docs updated but that is one of the issues we discussed in V. when we said that the current biomoby does not have enough of the 'project management' :-) Back to article names: I remember that in Malaga the ICN people had talked about their incoming proposal for more decent error handling in biomoby messages. For that, the article names were mandatory (so it is good that we are thinking about it in the same way) - but I think that they wanted to name also individual Simples in Collection. So it may be worth to make sure that they are listening now... > 2) Inheritence from primitive classes is now forbidden and this is enforced by > the MOBY Central code. > Again, this need to be documented first... > 4) a new method "retrieveResourceURLs" has been added to the API that provides > you with a list of the URLs from which you can retrieve the RDF versions of all > of the ontologies. > Here comes my previous email (send only to Mark) about how to make these (BIG) RDF documents compressed. One solution is to allow registry providers to specify two URLs for each resource type, one for normal and one for zipped document. > I will be moving the production server to the new codebase next week sometime. > No, don't do it so soon... Please... Describe it first in the API in details... Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Aug 4 09:16:57 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 4 Aug 2005 14:16:57 +0100 (BST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: > 1) *all* parameters going into a service must now be named (currently using the > articleName attribute of the Simple/Collection/Parameter tag, but I want to > migrate this to componentName if possible) > Generally it is a good idea (to have things named). I also remember that we had asked for in in Vancouver. But the change, even though may not be big in the code, is big in the documentation, in the API description. I would rather see first an updated API documentation, read it and only then have here a discussion about it. This is mainly we used the name 'article' not only as an XML attribute, but we had/have also an XML tag called 'secondaryArticle', we often speak about 'parameters' (as you just done above) but we mean by that actually all input data... and so on. Other issue is that the biomoby.org now has API086 from the August 3. But it does not have the changes described in your last email - and the email is labeled 'changes in the 0.86' - so you are actually describing changes that will be in 0.87API? I am confused... The normal practice - which I strongly suggest - is to keep on biomoby.org an API which works currently - and to have a separate page, where we can see 'proposed API' - which is not yet implemented, even it is not yet approved by us/developers and it serves for these discussions. I know that it is boring to keep docs updated but that is one of the issues we discussed in V. when we said that the current biomoby does not have enough of the 'project management' :-) Back to article names: I remember that in Malaga the ICN people had talked about their incoming proposal for more decent error handling in biomoby messages. For that, the article names were mandatory (so it is good that we are thinking about it in the same way) - but I think that they wanted to name also individual Simples in Collection. So it may be worth to make sure that they are listening now... > 2) Inheritence from primitive classes is now forbidden and this is enforced by > the MOBY Central code. > Again, this need to be documented first... > 4) a new method "retrieveResourceURLs" has been added to the API that provides > you with a list of the URLs from which you can retrieve the RDF versions of all > of the ontologies. > Here comes my previous email (send only to Mark) about how to make these (BIG) RDF documents compressed. One solution is to allow registry providers to specify two URLs for each resource type, one for normal and one for zipped document. > I will be moving the production server to the new codebase next week sometime. > No, don't do it so soon... Please... Describe it first in the API in details... Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From markw at illuminae.com Thu Aug 4 10:11:31 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 10:11:31 -0400 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <1123164691.42f222134a314@webmail.illuminae.com> Quoting Martin Senger : > Generally it is a good idea (to have things named). I also remember > that we had asked for in in Vancouver. But the change, even though may not > be big in the code, is big in the documentation, in the API description. I > would rather see first an updated API documentation, read it and only then > have here a discussion about it. This is mainly we used the name 'article' > not only as an XML attribute, but we had/have also an XML tag called > 'secondaryArticle', we often speak about 'parameters' (as you just done > above) but we mean by that actually all input data... and so on. > Other issue is that the biomoby.org now has API086 from the August > 3. But it does not have the changes described in your last email - and the > email is labeled 'changes in the 0.86' The changes I describe in my email are, in fact (I think??) documented in the 0.86 API that is on the website (see the change history at the bottom of the page), but you are correct that the current production server is not running the 0.86 API - it is running the 0.85 API. I have sent the main developers the endpoint of the instance of MOBY Central that is running the 0.86 codebase so that you can test it and begin the process of coding to it. I share your reservations about changing the articleName (in its "parameter" meaning) to componentName, given that we have many other tags in our XML messaging that use the word "Article" with the same intention. Perhaps it is better to change the MOBY Object articleName attribute to something else instead? That would likely require less changes in our code... One or the other of them really must go because they have two different meanings! > - so you are actually describing > changes that will be in 0.87API? I am confused... The normal practice - > which I strongly suggest - is to keep on biomoby.org an API which works > currently - and to have a separate page, where we can see 'proposed API' - > which is not yet implemented, even it is not yet approved by us/developers > and it serves for these discussions. This is a good idea... I will try to do that right now. I can get a diff of the current API versus the 0.85 API and then set up a second Twiki page from that diff. > I know that it is boring to keep docs > updated but that is one of the issues we discussed in V. when we said that > the current biomoby does not have enough of the 'project management' :-) It's not so much that it is boring (I actually enjoy documentation! What a pedantic nutter I am!), however it is really a matter of limited resourcing and time - it is rare for me to have so much time for coding, and as you have pointed out frequently, MOBY Central is currently a one-man-show for the most part, so when these moments arise I feel obligated to use it to push forward the codebase as far as possible rather than slowly and carefully as I would prefer :-/ I'm trying to keep you and the other core developers updated as to my activities, and I am similarly trying to limit my changes to those that were made in agreement with the attendees at the last meeting (i.e. that we have already discussed as a group), and to respond to those decisions as quickly as possible. Given the ten fingers I have, and the time constraints, that's the best I can manage... > Back to article names: I remember that in Malaga the ICN people had > talked about their incoming proposal for more decent error handling in > biomoby messages. For that, the article names were mandatory (so it is > good that we are thinking about it in the same way) - but I think that > they wanted to name also individual Simples in Collection. So it may be > worth to make sure that they are listening now... Eeek! I don't remember that... Can you recall why this was necessary? > > 2) Inheritence from primitive classes is now forbidden and this is > enforced by > > the MOBY Central code. > > > Again, this need to be documented first... It is, in the 0.86API. > > 4) a new method "retrieveResourceURLs" has been added to the API that > provides > > you with a list of the URLs from which you can retrieve the RDF versions of > all > > of the ontologies. > > > Here comes my previous email (send only to Mark) about how to make > these (BIG) RDF documents compressed. One solution is to allow registry > providers to specify two URLs for each resource type, one for normal and > one for zipped document. I guess the "safe" way to handle that would be to add a "type" attribute to the tag indicaing the MIME type of the document that is behind the URL (yeah... we could get that by calling HEAD, I guess...). It will be important to know this for software that needs to receive an ontology by calling the URL... > > I will be moving the production server to the new codebase next week > sometime. > > > No, don't do it so soon... Please... Describe it first in the API in > details... OK. The code is, however, up and running on the test server that I told you about yesterday. Cheers! M From gordonp at ucalgary.ca Thu Aug 4 10:56:22 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 04 Aug 2005 08:56:22 -0600 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> References: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: <42F22C96.3050106@ucalgary.ca> >2) Inheritence from primitive classes is now forbidden and this is enforced by >the MOBY Central code. > > May I humbly suggest that Boolean be considered primitive? I registered this object last week. >3) Collections may now only contain one type of Simple (I don't think anyone >uses it any other way, so no worries) > > Let me understand this though, if I declare a Collection of Objects, I should still be able to shove anything in there. If I declare a Collection of VirtualSequences, I should be able to put AminoAcidSequences and DNASequences in it. Otherwise we break the operational transparency of inheritence... From gordonp at ucalgary.ca Thu Aug 4 10:56:22 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 04 Aug 2005 08:56:22 -0600 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> References: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: <42F22C96.3050106@ucalgary.ca> >2) Inheritence from primitive classes is now forbidden and this is enforced by >the MOBY Central code. > > May I humbly suggest that Boolean be considered primitive? I registered this object last week. >3) Collections may now only contain one type of Simple (I don't think anyone >uses it any other way, so no worries) > > Let me understand this though, if I declare a Collection of Objects, I should still be able to shove anything in there. If I declare a Collection of VirtualSequences, I should be able to put AminoAcidSequences and DNASequences in it. Otherwise we break the operational transparency of inheritence... From senger at ebi.ac.uk Thu Aug 4 11:47:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 4 Aug 2005 16:47:59 +0100 (BST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123164691.42f222134a314@webmail.illuminae.com> Message-ID: > > Back to article names: I remember that in Malaga the ICN people had > > talked about their incoming proposal for more decent error handling in > > ... > Eeek! I don't remember that... Can you recall why this was necessary? > no, you were not there - it was the last meeting when Eddie and me were involved; perhaps Eddie remembers their suggestion, or to whom contact abou it (afaik they have not sent it yet) > I guess the "safe" way to handle that would be to add a "type" attribute to the > tag indicaing the MIME type of the document that is behind the URL > yes; and to allow returning several tags for the same resource name but with a different type; (Contra my recent advise: could you make it - so I can added it to jmoby :-) ... btw, jMoby already has the current way, without any compression, but I will wait for your reply before committing it tomorrow.) Cheers, Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From ots at ac.uma.es Thu Aug 4 12:03:34 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 4 Aug 2005 18:03:34 +0200 (CEST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: from "Martin Senger" at Aug 04, 2005 04:47:59 PM Message-ID: <200508041603.SAA24534@algarrobo.ac.uma.es> HI, I am sorry, but I am having a nice time near Barcelona and perhaps I have lost some messages. one week ago -more or less- we submitt a short proposal for error-handling The point to be considered is how to inform about an incidence (warning or error) when processing a collection (as a set of simples not as a "unit"). In this case it is necessary to identify each simple. one way is by using the articleName (which could be automatically produced by the client -in the worse case) sds, O. > > > Back to article names: I remember that in Malaga the ICN people had > > > talked about their incoming proposal for more decent error handling in > > > ... > > Eeek! I don't remember that... Can you recall why this was necessary? > > > no, you were not there - it was the last meeting when Eddie and me were > involved; perhaps Eddie remembers their suggestion, or to whom contact > abou it (afaik they have not sent it yet) > > > I guess the "safe" way to handle that would be to add a "type" attribute to the > > tag indicaing the MIME type of the document that is behind the URL > > > yes; and to allow returning several tags for the same > resource name but with a different type; > (Contra my recent advise: could you make it - so I can added it to > jmoby :-) ... btw, jMoby already has the current way, without any > compression, but I will wait for your reply before committing it > tomorrow.) > > Cheers, > Martin > > -- > Martin Senger martin.senger at gmail.com > > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Thu Aug 4 12:03:34 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 4 Aug 2005 18:03:34 +0200 (CEST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: from "Martin Senger" at Aug 04, 2005 04:47:59 PM Message-ID: <200508041603.SAA24534@algarrobo.ac.uma.es> HI, I am sorry, but I am having a nice time near Barcelona and perhaps I have lost some messages. one week ago -more or less- we submitt a short proposal for error-handling The point to be considered is how to inform about an incidence (warning or error) when processing a collection (as a set of simples not as a "unit"). In this case it is necessary to identify each simple. one way is by using the articleName (which could be automatically produced by the client -in the worse case) sds, O. > > > Back to article names: I remember that in Malaga the ICN people had > > > talked about their incoming proposal for more decent error handling in > > > ... > > Eeek! I don't remember that... Can you recall why this was necessary? > > > no, you were not there - it was the last meeting when Eddie and me were > involved; perhaps Eddie remembers their suggestion, or to whom contact > abou it (afaik they have not sent it yet) > > > I guess the "safe" way to handle that would be to add a "type" attribute to the > > tag indicaing the MIME type of the document that is behind the URL > > > yes; and to allow returning several tags for the same > resource name but with a different type; > (Contra my recent advise: could you make it - so I can added it to > jmoby :-) ... btw, jMoby already has the current way, without any > compression, but I will wait for your reply before committing it > tomorrow.) > > Cheers, > Martin > > -- > Martin Senger martin.senger at gmail.com > > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From jmrc at cnb.uam.es Thu Aug 4 12:28:34 2005 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Thu, 04 Aug 2005 18:28:34 +0200 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <42F24232.30207@cnb.uam.es> Martin Senger wrote: > Back to article names: I remember that in Malaga the_ ICN people_ had >talked about their incoming proposal for more decent error handling in >biomoby messages. For that, the article names were mandatory (so it is >good that we are thinking about it in the same way) - but I think that >they wanted to name also individual Simples in Collection. So it may be >worth to make sure that they are listening now... > > > Sorry Martin, but we are *INB* people! :-) http://www.inab.org Cheers, Jos? Manuel. From jmrc at cnb.uam.es Thu Aug 4 12:28:34 2005 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Thu, 04 Aug 2005 18:28:34 +0200 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <42F24232.30207@cnb.uam.es> Martin Senger wrote: > Back to article names: I remember that in Malaga the_ ICN people_ had >talked about their incoming proposal for more decent error handling in >biomoby messages. For that, the article names were mandatory (so it is >good that we are thinking about it in the same way) - but I think that >they wanted to name also individual Simples in Collection. So it may be >worth to make sure that they are listening now... > > > Sorry Martin, but we are *INB* people! :-) http://www.inab.org Cheers, Jos? Manuel. From jmfernandez at cnb.uam.es Fri Aug 5 15:10:00 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri, 05 Aug 2005 21:10:00 +0200 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY Message-ID: <42F3B988.7020506@cnb.uam.es> Hi everybody, I don't like crossposting, but I don't know if the bug I have found today is from the Taverna 1.2 core or the MOBY plugin. The bug is pretty simple: if you create/load a workflow which has a service whose name in the workflow is different from the service name, Taverna does not use the official service name when it is invoked. Instead, it uses the name given to the service in the workflow! The same workflow works flawlessly when it is loaded and run in Taverna 1.1. I have discovered the bug with a MOBY service (see the sample workflow ja5.xml, and the reports taverna-1.1-report.xml and taverna-1.2-report.xml), so I don't know which has the blame... This bug should arise when one service is used more than once, which is very common in real workflows! Best Regards, Jos? Mar?a Fern?ndez -- 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: ja5.xml Type: text/xml Size: 1813 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050805/8e5996c3/ja5-0002.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: taverna-1.1-report.xml Type: text/xml Size: 1796 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050805/8e5996c3/taverna-1.1-report-0002.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: taverna-1.2-report.xml Type: text/xml Size: 4405 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050805/8e5996c3/taverna-1.2-report-0002.xml From senger at ebi.ac.uk Sun Aug 7 19:47:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 8 Aug 2005 00:47:58 +0100 (BST) Subject: [MOBY-dev] jMoby updated Message-ID: Two new methods were added to the Central.java interface: * getResourceRefs() returns a list of URLs of available resources of a BioMoby registry (a "resource" is an RDF document describing registered entities), and * getResource() returns contents of a particular resource The implementation (in CentralImpl.java) seems to work now - but it may be slightly changed later when Mark adds possibility to fetch resources also in a compressed form. The new methods are also reflected in the main jMoby command line client - type 'build/run/run-cmdline-client -help'. I have also updated the 'Acknowledgements' section in the main jMoby page (http://www.biomoby.org/moby-live/Java/docs/index.html). Please feel free to add there your own funding sources. With regards, Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Mon Aug 8 09:42:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 8 Aug 2005 06:42:55 -0700 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F3B988.7020506@cnb.uam.es> Message-ID: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Hi, I think that that has been fixed. I actually noticed that bug when using the Planet workflows. So, like I said, it should be fixed. Out of curiosity, did you cvs build or download a prepackaged Taverna? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Friday, August 05, 2005 12:10 PM > To: taverna-users at lists.sourceforge.net; moby- > l at biomoby.org; mobydev; taverna- > hackers at lists.sourceforge.net > Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related > to BioMOBY > > Hi everybody, > I don't like crossposting, but I don't know if the > bug I have found > today is from the Taverna 1.2 core or the MOBY plugin. > > The bug is pretty simple: if you create/load a > workflow which has a > service whose name in the workflow is different from the > service name, > Taverna does not use the official service name when it is > invoked. > Instead, it uses the name given to the service in the > workflow! The same > workflow works flawlessly when it is loaded and run in > Taverna 1.1. > > I have discovered the bug with a MOBY service (see > the sample workflow > ja5.xml, and the reports taverna-1.1-report.xml and > taverna-1.2-report.xml), so I don't know which has the > blame... > > This bug should arise when one service is used more > than once, which is > very common in real workflows! > > Best Regards, > Jos? Mar?a Fern?ndez > -- > 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 edward.kawas at gmail.com Mon Aug 8 09:42:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 8 Aug 2005 06:42:55 -0700 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F3B988.7020506@cnb.uam.es> Message-ID: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Hi, I think that that has been fixed. I actually noticed that bug when using the Planet workflows. So, like I said, it should be fixed. Out of curiosity, did you cvs build or download a prepackaged Taverna? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Friday, August 05, 2005 12:10 PM > To: taverna-users at lists.sourceforge.net; moby- > l at biomoby.org; mobydev; taverna- > hackers at lists.sourceforge.net > Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related > to BioMOBY > > Hi everybody, > I don't like crossposting, but I don't know if the > bug I have found > today is from the Taverna 1.2 core or the MOBY plugin. > > The bug is pretty simple: if you create/load a > workflow which has a > service whose name in the workflow is different from the > service name, > Taverna does not use the official service name when it is > invoked. > Instead, it uses the name given to the service in the > workflow! The same > workflow works flawlessly when it is loaded and run in > Taverna 1.1. > > I have discovered the bug with a MOBY service (see > the sample workflow > ja5.xml, and the reports taverna-1.1-report.xml and > taverna-1.2-report.xml), so I don't know which has the > blame... > > This bug should arise when one service is used more > than once, which is > very common in real workflows! > > Best Regards, > Jos? Mar?a Fern?ndez > -- > 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 jmfernandez at cnb.uam.es Mon Aug 8 10:52:35 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon, 08 Aug 2005 16:52:35 +0200 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42f76179.195ac951.0c6c.100f@mx.gmail.com> References: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Message-ID: <42F771B3.8010600@cnb.uam.es> Hi Eddie, Edward Kawas wrote: > Hi, > > I think that that has been fixed. I actually noticed that > bug when using the Planet workflows. So, like I said, it > should be fixed. > Yes, Tom told me that on Friday. I was looking at CVS and as you have said, it seems it is fixed there. > Out of curiosity, did you cvs build or download a > prepackaged Taverna? > As you can imagine, I was working on a prepackaged Taverna 1.2 version :-(. We are working behind a firewall, and I was digging as an user how much functionality related to MOBY in Taverna 1.2 was affected by that fact. I realized that problem when I did a worflow with two branches, both branches with the same service and one of them had to be renamed. What I have seen is that object instances generated from the new object tree in BioMOBY scavenger use information from http://biomoby.org/RESOURCES/MOBY-S/Objects so those workflow branches with any of those object instantes stalled just inside them. I was digging on that URL, and I saw that all the rdf:about attributes (plus others, like rdf:resource in http://biomoby.org/RESOURCES/MOBY-S/Services) were referencing your Tomcat server at mobycentral.icapture.ubc.ca:8090. Is there some progress on MOBY Apache server with ProxyPass/ProxyPassReverse? Best Regards, 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 edward.kawas at gmail.com Mon Aug 8 10:54:20 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 8 Aug 2005 07:54:20 -0700 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F771B3.8010600@cnb.uam.es> Message-ID: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> Actually, give it a try now. It should work as Mark tweeked it! Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Monday, August 08, 2005 7:53 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] A bug in Taverna 1.2 perhaps > related to BioMOBY > > Hi Eddie, > > Edward Kawas wrote: > > Hi, > > > > I think that that has been fixed. I actually noticed > that > > bug when using the Planet workflows. So, like I said, it > > should be fixed. > > > > Yes, Tom told me that on Friday. I was looking at CVS and > as you have > said, it seems it is fixed there. > > > Out of curiosity, did you cvs build or download a > > prepackaged Taverna? > > > > As you can imagine, I was working on a prepackaged Taverna > 1.2 version > :-(. We are working behind a firewall, and I was digging > as an user how > much functionality related to MOBY in Taverna 1.2 was > affected by that > fact. I realized that problem when I did a worflow with > two branches, > both branches with the same service and one of them had to > be renamed. > > What I have seen is that object instances generated > from the new object > tree in BioMOBY scavenger use information from > > http://biomoby.org/RESOURCES/MOBY-S/Objects > > so those workflow branches with any of those object > instantes stalled > just inside them. I was digging on that URL, and I saw > that all the > rdf:about attributes (plus others, like rdf:resource in > http://biomoby.org/RESOURCES/MOBY-S/Services) were > referencing your > Tomcat server at mobycentral.icapture.ubc.ca:8090. Is > there some > progress on MOBY Apache server with > ProxyPass/ProxyPassReverse? > > Best Regards, > 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 Aug 8 11:52:46 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Mon, 8 Aug 2005 11:52:46 -0400 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> References: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> Message-ID: <1123516366.42f77fceb1a8f@webmail.illuminae.com> Quoting Edward Kawas : > Actually, give it a try now. It should work as Mark tweeked > it! > > Tomcat server at mobycentral.icapture.ubc.ca:8090. Is > > there some progress on MOBY Apache server with > > ProxyPass/ProxyPassReverse? Yes, I made those changes a few days ago. Please let me know ASAP if they aren't solving the problem. Greetings from (and goodbye to) Manchester! I'll be back in Vancouver on Wednesday. M From senger at ebi.ac.uk Wed Aug 10 21:10:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 11 Aug 2005 02:10:31 +0100 (BST) Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: This question is meant primarily for Java-based biomoby services, but a suggestion from Perl people can help me as well. I wonder what are the general rules for handling errors in biomoby services. The API is silent about it, and the only thing I remember from the discussions is that if there is an error the service will return an empty output object (still, of course, wrapped in a biomoby XML envelope). Is this really the only way how to handle all kinds of errors? I understand that this behaviour is reasonable when my input data does not produce any result (wrong id, non-existing id, etc.). But should I use the same mechanism for things like: * the input data does not come as String or base64 type, * the input XML does not conform to the Biomoby API, * my service cannot respond because of some limited internal resources, * etc. Any advise how you deal with these situations will be appreciated, and I thank you very much. With regards, Martin PS. Of course, you noticed that in my main email body above I have not mentioned how dissapointing the Biomoby API is if it does not deal with error handling :-) M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 12 15:38:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 12 Aug 2005 12:38:43 -0700 Subject: [MOBY-dev] lease versus agent for registry updating Message-ID: <1123875523.15335.19.camel@bioinfo.icapture.ubc.ca> Hi all! Eddie and I are spending the day working on MOBY Central architecture issues. We've run into a question that has so many pros and cons that we decided to toss it out to the list for other opinions. Keeping MOBY Central up-to-date: Method 1: Agent An agent retrieves the list of SignatureURL's from the registry, and crawls around retrieving the RDF from each of those URLs. The RDF is compared to what is in the registry, and updates/deletions are made. Consequence to service provider: a service providers machine goes down, the service is deregistered (the agent can't retrieve the URL) and the service provider must then actively re-register their services Method 2: Lease Services have a time-stamp in the registry and expire after X time. They must then be actively re-registered. Consequence to service provider: Service providers must set up a cron (or whatever) that is aware of all of their *current* Signature URL's and can call MOBY Central to re-register their services on a regular basis. Both solutions seem to put an unwanted burden on the service providers, but the burdens are different in nature and frequency. Which of these seems preferable? Are there solutions we haven't thought of? ??? Mark & Eddie -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From boris.steipe at utoronto.ca Fri Aug 12 15:50:50 2005 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Fri, 12 Aug 2005 16:50:50 -0300 Subject: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123875523.15335.19.camel@bioinfo.icapture.ubc.ca> Message-ID: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Why not put the burden of the lease on the agent to combine the advantages of both models? I.e. if service is down for less then a specific time, it might not get deregistered but only flagged as temporarily unavailable ... then un-flagged as it comes up again, except if it's down for, say > 1week, then it gets deregistered. $0.02 Boris On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > Hi all! > > Eddie and I are spending the day working on MOBY Central architecture > issues. We've run into a question that has so many pros and cons that > we decided to toss it out to the list for other opinions. > > Keeping MOBY Central up-to-date: > > Method 1: Agent > > An agent retrieves the list of SignatureURL's from the registry, and > crawls around retrieving the RDF from each of those URLs. The RDF is > compared to what is in the registry, and updates/deletions are made. > > Consequence to service provider: a service providers machine goes down, > the service is deregistered (the agent can't retrieve the URL) and the > service provider must then actively re-register their services > > > Method 2: Lease > > Services have a time-stamp in the registry and expire after X time. > They must then be actively re-registered. > > Consequence to service provider: Service providers must set up a cron > (or whatever) that is aware of all of their *current* Signature URL's > and can call MOBY Central to re-register their services on a regular > basis. > > > Both solutions seem to put an unwanted burden on the service providers, > but the burdens are different in nature and frequency. > > Which of these seems preferable? Are there solutions we haven't > thought > of? > > ??? > > Mark & Eddie > > > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri Aug 12 15:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 12 Aug 2005 12:57:02 -0700 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Message-ID: <1123876622.15335.25.camel@bioinfo.icapture.ubc.ca> Hi Boris! Thanks for the rapid reply! That is how we had initially planned to do it as well, however the consequence is that the registry (a) has to have a mechanism for recording the number of failure occurrences, and this might be handled differently by different underlying data stores, and (b) the registry KNOWS that it contains service instances that are likely non-functional but still reports them as being functional. ... Eddie just suggested an alternative to this alternative :-) The agent can deregister services that fail the URL lookup, but still retain the URL and try them a few more times just in case they come back up again. That way the registry is always reflecting the *best* information it can possibly know, but the burden of re-registering services still falls on the Registry as much as possible. That might be the way to go... Other opinions? M On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > Why not put the burden of the lease on the agent to combine the > advantages of both models? I.e. if service is down for less then a > specific time, it might not get deregistered but only flagged as > temporarily unavailable ... then un-flagged as it comes up again, > except if it's down for, say > 1week, then it gets deregistered. > > $0.02 > > Boris > > On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > > > Hi all! > > > > Eddie and I are spending the day working on MOBY Central architecture > > issues. We've run into a question that has so many pros and cons that > > we decided to toss it out to the list for other opinions. > > > > Keeping MOBY Central up-to-date: > > > > Method 1: Agent > > > > An agent retrieves the list of SignatureURL's from the registry, and > > crawls around retrieving the RDF from each of those URLs. The RDF is > > compared to what is in the registry, and updates/deletions are made. > > > > Consequence to service provider: a service providers machine goes down, > > the service is deregistered (the agent can't retrieve the URL) and the > > service provider must then actively re-register their services > > > > > > Method 2: Lease > > > > Services have a time-stamp in the registry and expire after X time. > > They must then be actively re-registered. > > > > Consequence to service provider: Service providers must set up a cron > > (or whatever) that is aware of all of their *current* Signature URL's > > and can call MOBY Central to re-register their services on a regular > > basis. > > > > > > Both solutions seem to put an unwanted burden on the service providers, > > but the burdens are different in nature and frequency. > > > > Which of these seems preferable? Are there solutions we haven't > > thought > > of? > > > > ??? > > > > Mark & Eddie > > > > > > -- > > "Ontologists do it with the edges!" > > > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > _______________________________________________ > > 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 -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From boris.steipe at utoronto.ca Fri Aug 12 16:04:34 2005 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Fri, 12 Aug 2005 17:04:34 -0300 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123876622.15335.25.camel@bioinfo.icapture.ubc.ca> Message-ID: <4D6827FD-0B6C-11DA-A8DF-000A9577512E@utoronto.ca> On Friday, Aug 12, 2005, at 16:57 Canada/Atlantic, Mark Wilkinson wrote: > The > agent can deregister services that fail the URL lookup, but still > retain > the URL and try them a few more times just in case they come back up > again. That way the registry is always reflecting the *best* > information it can possibly know, but the burden of re-registering > services still falls on the Registry as much as possible. If the agent then automatically re-registers when it succeeds, that's what I just said. (I think.) (Except you went like *this* (gestures handwave to the side, sort of)). :-) B. From markw at illuminae.com Fri Aug 12 16:41:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 12 Aug 2005 13:41:35 -0700 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Message-ID: <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> Ah... I missed the bit about a service being flagged as "temporarily unavailable" rather than just flagged in general. The reason we are loathe to do that is it makes assumptions about the underlying data store being able to capture that information (or at least, forces queries on the underlying data store to then be passed through a post- retrieval "available" filter implemented by the data adaptor)... We're trying to make as few assumptions about the underlying store as possible - a minimum of information about the core functionality of a service (i.e. at this point, the overlap between the MOBY and the Feta data models) M On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > Why not put the burden of the lease on the agent to combine the > advantages of both models? I.e. if service is down for less then a > specific time, it might not get deregistered but only flagged as > temporarily unavailable ... then un-flagged as it comes up again, > except if it's down for, say > 1week, then it gets deregistered. > > $0.02 > > Boris > > On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > > > Hi all! > > > > Eddie and I are spending the day working on MOBY Central architecture > > issues. We've run into a question that has so many pros and cons that > > we decided to toss it out to the list for other opinions. > > > > Keeping MOBY Central up-to-date: > > > > Method 1: Agent > > > > An agent retrieves the list of SignatureURL's from the registry, and > > crawls around retrieving the RDF from each of those URLs. The RDF is > > compared to what is in the registry, and updates/deletions are made. > > > > Consequence to service provider: a service providers machine goes down, > > the service is deregistered (the agent can't retrieve the URL) and the > > service provider must then actively re-register their services > > > > > > Method 2: Lease > > > > Services have a time-stamp in the registry and expire after X time. > > They must then be actively re-registered. > > > > Consequence to service provider: Service providers must set up a cron > > (or whatever) that is aware of all of their *current* Signature URL's > > and can call MOBY Central to re-register their services on a regular > > basis. > > > > > > Both solutions seem to put an unwanted burden on the service providers, > > but the burdens are different in nature and frequency. > > > > Which of these seems preferable? Are there solutions we haven't > > thought > > of? > > > > ??? > > > > Mark & Eddie > > > > > > -- > > "Ontologists do it with the edges!" > > > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From gordonp at ucalgary.ca Fri Aug 12 17:23:46 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 12 Aug 2005 15:23:46 -0600 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> Message-ID: <42FD1362.8000107@ucalgary.ca> I would go for the server polling the RDFs option. In that way, there could potentially be more than one MOBY Central (e.g. private ones) that could simply get the provider RDF URL list from the "Master" MOBY Central, and replicate the service registry (in whatever underlying data store they like). Decentralizing is good. >Ah... I missed the bit about a service being flagged as "temporarily >unavailable" rather than just flagged in general. The reason we are >loathe to do that is it makes assumptions about the underlying data >store being able to capture that information (or at least, forces >queries on the underlying data store to then be passed through a post- >retrieval "available" filter implemented by the data adaptor)... > >We're trying to make as few assumptions about the underlying store as >possible - a minimum of information about the core functionality of a >service (i.e. at this point, the overlap between the MOBY and the Feta >data models) > >M > > >On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > > >>Why not put the burden of the lease on the agent to combine the >>advantages of both models? I.e. if service is down for less then a >>specific time, it might not get deregistered but only flagged as >>temporarily unavailable ... then un-flagged as it comes up again, >>except if it's down for, say > 1week, then it gets deregistered. >> >>$0.02 >> >>Boris >> >>On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: >> >> >> >>>Hi all! >>> >>>Eddie and I are spending the day working on MOBY Central architecture >>>issues. We've run into a question that has so many pros and cons that >>>we decided to toss it out to the list for other opinions. >>> >>>Keeping MOBY Central up-to-date: >>> >>>Method 1: Agent >>> >>>An agent retrieves the list of SignatureURL's from the registry, and >>>crawls around retrieving the RDF from each of those URLs. The RDF is >>>compared to what is in the registry, and updates/deletions are made. >>> >>>Consequence to service provider: a service providers machine goes down, >>>the service is deregistered (the agent can't retrieve the URL) and the >>>service provider must then actively re-register their services >>> >>> >>>Method 2: Lease >>> >>>Services have a time-stamp in the registry and expire after X time. >>>They must then be actively re-registered. >>> >>>Consequence to service provider: Service providers must set up a cron >>>(or whatever) that is aware of all of their *current* Signature URL's >>>and can call MOBY Central to re-register their services on a regular >>>basis. >>> >>> >>>Both solutions seem to put an unwanted burden on the service providers, >>>but the burdens are different in nature and frequency. >>> >>>Which of these seems preferable? Are there solutions we haven't >>>thought >>>of? >>> >>>??? >>> >>>Mark & Eddie >>> >>> >>>-- >>>"Ontologists do it with the edges!" >>> >>>Mark Wilkinson >>>Asst. Professor >>>Dept. of Medical Genetics >>>University of British Columbia >>>PI in Bioinformatics >>>iCAPTURE Centre >>>St. Paul's Hospital >>>Rm. 166, 1081 Burrard St. >>>Vancouver, BC, V6Z 1Y6 >>>tel: 604 682 2344 x62129 >>>fax: 604 806 9274 >>> >>>_______________________________________________ >>>MOBY-dev mailing list >>>MOBY-dev at biomoby.org >>>http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> From markw at illuminae.com Fri Aug 12 18:18:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 12 Aug 2005 15:18:30 -0700 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <42FD1362.8000107@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> Message-ID: <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> We're certainly of like-mind at this end, though certain people ;-) at myGrid think that the agent is the wrong way to go... I just don't see it. IMO a leasing model would be akin to leasing space in Google! Anyway, we'll leave the question open for a couple of days and see if any more optimal solutions come up. M On Fri, 2005-08-12 at 15:23 -0600, Paul Gordon wrote: > I would go for the server polling the RDFs option. In that way, there > could potentially be more than one MOBY Central (e.g. private ones) that > could simply get the provider RDF URL list from the "Master" MOBY > Central, and replicate the service registry (in whatever underlying data > store they like). Decentralizing is good. > > > >Ah... I missed the bit about a service being flagged as "temporarily > >unavailable" rather than just flagged in general. The reason we are > >loathe to do that is it makes assumptions about the underlying data > >store being able to capture that information (or at least, forces > >queries on the underlying data store to then be passed through a post- > >retrieval "available" filter implemented by the data adaptor)... > > > >We're trying to make as few assumptions about the underlying store as > >possible - a minimum of information about the core functionality of a > >service (i.e. at this point, the overlap between the MOBY and the Feta > >data models) > > > >M > > > > > >On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > > > > > >>Why not put the burden of the lease on the agent to combine the > >>advantages of both models? I.e. if service is down for less then a > >>specific time, it might not get deregistered but only flagged as > >>temporarily unavailable ... then un-flagged as it comes up again, > >>except if it's down for, say > 1week, then it gets deregistered. > >> > >>$0.02 > >> > >>Boris > >> > >>On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > >> > >> > >> > >>>Hi all! > >>> > >>>Eddie and I are spending the day working on MOBY Central architecture > >>>issues. We've run into a question that has so many pros and cons that > >>>we decided to toss it out to the list for other opinions. > >>> > >>>Keeping MOBY Central up-to-date: > >>> > >>>Method 1: Agent > >>> > >>>An agent retrieves the list of SignatureURL's from the registry, and > >>>crawls around retrieving the RDF from each of those URLs. The RDF is > >>>compared to what is in the registry, and updates/deletions are made. > >>> > >>>Consequence to service provider: a service providers machine goes down, > >>>the service is deregistered (the agent can't retrieve the URL) and the > >>>service provider must then actively re-register their services > >>> > >>> > >>>Method 2: Lease > >>> > >>>Services have a time-stamp in the registry and expire after X time. > >>>They must then be actively re-registered. > >>> > >>>Consequence to service provider: Service providers must set up a cron > >>>(or whatever) that is aware of all of their *current* Signature URL's > >>>and can call MOBY Central to re-register their services on a regular > >>>basis. > >>> > >>> > >>>Both solutions seem to put an unwanted burden on the service providers, > >>>but the burdens are different in nature and frequency. > >>> > >>>Which of these seems preferable? Are there solutions we haven't > >>>thought > >>>of? > >>> > >>>??? > >>> > >>>Mark & Eddie > >>> > >>> > >>>-- > >>>"Ontologists do it with the edges!" > >>> > >>>Mark Wilkinson > >>>Asst. Professor > >>>Dept. of Medical Genetics > >>>University of British Columbia > >>>PI in Bioinformatics > >>>iCAPTURE Centre > >>>St. Paul's Hospital > >>>Rm. 166, 1081 Burrard St. > >>>Vancouver, BC, V6Z 1Y6 > >>>tel: 604 682 2344 x62129 > >>>fax: 604 806 9274 > >>> > >>>_______________________________________________ > >>>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 -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From ots at ac.uma.es Thu Aug 11 06:05:23 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 11 Aug 2005 12:05:23 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: Message-ID: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Dear all, We sent a message (July 25) regarding error handling. I am not sure weather the message is in your hands, thus I am re-sending it for discussion. best regards Oswaldo -------------- ----- Original Message ----- From: "Oswaldo Trelles" To: "Eddie Kawas" Sent: Monday, July 25, 2005 6:43 PM Subject: Error handling proposal > Eddie, could you please circulate this message and made the document > available following your protocol? > thanks in advance > Oswaldo > > Please let me introduce myself. My name is Oswaldo Trelles and I work at the > Computer architecture Department of the University of Malaga, Spain (where > all of you are invited and welcomed). Our group is in charge of the > "Integrated Bioinformatics" aspects at the INB (National Institute of > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > meeting we are developing an integrated platform to deploy general and > specific services using BioMOBY as the underlying protocol. > > Thus we are quite concerned with BM specifications and we would like to > contribute in the development, extension and improvements in the protocol. > At this moment Roman has made a preliminary version and description of > Theseu project available. Now we would like to put over the table the error > handling issue. We have prepared a document, which represent an extension of > our current implementation. This proposal was discussed during the > INB-meeting here in Malaga (July 2005) and now is distributed as an open > document for further discussion. > > Please feel free to comment. > > best regards, Oswaldo + GNV5 team + INB team ----- Original Message ----- From: "Martin Senger" To: "Moby Developers" Sent: Thursday, August 11, 2005 3:10 AM Subject: [MOBY-dev] how to handle errors in a biomoby service? > This question is meant primarily for Java-based biomoby services, but a > suggestion from Perl people can help me as well. > > I wonder what are the general rules for handling errors in biomoby > services. The API is silent about it, and the only thing I remember from > the discussions is that if there is an error the service will return an > empty output object (still, of course, wrapped in a biomoby XML > envelope). Is this really the only way how to handle all kinds of > errors? > > I understand that this behaviour is reasonable when my input data does not > produce any result (wrong id, non-existing id, etc.). But should I use the > same mechanism for things like: > * the input data does not come as String or base64 type, > * the input XML does not conform to the Biomoby API, > * my service cannot respond because of some limited internal resources, > * etc. > > Any advise how you deal with these situations will be appreciated, and I > thank you very much. > > With regards, > Martin > > PS. Of course, you noticed that in my main email body above I have not > mentioned how dissapointing the Biomoby API is if it does not deal with > error handling :-) > > M. > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: 0509GNV5-ErrorHandling-v034distributed.pdf Type: application/pdf Size: 338293 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050811/ec6846b9/0509GNV5-ErrorHandling-v034distributed-0004.pdf From ots at ac.uma.es Thu Aug 11 06:05:23 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 11 Aug 2005 12:05:23 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: Message-ID: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Dear all, We sent a message (July 25) regarding error handling. I am not sure weather the message is in your hands, thus I am re-sending it for discussion. best regards Oswaldo -------------- ----- Original Message ----- From: "Oswaldo Trelles" To: "Eddie Kawas" Sent: Monday, July 25, 2005 6:43 PM Subject: Error handling proposal > Eddie, could you please circulate this message and made the document > available following your protocol? > thanks in advance > Oswaldo > > Please let me introduce myself. My name is Oswaldo Trelles and I work at the > Computer architecture Department of the University of Malaga, Spain (where > all of you are invited and welcomed). Our group is in charge of the > "Integrated Bioinformatics" aspects at the INB (National Institute of > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > meeting we are developing an integrated platform to deploy general and > specific services using BioMOBY as the underlying protocol. > > Thus we are quite concerned with BM specifications and we would like to > contribute in the development, extension and improvements in the protocol. > At this moment Roman has made a preliminary version and description of > Theseu project available. Now we would like to put over the table the error > handling issue. We have prepared a document, which represent an extension of > our current implementation. This proposal was discussed during the > INB-meeting here in Malaga (July 2005) and now is distributed as an open > document for further discussion. > > Please feel free to comment. > > best regards, Oswaldo + GNV5 team + INB team ----- Original Message ----- From: "Martin Senger" To: "Moby Developers" Sent: Thursday, August 11, 2005 3:10 AM Subject: [MOBY-dev] how to handle errors in a biomoby service? > This question is meant primarily for Java-based biomoby services, but a > suggestion from Perl people can help me as well. > > I wonder what are the general rules for handling errors in biomoby > services. The API is silent about it, and the only thing I remember from > the discussions is that if there is an error the service will return an > empty output object (still, of course, wrapped in a biomoby XML > envelope). Is this really the only way how to handle all kinds of > errors? > > I understand that this behaviour is reasonable when my input data does not > produce any result (wrong id, non-existing id, etc.). But should I use the > same mechanism for things like: > * the input data does not come as String or base64 type, > * the input XML does not conform to the Biomoby API, > * my service cannot respond because of some limited internal resources, > * etc. > > Any advise how you deal with these situations will be appreciated, and I > thank you very much. > > With regards, > Martin > > PS. Of course, you noticed that in my main email body above I have not > mentioned how dissapointing the Biomoby API is if it does not deal with > error handling :-) > > M. > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: 0509GNV5-ErrorHandling-v034distributed.pdf Type: application/pdf Size: 338293 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050811/ec6846b9/0509GNV5-ErrorHandling-v034distributed-0005.pdf From edward.kawas at gmail.com Mon Aug 15 21:26:04 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Mon, 15 Aug 2005 20:26:04 -0500 Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Hi Oswaldo, Do you think that you could repost it to the list? Thanks, Eddie On 8/11/05, Oswaldo Trelles wrote: > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > From edward.kawas at gmail.com Mon Aug 15 21:26:04 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Mon, 15 Aug 2005 20:26:04 -0500 Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Hi Oswaldo, Do you think that you could repost it to the list? Thanks, Eddie On 8/11/05, Oswaldo Trelles wrote: > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > 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 ots at ac.uma.es Tue Aug 16 05:27:02 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue, 16 Aug 2005 11:27:02 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: <000d01c5a244$aa5b8e90$346dd696@ac.uma.es> ----- Original Message ----- From: "Oswaldo Trelles" To: "Core developer announcements" ; "Moby Developers" Sent: Thursday, August 11, 2005 12:05 PM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Tue Aug 16 05:27:02 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue, 16 Aug 2005 11:27:02 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: <000d01c5a244$aa5b8e90$346dd696@ac.uma.es> ----- Original Message ----- From: "Oswaldo Trelles" To: "Core developer announcements" ; "Moby Developers" Sent: Thursday, August 11, 2005 12:05 PM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Tue Aug 16 05:32:40 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue, 16 Aug 2005 11:32:40 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <007d01c5a245$726a2810$346dd696@ac.uma.es> Hi Eddie, OK I have posted again the message regards, O. ----- Original Message ----- From: "Eddie Kawas" To: "Core developer announcements" Cc: "Moby Developers" Sent: Tuesday, August 16, 2005 3:26 AM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Hi Oswaldo, > > Do you think that you could repost it to the list? > > Thanks, > > Eddie > > On 8/11/05, Oswaldo Trelles wrote: > > Dear all, > > > > We sent a message (July 25) regarding error handling. I am not sure weather > > the message is in your hands, thus I am re-sending it for discussion. > > > > best regards > > > > Oswaldo > > > > > > > > > > > > -------------- > > > > > > ----- Original Message ----- > > From: "Oswaldo Trelles" > > To: "Eddie Kawas" > > Sent: Monday, July 25, 2005 6:43 PM > > Subject: Error handling proposal > > > > > > > Eddie, could you please circulate this message and made the document > > > available following your protocol? > > > thanks in advance > > > Oswaldo > > > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > > the > > > Computer architecture Department of the University of Malaga, Spain (where > > > all of you are invited and welcomed). Our group is in charge of the > > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > > meeting we are developing an integrated platform to deploy general and > > > specific services using BioMOBY as the underlying protocol. > > > > > > Thus we are quite concerned with BM specifications and we would like to > > > contribute in the development, extension and improvements in the protocol. > > > At this moment Roman has made a preliminary version and description of > > > Theseu project available. Now we would like to put over the table the > > error > > > handling issue. We have prepared a document, which represent an extension > > of > > > our current implementation. This proposal was discussed during the > > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > > document for further discussion. > > > > > > Please feel free to comment. > > > > > > best regards, Oswaldo + GNV5 team + INB team > > > > > > ----- Original Message ----- > > From: "Martin Senger" > > To: "Moby Developers" > > Sent: Thursday, August 11, 2005 3:10 AM > > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > > > > This question is meant primarily for Java-based biomoby services, but a > > > suggestion from Perl people can help me as well. > > > > > > I wonder what are the general rules for handling errors in biomoby > > > services. The API is silent about it, and the only thing I remember from > > > the discussions is that if there is an error the service will return an > > > empty output object (still, of course, wrapped in a biomoby XML > > > envelope). Is this really the only way how to handle all kinds of > > > errors? > > > > > > I understand that this behaviour is reasonable when my input data does not > > > produce any result (wrong id, non-existing id, etc.). But should I use the > > > same mechanism for things like: > > > * the input data does not come as String or base64 type, > > > * the input XML does not conform to the Biomoby API, > > > * my service cannot respond because of some limited internal resources, > > > * etc. > > > > > > Any advise how you deal with these situations will be appreciated, and I > > > thank you very much. > > > > > > With regards, > > > Martin > > > > > > PS. Of course, you noticed that in my main email body above I have not > > > mentioned how dissapointing the Biomoby API is if it does not deal with > > > error handling :-) > > > > > > M. > > > > > > > > > -- > > > Martin Senger > > > email: martin.senger at gmail.com > > > skype: martinsenger > > > International Rice Research Institute > > > Biometrics and Bioinformatics Unit > > > DAPO BOX 7777, Metro Manila > > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Aug 16 09:19:32 2005 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 16 Aug 2005 15:19:32 +0200 Subject: [MOBY-dev] Taverna: moby_collection widget Message-ID: <200508161519.32949.d.haase@gsf.de> Hi! I just tried out the Create_a_moby_collection widget in the new Taverna (after CVS build, the package is still the buggy one I think...) but didn't have much fun with it. As soon as I use it in the workflow, the service invocation fails, a ClassCastException is reported. Failure is even before an http request is sent out. Can anybody confirm that the widget is working? One thing I noticed is that the widget output is typed only as text/plain not as text/xml like for example Create_moby_data does it. But I have no idea if this is relevant... I'll be thankful for any hints. Regards, dirk -- ---------------------------------------------------------- Dirk Haase phone +49 89 3187 3583 http://mips.gsf.de/~haase email d.haase at gsf.de From edward.kawas at gmail.com Tue Aug 16 12:16:40 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue, 16 Aug 2005 11:16:40 -0500 Subject: [MOBY-dev] Taverna: moby_collection widget In-Reply-To: <200508161519.32949.d.haase@gsf.de> References: <200508161519.32949.d.haase@gsf.de> Message-ID: Hi, The widget should work. I dont have a computer that could try it out (using dial-up) but as i recall, what one has to do is add the widget 'create_moby_collection' to a work flow and then add the various datatypes (DNASequence, Integer, etc) to the input ports and a properly formed collection should result and can be passed to the appropriate moby service. Out of curiousity, what was the class that caused the exception? Do you think that you could send me the error output? I am not sure how much help i can be for the next 2 weeks (no steady net connection) but i'll try! If you want to see how to use the collection, you could try the following workflow: http://bioinfo.icapture.ubc.ca/ekawas/workflow.xml with the following input: http://bioinfo.icapture.ubc.ca/ekawas/workflowInput.xml That workflow is known to work (actually, you will need to do a find/replace on the following string: find-> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl replace-> http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl and then it will work. Sorry about that!). Eddie On 8/16/05, Dirk Haase wrote: > Hi! > > I just tried out the Create_a_moby_collection widget in the new Taverna (after > CVS build, the package is still the buggy one I think...) but didn't have > much fun with it. As soon as I use it in the workflow, the service invocation > fails, a ClassCastException is reported. Failure is even before an http > request is sent out. > > Can anybody confirm that the widget is working? One thing I noticed is that > the widget output is typed only as text/plain not as text/xml like for > example Create_moby_data does it. But I have no idea if this is relevant... > > I'll be thankful for any hints. > > Regards, > dirk > > -- > > ---------------------------------------------------------- > Dirk Haase phone +49 89 3187 3583 > http://mips.gsf.de/~haase email d.haase at gsf.de > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Tue Aug 16 12:21:23 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 16 Aug 2005 09:21:23 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Hi all, Thanks for writing this up so clearly! I agree 100% that the current error-reporting system in BioMOBY is insufficient (it was never part of the initial proposal, and even that initial proposal was cut by 80%, so...) I am a bit wary of two aspects of the solution you propose, though I need more time to think about exactly why they make me nervous: 1) Mixing metadata (errors) into the data seems... well... wrong somehow. I would prefer a solution that somehow used the serviceNotes block as the place to put error messages, and added an attribute to teh mobyData, Collection, or Simple tags that Xref'ed a node in the serviceNotes block. I wasn't in Malaga for the discussion, so perhaps there is a strong argument for putting it there that I am unaware of? 2) overloading the articleName attribute in the Simple/Collection tag (and especially in the case where Simples are part of a Collection) would then give **three** different "meanings" to the articleName attribute!! It's bad enough that we already have two different uses for that attribute... I'm reluctant to add one more to the fray! :-) Let's create a new attribute instead of adding a new meaning to an existing one. I hope others will participate in this discussion - it's been pretty quiet out there! I have not thought deeply about error reporting, and I would prefer to leave the final decision to people who *have* thought deeply about it. I am perfectly happy to simply sign-off on whatever the expert group decides - I really do not want to be the arbiter of the final decision in this matter because I just don't have the full scope of the problem in my head! I am happy, however, to participate in the overall debate leading up to that decision. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Tue Aug 16 12:21:23 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 16 Aug 2005 09:21:23 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Hi all, Thanks for writing this up so clearly! I agree 100% that the current error-reporting system in BioMOBY is insufficient (it was never part of the initial proposal, and even that initial proposal was cut by 80%, so...) I am a bit wary of two aspects of the solution you propose, though I need more time to think about exactly why they make me nervous: 1) Mixing metadata (errors) into the data seems... well... wrong somehow. I would prefer a solution that somehow used the serviceNotes block as the place to put error messages, and added an attribute to teh mobyData, Collection, or Simple tags that Xref'ed a node in the serviceNotes block. I wasn't in Malaga for the discussion, so perhaps there is a strong argument for putting it there that I am unaware of? 2) overloading the articleName attribute in the Simple/Collection tag (and especially in the case where Simples are part of a Collection) would then give **three** different "meanings" to the articleName attribute!! It's bad enough that we already have two different uses for that attribute... I'm reluctant to add one more to the fray! :-) Let's create a new attribute instead of adding a new meaning to an existing one. I hope others will participate in this discussion - it's been pretty quiet out there! I have not thought deeply about error reporting, and I would prefer to leave the final decision to people who *have* thought deeply about it. I am perfectly happy to simply sign-off on whatever the expert group decides - I really do not want to be the arbiter of the final decision in this matter because I just don't have the full scope of the problem in my head! I am happy, however, to participate in the overall debate leading up to that decision. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From dgpisano at cnb.uam.es Wed Aug 17 07:12:16 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Wed, 17 Aug 2005 13:12:16 +0200 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43031B90.4020802@cnb.uam.es> Hello, Mark Wilkinson escribi?: >Hi all, > >Thanks for writing this up so clearly! I agree 100% that the current >error-reporting system in BioMOBY is insufficient (it was never part of >the initial proposal, and even that initial proposal was cut by 80%, >so...) > >I am a bit wary of two aspects of the solution you propose, though I >need more time to think about exactly why they make me nervous: > >1) Mixing metadata (errors) into the data seems... well... wrong >somehow. I would prefer a solution that somehow used the serviceNotes >block as the place to put error messages, and added an attribute to teh >mobyData, Collection, or Simple tags that Xref'ed a node in the >serviceNotes block. I wasn't in Malaga for the discussion, so perhaps >there is a strong argument for putting it there that I am unaware of? > > > There were 2 proposals in the document and yes, the second one had the errors mixed with the data. We will write it again to clearly separate the moby data from the error information (like in the first proposal, that uses serviceNotes) and crossref them someway (see below) >2) overloading the articleName attribute in the Simple/Collection tag >(and especially in the case where Simples are part of a Collection) >would then give **three** different "meanings" to the articleName >attribute!! It's bad enough that we already have two different uses for >that attribute... I'm reluctant to add one more to the fray! :-) Let's >create a new attribute instead of adding a new meaning to an existing >one. > > > We understand that the articleName attribute in Simple / Collection tags is the "anchor point" we have to use to refer to that Simple / Collection. Referring to Simples / Collections / Simples into collection using articleNames give us more granularity than referring to mobyDatas using queryIDs. There is no need to create another additional "identifying" attribute if we can identify the entity we are reporting an error for. Probably we have to rewrite that part to clarify several points: - The error tag has to use an attribute to refer to the corresponding failing simple / collection. We can call this attribute exceptionRef, articleNameRef or something similar, to avoid using articleName again in a different context, but - We are referring to the erroneus entity using its articleName, and that's why the articleName has to be mandatory (note that this is a significant change in the bioMOBY specification, but we can't figure out any other way to report errors at this level) David >I hope others will participate in this discussion - it's been pretty >quiet out there! I have not thought deeply about error reporting, and I >would prefer to leave the final decision to people who *have* thought >deeply about it. I am perfectly happy to simply sign-off on whatever >the expert group decides - I really do not want to be the arbiter of the >final decision in this matter because I just don't have the full scope >of the problem in my head! I am happy, however, to participate in the >overall debate leading up to that decision. > >M > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050817/91cab6be/dgpisano-0004.vcf From dgpisano at cnb.uam.es Wed Aug 17 07:12:16 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Wed, 17 Aug 2005 13:12:16 +0200 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43031B90.4020802@cnb.uam.es> Hello, Mark Wilkinson escribi?: >Hi all, > >Thanks for writing this up so clearly! I agree 100% that the current >error-reporting system in BioMOBY is insufficient (it was never part of >the initial proposal, and even that initial proposal was cut by 80%, >so...) > >I am a bit wary of two aspects of the solution you propose, though I >need more time to think about exactly why they make me nervous: > >1) Mixing metadata (errors) into the data seems... well... wrong >somehow. I would prefer a solution that somehow used the serviceNotes >block as the place to put error messages, and added an attribute to teh >mobyData, Collection, or Simple tags that Xref'ed a node in the >serviceNotes block. I wasn't in Malaga for the discussion, so perhaps >there is a strong argument for putting it there that I am unaware of? > > > There were 2 proposals in the document and yes, the second one had the errors mixed with the data. We will write it again to clearly separate the moby data from the error information (like in the first proposal, that uses serviceNotes) and crossref them someway (see below) >2) overloading the articleName attribute in the Simple/Collection tag >(and especially in the case where Simples are part of a Collection) >would then give **three** different "meanings" to the articleName >attribute!! It's bad enough that we already have two different uses for >that attribute... I'm reluctant to add one more to the fray! :-) Let's >create a new attribute instead of adding a new meaning to an existing >one. > > > We understand that the articleName attribute in Simple / Collection tags is the "anchor point" we have to use to refer to that Simple / Collection. Referring to Simples / Collections / Simples into collection using articleNames give us more granularity than referring to mobyDatas using queryIDs. There is no need to create another additional "identifying" attribute if we can identify the entity we are reporting an error for. Probably we have to rewrite that part to clarify several points: - The error tag has to use an attribute to refer to the corresponding failing simple / collection. We can call this attribute exceptionRef, articleNameRef or something similar, to avoid using articleName again in a different context, but - We are referring to the erroneus entity using its articleName, and that's why the articleName has to be mandatory (note that this is a significant change in the bioMOBY specification, but we can't figure out any other way to report errors at this level) David >I hope others will participate in this discussion - it's been pretty >quiet out there! I have not thought deeply about error reporting, and I >would prefer to leave the final decision to people who *have* thought >deeply about it. I am perfectly happy to simply sign-off on whatever >the expert group decides - I really do not want to be the arbiter of the >final decision in this matter because I just don't have the full scope >of the problem in my head! I am happy, however, to participate in the >overall debate leading up to that decision. > >M > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050817/91cab6be/dgpisano-0005.vcf From markw at illuminae.com Wed Aug 17 12:17:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 17 Aug 2005 09:17:57 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <43031B90.4020802@cnb.uam.es> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> <43031B90.4020802@cnb.uam.es> Message-ID: <1124295477.21293.18.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-17 at 13:12 +0200, David Gonz?lez Pisano wrote: > We understand that the articleName attribute in Simple / Collection tags > is the "anchor point" we have to use to refer to that Simple / > Collection. Referring to Simples / Collections / Simples into collection > using articleNames give us more granularity than referring to mobyDatas > using queryIDs. There is no need to create another additional > "identifying" attribute if we can identify the entity we are reporting > an error for. This is the only problematic part of the solution, since it requires a potentially troublesome change to the API. For this solution, you require all of the Simples in a Collection to have a unique articleName tag. At present, they likely have no tag at all (since this is not mandated by the API), and at best will all have the *same* tag even if we mandate that all output parameters must have an article name. If we make the value of this tag auto-generated (like an auto-increment field in a database), then it adds a new meaning to articleName, so let's just not pursue this possibility any further :-) Whatever solution we come up with, it cannot use articleName as its primary means of identifying the failed entity. > - The error tag has to use an attribute to refer to the corresponding > failing simple / collection. We can call this attribute exceptionRef, > articleNameRef or something similar, to avoid using articleName again in > a different context, but Super! > - We are referring to the erroneus entity using its articleName, and > that's why the articleName has to be mandatory (note that this is a > significant change in the bioMOBY specification, but we can't figure out > any other way to report errors at this level) I'm not sure why we need two ways of referring to the same entity? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Aug 18 17:27:16 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 18 Aug 2005 14:27:16 -0700 Subject: [MOBY-dev] CORE DEVELOPERS please create a bugzilla account... Message-ID: <1124400436.25003.2.camel@bioinfo.icapture.ubc.ca> Hi all core developers, We had our first Bugzilla bug report today, but nobody has signed-up to be a debugger :-) Can I request that all core developers (anyone who has committed significant code to the repository, or anyone who wants to be a MOBY debugger) please sign-up so that bugs can be assigned to you with email notification. It would be a good idea if we started using this bug tracking system rather than relying on the mailing list. http://bugzilla.open-bio.org/createaccount.cgi Thanks! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 03:43:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 08:43:55 +0100 (BST) Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Dear all, I am late with handling this email but it does not mean that I under-estimate the importance of th topic. It's actually crucial for claiming that we have a robust and interoperable technology. But we need it fast. I mean A decision should be made soon. i completely agree with Oswaldo that waiting for such important topic for several years now is a bit unfortunate. So let's face the problem... I read Oswaldo's proposal and I had opportunity to discuss it personaly. But actually I do not have a strong opinion HOW to handle errors if we handle them SOON. One missing piece (IMHO) there is not using the standard way for error handling in web services. I suspect that i know why it is not there - because there is not clear solution that would guarantee to work everywhere (now I am quoting the documenattion for the latest Apache Axis). However, I have tried it, and it works fine between perl and java (from both sides). So I think it is worth to use it. So now is my summary (and perhaps suggestion): 1) Critical errors. A service should raise an exception. So this level does not return any Moby specific data - everything is handled on SOAP level (sending back faultCode, faultString and such usuaal tags). In Java it is easy, in Perl as well (use SOAP::Fault). This does not bring any additional complexity to the client code - unless a client is badly written. What I want to say is that a good client even now should be prepared for transport exception (when a service is down completely, for example). So catching also a SOAP error produced by a service is trivial addition. To improve interoperability here, we should discuss the error strings etc. But there were suggestion in Osvaldo's proposal we can follow. The critical is a decision that we allow services to raise an exception in a critical situation. 2) "Your data are wrong" is the next level of errors. For this, both Oswaldo's sollution would work. As I said, I can go both ways IF we define what is an empty response. Does it mean an empty tag mobyData or an empty Object, or Simple... If we come to the end, what does an empty Integer mean? Does it mean always an error? Because an empry String can be a valid answer but empty Integer probably not. So the problems here are not that much where to put error strings (service notes or inside simples) but what "empty" means. 3) And we can talk about the third level - if we distinguish that sometimes simply your data are wrong and I cannot return you anything (above), or your data are partially wrong and I can retunr you at least something. but again, Oswaldo explained it already. So what should I put into my services? Please, Mark, tell us... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 03:43:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 08:43:55 +0100 (BST) Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Dear all, I am late with handling this email but it does not mean that I under-estimate the importance of th topic. It's actually crucial for claiming that we have a robust and interoperable technology. But we need it fast. I mean A decision should be made soon. i completely agree with Oswaldo that waiting for such important topic for several years now is a bit unfortunate. So let's face the problem... I read Oswaldo's proposal and I had opportunity to discuss it personaly. But actually I do not have a strong opinion HOW to handle errors if we handle them SOON. One missing piece (IMHO) there is not using the standard way for error handling in web services. I suspect that i know why it is not there - because there is not clear solution that would guarantee to work everywhere (now I am quoting the documenattion for the latest Apache Axis). However, I have tried it, and it works fine between perl and java (from both sides). So I think it is worth to use it. So now is my summary (and perhaps suggestion): 1) Critical errors. A service should raise an exception. So this level does not return any Moby specific data - everything is handled on SOAP level (sending back faultCode, faultString and such usuaal tags). In Java it is easy, in Perl as well (use SOAP::Fault). This does not bring any additional complexity to the client code - unless a client is badly written. What I want to say is that a good client even now should be prepared for transport exception (when a service is down completely, for example). So catching also a SOAP error produced by a service is trivial addition. To improve interoperability here, we should discuss the error strings etc. But there were suggestion in Osvaldo's proposal we can follow. The critical is a decision that we allow services to raise an exception in a critical situation. 2) "Your data are wrong" is the next level of errors. For this, both Oswaldo's sollution would work. As I said, I can go both ways IF we define what is an empty response. Does it mean an empty tag mobyData or an empty Object, or Simple... If we come to the end, what does an empty Integer mean? Does it mean always an error? Because an empry String can be a valid answer but empty Integer probably not. So the problems here are not that much where to put error strings (service notes or inside simples) but what "empty" means. 3) And we can talk about the third level - if we distinguish that sometimes simply your data are wrong and I cannot return you anything (above), or your data are partially wrong and I can retunr you at least something. but again, Oswaldo explained it already. So what should I put into my services? Please, Mark, tell us... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 11:26:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 08:26:04 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> > So what should I put into my services? Please, Mark, tell us... If you read my earlier comments I have already refused to make these decisions - the are better left to people who have thought extensively about them. Once you have come to an agreement, YOU tell ME what to do, and I (or the new curator, Frank) will add it to the API. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 11:26:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 08:26:04 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> > So what should I put into my services? Please, Mark, tell us... If you read my earlier comments I have already refused to make these decisions - the are better left to people who have thought extensively about them. Once you have come to an agreement, YOU tell ME what to do, and I (or the new curator, Frank) will add it to the API. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 11:44:33 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 16:44:33 +0100 (BST) Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> Message-ID: > If you read my earlier comments > I always read your comments... > I have already refused to make these decisions - the are better left > to people who have thought extensively about them. > That's nonsense. Sorry, Mark, but you put us into this mess because you had no time, mood or funding to make the error handling properly in the first place. Also, the current API - that does not define fully what "an empty result" means - is surely something you could /should think about it, and not let it completely on decision on other people. I am happy to discuss it, but at the end it will surely require changes in your code (perhaps not so much in registry, but surely in the library for service providers). So without your commitment to this topic it seems a bit of waste of time... The problem is not that you *have* to participate on every decision - but the problem is that we do not have (still) a procedure how to make changes in the API. Just "I or Frank will add it to the API" is not a proper process. And this process, in order to be successful, must be discussed with you as a PI and project manager. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 11:44:33 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 16:44:33 +0100 (BST) Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> Message-ID: > If you read my earlier comments > I always read your comments... > I have already refused to make these decisions - the are better left > to people who have thought extensively about them. > That's nonsense. Sorry, Mark, but you put us into this mess because you had no time, mood or funding to make the error handling properly in the first place. Also, the current API - that does not define fully what "an empty result" means - is surely something you could /should think about it, and not let it completely on decision on other people. I am happy to discuss it, but at the end it will surely require changes in your code (perhaps not so much in registry, but surely in the library for service providers). So without your commitment to this topic it seems a bit of waste of time... The problem is not that you *have* to participate on every decision - but the problem is that we do not have (still) a procedure how to make changes in the API. Just "I or Frank will add it to the API" is not a proper process. And this process, in order to be successful, must be discussed with you as a PI and project manager. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 11:47:03 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 08:47:03 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 16:44 +0100, Martin Senger wrote: > is surely something you could /should think about > it, and not let it completely on decision on other people. I have offered to participate in the discussion, and am doing so. > I am happy to discuss it, but at the end it will surely require changes > in your code (perhaps not so much in registry, but surely in the library > for service providers). So without your commitment to this topic it seems > a bit of waste of time... And will make the necessary changes in the code once a decision has been reached. > The problem is not that you *have* to participate on every decision - > but the problem is that we do not have (still) a procedure how to make > changes in the API. Correct. > discussed with you as a PI and project manager. It is as we speak. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 11:47:03 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 08:47:03 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 16:44 +0100, Martin Senger wrote: > is surely something you could /should think about > it, and not let it completely on decision on other people. I have offered to participate in the discussion, and am doing so. > I am happy to discuss it, but at the end it will surely require changes > in your code (perhaps not so much in registry, but surely in the library > for service providers). So without your commitment to this topic it seems > a bit of waste of time... And will make the necessary changes in the code once a decision has been reached. > The problem is not that you *have* to participate on every decision - > but the problem is that we do not have (still) a procedure how to make > changes in the API. Correct. > discussed with you as a PI and project manager. It is as we speak. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 12:07:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 17:07:11 +0100 (BST) Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > > but the problem is that we do not have (still) a procedure how to make > > changes in the API. > > Correct. > So how are we going to solve this? This is *a* solution (based on my experiences from the OMG process): 1) Anybody can make a suggestion to make a change in API (we can call it RFP - request for proposal, or RFC - request for comments, or whatever). An example of such thing are the proposals from Oswaldo and his collegues (eventhough I would not expect to have it always so perfectly written :-)). Important is that it must *say* this is a RFP/RFC, not just a wish in email. We will keep a place for it (bugzilla has wishlists?). 2) Then a calendar (deadline) must be attached to it. It can be suggested already by the author of the RFP/RFC, or a default value is attached. We need to say what is a default value. 3) The RFP can be considered only if the change is back-uped by two (three?) other developers. They do not need to fully agree with all details, their role is just to prevent overhelming number of small changes coming fast. 4) It is also considered only if somebody has resources to really implement the change. This should be also a part of the clendar ("when it can be done"). 5) Discussion on RFC, changes re-distributed, etc. In charge is the author of the original RFC. Deadline can be extended - don't be too formal here. 6) Now the tricky part: I think taht there should be only few people (major developers) who can vote on it. This is called an "Architecture Board" at OMG and guarantees that the changes are hopefully not breaking other things. 7) Then comes implementation, documenttaion etc. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 12:07:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 17:07:11 +0100 (BST) Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > > but the problem is that we do not have (still) a procedure how to make > > changes in the API. > > Correct. > So how are we going to solve this? This is *a* solution (based on my experiences from the OMG process): 1) Anybody can make a suggestion to make a change in API (we can call it RFP - request for proposal, or RFC - request for comments, or whatever). An example of such thing are the proposals from Oswaldo and his collegues (eventhough I would not expect to have it always so perfectly written :-)). Important is that it must *say* this is a RFP/RFC, not just a wish in email. We will keep a place for it (bugzilla has wishlists?). 2) Then a calendar (deadline) must be attached to it. It can be suggested already by the author of the RFP/RFC, or a default value is attached. We need to say what is a default value. 3) The RFP can be considered only if the change is back-uped by two (three?) other developers. They do not need to fully agree with all details, their role is just to prevent overhelming number of small changes coming fast. 4) It is also considered only if somebody has resources to really implement the change. This should be also a part of the clendar ("when it can be done"). 5) Discussion on RFC, changes re-distributed, etc. In charge is the author of the original RFC. Deadline can be extended - don't be too formal here. 6) Now the tricky part: I think taht there should be only few people (major developers) who can vote on it. This is called an "Architecture Board" at OMG and guarantees that the changes are hopefully not breaking other things. 7) Then comes implementation, documenttaion etc. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 12:24:10 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 09:24:10 -0700 Subject: [personal] Re: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 17:07 +0100, Martin Senger wrote: > An example of such thing are the proposals from Oswaldo and his > collegues (eventhough I would not expect to have it always so perfectly > written :-)). Indeed! It was more of a work of art than an RFC :-) They have really set the bar for the rest of us... > Important is that it must *say* this is a RFP/RFC, not just > a wish in email. We will keep a place for it (bugzilla has wishlists?). Unfortunately not :-( I'm looking for something to use as an alternative, but coming up empty. I wonder if Simon's Wordpress could do something in this regard? TWiki has templates, and I suspect Wordpress has something similar... > 6) Now the tricky part: I think taht there should be only few people > (major developers) who can vote on it. This is called an "Architecture > Board" at OMG and guarantees that the changes are hopefully not breaking > other things. I think we know who those people are, for the most part, but I think it would be good to open up the floor for volunteers with the caveat that there *will be an expectation* of a ~significant time commitment from those who volunteer, and with a one-year tenure (so that people don't join just to get their favorite feature through the process and then disappear again). This should sufficiently self-regulate the membership that it wont get unwieldy, and selects those who are both committed, and knowledgeable. > 7) Then comes implementation, documenttaion etc. Is that the fun part? ;-) M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 12:29:55 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 09:29:55 -0700 Subject: [personal] Re: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> References: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <1124900995.8181.57.camel@bioinfo.icapture.ubc.ca> This would also give us a clear basis for splitting-up the semi-annual developers meeting into the "core" developers and the "adherents". This is something I had hoped to do in the coming year anyway (assuming that we get funded at all... which is what I am currently working on! Fingers crossed!) M > > 6) Now the tricky part: I think taht there should be only few people > > (major developers) who can vote on it. This is called an "Architecture > > Board" at OMG and guarantees that the changes are hopefully not breaking > > other things. > > I think we know who those people are, for the most part, but I think it > would be good to open up the floor for volunteers with the caveat that > there *will be an expectation* of a ~significant time commitment from > those who volunteer, and with a one-year tenure (so that people don't > join just to get their favorite feature through the process and then > disappear again). This should sufficiently self-regulate the membership > that it wont get unwieldy, and selects those who are both committed, and > knowledgeable. -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From fgibbons at hms.harvard.edu Wed Aug 24 14:08:10 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 24 Aug 2005 14:08:10 -0400 Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <200508241557.j7OFv1Tu013092@portal.open-bio.org> Message-ID: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Martin, At 11:57 AM 8/24/2005, moby-dev-request at portal.open-bio.org wrote: >This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). Thanks for that suggestion - that sounds very sensible to me. As to whether Bugzilla has wishlists, I can't find them. (I hold the distinction of being the first - and to my knowledge, only - user of MOBY's Bugzilla set up.) Still, I guess we could overload the definition of 'bug' as meaning anything that needs attention. SourceForge has trackers that can differentiate between at least these four categories: bugs, support-requests, patches, and features requests. I'm sure there are good reasons why it makes sense to put MOBY on open-bio, rather than SourceForge. Is there any way we (and by 'we' I mean whoever runs open-bio :) could 'upgrade' the features offered by bugzilla there, to distinguish between those different kinds of requests? It would also help if the link to bugzilla got moved to a more prominent position on the MOBY home page. I really agree with Martin, that we need to adopt a more formalized (but not necessarily formal) approach to developing MOBY, because it's becoming bigger, and more widely used. The unformalized communication based on email doesn't scale terribly well: * there's poor differentiation between feature requests and bugs; and no definitive process for making decisions on either one; * there's no permanent record of decisions taken (except by searching the mail archives - good luck with that!); * although it's possible to announce future directions for development, they soon get lost in the archives, since they're not tagged as such. There are already powerful tools to help manage distributed software development, and I'd like to see us use them more. Using them would not only be good for our internal development, it would be good for our image, because it would look like we know what we're doing, giving newbies more confidence to join. Just my opinion, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From gordonp at ucalgary.ca Wed Aug 24 14:28:18 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 24 Aug 2005 12:28:18 -0600 Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> References: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: <430CBC42.4040404@ucalgary.ca> At the very least, you can set the severity of a bug to "enhancement" in Bugzilla. It's a start... > * there's poor differentiation between feature requests and bugs; and > no definitive process for making decisions on either one; > * there's no permanent record of decisions taken (except by searching > the mail archives - good luck with that!); > * although it's possible to announce future directions for > development, they soon get lost in the archives, since they're not > tagged as such. From markw at illuminae.com Wed Aug 24 16:54:48 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 13:54:48 -0700 Subject: [MOBY-dev] RFC management system? Message-ID: <1124916888.8181.115.camel@bioinfo.icapture.ubc.ca> Hi all, I'm looking into "RT" from http://www.bestpractical.com It is being used by the open-bio people for their request tracking, so if it serves our purposes we could easily piggy-back. if anyone knows about this, please send your opinion. I'm just starting to look at it now... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Thu Aug 25 18:04:34 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Thu, 25 Aug 2005 16:04:34 -0600 Subject: [MOBY-dev] question to ask References: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> <1124900995.8181.57.camel@bioinfo.icapture.ubc.ca> Message-ID: <430E4072.6010801@cpsc.ucalgary.ca> Hi Mark, I have a question to ask you: I made my service can take a large input sequences (1000 to 5000 DNA) in XML format. I use "./build/run/run-cmdline-client -scall search_Pfam ../../../JMOBY2/DNASEQ/input_1000" to test this service. The input_1000 contains 1000 DNA sequences in XML format. This service takes 3 mins and 34 seconds to parse the input file, and terminated after 3 mins and 41 seconds, then I got the error message as the following: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [string: null] Fault string: (0)null Fault code: {http://xml.apache.org/axis/}HTTP Fault actor: null When calling: http://moby.ucalgary.ca/cgi-bin/MobyEd_dispatcher.cgi =========== at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:196) at org.biomoby.client.CentralImpl.call(CentralImpl.java:1422) at MobyCmdLineClient.main(MobyCmdLineClient.java:641) =========== I thought the service got time out, so I changed "call.setTimeout(new Integer (0)" to "call.setTimeout(new Integer (600000)" in the "CentralImpl.java", then recompiled and I tested the service again, but still got same message. However, the big problem which I have right now is the service will be terminated after around 4 mins. I want to delay the timeout time. If you can, could you let me know is there anyway which I can solve this problem. Now I just tested on 800 and 1000 sequences. The 800 sequences worked fine, but not 1000 sequences. please help me if you can. I know you are very busy. Thanks so much! Joyce From markw at illuminae.com Thu Aug 25 18:04:55 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 25 Aug 2005 22:04:55 +0000 GMT Subject: [MOBY-dev] question to ask Message-ID: <1142838580-1125007531-cardhu_blackberry.rim.net-21511-@engine09-cell01> This is for the Java guru's to answer... M -----Original Message----- From: Chunyan Wang Date: Thu, 25 Aug 2005 16:04:34 To:markw at illuminae.com, Core developer announcements Subject: [MOBY-dev] question to ask Hi Mark, I have a question to ask you: I made my service can take a large input sequences (1000 to 5000 DNA) in XML format. I use "./build/run/run-cmdline-client -scall search_Pfam ../../../JMOBY2/DNASEQ/input_1000" to test this service. The input_1000 contains 1000 DNA sequences in XML format. This service takes 3 mins and 34 seconds to parse the input file, and terminated after 3 mins and 41 seconds, then I got the error message as the following: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [string: null] Fault string: (0)null Fault code: {http://xml.apache.org/axis/}HTTP Fault actor: null When calling: http://moby.ucalgary.ca/cgi-bin/MobyEd_dispatcher.cgi =========== at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:196) at org.biomoby.client.CentralImpl.call(CentralImpl.java:1422) at MobyCmdLineClient.main(MobyCmdLineClient.java:641) =========== I thought the service got time out, so I changed "call.setTimeout(new Integer (0)" to "call.setTimeout(new Integer (600000)" in the "CentralImpl.java", then recompiled and I tested the service again, but still got same message. However, the big problem which I have right now is the service will be terminated after around 4 mins. I want to delay the timeout time. If you can, could you let me know is there anyway which I can solve this problem. Now I just tested on 800 and 1000 sequences. The 800 sequences worked fine, but not 1000 sequences. please help me if you can. I know you are very busy. Thanks so much! Joyce _______________________________________________ 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 Thu Aug 25 20:03:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 26 Aug 2005 01:03:44 +0100 (BST) Subject: [MOBY-dev] question to ask In-Reply-To: <430E4072.6010801@cpsc.ucalgary.ca> Message-ID: Hi, I am afraid I do not have any good answer for you. When I tried the same service today (with a very short sequence) I have got timeout after several seconds. It said "(504)Proxy Timeout ( This operation returned because the timeout period expired.)", which seems exactly what you witnessed. My feeling is that the proxy mentioned in the message is on the service provider side. I think that the best would be to contact and ask the service provider. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Aug 26 03:52:34 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 26 Aug 2005 08:52:34 +0100 (BST) Subject: [MOBY-dev] changes in jMoby Message-ID: Dear all, I have made few (hopefully not breaking anything) in jMoby (the reason why will come apparent when I finish documenting my efforts over this weekend and send another email here). The most important is that you should call ./build.sh in order to get a newly added jar (alltools2.jar). This will probably download all libraries again - thats' because an updated time-stamp in the jar registry - but it wil happen just once (but do not do it on a slow modem :-)). Also I updated version of jdom.jar from beta to the 1.0. Everything compiled fine, but please check your code that nothing broke (it's really time to think seriously on jUnits - and I do think about it...). The directory src/Services was almost empty - and I moved the rest what was there into the more appropriate place src/main (the package name remained the same). Instead there is now src/samples where we can put examples, tutorial as etc. It does not compile by default - so it does not break the normal/main code. There is a bunch of new targets in Ant, such as samples-compile, samples-docs, samples-jar, samples-clean. There is also a directory src/samples-resources where you can put testing or demo files. All files here are utomatically loaded to the CLASSPATH so you can use getResource() to get them without troubles with their physical location (and there is a new method in Utils.java doing so in one line - readResource(). Please read docs/ChangeLog for few details what I did. Thank you, Paul, that you are contributing there. Have ever headrd about this file, Eddie? Eddie, could you reconsider directory 'org' that suddenl;y appeared in the main directory? It should be somewhere else... (let's discuss it offline). Please let me know if I broke anything. I apologize if I did (but I have checked many times before commiting my huge changes, so I hope everything is fine...). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From wangch at cpsc.ucalgary.ca Fri Aug 26 11:55:03 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Fri, 26 Aug 2005 09:55:03 -0600 Subject: [MOBY-dev] question to ask References: Message-ID: <430F3B57.2040602@cpsc.ucalgary.ca> Thanks, Martin. You said you tried the same service, which service? Is that search_Pfam? This service is tested with up to 800 sequences; it worked fine by using command line, but not from the MOBY Browser (works fine with one sequence). Actually, this is another big problem I have right now. The another problem is : When a user submits a request to one of our services from the MOBY Browser, if our server is busy and the request needs to take more than a few minutes to finish, then the service gets timeout. For our services, we need them to be able to take mutiple input sequences (maybe up to 5000 sequences) and input with seconary input. I am not sure what these problems are. But I will look into them. If anyone can give me suggestions, please let me know. Thanks. Joyce Martin Senger wrote: >Hi, > I am afraid I do not have any good answer for you. When I tried the >same service today (with a very short sequence) I have got timeout after >several seconds. It said "(504)Proxy Timeout ( This operation returned >because the timeout period expired.)", which seems exactly what you >witnessed. My feeling is that the proxy mentioned in the message is on the >service provider side. I think that the best would be to contact and ask >the service provider. > > With regards, > Martin > > > From senger at ebi.ac.uk Fri Aug 26 12:40:54 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 26 Aug 2005 17:40:54 +0100 (BST) Subject: [MOBY-dev] question to ask In-Reply-To: <430F3B57.2040602@cpsc.ucalgary.ca> Message-ID: > You said you tried the same service, which service? Is that search_Pfam? > Yes, the search_Pfam. > needs to take more than a few minutes to finish, then the service gets > timeout. > We had the same (or similar) problem at EBI. The timeout can happen at several places. And one good candidate is a proxy server (I am saying good, because the error I got mentioned proxy). The proxy can be configured how long it waits before timeout. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 26 18:20:31 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 26 Aug 2005 15:20:31 -0700 Subject: [MOBY-dev] Migration of database to new API Message-ID: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Hi all, As we move toward deploying the new API, there are some serious consequences on the underlying databases. Let me first re-cap the new API features that I am discussing and what effects they have on the databases: 1) Inheritence from primitives through ISA relationships is no longer allowed. e.g. plain-text ISA String is no longer allowed. To achieve the same result, you now create an object that inherits from Object and contains the primitive. e.g. plain-text ISA Object; plain-text HASA String. 2) All service inputs and outputs must now be named (articleName) ------ For case 1, I have written a migration script that does the following: a) identifies every object that inherits directly from a primitive b) creates a new object called OldObjectName_v2 that inherits from Object and contains that primitive type through a HASA relationship, with the contained articleName being the same as the original object name. e.g. plain-text ISA String results in a new object plain_text_v2 ISA Object; plain_text_v2 HASA String(plain_text) c) updates the description of the original object such that the description now reads "DEPRECATED - use plain_text_v2 instead" This is in the Database folder of the CVS. At present, this script only goes down one level of the object hierarchy, and does not explicitly deprecate, nor create new object types for, any children of now deprecated objects, nor for any objects that contain a deprecated object Q1: Should it do so ...or is this going to create mass confusion for people? Q2: How long should the deprecation period be before we refuse to support the old objects any longer? My feeling is that it should be quite limited... e.g. 2 months. If you can't update your service to use a new object type within two months, then it gets removed from the registry. I updated all ~20 of my services in about 5 minutes, so that gives you a sense of how much effort it is... -------- For case 2, I have not yet written a script. I am loathe to change people's service registrations at all! I would prefer that people update their RDF signatures and let the agent update their service registration (once we get the agent running - this has been postponed *yet again* in order to bring our service signature model in sync with the one that we just jointly developed with myGrid last month). What concerns me is that this might require a lot of hand-editing from those who have hundreds of services registered (e.g. soaplab), so...?? Would it be preferable for me to script this and just attach arbitrary names to your inputs/outputs in the database? This is going to be a painful API change no matter how we play it, but I want to be sure that we all know what the changes are going to be and have agreed on the path of least pain before we begin the process. It's all for the best! Honestly! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Fri Aug 26 20:53:22 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 01:53:22 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Aug 26 20:53:22 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 01:53:22 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 26 20:58:33 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 27 Aug 2005 00:58:33 +0000 GMT Subject: [MOBY-dev] Migration of database to new API Message-ID: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> There is no need for a name change again. The object will forever be called -v2 It's just an identifier... M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 01:53:22 To:markw at illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Fri Aug 26 20:58:33 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 27 Aug 2005 00:58:33 +0000 GMT Subject: [MOBY-dev] Migration of database to new API Message-ID: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> There is no need for a name change again. The object will forever be called -v2 It's just an identifier... M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 01:53:22 To:markw at illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Fri Aug 26 21:06:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 02:06:55 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> Message-ID: > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Aug 26 21:06:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 02:06:55 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> Message-ID: > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 26 21:12:53 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 27 Aug 2005 01:12:53 +0000 GMT Subject: [MOBY-dev] Migration of database to new API Message-ID: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> I strongly disagree in return :-) If I have an object called "sequence" there is no indication in the name that it is a fasta sequence or an embl sequence or a genbank sequence or whatever. The fact that it is called sequence-v2 is no more nor less confusing! (Ben is sitting here beside me in the pub chuckling about the dangers of mixing semantics meaning into names :-) ) M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 02:06:55 To:markw at illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Fri Aug 26 21:22:42 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 02:22:42 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> Message-ID: > The fact that it is called sequence-v2 is no more nor less confusing! > Nonsense. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Aug 27 07:11:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 12:11:09 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? Message-ID: Having an LSID of a service instance (as returned by 'findService' from a registry) I can do two things: ask for data and ask for metadata (connected to this LSID). The metadata is not the topic here (now). What if I ask for data? I can get nothing back, indicating that there is no data associated with this service instance. And I think that I would get nothing because looking at the LSID now it does not seem to indicate any data (it does not have any version etc., for example). I may be wrong, but let's assume, only hypotetically, that I am not wrong and that really I do not get back any data. That's a pity because I want to improve my cache-aware clients by storing LSID in my cache, then asking for a list of services, and by comparing what I have and what I get, I can update in my cache only services that changed. Two problems with that: 1) The list of services (method retrieveServices) does not return LSIDs. Bad luck. Mark, you sent an email saying that lsid attribute is now everywhere. Well, it is not... 2) LSID resolver does return nothing when asking for data (if my hophoteziz above is rigth). Can this be fixed please? Thanks you, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 07:15:15 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 27 Aug 2005 11:15:15 +0000 GMT Subject: [MOBY-dev] what are services LSIDs good for? Message-ID: <1178247580-1125141356-cardhu_blackberry.rim.net-18035-@engine10-cell01> I think I said it was returned on the new codebase, which is only running on the test server - is that the one you are hitting? We thought about keeping trtack of versions and sending the WSDL of the service as the data, but the discussion bogged down on whether that was really what service data *should* be, so it never got resolved (excuse the pun!) M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 12:11:09 To:Moby Developers Subject: [MOBY-dev] what are services LSIDs good for? Having an LSID of a service instance (as returned by 'findService' from a registry) I can do two things: ask for data and ask for metadata (connected to this LSID). The metadata is not the topic here (now). What if I ask for data? I can get nothing back, indicating that there is no data associated with this service instance. And I think that I would get nothing because looking at the LSID now it does not seem to indicate any data (it does not have any version etc., for example). I may be wrong, but let's assume, only hypotetically, that I am not wrong and that really I do not get back any data. That's a pity because I want to improve my cache-aware clients by storing LSID in my cache, then asking for a list of services, and by comparing what I have and what I get, I can update in my cache only services that changed. Two problems with that: 1) The list of services (method retrieveServices) does not return LSIDs. Bad luck. Mark, you sent an email saying that lsid attribute is now everywhere. Well, it is not... 2) LSID resolver does return nothing when asking for data (if my hophoteziz above is rigth). Can this be fixed please? Thanks you, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Sat Aug 27 07:25:43 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 12:25:43 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <1178247580-1125141356-cardhu_blackberry.rim.net-18035-@engine10-cell01> Message-ID: > I think I said it was returned on the new codebase, which is only > running on the test server - is that the one you are hitting? > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > We thought about keeping trtack of versions and sending the WSDL of > the service as the data, but the discussion bogged down on whether > that was really what service data *should* be, so it never got > resolved (excuse the pun!) > I know about this discussion. I actually do not care what will be returned back (at least not now), but I do care that the LSID of a registered service will chnage if I re-register the same service and I change something in it. That's what LSIDs are for, not? Can that be done? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 12:21:27 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 27 Aug 2005 09:21:27 -0700 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <43109307.70402@illuminae.com> Hit the test server: http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl We are planning to keep version numbers of services, but this is waiting on the agent, and the agent is waiting on the final decision on an RDF document format describing a service. Eddie is back from holiday on Monday and this is the first thing on his list, so it should all come together quickly from here on! M Martin Senger wrote: >>I think I said it was returned on the new codebase, which is only >>running on the test server - is that the one you are hitting? >> >> >> > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > > > >>We thought about keeping trtack of versions and sending the WSDL of >>the service as the data, but the discussion bogged down on whether >>that was really what service data *should* be, so it never got >>resolved (excuse the pun!) >> >> >> > I know about this discussion. I actually do not care what will be >returned back (at least not now), but I do care that the LSID of a >registered service will chnage if I re-register the same service and I >change something in it. That's what LSIDs are for, not? > Can that be done? > > Martin > > > From senger at ebi.ac.uk Sat Aug 27 12:30:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 17:30:31 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <43109307.70402@illuminae.com> Message-ID: > Hit the test server: > > http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl > This has only two services and neither of them has an LSID as an attribute. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Aug 27 12:33:25 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 17:33:25 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <43109307.70402@illuminae.com> Message-ID: > We are planning to keep version numbers of services > Good. Please keep in mind my suggestion *not* to return WSDL as service data (I told it to Eddie already in Malaga; there is no sense to duplicate this feature if we have it already in registry API) but returns instead a fingerprint of data that are registered. So if a provider re-register the LSID changes and people can se that a new version of a service is there. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From tmo at ebi.ac.uk Sat Aug 27 12:49:43 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Sat, 27 Aug 2005 17:49:43 +0100 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <431099A7.7000902@ebi.ac.uk> Martin Senger wrote: >>We are planning to keep version numbers of services >> > > Good. Please keep in mind my suggestion *not* to return WSDL as service > data (I told it to Eddie already in Malaga; there is no sense to duplicate > this feature if we have it already in registry API) but returns instead a > fingerprint of data that are registered. So if a provider re-register the > LSID changes and people can se that a new version of a service is there. Should there be anything returned as LSID data for a service? A service is an abstract entity, it doesn't have a physical existance so it's meaningless (according to the LSID specification) to return data for it. Something like a protein sequence has a real world entity which can have various literal representations (hence having an abstract root sequence object which referes in the metadata to various concrete LSIDs for each format) but in this case there is no real world object. LSIDs for services should only return metadata, they shouldn't return data in any form whatsoever. If you want to return metadata pointing to a servicedescription LSID (or whatever) and have the data for the servicedescription be a WSDL that would sound reasonable but the service itself is an abstract entity. It would be exactly as reasonable to return a bitmap image of the server hardware... Tom From senger at ebi.ac.uk Sat Aug 27 13:03:00 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 18:03:00 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <431099A7.7000902@ebi.ac.uk> Message-ID: Tom, No, Tom, I disagree. There is no reason why abstract term/entities could not have a real data associated. And I gave a good reason how I would use such data. A "service instance" (an unfortunate name of a service fingerprint in a registry invented by a bilogist) is a real object in a registry, and I am asking to give LSID data to reflect the fact that it is important and useful to know whether such object in registry changed or not. Of course, and you are right, that the same can be achieved from metadata. But it would mean that if I need information about all services, I would need to go to all service providers (because they act as LSID metadata resolvers) - and not just to one place where this information is already stored. And, to be fair, where the API for such simple task is easy enough. As long as we have a central registry (and everytime I listen to Mark I have feeling that he is going as much as possible not to have it :-)) why not to use it efficiently for what it was designed (this time the same biologist had luckier hand). Nice to hear again from you, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 22:50:37 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun, 28 Aug 2005 02:50:37 +0000 GMT Subject: [MOBY-dev] Migration of database to new API Message-ID: <17778361-1125197479-cardhu_blackberry.rim.net-5182-@engine08-cell01> I don't see how flipping names back and forth over different underlying structures is a "meaningful and consistent" strategy... ?!?!?!!!???! M -----Original Message----- From: Benjamin Good Date: Sat, 27 Aug 2005 15:37:26 To:markw at illuminae.com, Core developer announcements Subject: Re: [MOBY-dev] Migration of database to new API Jumping in since I was mentioned ... In the current version of moby, as I understand it at least, I have to side with Martin on this (sorry Mark, don't fire me!). Ahab, as well as other generic clients, benefits substantially from meaningful object and service names. Taking your (Mark's) argument further, we might as well eliminate human-readable names altogether and simply assign a unique number to each one - which is fine for the use as a machine name, but totally useless to an anonymous human user of the data-type. To be precise, in the current formulation of BioMoby, the ONLY semantics associated with the data-types are encoded in the names of the objects. Thus, until we have a consistent framework for encoding semantics in another more robust fashion, like a separate ontology that has nothing to do with syntax, we should at least attempt to encourage meaningful and consistent naming strategies. -Ben On Aug 26, 2005, at 6:12 PM, mark wilkinson wrote: > I strongly disagree in return :-) > > If I have an object called "sequence" there is no indication in the > name that it is a fasta sequence or an embl sequence or a genbank > sequence or whatever. The fact that it is called sequence-v2 is no > more nor less confusing! > > (Ben is sitting here beside me in the pub chuckling about the > dangers of mixing semantics meaning into names :-) ) > > M > > > -----Original Message----- > From: Martin Senger > Date: Sat, 27 Aug 2005 02:06:55 > To:markw at illuminae.com, Core developer announcements dev at portal.open-bio.org> > Cc:mobydev > Subject: Re: [MOBY-dev] Migration of database to new API > > >> There is no need for a name change again. The object will forever >> be called -v2 >> >> It's just an identifier... >> >> > Strongly disagree. The names are visible to people in many > clients that > list them. They should be named sensibly. Adding an artificial > suffix v2 > just without any compelling reasons is a bad design (and there is no > compelling reason for that). > I will better stop now (you got me agian!?)... > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > >_______________________________________________ > 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 > > -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Mon Aug 29 10:32:30 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 29 Aug 2005 15:32:30 +0100 (BST) Subject: [MOBY-dev] Moses - Moby Services Support In-Reply-To: <1476.82.66.216.27.1118945157.squirrel@82.66.216.27> Message-ID: Hi all, My first month at Philippines, at IRRI, is almost finished. So it's time to announce some progress :-) I have commited code and a lot of documentation helping to write Biomoby services in Java. The idea is to generate classes for all registered data types and then generate skeleton for a new service. Its developer can extend such skeleton , put there the business logic without worries about the Biomoby XML and about the SOAP itself. These things should be hidden. It is similar what Paul Gordon provides for the clients, but here you can use strongly-type approach (having all data types generated). Or, you can say, that we can have more ways to do the same, like in Perl :-) As (almost) a side-effect, the generated code, because it has rich API/javadoc comments, can be used as a primitive browser of the biomoby registry. Here you can see the API for all data types and for all services as they are today (when I find a place where I can run a cronjob, we can have this API up-to-date anytime you look): http://www.ebi.ac.uk/~senger/jMoby/APIservices/index.html The documentation is in jMoby and can be viewed at: http://biomoby.org/moby-live/Java/docs/Moses.html. I hope you'll enjoy it and I am happy to hear your suggestions, bug reports (remember there is also a bugzilla open now, but feel free to send emails direcly to me) and anything bout Moses. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From wangch at cpsc.ucalgary.ca Mon Aug 29 13:44:34 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Mon, 29 Aug 2005 11:44:34 -0600 Subject: [MOBY-dev] Question on parser References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43134982.4020503@cpsc.ucalgary.ca> Hi all, I have a question about the parser. I am working on making my service to take mutiple sequences (up to 5000 and more) input. When I tested on 800 sequences, the time to take the parser to parse a 800 sequences is about 3 mins and 32 seconds. It took 14 mins to parse a 2000 sequences. It seems to take longer time when the input sequence size increases. Is this normal? I think the time should not be too much difference for parsing different size sequence input. Could anybody explain this "problem" to me? Thanks. Joyce From markw at illuminae.com Mon Aug 29 13:45:55 2005 From: markw at illuminae.com (mark wilkinson) Date: Mon, 29 Aug 2005 17:45:55 +0000 GMT Subject: [MOBY-dev] Re: Question on parser Message-ID: <1690593290-1125337603-cardhu_blackberry.rim.net-28949-@engine13-cell01> Define "parser"... What parser are you talking about? M -----Original Message----- From: Chunyan Wang Date: Mon, 29 Aug 2005 11:44:34 To:markw at illuminae.com, Core developer announcements Subject: Question on parser Hi all, I have a question about the parser. I am working on making my service to take mutiple sequences (up to 5000 and more) input. When I tested on 800 sequences, the time to take the parser to parse a 800 sequences is about 3 mins and 32 seconds. It took 14 mins to parse a 2000 sequences. It seems to take longer time when the input sequence size increases. Is this normal? I think the time should not be too much difference for parsing different size sequence input. Could anybody explain this "problem" to me? Thanks. Joyce -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Mon Aug 29 13:49:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 29 Aug 2005 18:49:59 +0100 (BST) Subject: [MOBY-dev] Question on parser In-Reply-To: <43134982.4020503@cpsc.ucalgary.ca> Message-ID: > Could anybody explain this "problem" to me? Thanks. > What language are you using, what XML library in that language? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Aug 29 15:45:07 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 29 Aug 2005 12:45:07 -0700 Subject: [moby] Re: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <1125344707.16473.17.camel@bioinfo.icapture.ubc.ca> On Sat, 2005-08-27 at 17:30 +0100, Martin Senger wrote: > This has only two services and neither of them has an LSID as an > attribute. I think they have an LSID attribute (or at least, they do when I make the call), but that attribute has no value. I have just added an LSID value into the database manually so that you have something to retrieve, but don't try to resolve it, because it isn't "real" M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Mon Aug 29 15:45:37 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Mon, 29 Aug 2005 13:45:37 -0600 Subject: [MOBY-dev] Question on parser References: Message-ID: <431365E1.7080800@cpsc.ucalgary.ca> Martin Senger wrote: >>Could anybody explain this "problem" to me? Thanks. >> >> >> > What language are you using, what XML library in that language? > I am using Perl and XML::DOM. I am using "genericServiceInputParser($data)" to parse the input sequence in my service. By the way, I want to let you know I fixed timeout problem. Thanks for your suggestion. Joyce > Martin > > > From senger at ebi.ac.uk Mon Aug 29 20:06:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 30 Aug 2005 01:06:09 +0100 (BST) Subject: [moby] Re: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <1125344707.16473.17.camel@bioinfo.icapture.ubc.ca> Message-ID: > I think they have an LSID attribute (or at least, they do when I make > the call), but that attribute has no value. > Yes, that was also my observation. Hard to test if it is empty :-) > but don't try to resolve it, because it isn't "real" > Let us know please where things are real :-) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Aug 29 19:36:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 29 Aug 2005 16:36:34 -0700 Subject: [MOBY-dev] Production registry now running on new codebase Message-ID: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Mon Aug 29 22:08:44 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue, 30 Aug 2005 02:08:44 +0000 GMT Subject: [MOBY-dev] Moby central "Relationships" function is buggy Message-ID: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Hi all, Don't trust the output from "Relationships" in moby central. It seems to return only the immediate parent and root. I'm working on it. M -----Original Message----- From: Mark Wilkinson Date: Mon, 29 Aug 2005 16:36:34 To:mobydev Subject: [MOBY-dev] Production registry now running on new codebase Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 _______________________________________________ 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 Mon Aug 29 22:08:44 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue, 30 Aug 2005 02:08:44 +0000 GMT Subject: [MOBY-dev] Moby central "Relationships" function is buggy Message-ID: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Hi all, Don't trust the output from "Relationships" in moby central. It seems to return only the immediate parent and root. I'm working on it. M -----Original Message----- From: Mark Wilkinson Date: Mon, 29 Aug 2005 16:36:34 To:mobydev Subject: [MOBY-dev] Production registry now running on new codebase Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From carrere at toulouse.inra.fr Tue Aug 30 02:36:32 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Tue, 30 Aug 2005 08:36:32 +0200 Subject: [MOBY-dev] Question on parser In-Reply-To: <431365E1.7080800@cpsc.ucalgary.ca> References: <431365E1.7080800@cpsc.ucalgary.ca> Message-ID: <4313FE70.80308@toulouse.inra.fr> Hi all, I got the same problem when I wanted to parse huge XML files. That's why I have written a clone of CommonSub.pm using "xsltproc" to parse MOBY message. Then the parsing time problem was removed. However, how do you fixed timeout problem ? Sebastien Chunyan Wang wrote: > > > Martin Senger wrote: > >>> Could anybody explain this "problem" to me? Thanks. >>> >>> >> >> What language are you using, what XML library in that language? >> > I am using Perl and XML::DOM. I am using > "genericServiceInputParser($data)" to parse the input sequence in my > service. > By the way, I want to let you know I fixed timeout problem. Thanks for > your suggestion. > > Joyce > >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Tue Aug 30 11:01:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 30 Aug 2005 08:01:00 -0700 Subject: [moby] Re: [MOBY-dev] Question on parser In-Reply-To: <4313FE70.80308@toulouse.inra.fr> References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> Message-ID: <1125414060.19194.26.camel@bioinfo.icapture.ubc.ca> On Tue, 2005-08-30 at 08:36 +0200, Sebastien Carrere wrote: > That's why I have written a clone of CommonSub.pm using "xsltproc" to > parse MOBY message. Would you be willing to add this to the CVS? > However, how do you fixed timeout problem ? In the 1.0 release we should have a spec for asynchronous services, so this problem will hopefully not be as severe... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Tue Aug 30 12:17:56 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Tue, 30 Aug 2005 10:17:56 -0600 Subject: [MOBY-dev] Question on parser References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> Message-ID: <431486B4.6060700@cpsc.ucalgary.ca> Hi, I changed TimeOut from default to 50000 in the Apache config to fix timeout problem. How big was your XML file when you had problem? Cheers, Joyce Sebastien Carrere wrote: > Hi all, > > I got the same problem when I wanted to parse huge XML files. > That's why I have written a clone of CommonSub.pm using "xsltproc" to > parse MOBY message. > Then the parsing time problem was removed. > > However, how do you fixed timeout problem ? > > Sebastien > > Chunyan Wang wrote: > >> >> >> Martin Senger wrote: >> >>>> Could anybody explain this "problem" to me? Thanks. >>>> >>>> >>> >>> >>> What language are you using, what XML library in that language? >>> >> I am using Perl and XML::DOM. I am using >> "genericServiceInputParser($data)" to parse the input sequence in my >> service. >> By the way, I want to let you know I fixed timeout problem. Thanks >> for your suggestion. >> >> Joyce >> >>> Martin >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > From leolxshen at gmail.com Tue Aug 30 17:03:43 2005 From: leolxshen at gmail.com (leo shen) Date: Tue, 30 Aug 2005 14:03:43 -0700 Subject: [MOBY-dev] xml schema generator for Moby object committed Message-ID: Hi all, The java codes of XML schema generator has been commited in org/biomoby/shared/schema Cheers From dgpisano at cnb.uam.es Thu Aug 25 08:36:01 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu, 25 Aug 2005 14:36:01 +0200 Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <430DBB31.8070009@cnb.uam.es> Dear all, Here you have the Exception (Errors) reporting Request for Comments document. We have included some interesting comments taken from discussions / lists and rewritten it to make it more clear. It presents only one proposal to deal with error information, although it has also presents an extension option to report errors related to Simples into Collections. That extension can be considerered optional (we in the INB will be using it anyways). Please feel free to comment / discuss about it. Also, please feel free to use the document as guinea pig if we set up a procedure to deal with RFPs/RFCs in the MOBY community ;-) Regards, David Martin Senger escribi?: >>>but the problem is that we do not have (still) a procedure how to make >>>changes in the API. >>> >>> >>Correct. >> >> >> > So how are we going to solve this? > This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). > > 2) Then a calendar (deadline) must be attached to it. It can be >suggested already by the author of the RFP/RFC, or a default value is >attached. We need to say what is a default value. > > 3) The RFP can be considered only if the change is back-uped by two >(three?) other developers. They do not need to fully agree with all >details, their role is just to prevent overhelming number of small >changes coming fast. > > 4) It is also considered only if somebody has resources to really >implement the change. This should be also a part of the clendar ("when it >can be done"). > > 5) Discussion on RFC, changes re-distributed, etc. In charge is the >author of the original RFC. Deadline can be extended - don't be too formal >here. > > 6) Now the tricky part: I think taht there should be only few people >(major developers) who can vote on it. This is called an "Architecture >Board" at OMG and guarantees that the changes are hopefully not breaking >other things. > > 7) Then comes implementation, documenttaion etc. > > Cheers, > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v1.5.doc Type: application/msword Size: 139776 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050825/8c0dd56f/0501INB-ExceptionReporting-v1.5-0004.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050825/8c0dd56f/dgpisano-0004.vcf From goodb at interchange.ubc.ca Sat Aug 27 18:37:26 2005 From: goodb at interchange.ubc.ca (Benjamin Good) Date: Sat, 27 Aug 2005 15:37:26 -0700 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> References: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> Message-ID: Jumping in since I was mentioned ... In the current version of moby, as I understand it at least, I have to side with Martin on this (sorry Mark, don't fire me!). Ahab, as well as other generic clients, benefits substantially from meaningful object and service names. Taking your (Mark's) argument further, we might as well eliminate human-readable names altogether and simply assign a unique number to each one - which is fine for the use as a machine name, but totally useless to an anonymous human user of the data-type. To be precise, in the current formulation of BioMoby, the ONLY semantics associated with the data-types are encoded in the names of the objects. Thus, until we have a consistent framework for encoding semantics in another more robust fashion, like a separate ontology that has nothing to do with syntax, we should at least attempt to encourage meaningful and consistent naming strategies. -Ben On Aug 26, 2005, at 6:12 PM, mark wilkinson wrote: > I strongly disagree in return :-) > > If I have an object called "sequence" there is no indication in the > name that it is a fasta sequence or an embl sequence or a genbank > sequence or whatever. The fact that it is called sequence-v2 is no > more nor less confusing! > > (Ben is sitting here beside me in the pub chuckling about the > dangers of mixing semantics meaning into names :-) ) > > M > > > -----Original Message----- > From: Martin Senger > Date: Sat, 27 Aug 2005 02:06:55 > To:markw at illuminae.com, Core developer announcements dev at portal.open-bio.org> > Cc:mobydev > Subject: Re: [MOBY-dev] Migration of database to new API > > >> There is no need for a name change again. The object will forever >> be called -v2 >> >> It's just an identifier... >> >> > Strongly disagree. The names are visible to people in many > clients that > list them. They should be named sensibly. Adding an artificial > suffix v2 > just without any compelling reasons is a bad design (and there is no > compelling reason for that). > I will better stop now (you got me agian!?)... > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > > _______________________________________________ > 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 > > From dgpisano at cnb.uam.es Thu Aug 25 08:36:01 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu, 25 Aug 2005 14:36:01 +0200 Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <430DBB31.8070009@cnb.uam.es> Dear all, Here you have the Exception (Errors) reporting Request for Comments document. We have included some interesting comments taken from discussions / lists and rewritten it to make it more clear. It presents only one proposal to deal with error information, although it has also presents an extension option to report errors related to Simples into Collections. That extension can be considerered optional (we in the INB will be using it anyways). Please feel free to comment / discuss about it. Also, please feel free to use the document as guinea pig if we set up a procedure to deal with RFPs/RFCs in the MOBY community ;-) Regards, David Martin Senger escribi?: >>>but the problem is that we do not have (still) a procedure how to make >>>changes in the API. >>> >>> >>Correct. >> >> >> > So how are we going to solve this? > This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). > > 2) Then a calendar (deadline) must be attached to it. It can be >suggested already by the author of the RFP/RFC, or a default value is >attached. We need to say what is a default value. > > 3) The RFP can be considered only if the change is back-uped by two >(three?) other developers. They do not need to fully agree with all >details, their role is just to prevent overhelming number of small >changes coming fast. > > 4) It is also considered only if somebody has resources to really >implement the change. This should be also a part of the clendar ("when it >can be done"). > > 5) Discussion on RFC, changes re-distributed, etc. In charge is the >author of the original RFC. Deadline can be extended - don't be too formal >here. > > 6) Now the tricky part: I think taht there should be only few people >(major developers) who can vote on it. This is called an "Architecture >Board" at OMG and guarantees that the changes are hopefully not breaking >other things. > > 7) Then comes implementation, documenttaion etc. > > Cheers, > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v1.5.doc Type: application/msword Size: 139776 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050825/8c0dd56f/0501INB-ExceptionReporting-v1.5-0005.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050825/8c0dd56f/dgpisano-0005.vcf From senger at ebi.ac.uk Tue Aug 30 21:38:51 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:38:51 +0100 (BST) Subject: [MOBY-dev] Production registry now running on new codebase In-Reply-To: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Message-ID: I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger at gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 21:38:51 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:38:51 +0100 (BST) Subject: [MOBY-dev] Production registry now running on new codebase In-Reply-To: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Message-ID: I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger at gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 21:23:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:23:31 +0100 (BST) Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <430DBB31.8070009@cnb.uam.es> Message-ID: Thanks for the updated document. Before I express my comments to it here is a few bits regarding RFC procedure for this proposal (assuming that we agreed on an RFC procedure as, or close to, suggested in previous emails: 1) I second the proposal (so it can become an RFC) 2) I suggest to resolve it (accept or refuse) before September 15 (so this is an RFC calendar). Concretely, I propose that Mark will ask selected voters after this date to vote on it. (BTW, I like and support his idea to have a year-long tenure on the voting list (that's actually very close why OMG has its Architecture Board also with rotating, and *dedicated*, people). Now back to the proposal, here are my comments (I suggest that those comments that are acceptable by the INB authors, and that are not in contradiction with the email discussion, will be incorporate and a new draft will be circulated - perhaps already without reasoning). Generally, I like the proposal, my comments are only about details. 1) The attribute names 'Value' and 'Description' are not intuitive. They should express more what they are about. What about "errorCode" (or only "code") and "errorMessage" (or only "message")? 2) I know that the article name in Simples in Collection is an optional part of the proposal - but I agree with Mark that using there again the term "articleName" is bad (too overloaded). What about to use there a completely different tag, like "elementId"? >From this change (if accepted) follows at once that the attribute name in mobyException should not be "refArticleName" (because sometimes it refers to a non-article name) - so why not to call it just a "ref", or "refElement"? 3) I would like to have (in the exception API handling) a remark that the clients are obliged to be aware that a service can also raise an exception that will be delivered in the SOAP envelope (that is a standard way). As I said, good clients have to do it anyway (because your service does not have always full control what to return back) - so I would keep this option there. 4) Just to keep in synch with other software projects, I would add one more severity level - a simple "message" (so we would have, errors, warnings, messages). 5) The list of codes is not always clear: - should the sub-phrases in 201 be distinguish by a separate code? - 621 (service not available) means actually that the resources the service wishes to use are not available (because if it was a service itself, it would not have any chance to report it, that would be a soap exception mentioned above), - 622 (malformed Moby response) - what is a response here? - and anyway, this may be difficult to catch (I know in SOAP::Lite you do not get control only when the whole XML is parsed) - why do you call some codes "client-side detected errors"? - generally, I would put less codes and rather to define how service providers can expressed their own service-specific codes (by saying in which range they should put such specific codes) 6) Some typos: - articlename attribute should be articleName - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is something else in Biomoby API) 7) Attributes in mobyException (refArticleName, or whatever name we will agree on, and reqQuery) should be made optional - so an exception can refer to the whole response (or to a whole query if only reqQuery is present). With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 21:23:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:23:31 +0100 (BST) Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <430DBB31.8070009@cnb.uam.es> Message-ID: Thanks for the updated document. Before I express my comments to it here is a few bits regarding RFC procedure for this proposal (assuming that we agreed on an RFC procedure as, or close to, suggested in previous emails: 1) I second the proposal (so it can become an RFC) 2) I suggest to resolve it (accept or refuse) before September 15 (so this is an RFC calendar). Concretely, I propose that Mark will ask selected voters after this date to vote on it. (BTW, I like and support his idea to have a year-long tenure on the voting list (that's actually very close why OMG has its Architecture Board also with rotating, and *dedicated*, people). Now back to the proposal, here are my comments (I suggest that those comments that are acceptable by the INB authors, and that are not in contradiction with the email discussion, will be incorporate and a new draft will be circulated - perhaps already without reasoning). Generally, I like the proposal, my comments are only about details. 1) The attribute names 'Value' and 'Description' are not intuitive. They should express more what they are about. What about "errorCode" (or only "code") and "errorMessage" (or only "message")? 2) I know that the article name in Simples in Collection is an optional part of the proposal - but I agree with Mark that using there again the term "articleName" is bad (too overloaded). What about to use there a completely different tag, like "elementId"? >From this change (if accepted) follows at once that the attribute name in mobyException should not be "refArticleName" (because sometimes it refers to a non-article name) - so why not to call it just a "ref", or "refElement"? 3) I would like to have (in the exception API handling) a remark that the clients are obliged to be aware that a service can also raise an exception that will be delivered in the SOAP envelope (that is a standard way). As I said, good clients have to do it anyway (because your service does not have always full control what to return back) - so I would keep this option there. 4) Just to keep in synch with other software projects, I would add one more severity level - a simple "message" (so we would have, errors, warnings, messages). 5) The list of codes is not always clear: - should the sub-phrases in 201 be distinguish by a separate code? - 621 (service not available) means actually that the resources the service wishes to use are not available (because if it was a service itself, it would not have any chance to report it, that would be a soap exception mentioned above), - 622 (malformed Moby response) - what is a response here? - and anyway, this may be difficult to catch (I know in SOAP::Lite you do not get control only when the whole XML is parsed) - why do you call some codes "client-side detected errors"? - generally, I would put less codes and rather to define how service providers can expressed their own service-specific codes (by saying in which range they should put such specific codes) 6) Some typos: - articlename attribute should be articleName - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is something else in Biomoby API) 7) Attributes in mobyException (refArticleName, or whatever name we will agree on, and reqQuery) should be made optional - so an exception can refer to the whole response (or to a whole query if only reqQuery is present). With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Tue Aug 30 21:40:20 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed, 31 Aug 2005 01:40:20 +0000 GMT Subject: [MOBY-dev] Production registry now running on new codebase Message-ID: <1929607892-1125452470-cardhu_blackberry.rim.net-30717-@engine12-cell01> Let's use bugzilla rather than the list, though... M -----Original Message----- From: Martin Senger Date: Wed, 31 Aug 2005 02:38:51 To:markw at illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Production registry now running on new codebase I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger at gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Tue Aug 30 21:49:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:49:01 +0100 (BST) Subject: [MOBY-dev] Moby central "Relationships" function is buggy In-Reply-To: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Message-ID: > Don't trust the output from "Relationships" in moby central. It seems > to return only the immediate parent and root. I'm working on it. > Actually, for me, it does not return anything, at all: METHOD CALL: Relationships ------------ GenericSequenceISAHASAHAS1 ------------ METHOD RETURN: ------------ Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 21:49:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:49:01 +0100 (BST) Subject: [MOBY-dev] Moby central "Relationships" function is buggy In-Reply-To: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Message-ID: > Don't trust the output from "Relationships" in moby central. It seems > to return only the immediate parent and root. I'm working on it. > Actually, for me, it does not return anything, at all: METHOD CALL: Relationships ------------ GenericSequenceISAHASAHAS1 ------------ METHOD RETURN: ------------ Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 23:30:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 04:30:12 +0100 (BST) Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: Frank, I am slowly starting to read your version of API. I am sorry that I have not read it whole, and that I am giving the comments step by step. The first few comments about the registry API: * I think that the first page (with a list of methods) should also have (even start with) a list of links to objects used by these methods, such as a query object. * I disagree with labelling the deregisteService as depracated. As far as I understood, it will be still around for quick resgiter/unregister cycle where I am not conceedrn about security (that somebody can deregister my service). So from the API point of view it is a normal method, not a deprecated one. Mark? * service protocol "moby" is actually a service category, not a protocol I think * I would move definition of a "A MOBY compliant service" to the section about services API (here may be just a link to it). As I said I am really concern that these two APIs are (or were before you enter the scene) confusing, so make them as separate as possible. * retrieveResourceURLs has a wrong description (something about providers) * some details have also categories cgi.soap, some not... I suggest to remove all cgi and sopa for now (we will have in in the CVS if we need it to re-introsduce it later; surely the 'soap' category bring nothing than a confusion (isn't it current moby based on soap? - I know how it is, but newbies perhaps not) * the notes starting the section " MOBY Central Procedure Call XML" shoulod be on the first page, or linked in the first page". And the last (but not an unimportant) general comment: the XML-based API should be expressed as DTD (which is more preferable in this context, XSD is not so human readable). Also the details about individual tags and attributes are quitel imited now. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Aug 30 23:30:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 04:30:12 +0100 (BST) Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: Frank, I am slowly starting to read your version of API. I am sorry that I have not read it whole, and that I am giving the comments step by step. The first few comments about the registry API: * I think that the first page (with a list of methods) should also have (even start with) a list of links to objects used by these methods, such as a query object. * I disagree with labelling the deregisteService as depracated. As far as I understood, it will be still around for quick resgiter/unregister cycle where I am not conceedrn about security (that somebody can deregister my service). So from the API point of view it is a normal method, not a deprecated one. Mark? * service protocol "moby" is actually a service category, not a protocol I think * I would move definition of a "A MOBY compliant service" to the section about services API (here may be just a link to it). As I said I am really concern that these two APIs are (or were before you enter the scene) confusing, so make them as separate as possible. * retrieveResourceURLs has a wrong description (something about providers) * some details have also categories cgi.soap, some not... I suggest to remove all cgi and sopa for now (we will have in in the CVS if we need it to re-introsduce it later; surely the 'soap' category bring nothing than a confusion (isn't it current moby based on soap? - I know how it is, but newbies perhaps not) * the notes starting the section " MOBY Central Procedure Call XML" shoulod be on the first page, or linked in the first page". And the last (but not an unimportant) general comment: the XML-based API should be expressed as DTD (which is more preferable in this context, XSD is not so human readable). Also the details about individual tags and attributes are quitel imited now. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From carrere at toulouse.inra.fr Wed Aug 31 02:46:36 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Wed, 31 Aug 2005 08:46:36 +0200 Subject: [MOBY-dev] Question on parser In-Reply-To: <431486B4.6060700@cpsc.ucalgary.ca> References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> <431486B4.6060700@cpsc.ucalgary.ca> Message-ID: <4315524C.6040307@toulouse.inra.fr> The MOBY message that I wanted to parse was a 12 Megabyte one. The web-service concerned is: name: ImgaGetTigrXMLEntriesFromKeyword uri: bioinfo.genopole-toulouse.prd.fr input: String Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /IMGA_Accession, as IMGA_Accession I think this is a little bit extreme, but it works fine now. Sebastien Chunyan Wang wrote: > Hi, > I changed TimeOut from default to 50000 in the Apache config to fix > timeout problem. > How big was your XML file when you had problem? > Cheers, > > Joyce > > Sebastien Carrere wrote: > >> Hi all, >> >> I got the same problem when I wanted to parse huge XML files. >> That's why I have written a clone of CommonSub.pm using "xsltproc" to >> parse MOBY message. >> Then the parsing time problem was removed. >> >> However, how do you fixed timeout problem ? >> >> Sebastien >> >> Chunyan Wang wrote: >> >>> >>> >>> Martin Senger wrote: >>> >>>>> Could anybody explain this "problem" to me? Thanks. >>>>> >>>>> >>>> >>>> >>>> >>>> What language are you using, what XML library in that language? >>>> >>> I am using Perl and XML::DOM. I am using >>> "genericServiceInputParser($data)" to parse the input sequence in my >>> service. >>> By the way, I want to let you know I fixed timeout problem. Thanks >>> for your suggestion. >>> >>> Joyce >>> >>>> Martin >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Wed Aug 31 15:39:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 31 Aug 2005 12:39:44 -0700 Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-31 at 02:23 +0100, Martin Senger wrote: > 2) I suggest to resolve it (accept or refuse) before September 15 (so > this is an RFC calendar). Concretely, I propose that Mark will ask > selected voters after this date to vote on it. OK. I will be on holiday that day in the mountains (likely with no net access even from my cell phone) so perhaps David or Martin can call the vote in my absence? > (BTW, I like and > support his idea to have a year-long tenure on the voting list (that's > actually very close why OMG has its Architecture Board also with > rotating, and *dedicated*, people). Super! I'll try to write-up a formal "constitution" document in the next few days... > 1) The attribute names 'Value' and 'Description' are not > intuitive. They should express more what they are about. What about > "errorCode" (or only "code") and "errorMessage" (or only "message")? I agree. > 2) I know that the article name in Simples in Collection is an > optional part of the proposal - but I agree with Mark that using there > again the term "articleName" is bad (too overloaded). What about to > use there a completely different tag, like "elementId"? I think I proposed this alternative as well. I do have a deeper concern, however, and I want to discuss this thoroughly before we make any decisions here. It isn't entirely clear to me that there is a need to throw errors on a specific Simple within a Collection. This is very complicated for me to explain clearly, but I will try... A collection is a "semantic unit" - it is the response to a ***single*** input. As such, it cannot be partially erroneous! It is either entirely erroneous, or entirely correct. To throw an error on a single sub-unit of a collection casts doubt on the validity of the entire collection (since you cannot interpret what the collection would have "looked like" had that error not been thrown) and thus the entire collection must be considered flawed. Imagine it this way: What would it mean to have a Blast report where certain HSP's within the Blast report contained error messages? Does it mean that there was a sequence in the underlying database that was somehow incorrectly formatted If so, then the blast provider should have caught that error and not reported that match at all rather than telling the client that there is a flakey sequence in their database. Does it mean that the software is buggy? If so, then the entire report is potentially flawed, and should not have been produced. Does it mean that (in some way) the input sequence was peculiar? If so, then again the entire output is suspect and not just a single HSP within that output. Do you see what I am getting at? The scenario we are trying to accommodate, in my opinion, is impossible if people are using Collections in the way they are intended to be used. > 3) I would like to have (in the exception API handling) a remark that > the clients are obliged to be aware that a service can also raise an > exception that will be delivered in the SOAP envelope (that is a > standard way). As I said, good clients have to do it anyway (because > your service does not have always full control what to return back) - > so I would keep this option there. Absolutely! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 31 15:39:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 31 Aug 2005 12:39:44 -0700 Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-31 at 02:23 +0100, Martin Senger wrote: > 2) I suggest to resolve it (accept or refuse) before September 15 (so > this is an RFC calendar). Concretely, I propose that Mark will ask > selected voters after this date to vote on it. OK. I will be on holiday that day in the mountains (likely with no net access even from my cell phone) so perhaps David or Martin can call the vote in my absence? > (BTW, I like and > support his idea to have a year-long tenure on the voting list (that's > actually very close why OMG has its Architecture Board also with > rotating, and *dedicated*, people). Super! I'll try to write-up a formal "constitution" document in the next few days... > 1) The attribute names 'Value' and 'Description' are not > intuitive. They should express more what they are about. What about > "errorCode" (or only "code") and "errorMessage" (or only "message")? I agree. > 2) I know that the article name in Simples in Collection is an > optional part of the proposal - but I agree with Mark that using there > again the term "articleName" is bad (too overloaded). What about to > use there a completely different tag, like "elementId"? I think I proposed this alternative as well. I do have a deeper concern, however, and I want to discuss this thoroughly before we make any decisions here. It isn't entirely clear to me that there is a need to throw errors on a specific Simple within a Collection. This is very complicated for me to explain clearly, but I will try... A collection is a "semantic unit" - it is the response to a ***single*** input. As such, it cannot be partially erroneous! It is either entirely erroneous, or entirely correct. To throw an error on a single sub-unit of a collection casts doubt on the validity of the entire collection (since you cannot interpret what the collection would have "looked like" had that error not been thrown) and thus the entire collection must be considered flawed. Imagine it this way: What would it mean to have a Blast report where certain HSP's within the Blast report contained error messages? Does it mean that there was a sequence in the underlying database that was somehow incorrectly formatted If so, then the blast provider should have caught that error and not reported that match at all rather than telling the client that there is a flakey sequence in their database. Does it mean that the software is buggy? If so, then the entire report is potentially flawed, and should not have been produced. Does it mean that (in some way) the input sequence was peculiar? If so, then again the entire output is suspect and not just a single HSP within that output. Do you see what I am getting at? The scenario we are trying to accommodate, in my opinion, is impossible if people are using Collections in the way they are intended to be used. > 3) I would like to have (in the exception API handling) a remark that > the clients are obliged to be aware that a service can also raise an > exception that will be delivered in the SOAP envelope (that is a > standard way). As I said, good clients have to do it anyway (because > your service does not have always full control what to return back) - > so I would keep this option there. Absolutely! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 31 20:10:39 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 1 Sep 2005 01:10:39 +0100 (BST) Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> Message-ID: > It isn't entirely clear to me that there is a need to throw errors on a > specific Simple within a Collection. > I quite like how Mark explained it, and it makes sense to me. I am just not too concerned because this part is just an optional part - so the only "mandatory" part in the API (regarding this issue) will/would be "...and ignore other possibly present attributes in the Simples in a Collection". But still, I am interested to hear David's argumentation againts Mark's explanation. David, do you have a real-life use-case where you expect to create such response? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 20:10:39 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 1 Sep 2005 01:10:39 +0100 (BST) Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> Message-ID: > It isn't entirely clear to me that there is a need to throw errors on a > specific Simple within a Collection. > I quite like how Mark explained it, and it makes sense to me. I am just not too concerned because this part is just an optional part - so the only "mandatory" part in the API (regarding this issue) will/would be "...and ignore other possibly present attributes in the Simples in a Collection". But still, I am interested to hear David's argumentation againts Mark's explanation. David, do you have a real-life use-case where you expect to create such response? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 21:19:25 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 1 Sep 2005 02:19:25 +0100 (BST) Subject: [MOBY-dev] jMoby: problems with Ant under Windows Message-ID: You are a pool of clever and experiences people - would anybody be able to help me to write (actually to fix) the current Ant's build.zml so it works fine also under Windows? I am desperately seeking an advise: 1) The command-line arguments when using target cannot remain empty (under Windows). For example, the command-line: java MosesGenerator -e "" -debug means (under Linux) a command-line with three arguments, but (under windows) a command-line with just two arguments (-e and -debug). Is there a solution for this, at all? 2) The target , when used with rich attributes (like bottom, headre etc.), does not work under windows. First I had to change double quotes into single quotes (okay, Ant should do it, but does not; but it's doable). Second I have to remove newlines from some XML elements - like the 'bottom' one (okay, doable, but annoying, again Any should do it - as it does for unix). But third: the line for javadoc is too long for windows. Well, if you have a windows running, try the current build.xml - try target 'docs' - and you will see what I am talking about, and perhaps you will kniw how to rectiry. Many thanks for your help, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Aug 31 21:24:35 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 31 Aug 2005 18:24:35 -0700 Subject: [MOBY-dev] jMoby: problems with Ant under Windows In-Reply-To: Message-ID: <43165859.64ac00f0.3259.3e66@mx.gmail.com> Don't yell at me, but all that windows needed was a good 'clean'ing. Thanks. Ed > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Martin > Senger > Sent: Wednesday, August 31, 2005 6:19 PM > To: Moby Developers > Subject: [MOBY-dev] jMoby: problems with Ant under Windows > > You are a pool of clever and experiences people - would > anybody be able to > help me to write (actually to fix) the current Ant's > build.zml so it works > fine also under Windows? I am desperately seeking an > advise: > > 1) The command-line arguments when using target > cannot remain empty > (under Windows). For example, the command-line: > java MosesGenerator -e "" -debug > means (under Linux) a command-line with three arguments, > but (under > windows) a command-line with just two arguments (-e and - > debug). Is there > a solution for this, at all? > > 2) The target , when used with rich attributes > (like bottom, > headre etc.), does not work under windows. First I had to > change double > quotes into single quotes (okay, Ant should do it, but > does not; but it's > doable). Second I have to remove newlines from some XML > elements - like > the 'bottom' one (okay, doable, but annoying, again Any > should do it - as > it does for unix). But third: the line for javadoc is too > long for > windows. Well, if you have a windows running, try the > current build.xml - > try target 'docs' - and you will see what I am talking > about, and perhaps > you will kniw how to rectiry. > > Many thanks for your help, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From hase at umbc.edu Tue Aug 2 03:30:31 2005 From: hase at umbc.edu (HASE) Date: Mon, 1 Aug 2005 23:30:31 -0400 (EDT) Subject: [MOBY-dev] Bioinformatics Software Development Survey Message-ID: <2015.68.49.173.177.1122953431.squirrel@68.49.173.177> Hello, As part of our research at UMBC, we are studying the characteristics of software development in the bioinformatics domain. We believe that this study should be guided by the people who are actively involved in bioinformatics. This research is our first step towards enabling the production of high quality bioinformatics software with less time and effort. Therefore, your feedback is very important to us. We seek your input in the form of a survey questionnaire that will take around 15 minutes of your time. We solicit general demographic information, information about the products that you have developed, your work practices, and your software development process. So, if you are a bioinformatics professional doing software development or a software developer working in the bioinformatics domain, please provide us with your valuable input. We assure you that this information will be used only for academic purposes and will be completely confidential. Please follow the link below to start the survey: http://www.is.umbc.edu/bio-survey/ We appreciate your participation in advance. Regards, HASE (Human Aspects of Software Engineering) 1000 Hilltop Circle Department of Information Systems University of Maryland Baltimore County Baltimore, MD, 21250 hase at umbc.edu From senger at ebi.ac.uk Wed Aug 3 04:23:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 3 Aug 2005 05:23:29 +0100 (BST) Subject: [MOBY-dev] 0.85 codebase running on test server In-Reply-To: <1122672917.19643.31.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, These are good news. Things are moving forwards, that's great. One thing that I missed in your "in the pipelines" section is an implementation of an API giving back URLs of the various RESOURCES. I really needs this soon - so I can code various things using data in RDF (which is much faster than to get things one-by-obe from the registry by the traditional API calls). Would you consider to give it higher priority please? Thanks and regards, Martin -- Martin Senger martin.senger at gmail.com From senger at ebi.ac.uk Wed Aug 3 04:23:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 3 Aug 2005 05:23:29 +0100 (BST) Subject: [MOBY-dev] 0.85 codebase running on test server In-Reply-To: <1122672917.19643.31.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, These are good news. Things are moving forwards, that's great. One thing that I missed in your "in the pipelines" section is an implementation of an API giving back URLs of the various RESOURCES. I really needs this soon - so I can code various things using data in RDF (which is much faster than to get things one-by-obe from the registry by the traditional API calls). Would you consider to give it higher priority please? Thanks and regards, Martin -- Martin Senger martin.senger at gmail.com From markw at illuminae.com Thu Aug 4 09:31:15 2005 From: markw at illuminae.com (markw at illuminae.com) Date: Thu, 4 Aug 2005 05:31:15 -0400 Subject: [MOBY-dev] articleName legacy cruft... Message-ID: <1123147875.42f1e06355b9f@webmail.illuminae.com> Hi all, the presence of "articleName" in the Simple/Collection and Secondary tags is really bothering me, given that it is used with a different meaning in the objects (this is legacy cruft that has now become fixed into the code!) It's a fairly significant modification to change this to "componentName"... but I am itching to do it! Given that we are about to break things anyway with the 1.0 release, should we break this at the same time? M From markw at illuminae.com Thu Aug 4 09:38:25 2005 From: markw at illuminae.com (markw at illuminae.com) Date: Thu, 4 Aug 2005 05:38:25 -0400 Subject: [MOBY-dev] Changes in the 0.86API Message-ID: <1123148305.42f1e211565c7@webmail.illuminae.com> Hi all, A few changes to announce for the 0.86 API (this is not yet running on the production server): 1) *all* parameters going into a service must now be named (currently using the articleName attribute of the Simple/Collection/Parameter tag, but I want to migrate this to componentName if possible) 2) Inheritence from primitive classes is now forbidden and this is enforced by the MOBY Central code. 3) Collections may now only contain one type of Simple (I don't think anyone uses it any other way, so no worries) 4) a new method "retrieveResourceURLs" has been added to the API that provides you with a list of the URLs from which you can retrieve the RDF versions of all of the ontologies. I will be moving the production server to the new codebase next week sometime. Cheers! M From senger at ebi.ac.uk Thu Aug 4 13:16:57 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 4 Aug 2005 14:16:57 +0100 (BST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: > 1) *all* parameters going into a service must now be named (currently using the > articleName attribute of the Simple/Collection/Parameter tag, but I want to > migrate this to componentName if possible) > Generally it is a good idea (to have things named). I also remember that we had asked for in in Vancouver. But the change, even though may not be big in the code, is big in the documentation, in the API description. I would rather see first an updated API documentation, read it and only then have here a discussion about it. This is mainly we used the name 'article' not only as an XML attribute, but we had/have also an XML tag called 'secondaryArticle', we often speak about 'parameters' (as you just done above) but we mean by that actually all input data... and so on. Other issue is that the biomoby.org now has API086 from the August 3. But it does not have the changes described in your last email - and the email is labeled 'changes in the 0.86' - so you are actually describing changes that will be in 0.87API? I am confused... The normal practice - which I strongly suggest - is to keep on biomoby.org an API which works currently - and to have a separate page, where we can see 'proposed API' - which is not yet implemented, even it is not yet approved by us/developers and it serves for these discussions. I know that it is boring to keep docs updated but that is one of the issues we discussed in V. when we said that the current biomoby does not have enough of the 'project management' :-) Back to article names: I remember that in Malaga the ICN people had talked about their incoming proposal for more decent error handling in biomoby messages. For that, the article names were mandatory (so it is good that we are thinking about it in the same way) - but I think that they wanted to name also individual Simples in Collection. So it may be worth to make sure that they are listening now... > 2) Inheritence from primitive classes is now forbidden and this is enforced by > the MOBY Central code. > Again, this need to be documented first... > 4) a new method "retrieveResourceURLs" has been added to the API that provides > you with a list of the URLs from which you can retrieve the RDF versions of all > of the ontologies. > Here comes my previous email (send only to Mark) about how to make these (BIG) RDF documents compressed. One solution is to allow registry providers to specify two URLs for each resource type, one for normal and one for zipped document. > I will be moving the production server to the new codebase next week sometime. > No, don't do it so soon... Please... Describe it first in the API in details... Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Aug 4 13:16:57 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 4 Aug 2005 14:16:57 +0100 (BST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: > 1) *all* parameters going into a service must now be named (currently using the > articleName attribute of the Simple/Collection/Parameter tag, but I want to > migrate this to componentName if possible) > Generally it is a good idea (to have things named). I also remember that we had asked for in in Vancouver. But the change, even though may not be big in the code, is big in the documentation, in the API description. I would rather see first an updated API documentation, read it and only then have here a discussion about it. This is mainly we used the name 'article' not only as an XML attribute, but we had/have also an XML tag called 'secondaryArticle', we often speak about 'parameters' (as you just done above) but we mean by that actually all input data... and so on. Other issue is that the biomoby.org now has API086 from the August 3. But it does not have the changes described in your last email - and the email is labeled 'changes in the 0.86' - so you are actually describing changes that will be in 0.87API? I am confused... The normal practice - which I strongly suggest - is to keep on biomoby.org an API which works currently - and to have a separate page, where we can see 'proposed API' - which is not yet implemented, even it is not yet approved by us/developers and it serves for these discussions. I know that it is boring to keep docs updated but that is one of the issues we discussed in V. when we said that the current biomoby does not have enough of the 'project management' :-) Back to article names: I remember that in Malaga the ICN people had talked about their incoming proposal for more decent error handling in biomoby messages. For that, the article names were mandatory (so it is good that we are thinking about it in the same way) - but I think that they wanted to name also individual Simples in Collection. So it may be worth to make sure that they are listening now... > 2) Inheritence from primitive classes is now forbidden and this is enforced by > the MOBY Central code. > Again, this need to be documented first... > 4) a new method "retrieveResourceURLs" has been added to the API that provides > you with a list of the URLs from which you can retrieve the RDF versions of all > of the ontologies. > Here comes my previous email (send only to Mark) about how to make these (BIG) RDF documents compressed. One solution is to allow registry providers to specify two URLs for each resource type, one for normal and one for zipped document. > I will be moving the production server to the new codebase next week sometime. > No, don't do it so soon... Please... Describe it first in the API in details... Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From markw at illuminae.com Thu Aug 4 14:11:31 2005 From: markw at illuminae.com (markw at illuminae.com) Date: Thu, 4 Aug 2005 10:11:31 -0400 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <1123164691.42f222134a314@webmail.illuminae.com> Quoting Martin Senger : > Generally it is a good idea (to have things named). I also remember > that we had asked for in in Vancouver. But the change, even though may not > be big in the code, is big in the documentation, in the API description. I > would rather see first an updated API documentation, read it and only then > have here a discussion about it. This is mainly we used the name 'article' > not only as an XML attribute, but we had/have also an XML tag called > 'secondaryArticle', we often speak about 'parameters' (as you just done > above) but we mean by that actually all input data... and so on. > Other issue is that the biomoby.org now has API086 from the August > 3. But it does not have the changes described in your last email - and the > email is labeled 'changes in the 0.86' The changes I describe in my email are, in fact (I think??) documented in the 0.86 API that is on the website (see the change history at the bottom of the page), but you are correct that the current production server is not running the 0.86 API - it is running the 0.85 API. I have sent the main developers the endpoint of the instance of MOBY Central that is running the 0.86 codebase so that you can test it and begin the process of coding to it. I share your reservations about changing the articleName (in its "parameter" meaning) to componentName, given that we have many other tags in our XML messaging that use the word "Article" with the same intention. Perhaps it is better to change the MOBY Object articleName attribute to something else instead? That would likely require less changes in our code... One or the other of them really must go because they have two different meanings! > - so you are actually describing > changes that will be in 0.87API? I am confused... The normal practice - > which I strongly suggest - is to keep on biomoby.org an API which works > currently - and to have a separate page, where we can see 'proposed API' - > which is not yet implemented, even it is not yet approved by us/developers > and it serves for these discussions. This is a good idea... I will try to do that right now. I can get a diff of the current API versus the 0.85 API and then set up a second Twiki page from that diff. > I know that it is boring to keep docs > updated but that is one of the issues we discussed in V. when we said that > the current biomoby does not have enough of the 'project management' :-) It's not so much that it is boring (I actually enjoy documentation! What a pedantic nutter I am!), however it is really a matter of limited resourcing and time - it is rare for me to have so much time for coding, and as you have pointed out frequently, MOBY Central is currently a one-man-show for the most part, so when these moments arise I feel obligated to use it to push forward the codebase as far as possible rather than slowly and carefully as I would prefer :-/ I'm trying to keep you and the other core developers updated as to my activities, and I am similarly trying to limit my changes to those that were made in agreement with the attendees at the last meeting (i.e. that we have already discussed as a group), and to respond to those decisions as quickly as possible. Given the ten fingers I have, and the time constraints, that's the best I can manage... > Back to article names: I remember that in Malaga the ICN people had > talked about their incoming proposal for more decent error handling in > biomoby messages. For that, the article names were mandatory (so it is > good that we are thinking about it in the same way) - but I think that > they wanted to name also individual Simples in Collection. So it may be > worth to make sure that they are listening now... Eeek! I don't remember that... Can you recall why this was necessary? > > 2) Inheritence from primitive classes is now forbidden and this is > enforced by > > the MOBY Central code. > > > Again, this need to be documented first... It is, in the 0.86API. > > 4) a new method "retrieveResourceURLs" has been added to the API that > provides > > you with a list of the URLs from which you can retrieve the RDF versions of > all > > of the ontologies. > > > Here comes my previous email (send only to Mark) about how to make > these (BIG) RDF documents compressed. One solution is to allow registry > providers to specify two URLs for each resource type, one for normal and > one for zipped document. I guess the "safe" way to handle that would be to add a "type" attribute to the tag indicaing the MIME type of the document that is behind the URL (yeah... we could get that by calling HEAD, I guess...). It will be important to know this for software that needs to receive an ontology by calling the URL... > > I will be moving the production server to the new codebase next week > sometime. > > > No, don't do it so soon... Please... Describe it first in the API in > details... OK. The code is, however, up and running on the test server that I told you about yesterday. Cheers! M From gordonp at ucalgary.ca Thu Aug 4 14:56:22 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 04 Aug 2005 08:56:22 -0600 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> References: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: <42F22C96.3050106@ucalgary.ca> >2) Inheritence from primitive classes is now forbidden and this is enforced by >the MOBY Central code. > > May I humbly suggest that Boolean be considered primitive? I registered this object last week. >3) Collections may now only contain one type of Simple (I don't think anyone >uses it any other way, so no worries) > > Let me understand this though, if I declare a Collection of Objects, I should still be able to shove anything in there. If I declare a Collection of VirtualSequences, I should be able to put AminoAcidSequences and DNASequences in it. Otherwise we break the operational transparency of inheritence... From gordonp at ucalgary.ca Thu Aug 4 14:56:22 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 04 Aug 2005 08:56:22 -0600 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123148305.42f1e211565c7@webmail.illuminae.com> References: <1123148305.42f1e211565c7@webmail.illuminae.com> Message-ID: <42F22C96.3050106@ucalgary.ca> >2) Inheritence from primitive classes is now forbidden and this is enforced by >the MOBY Central code. > > May I humbly suggest that Boolean be considered primitive? I registered this object last week. >3) Collections may now only contain one type of Simple (I don't think anyone >uses it any other way, so no worries) > > Let me understand this though, if I declare a Collection of Objects, I should still be able to shove anything in there. If I declare a Collection of VirtualSequences, I should be able to put AminoAcidSequences and DNASequences in it. Otherwise we break the operational transparency of inheritence... From senger at ebi.ac.uk Thu Aug 4 15:47:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 4 Aug 2005 16:47:59 +0100 (BST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: <1123164691.42f222134a314@webmail.illuminae.com> Message-ID: > > Back to article names: I remember that in Malaga the ICN people had > > talked about their incoming proposal for more decent error handling in > > ... > Eeek! I don't remember that... Can you recall why this was necessary? > no, you were not there - it was the last meeting when Eddie and me were involved; perhaps Eddie remembers their suggestion, or to whom contact abou it (afaik they have not sent it yet) > I guess the "safe" way to handle that would be to add a "type" attribute to the > tag indicaing the MIME type of the document that is behind the URL > yes; and to allow returning several tags for the same resource name but with a different type; (Contra my recent advise: could you make it - so I can added it to jmoby :-) ... btw, jMoby already has the current way, without any compression, but I will wait for your reply before committing it tomorrow.) Cheers, Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From ots at ac.uma.es Thu Aug 4 16:03:34 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 4 Aug 2005 18:03:34 +0200 (CEST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: from "Martin Senger" at Aug 04, 2005 04:47:59 PM Message-ID: <200508041603.SAA24534@algarrobo.ac.uma.es> HI, I am sorry, but I am having a nice time near Barcelona and perhaps I have lost some messages. one week ago -more or less- we submitt a short proposal for error-handling The point to be considered is how to inform about an incidence (warning or error) when processing a collection (as a set of simples not as a "unit"). In this case it is necessary to identify each simple. one way is by using the articleName (which could be automatically produced by the client -in the worse case) sds, O. > > > Back to article names: I remember that in Malaga the ICN people had > > > talked about their incoming proposal for more decent error handling in > > > ... > > Eeek! I don't remember that... Can you recall why this was necessary? > > > no, you were not there - it was the last meeting when Eddie and me were > involved; perhaps Eddie remembers their suggestion, or to whom contact > abou it (afaik they have not sent it yet) > > > I guess the "safe" way to handle that would be to add a "type" attribute to the > > tag indicaing the MIME type of the document that is behind the URL > > > yes; and to allow returning several tags for the same > resource name but with a different type; > (Contra my recent advise: could you make it - so I can added it to > jmoby :-) ... btw, jMoby already has the current way, without any > compression, but I will wait for your reply before committing it > tomorrow.) > > Cheers, > Martin > > -- > Martin Senger martin.senger at gmail.com > > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Thu Aug 4 16:03:34 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 4 Aug 2005 18:03:34 +0200 (CEST) Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: from "Martin Senger" at Aug 04, 2005 04:47:59 PM Message-ID: <200508041603.SAA24534@algarrobo.ac.uma.es> HI, I am sorry, but I am having a nice time near Barcelona and perhaps I have lost some messages. one week ago -more or less- we submitt a short proposal for error-handling The point to be considered is how to inform about an incidence (warning or error) when processing a collection (as a set of simples not as a "unit"). In this case it is necessary to identify each simple. one way is by using the articleName (which could be automatically produced by the client -in the worse case) sds, O. > > > Back to article names: I remember that in Malaga the ICN people had > > > talked about their incoming proposal for more decent error handling in > > > ... > > Eeek! I don't remember that... Can you recall why this was necessary? > > > no, you were not there - it was the last meeting when Eddie and me were > involved; perhaps Eddie remembers their suggestion, or to whom contact > abou it (afaik they have not sent it yet) > > > I guess the "safe" way to handle that would be to add a "type" attribute to the > > tag indicaing the MIME type of the document that is behind the URL > > > yes; and to allow returning several tags for the same > resource name but with a different type; > (Contra my recent advise: could you make it - so I can added it to > jmoby :-) ... btw, jMoby already has the current way, without any > compression, but I will wait for your reply before committing it > tomorrow.) > > Cheers, > Martin > > -- > Martin Senger martin.senger at gmail.com > > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From jmrc at cnb.uam.es Thu Aug 4 16:28:34 2005 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Thu, 04 Aug 2005 18:28:34 +0200 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <42F24232.30207@cnb.uam.es> Martin Senger wrote: > Back to article names: I remember that in Malaga the_ ICN people_ had >talked about their incoming proposal for more decent error handling in >biomoby messages. For that, the article names were mandatory (so it is >good that we are thinking about it in the same way) - but I think that >they wanted to name also individual Simples in Collection. So it may be >worth to make sure that they are listening now... > > > Sorry Martin, but we are *INB* people! :-) http://www.inab.org Cheers, Jos? Manuel. From jmrc at cnb.uam.es Thu Aug 4 16:28:34 2005 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Thu, 04 Aug 2005 18:28:34 +0200 Subject: [MOBY-dev] Changes in the 0.86API In-Reply-To: References: Message-ID: <42F24232.30207@cnb.uam.es> Martin Senger wrote: > Back to article names: I remember that in Malaga the_ ICN people_ had >talked about their incoming proposal for more decent error handling in >biomoby messages. For that, the article names were mandatory (so it is >good that we are thinking about it in the same way) - but I think that >they wanted to name also individual Simples in Collection. So it may be >worth to make sure that they are listening now... > > > Sorry Martin, but we are *INB* people! :-) http://www.inab.org Cheers, Jos? Manuel. From jmfernandez at cnb.uam.es Fri Aug 5 19:10:00 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri, 05 Aug 2005 21:10:00 +0200 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY Message-ID: <42F3B988.7020506@cnb.uam.es> Hi everybody, I don't like crossposting, but I don't know if the bug I have found today is from the Taverna 1.2 core or the MOBY plugin. The bug is pretty simple: if you create/load a workflow which has a service whose name in the workflow is different from the service name, Taverna does not use the official service name when it is invoked. Instead, it uses the name given to the service in the workflow! The same workflow works flawlessly when it is loaded and run in Taverna 1.1. I have discovered the bug with a MOBY service (see the sample workflow ja5.xml, and the reports taverna-1.1-report.xml and taverna-1.2-report.xml), so I don't know which has the blame... This bug should arise when one service is used more than once, which is very common in real workflows! Best Regards, Jos? Mar?a Fern?ndez -- 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: ja5.xml Type: text/xml Size: 1813 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: taverna-1.1-report.xml Type: text/xml Size: 1796 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: taverna-1.2-report.xml Type: text/xml Size: 4405 bytes Desc: not available URL: From senger at ebi.ac.uk Sun Aug 7 23:47:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 8 Aug 2005 00:47:58 +0100 (BST) Subject: [MOBY-dev] jMoby updated Message-ID: Two new methods were added to the Central.java interface: * getResourceRefs() returns a list of URLs of available resources of a BioMoby registry (a "resource" is an RDF document describing registered entities), and * getResource() returns contents of a particular resource The implementation (in CentralImpl.java) seems to work now - but it may be slightly changed later when Mark adds possibility to fetch resources also in a compressed form. The new methods are also reflected in the main jMoby command line client - type 'build/run/run-cmdline-client -help'. I have also updated the 'Acknowledgements' section in the main jMoby page (http://www.biomoby.org/moby-live/Java/docs/index.html). Please feel free to add there your own funding sources. With regards, Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Mon Aug 8 13:42:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 8 Aug 2005 06:42:55 -0700 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F3B988.7020506@cnb.uam.es> Message-ID: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Hi, I think that that has been fixed. I actually noticed that bug when using the Planet workflows. So, like I said, it should be fixed. Out of curiosity, did you cvs build or download a prepackaged Taverna? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Friday, August 05, 2005 12:10 PM > To: taverna-users at lists.sourceforge.net; moby- > l at biomoby.org; mobydev; taverna- > hackers at lists.sourceforge.net > Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related > to BioMOBY > > Hi everybody, > I don't like crossposting, but I don't know if the > bug I have found > today is from the Taverna 1.2 core or the MOBY plugin. > > The bug is pretty simple: if you create/load a > workflow which has a > service whose name in the workflow is different from the > service name, > Taverna does not use the official service name when it is > invoked. > Instead, it uses the name given to the service in the > workflow! The same > workflow works flawlessly when it is loaded and run in > Taverna 1.1. > > I have discovered the bug with a MOBY service (see > the sample workflow > ja5.xml, and the reports taverna-1.1-report.xml and > taverna-1.2-report.xml), so I don't know which has the > blame... > > This bug should arise when one service is used more > than once, which is > very common in real workflows! > > Best Regards, > Jos? Mar?a Fern?ndez > -- > 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 edward.kawas at gmail.com Mon Aug 8 13:42:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 8 Aug 2005 06:42:55 -0700 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F3B988.7020506@cnb.uam.es> Message-ID: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Hi, I think that that has been fixed. I actually noticed that bug when using the Planet workflows. So, like I said, it should be fixed. Out of curiosity, did you cvs build or download a prepackaged Taverna? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Friday, August 05, 2005 12:10 PM > To: taverna-users at lists.sourceforge.net; moby- > l at biomoby.org; mobydev; taverna- > hackers at lists.sourceforge.net > Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related > to BioMOBY > > Hi everybody, > I don't like crossposting, but I don't know if the > bug I have found > today is from the Taverna 1.2 core or the MOBY plugin. > > The bug is pretty simple: if you create/load a > workflow which has a > service whose name in the workflow is different from the > service name, > Taverna does not use the official service name when it is > invoked. > Instead, it uses the name given to the service in the > workflow! The same > workflow works flawlessly when it is loaded and run in > Taverna 1.1. > > I have discovered the bug with a MOBY service (see > the sample workflow > ja5.xml, and the reports taverna-1.1-report.xml and > taverna-1.2-report.xml), so I don't know which has the > blame... > > This bug should arise when one service is used more > than once, which is > very common in real workflows! > > Best Regards, > Jos? Mar?a Fern?ndez > -- > 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 jmfernandez at cnb.uam.es Mon Aug 8 14:52:35 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon, 08 Aug 2005 16:52:35 +0200 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42f76179.195ac951.0c6c.100f@mx.gmail.com> References: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Message-ID: <42F771B3.8010600@cnb.uam.es> Hi Eddie, Edward Kawas wrote: > Hi, > > I think that that has been fixed. I actually noticed that > bug when using the Planet workflows. So, like I said, it > should be fixed. > Yes, Tom told me that on Friday. I was looking at CVS and as you have said, it seems it is fixed there. > Out of curiosity, did you cvs build or download a > prepackaged Taverna? > As you can imagine, I was working on a prepackaged Taverna 1.2 version :-(. We are working behind a firewall, and I was digging as an user how much functionality related to MOBY in Taverna 1.2 was affected by that fact. I realized that problem when I did a worflow with two branches, both branches with the same service and one of them had to be renamed. What I have seen is that object instances generated from the new object tree in BioMOBY scavenger use information from http://biomoby.org/RESOURCES/MOBY-S/Objects so those workflow branches with any of those object instantes stalled just inside them. I was digging on that URL, and I saw that all the rdf:about attributes (plus others, like rdf:resource in http://biomoby.org/RESOURCES/MOBY-S/Services) were referencing your Tomcat server at mobycentral.icapture.ubc.ca:8090. Is there some progress on MOBY Apache server with ProxyPass/ProxyPassReverse? Best Regards, 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 edward.kawas at gmail.com Mon Aug 8 14:54:20 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 8 Aug 2005 07:54:20 -0700 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F771B3.8010600@cnb.uam.es> Message-ID: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> Actually, give it a try now. It should work as Mark tweeked it! Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Monday, August 08, 2005 7:53 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] A bug in Taverna 1.2 perhaps > related to BioMOBY > > Hi Eddie, > > Edward Kawas wrote: > > Hi, > > > > I think that that has been fixed. I actually noticed > that > > bug when using the Planet workflows. So, like I said, it > > should be fixed. > > > > Yes, Tom told me that on Friday. I was looking at CVS and > as you have > said, it seems it is fixed there. > > > Out of curiosity, did you cvs build or download a > > prepackaged Taverna? > > > > As you can imagine, I was working on a prepackaged Taverna > 1.2 version > :-(. We are working behind a firewall, and I was digging > as an user how > much functionality related to MOBY in Taverna 1.2 was > affected by that > fact. I realized that problem when I did a worflow with > two branches, > both branches with the same service and one of them had to > be renamed. > > What I have seen is that object instances generated > from the new object > tree in BioMOBY scavenger use information from > > http://biomoby.org/RESOURCES/MOBY-S/Objects > > so those workflow branches with any of those object > instantes stalled > just inside them. I was digging on that URL, and I saw > that all the > rdf:about attributes (plus others, like rdf:resource in > http://biomoby.org/RESOURCES/MOBY-S/Services) were > referencing your > Tomcat server at mobycentral.icapture.ubc.ca:8090. Is > there some > progress on MOBY Apache server with > ProxyPass/ProxyPassReverse? > > Best Regards, > 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 Aug 8 15:52:46 2005 From: markw at illuminae.com (markw at illuminae.com) Date: Mon, 8 Aug 2005 11:52:46 -0400 Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> References: <42f77233.3cdaf281.48fc.33d0@mx.gmail.com> Message-ID: <1123516366.42f77fceb1a8f@webmail.illuminae.com> Quoting Edward Kawas : > Actually, give it a try now. It should work as Mark tweeked > it! > > Tomcat server at mobycentral.icapture.ubc.ca:8090. Is > > there some progress on MOBY Apache server with > > ProxyPass/ProxyPassReverse? Yes, I made those changes a few days ago. Please let me know ASAP if they aren't solving the problem. Greetings from (and goodbye to) Manchester! I'll be back in Vancouver on Wednesday. M From senger at ebi.ac.uk Thu Aug 11 01:10:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 11 Aug 2005 02:10:31 +0100 (BST) Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: This question is meant primarily for Java-based biomoby services, but a suggestion from Perl people can help me as well. I wonder what are the general rules for handling errors in biomoby services. The API is silent about it, and the only thing I remember from the discussions is that if there is an error the service will return an empty output object (still, of course, wrapped in a biomoby XML envelope). Is this really the only way how to handle all kinds of errors? I understand that this behaviour is reasonable when my input data does not produce any result (wrong id, non-existing id, etc.). But should I use the same mechanism for things like: * the input data does not come as String or base64 type, * the input XML does not conform to the Biomoby API, * my service cannot respond because of some limited internal resources, * etc. Any advise how you deal with these situations will be appreciated, and I thank you very much. With regards, Martin PS. Of course, you noticed that in my main email body above I have not mentioned how dissapointing the Biomoby API is if it does not deal with error handling :-) M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 12 19:38:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 12 Aug 2005 12:38:43 -0700 Subject: [MOBY-dev] lease versus agent for registry updating Message-ID: <1123875523.15335.19.camel@bioinfo.icapture.ubc.ca> Hi all! Eddie and I are spending the day working on MOBY Central architecture issues. We've run into a question that has so many pros and cons that we decided to toss it out to the list for other opinions. Keeping MOBY Central up-to-date: Method 1: Agent An agent retrieves the list of SignatureURL's from the registry, and crawls around retrieving the RDF from each of those URLs. The RDF is compared to what is in the registry, and updates/deletions are made. Consequence to service provider: a service providers machine goes down, the service is deregistered (the agent can't retrieve the URL) and the service provider must then actively re-register their services Method 2: Lease Services have a time-stamp in the registry and expire after X time. They must then be actively re-registered. Consequence to service provider: Service providers must set up a cron (or whatever) that is aware of all of their *current* Signature URL's and can call MOBY Central to re-register their services on a regular basis. Both solutions seem to put an unwanted burden on the service providers, but the burdens are different in nature and frequency. Which of these seems preferable? Are there solutions we haven't thought of? ??? Mark & Eddie -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From boris.steipe at utoronto.ca Fri Aug 12 19:50:50 2005 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Fri, 12 Aug 2005 16:50:50 -0300 Subject: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123875523.15335.19.camel@bioinfo.icapture.ubc.ca> Message-ID: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Why not put the burden of the lease on the agent to combine the advantages of both models? I.e. if service is down for less then a specific time, it might not get deregistered but only flagged as temporarily unavailable ... then un-flagged as it comes up again, except if it's down for, say > 1week, then it gets deregistered. $0.02 Boris On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > Hi all! > > Eddie and I are spending the day working on MOBY Central architecture > issues. We've run into a question that has so many pros and cons that > we decided to toss it out to the list for other opinions. > > Keeping MOBY Central up-to-date: > > Method 1: Agent > > An agent retrieves the list of SignatureURL's from the registry, and > crawls around retrieving the RDF from each of those URLs. The RDF is > compared to what is in the registry, and updates/deletions are made. > > Consequence to service provider: a service providers machine goes down, > the service is deregistered (the agent can't retrieve the URL) and the > service provider must then actively re-register their services > > > Method 2: Lease > > Services have a time-stamp in the registry and expire after X time. > They must then be actively re-registered. > > Consequence to service provider: Service providers must set up a cron > (or whatever) that is aware of all of their *current* Signature URL's > and can call MOBY Central to re-register their services on a regular > basis. > > > Both solutions seem to put an unwanted burden on the service providers, > but the burdens are different in nature and frequency. > > Which of these seems preferable? Are there solutions we haven't > thought > of? > > ??? > > Mark & Eddie > > > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri Aug 12 19:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 12 Aug 2005 12:57:02 -0700 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Message-ID: <1123876622.15335.25.camel@bioinfo.icapture.ubc.ca> Hi Boris! Thanks for the rapid reply! That is how we had initially planned to do it as well, however the consequence is that the registry (a) has to have a mechanism for recording the number of failure occurrences, and this might be handled differently by different underlying data stores, and (b) the registry KNOWS that it contains service instances that are likely non-functional but still reports them as being functional. ... Eddie just suggested an alternative to this alternative :-) The agent can deregister services that fail the URL lookup, but still retain the URL and try them a few more times just in case they come back up again. That way the registry is always reflecting the *best* information it can possibly know, but the burden of re-registering services still falls on the Registry as much as possible. That might be the way to go... Other opinions? M On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > Why not put the burden of the lease on the agent to combine the > advantages of both models? I.e. if service is down for less then a > specific time, it might not get deregistered but only flagged as > temporarily unavailable ... then un-flagged as it comes up again, > except if it's down for, say > 1week, then it gets deregistered. > > $0.02 > > Boris > > On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > > > Hi all! > > > > Eddie and I are spending the day working on MOBY Central architecture > > issues. We've run into a question that has so many pros and cons that > > we decided to toss it out to the list for other opinions. > > > > Keeping MOBY Central up-to-date: > > > > Method 1: Agent > > > > An agent retrieves the list of SignatureURL's from the registry, and > > crawls around retrieving the RDF from each of those URLs. The RDF is > > compared to what is in the registry, and updates/deletions are made. > > > > Consequence to service provider: a service providers machine goes down, > > the service is deregistered (the agent can't retrieve the URL) and the > > service provider must then actively re-register their services > > > > > > Method 2: Lease > > > > Services have a time-stamp in the registry and expire after X time. > > They must then be actively re-registered. > > > > Consequence to service provider: Service providers must set up a cron > > (or whatever) that is aware of all of their *current* Signature URL's > > and can call MOBY Central to re-register their services on a regular > > basis. > > > > > > Both solutions seem to put an unwanted burden on the service providers, > > but the burdens are different in nature and frequency. > > > > Which of these seems preferable? Are there solutions we haven't > > thought > > of? > > > > ??? > > > > Mark & Eddie > > > > > > -- > > "Ontologists do it with the edges!" > > > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > _______________________________________________ > > 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 -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From boris.steipe at utoronto.ca Fri Aug 12 20:04:34 2005 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Fri, 12 Aug 2005 17:04:34 -0300 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123876622.15335.25.camel@bioinfo.icapture.ubc.ca> Message-ID: <4D6827FD-0B6C-11DA-A8DF-000A9577512E@utoronto.ca> On Friday, Aug 12, 2005, at 16:57 Canada/Atlantic, Mark Wilkinson wrote: > The > agent can deregister services that fail the URL lookup, but still > retain > the URL and try them a few more times just in case they come back up > again. That way the registry is always reflecting the *best* > information it can possibly know, but the burden of re-registering > services still falls on the Registry as much as possible. If the agent then automatically re-registers when it succeeds, that's what I just said. (I think.) (Except you went like *this* (gestures handwave to the side, sort of)). :-) B. From markw at illuminae.com Fri Aug 12 20:41:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 12 Aug 2005 13:41:35 -0700 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Message-ID: <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> Ah... I missed the bit about a service being flagged as "temporarily unavailable" rather than just flagged in general. The reason we are loathe to do that is it makes assumptions about the underlying data store being able to capture that information (or at least, forces queries on the underlying data store to then be passed through a post- retrieval "available" filter implemented by the data adaptor)... We're trying to make as few assumptions about the underlying store as possible - a minimum of information about the core functionality of a service (i.e. at this point, the overlap between the MOBY and the Feta data models) M On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > Why not put the burden of the lease on the agent to combine the > advantages of both models? I.e. if service is down for less then a > specific time, it might not get deregistered but only flagged as > temporarily unavailable ... then un-flagged as it comes up again, > except if it's down for, say > 1week, then it gets deregistered. > > $0.02 > > Boris > > On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > > > Hi all! > > > > Eddie and I are spending the day working on MOBY Central architecture > > issues. We've run into a question that has so many pros and cons that > > we decided to toss it out to the list for other opinions. > > > > Keeping MOBY Central up-to-date: > > > > Method 1: Agent > > > > An agent retrieves the list of SignatureURL's from the registry, and > > crawls around retrieving the RDF from each of those URLs. The RDF is > > compared to what is in the registry, and updates/deletions are made. > > > > Consequence to service provider: a service providers machine goes down, > > the service is deregistered (the agent can't retrieve the URL) and the > > service provider must then actively re-register their services > > > > > > Method 2: Lease > > > > Services have a time-stamp in the registry and expire after X time. > > They must then be actively re-registered. > > > > Consequence to service provider: Service providers must set up a cron > > (or whatever) that is aware of all of their *current* Signature URL's > > and can call MOBY Central to re-register their services on a regular > > basis. > > > > > > Both solutions seem to put an unwanted burden on the service providers, > > but the burdens are different in nature and frequency. > > > > Which of these seems preferable? Are there solutions we haven't > > thought > > of? > > > > ??? > > > > Mark & Eddie > > > > > > -- > > "Ontologists do it with the edges!" > > > > Mark Wilkinson > > Asst. Professor > > Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics > > iCAPTURE Centre > > St. Paul's Hospital > > Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From gordonp at ucalgary.ca Fri Aug 12 21:23:46 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 12 Aug 2005 15:23:46 -0600 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> Message-ID: <42FD1362.8000107@ucalgary.ca> I would go for the server polling the RDFs option. In that way, there could potentially be more than one MOBY Central (e.g. private ones) that could simply get the provider RDF URL list from the "Master" MOBY Central, and replicate the service registry (in whatever underlying data store they like). Decentralizing is good. >Ah... I missed the bit about a service being flagged as "temporarily >unavailable" rather than just flagged in general. The reason we are >loathe to do that is it makes assumptions about the underlying data >store being able to capture that information (or at least, forces >queries on the underlying data store to then be passed through a post- >retrieval "available" filter implemented by the data adaptor)... > >We're trying to make as few assumptions about the underlying store as >possible - a minimum of information about the core functionality of a >service (i.e. at this point, the overlap between the MOBY and the Feta >data models) > >M > > >On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > > >>Why not put the burden of the lease on the agent to combine the >>advantages of both models? I.e. if service is down for less then a >>specific time, it might not get deregistered but only flagged as >>temporarily unavailable ... then un-flagged as it comes up again, >>except if it's down for, say > 1week, then it gets deregistered. >> >>$0.02 >> >>Boris >> >>On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: >> >> >> >>>Hi all! >>> >>>Eddie and I are spending the day working on MOBY Central architecture >>>issues. We've run into a question that has so many pros and cons that >>>we decided to toss it out to the list for other opinions. >>> >>>Keeping MOBY Central up-to-date: >>> >>>Method 1: Agent >>> >>>An agent retrieves the list of SignatureURL's from the registry, and >>>crawls around retrieving the RDF from each of those URLs. The RDF is >>>compared to what is in the registry, and updates/deletions are made. >>> >>>Consequence to service provider: a service providers machine goes down, >>>the service is deregistered (the agent can't retrieve the URL) and the >>>service provider must then actively re-register their services >>> >>> >>>Method 2: Lease >>> >>>Services have a time-stamp in the registry and expire after X time. >>>They must then be actively re-registered. >>> >>>Consequence to service provider: Service providers must set up a cron >>>(or whatever) that is aware of all of their *current* Signature URL's >>>and can call MOBY Central to re-register their services on a regular >>>basis. >>> >>> >>>Both solutions seem to put an unwanted burden on the service providers, >>>but the burdens are different in nature and frequency. >>> >>>Which of these seems preferable? Are there solutions we haven't >>>thought >>>of? >>> >>>??? >>> >>>Mark & Eddie >>> >>> >>>-- >>>"Ontologists do it with the edges!" >>> >>>Mark Wilkinson >>>Asst. Professor >>>Dept. of Medical Genetics >>>University of British Columbia >>>PI in Bioinformatics >>>iCAPTURE Centre >>>St. Paul's Hospital >>>Rm. 166, 1081 Burrard St. >>>Vancouver, BC, V6Z 1Y6 >>>tel: 604 682 2344 x62129 >>>fax: 604 806 9274 >>> >>>_______________________________________________ >>>MOBY-dev mailing list >>>MOBY-dev at biomoby.org >>>http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> From markw at illuminae.com Fri Aug 12 22:18:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 12 Aug 2005 15:18:30 -0700 Subject: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <42FD1362.8000107@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> Message-ID: <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> We're certainly of like-mind at this end, though certain people ;-) at myGrid think that the agent is the wrong way to go... I just don't see it. IMO a leasing model would be akin to leasing space in Google! Anyway, we'll leave the question open for a couple of days and see if any more optimal solutions come up. M On Fri, 2005-08-12 at 15:23 -0600, Paul Gordon wrote: > I would go for the server polling the RDFs option. In that way, there > could potentially be more than one MOBY Central (e.g. private ones) that > could simply get the provider RDF URL list from the "Master" MOBY > Central, and replicate the service registry (in whatever underlying data > store they like). Decentralizing is good. > > > >Ah... I missed the bit about a service being flagged as "temporarily > >unavailable" rather than just flagged in general. The reason we are > >loathe to do that is it makes assumptions about the underlying data > >store being able to capture that information (or at least, forces > >queries on the underlying data store to then be passed through a post- > >retrieval "available" filter implemented by the data adaptor)... > > > >We're trying to make as few assumptions about the underlying store as > >possible - a minimum of information about the core functionality of a > >service (i.e. at this point, the overlap between the MOBY and the Feta > >data models) > > > >M > > > > > >On Fri, 2005-08-12 at 16:50 -0300, Boris Steipe wrote: > > > > > >>Why not put the burden of the lease on the agent to combine the > >>advantages of both models? I.e. if service is down for less then a > >>specific time, it might not get deregistered but only flagged as > >>temporarily unavailable ... then un-flagged as it comes up again, > >>except if it's down for, say > 1week, then it gets deregistered. > >> > >>$0.02 > >> > >>Boris > >> > >>On Friday, Aug 12, 2005, at 16:38 Canada/Atlantic, Mark Wilkinson wrote: > >> > >> > >> > >>>Hi all! > >>> > >>>Eddie and I are spending the day working on MOBY Central architecture > >>>issues. We've run into a question that has so many pros and cons that > >>>we decided to toss it out to the list for other opinions. > >>> > >>>Keeping MOBY Central up-to-date: > >>> > >>>Method 1: Agent > >>> > >>>An agent retrieves the list of SignatureURL's from the registry, and > >>>crawls around retrieving the RDF from each of those URLs. The RDF is > >>>compared to what is in the registry, and updates/deletions are made. > >>> > >>>Consequence to service provider: a service providers machine goes down, > >>>the service is deregistered (the agent can't retrieve the URL) and the > >>>service provider must then actively re-register their services > >>> > >>> > >>>Method 2: Lease > >>> > >>>Services have a time-stamp in the registry and expire after X time. > >>>They must then be actively re-registered. > >>> > >>>Consequence to service provider: Service providers must set up a cron > >>>(or whatever) that is aware of all of their *current* Signature URL's > >>>and can call MOBY Central to re-register their services on a regular > >>>basis. > >>> > >>> > >>>Both solutions seem to put an unwanted burden on the service providers, > >>>but the burdens are different in nature and frequency. > >>> > >>>Which of these seems preferable? Are there solutions we haven't > >>>thought > >>>of? > >>> > >>>??? > >>> > >>>Mark & Eddie > >>> > >>> > >>>-- > >>>"Ontologists do it with the edges!" > >>> > >>>Mark Wilkinson > >>>Asst. Professor > >>>Dept. of Medical Genetics > >>>University of British Columbia > >>>PI in Bioinformatics > >>>iCAPTURE Centre > >>>St. Paul's Hospital > >>>Rm. 166, 1081 Burrard St. > >>>Vancouver, BC, V6Z 1Y6 > >>>tel: 604 682 2344 x62129 > >>>fax: 604 806 9274 > >>> > >>>_______________________________________________ > >>>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 -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From ots at ac.uma.es Thu Aug 11 10:05:23 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 11 Aug 2005 12:05:23 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: Message-ID: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Dear all, We sent a message (July 25) regarding error handling. I am not sure weather the message is in your hands, thus I am re-sending it for discussion. best regards Oswaldo -------------- ----- Original Message ----- From: "Oswaldo Trelles" To: "Eddie Kawas" Sent: Monday, July 25, 2005 6:43 PM Subject: Error handling proposal > Eddie, could you please circulate this message and made the document > available following your protocol? > thanks in advance > Oswaldo > > Please let me introduce myself. My name is Oswaldo Trelles and I work at the > Computer architecture Department of the University of Malaga, Spain (where > all of you are invited and welcomed). Our group is in charge of the > "Integrated Bioinformatics" aspects at the INB (National Institute of > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > meeting we are developing an integrated platform to deploy general and > specific services using BioMOBY as the underlying protocol. > > Thus we are quite concerned with BM specifications and we would like to > contribute in the development, extension and improvements in the protocol. > At this moment Roman has made a preliminary version and description of > Theseu project available. Now we would like to put over the table the error > handling issue. We have prepared a document, which represent an extension of > our current implementation. This proposal was discussed during the > INB-meeting here in Malaga (July 2005) and now is distributed as an open > document for further discussion. > > Please feel free to comment. > > best regards, Oswaldo + GNV5 team + INB team ----- Original Message ----- From: "Martin Senger" To: "Moby Developers" Sent: Thursday, August 11, 2005 3:10 AM Subject: [MOBY-dev] how to handle errors in a biomoby service? > This question is meant primarily for Java-based biomoby services, but a > suggestion from Perl people can help me as well. > > I wonder what are the general rules for handling errors in biomoby > services. The API is silent about it, and the only thing I remember from > the discussions is that if there is an error the service will return an > empty output object (still, of course, wrapped in a biomoby XML > envelope). Is this really the only way how to handle all kinds of > errors? > > I understand that this behaviour is reasonable when my input data does not > produce any result (wrong id, non-existing id, etc.). But should I use the > same mechanism for things like: > * the input data does not come as String or base64 type, > * the input XML does not conform to the Biomoby API, > * my service cannot respond because of some limited internal resources, > * etc. > > Any advise how you deal with these situations will be appreciated, and I > thank you very much. > > With regards, > Martin > > PS. Of course, you noticed that in my main email body above I have not > mentioned how dissapointing the Biomoby API is if it does not deal with > error handling :-) > > M. > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: 0509GNV5-ErrorHandling-v034distributed.pdf Type: application/pdf Size: 338293 bytes Desc: not available URL: From ots at ac.uma.es Thu Aug 11 10:05:23 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Thu, 11 Aug 2005 12:05:23 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: Message-ID: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Dear all, We sent a message (July 25) regarding error handling. I am not sure weather the message is in your hands, thus I am re-sending it for discussion. best regards Oswaldo -------------- ----- Original Message ----- From: "Oswaldo Trelles" To: "Eddie Kawas" Sent: Monday, July 25, 2005 6:43 PM Subject: Error handling proposal > Eddie, could you please circulate this message and made the document > available following your protocol? > thanks in advance > Oswaldo > > Please let me introduce myself. My name is Oswaldo Trelles and I work at the > Computer architecture Department of the University of Malaga, Spain (where > all of you are invited and welcomed). Our group is in charge of the > "Integrated Bioinformatics" aspects at the INB (National Institute of > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > meeting we are developing an integrated platform to deploy general and > specific services using BioMOBY as the underlying protocol. > > Thus we are quite concerned with BM specifications and we would like to > contribute in the development, extension and improvements in the protocol. > At this moment Roman has made a preliminary version and description of > Theseu project available. Now we would like to put over the table the error > handling issue. We have prepared a document, which represent an extension of > our current implementation. This proposal was discussed during the > INB-meeting here in Malaga (July 2005) and now is distributed as an open > document for further discussion. > > Please feel free to comment. > > best regards, Oswaldo + GNV5 team + INB team ----- Original Message ----- From: "Martin Senger" To: "Moby Developers" Sent: Thursday, August 11, 2005 3:10 AM Subject: [MOBY-dev] how to handle errors in a biomoby service? > This question is meant primarily for Java-based biomoby services, but a > suggestion from Perl people can help me as well. > > I wonder what are the general rules for handling errors in biomoby > services. The API is silent about it, and the only thing I remember from > the discussions is that if there is an error the service will return an > empty output object (still, of course, wrapped in a biomoby XML > envelope). Is this really the only way how to handle all kinds of > errors? > > I understand that this behaviour is reasonable when my input data does not > produce any result (wrong id, non-existing id, etc.). But should I use the > same mechanism for things like: > * the input data does not come as String or base64 type, > * the input XML does not conform to the Biomoby API, > * my service cannot respond because of some limited internal resources, > * etc. > > Any advise how you deal with these situations will be appreciated, and I > thank you very much. > > With regards, > Martin > > PS. Of course, you noticed that in my main email body above I have not > mentioned how dissapointing the Biomoby API is if it does not deal with > error handling :-) > > M. > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: 0509GNV5-ErrorHandling-v034distributed.pdf Type: application/pdf Size: 338293 bytes Desc: not available URL: From edward.kawas at gmail.com Tue Aug 16 01:26:04 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Mon, 15 Aug 2005 20:26:04 -0500 Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Hi Oswaldo, Do you think that you could repost it to the list? Thanks, Eddie On 8/11/05, Oswaldo Trelles wrote: > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > From edward.kawas at gmail.com Tue Aug 16 01:26:04 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Mon, 15 Aug 2005 20:26:04 -0500 Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Hi Oswaldo, Do you think that you could repost it to the list? Thanks, Eddie On 8/11/05, Oswaldo Trelles wrote: > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > 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 ots at ac.uma.es Tue Aug 16 09:27:02 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue, 16 Aug 2005 11:27:02 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: <000d01c5a244$aa5b8e90$346dd696@ac.uma.es> ----- Original Message ----- From: "Oswaldo Trelles" To: "Core developer announcements" ; "Moby Developers" Sent: Thursday, August 11, 2005 12:05 PM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Tue Aug 16 09:27:02 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue, 16 Aug 2005 11:27:02 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? Message-ID: <000d01c5a244$aa5b8e90$346dd696@ac.uma.es> ----- Original Message ----- From: "Oswaldo Trelles" To: "Core developer announcements" ; "Moby Developers" Sent: Thursday, August 11, 2005 12:05 PM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Dear all, > > We sent a message (July 25) regarding error handling. I am not sure weather > the message is in your hands, thus I am re-sending it for discussion. > > best regards > > Oswaldo > > > > > > -------------- > > > ----- Original Message ----- > From: "Oswaldo Trelles" > To: "Eddie Kawas" > Sent: Monday, July 25, 2005 6:43 PM > Subject: Error handling proposal > > > > Eddie, could you please circulate this message and made the document > > available following your protocol? > > thanks in advance > > Oswaldo > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > the > > Computer architecture Department of the University of Malaga, Spain (where > > all of you are invited and welcomed). Our group is in charge of the > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > meeting we are developing an integrated platform to deploy general and > > specific services using BioMOBY as the underlying protocol. > > > > Thus we are quite concerned with BM specifications and we would like to > > contribute in the development, extension and improvements in the protocol. > > At this moment Roman has made a preliminary version and description of > > Theseu project available. Now we would like to put over the table the > error > > handling issue. We have prepared a document, which represent an extension > of > > our current implementation. This proposal was discussed during the > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > document for further discussion. > > > > Please feel free to comment. > > > > best regards, Oswaldo + GNV5 team + INB team > > > ----- Original Message ----- > From: "Martin Senger" > To: "Moby Developers" > Sent: Thursday, August 11, 2005 3:10 AM > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > This question is meant primarily for Java-based biomoby services, but a > > suggestion from Perl people can help me as well. > > > > I wonder what are the general rules for handling errors in biomoby > > services. The API is silent about it, and the only thing I remember from > > the discussions is that if there is an error the service will return an > > empty output object (still, of course, wrapped in a biomoby XML > > envelope). Is this really the only way how to handle all kinds of > > errors? > > > > I understand that this behaviour is reasonable when my input data does not > > produce any result (wrong id, non-existing id, etc.). But should I use the > > same mechanism for things like: > > * the input data does not come as String or base64 type, > > * the input XML does not conform to the Biomoby API, > > * my service cannot respond because of some limited internal resources, > > * etc. > > > > Any advise how you deal with these situations will be appreciated, and I > > thank you very much. > > > > With regards, > > Martin > > > > PS. Of course, you noticed that in my main email body above I have not > > mentioned how dissapointing the Biomoby API is if it does not deal with > > error handling :-) > > > > M. > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > International Rice Research Institute > > Biometrics and Bioinformatics Unit > > DAPO BOX 7777, Metro Manila > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > From ots at ac.uma.es Tue Aug 16 09:32:40 2005 From: ots at ac.uma.es (Oswaldo Trelles) Date: Tue, 16 Aug 2005 11:32:40 +0200 Subject: [MOBY-dev] how to handle errors in a biomoby service? References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <007d01c5a245$726a2810$346dd696@ac.uma.es> Hi Eddie, OK I have posted again the message regards, O. ----- Original Message ----- From: "Eddie Kawas" To: "Core developer announcements" Cc: "Moby Developers" Sent: Tuesday, August 16, 2005 3:26 AM Subject: Re: [MOBY-dev] how to handle errors in a biomoby service? > Hi Oswaldo, > > Do you think that you could repost it to the list? > > Thanks, > > Eddie > > On 8/11/05, Oswaldo Trelles wrote: > > Dear all, > > > > We sent a message (July 25) regarding error handling. I am not sure weather > > the message is in your hands, thus I am re-sending it for discussion. > > > > best regards > > > > Oswaldo > > > > > > > > > > > > -------------- > > > > > > ----- Original Message ----- > > From: "Oswaldo Trelles" > > To: "Eddie Kawas" > > Sent: Monday, July 25, 2005 6:43 PM > > Subject: Error handling proposal > > > > > > > Eddie, could you please circulate this message and made the document > > > available following your protocol? > > > thanks in advance > > > Oswaldo > > > > > > Please let me introduce myself. My name is Oswaldo Trelles and I work at > > the > > > Computer architecture Department of the University of Malaga, Spain (where > > > all of you are invited and welcomed). Our group is in charge of the > > > "Integrated Bioinformatics" aspects at the INB (National Institute of > > > Bioinformatics). As David Gonz?les Pisano informed you at the Vancouver > > > meeting we are developing an integrated platform to deploy general and > > > specific services using BioMOBY as the underlying protocol. > > > > > > Thus we are quite concerned with BM specifications and we would like to > > > contribute in the development, extension and improvements in the protocol. > > > At this moment Roman has made a preliminary version and description of > > > Theseu project available. Now we would like to put over the table the > > error > > > handling issue. We have prepared a document, which represent an extension > > of > > > our current implementation. This proposal was discussed during the > > > INB-meeting here in Malaga (July 2005) and now is distributed as an open > > > document for further discussion. > > > > > > Please feel free to comment. > > > > > > best regards, Oswaldo + GNV5 team + INB team > > > > > > ----- Original Message ----- > > From: "Martin Senger" > > To: "Moby Developers" > > Sent: Thursday, August 11, 2005 3:10 AM > > Subject: [MOBY-dev] how to handle errors in a biomoby service? > > > > > > > This question is meant primarily for Java-based biomoby services, but a > > > suggestion from Perl people can help me as well. > > > > > > I wonder what are the general rules for handling errors in biomoby > > > services. The API is silent about it, and the only thing I remember from > > > the discussions is that if there is an error the service will return an > > > empty output object (still, of course, wrapped in a biomoby XML > > > envelope). Is this really the only way how to handle all kinds of > > > errors? > > > > > > I understand that this behaviour is reasonable when my input data does not > > > produce any result (wrong id, non-existing id, etc.). But should I use the > > > same mechanism for things like: > > > * the input data does not come as String or base64 type, > > > * the input XML does not conform to the Biomoby API, > > > * my service cannot respond because of some limited internal resources, > > > * etc. > > > > > > Any advise how you deal with these situations will be appreciated, and I > > > thank you very much. > > > > > > With regards, > > > Martin > > > > > > PS. Of course, you noticed that in my main email body above I have not > > > mentioned how dissapointing the Biomoby API is if it does not deal with > > > error handling :-) > > > > > > M. > > > > > > > > > -- > > > Martin Senger > > > email: martin.senger at gmail.com > > > skype: martinsenger > > > International Rice Research Institute > > > Biometrics and Bioinformatics Unit > > > DAPO BOX 7777, Metro Manila > > > Philippines, phone: +63-2-580-5600 (ext.2324) > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Aug 16 13:19:32 2005 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 16 Aug 2005 15:19:32 +0200 Subject: [MOBY-dev] Taverna: moby_collection widget Message-ID: <200508161519.32949.d.haase@gsf.de> Hi! I just tried out the Create_a_moby_collection widget in the new Taverna (after CVS build, the package is still the buggy one I think...) but didn't have much fun with it. As soon as I use it in the workflow, the service invocation fails, a ClassCastException is reported. Failure is even before an http request is sent out. Can anybody confirm that the widget is working? One thing I noticed is that the widget output is typed only as text/plain not as text/xml like for example Create_moby_data does it. But I have no idea if this is relevant... I'll be thankful for any hints. Regards, dirk -- ---------------------------------------------------------- Dirk Haase phone +49 89 3187 3583 http://mips.gsf.de/~haase email d.haase at gsf.de From edward.kawas at gmail.com Tue Aug 16 16:16:40 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue, 16 Aug 2005 11:16:40 -0500 Subject: [MOBY-dev] Taverna: moby_collection widget In-Reply-To: <200508161519.32949.d.haase@gsf.de> References: <200508161519.32949.d.haase@gsf.de> Message-ID: Hi, The widget should work. I dont have a computer that could try it out (using dial-up) but as i recall, what one has to do is add the widget 'create_moby_collection' to a work flow and then add the various datatypes (DNASequence, Integer, etc) to the input ports and a properly formed collection should result and can be passed to the appropriate moby service. Out of curiousity, what was the class that caused the exception? Do you think that you could send me the error output? I am not sure how much help i can be for the next 2 weeks (no steady net connection) but i'll try! If you want to see how to use the collection, you could try the following workflow: http://bioinfo.icapture.ubc.ca/ekawas/workflow.xml with the following input: http://bioinfo.icapture.ubc.ca/ekawas/workflowInput.xml That workflow is known to work (actually, you will need to do a find/replace on the following string: find-> http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl replace-> http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl and then it will work. Sorry about that!). Eddie On 8/16/05, Dirk Haase wrote: > Hi! > > I just tried out the Create_a_moby_collection widget in the new Taverna (after > CVS build, the package is still the buggy one I think...) but didn't have > much fun with it. As soon as I use it in the workflow, the service invocation > fails, a ClassCastException is reported. Failure is even before an http > request is sent out. > > Can anybody confirm that the widget is working? One thing I noticed is that > the widget output is typed only as text/plain not as text/xml like for > example Create_moby_data does it. But I have no idea if this is relevant... > > I'll be thankful for any hints. > > Regards, > dirk > > -- > > ---------------------------------------------------------- > Dirk Haase phone +49 89 3187 3583 > http://mips.gsf.de/~haase email d.haase at gsf.de > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From markw at illuminae.com Tue Aug 16 16:21:23 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 16 Aug 2005 09:21:23 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Hi all, Thanks for writing this up so clearly! I agree 100% that the current error-reporting system in BioMOBY is insufficient (it was never part of the initial proposal, and even that initial proposal was cut by 80%, so...) I am a bit wary of two aspects of the solution you propose, though I need more time to think about exactly why they make me nervous: 1) Mixing metadata (errors) into the data seems... well... wrong somehow. I would prefer a solution that somehow used the serviceNotes block as the place to put error messages, and added an attribute to teh mobyData, Collection, or Simple tags that Xref'ed a node in the serviceNotes block. I wasn't in Malaga for the discussion, so perhaps there is a strong argument for putting it there that I am unaware of? 2) overloading the articleName attribute in the Simple/Collection tag (and especially in the case where Simples are part of a Collection) would then give **three** different "meanings" to the articleName attribute!! It's bad enough that we already have two different uses for that attribute... I'm reluctant to add one more to the fray! :-) Let's create a new attribute instead of adding a new meaning to an existing one. I hope others will participate in this discussion - it's been pretty quiet out there! I have not thought deeply about error reporting, and I would prefer to leave the final decision to people who *have* thought deeply about it. I am perfectly happy to simply sign-off on whatever the expert group decides - I really do not want to be the arbiter of the final decision in this matter because I just don't have the full scope of the problem in my head! I am happy, however, to participate in the overall debate leading up to that decision. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Tue Aug 16 16:21:23 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 16 Aug 2005 09:21:23 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Hi all, Thanks for writing this up so clearly! I agree 100% that the current error-reporting system in BioMOBY is insufficient (it was never part of the initial proposal, and even that initial proposal was cut by 80%, so...) I am a bit wary of two aspects of the solution you propose, though I need more time to think about exactly why they make me nervous: 1) Mixing metadata (errors) into the data seems... well... wrong somehow. I would prefer a solution that somehow used the serviceNotes block as the place to put error messages, and added an attribute to teh mobyData, Collection, or Simple tags that Xref'ed a node in the serviceNotes block. I wasn't in Malaga for the discussion, so perhaps there is a strong argument for putting it there that I am unaware of? 2) overloading the articleName attribute in the Simple/Collection tag (and especially in the case where Simples are part of a Collection) would then give **three** different "meanings" to the articleName attribute!! It's bad enough that we already have two different uses for that attribute... I'm reluctant to add one more to the fray! :-) Let's create a new attribute instead of adding a new meaning to an existing one. I hope others will participate in this discussion - it's been pretty quiet out there! I have not thought deeply about error reporting, and I would prefer to leave the final decision to people who *have* thought deeply about it. I am perfectly happy to simply sign-off on whatever the expert group decides - I really do not want to be the arbiter of the final decision in this matter because I just don't have the full scope of the problem in my head! I am happy, however, to participate in the overall debate leading up to that decision. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From dgpisano at cnb.uam.es Wed Aug 17 11:12:16 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Wed, 17 Aug 2005 13:12:16 +0200 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43031B90.4020802@cnb.uam.es> Hello, Mark Wilkinson escribi?: >Hi all, > >Thanks for writing this up so clearly! I agree 100% that the current >error-reporting system in BioMOBY is insufficient (it was never part of >the initial proposal, and even that initial proposal was cut by 80%, >so...) > >I am a bit wary of two aspects of the solution you propose, though I >need more time to think about exactly why they make me nervous: > >1) Mixing metadata (errors) into the data seems... well... wrong >somehow. I would prefer a solution that somehow used the serviceNotes >block as the place to put error messages, and added an attribute to teh >mobyData, Collection, or Simple tags that Xref'ed a node in the >serviceNotes block. I wasn't in Malaga for the discussion, so perhaps >there is a strong argument for putting it there that I am unaware of? > > > There were 2 proposals in the document and yes, the second one had the errors mixed with the data. We will write it again to clearly separate the moby data from the error information (like in the first proposal, that uses serviceNotes) and crossref them someway (see below) >2) overloading the articleName attribute in the Simple/Collection tag >(and especially in the case where Simples are part of a Collection) >would then give **three** different "meanings" to the articleName >attribute!! It's bad enough that we already have two different uses for >that attribute... I'm reluctant to add one more to the fray! :-) Let's >create a new attribute instead of adding a new meaning to an existing >one. > > > We understand that the articleName attribute in Simple / Collection tags is the "anchor point" we have to use to refer to that Simple / Collection. Referring to Simples / Collections / Simples into collection using articleNames give us more granularity than referring to mobyDatas using queryIDs. There is no need to create another additional "identifying" attribute if we can identify the entity we are reporting an error for. Probably we have to rewrite that part to clarify several points: - The error tag has to use an attribute to refer to the corresponding failing simple / collection. We can call this attribute exceptionRef, articleNameRef or something similar, to avoid using articleName again in a different context, but - We are referring to the erroneus entity using its articleName, and that's why the articleName has to be mandatory (note that this is a significant change in the bioMOBY specification, but we can't figure out any other way to report errors at this level) David >I hope others will participate in this discussion - it's been pretty >quiet out there! I have not thought deeply about error reporting, and I >would prefer to leave the final decision to people who *have* thought >deeply about it. I am perfectly happy to simply sign-off on whatever >the expert group decides - I really do not want to be the arbiter of the >final decision in this matter because I just don't have the full scope >of the problem in my head! I am happy, however, to participate in the >overall debate leading up to that decision. > >M > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available URL: From dgpisano at cnb.uam.es Wed Aug 17 11:12:16 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Wed, 17 Aug 2005 13:12:16 +0200 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43031B90.4020802@cnb.uam.es> Hello, Mark Wilkinson escribi?: >Hi all, > >Thanks for writing this up so clearly! I agree 100% that the current >error-reporting system in BioMOBY is insufficient (it was never part of >the initial proposal, and even that initial proposal was cut by 80%, >so...) > >I am a bit wary of two aspects of the solution you propose, though I >need more time to think about exactly why they make me nervous: > >1) Mixing metadata (errors) into the data seems... well... wrong >somehow. I would prefer a solution that somehow used the serviceNotes >block as the place to put error messages, and added an attribute to teh >mobyData, Collection, or Simple tags that Xref'ed a node in the >serviceNotes block. I wasn't in Malaga for the discussion, so perhaps >there is a strong argument for putting it there that I am unaware of? > > > There were 2 proposals in the document and yes, the second one had the errors mixed with the data. We will write it again to clearly separate the moby data from the error information (like in the first proposal, that uses serviceNotes) and crossref them someway (see below) >2) overloading the articleName attribute in the Simple/Collection tag >(and especially in the case where Simples are part of a Collection) >would then give **three** different "meanings" to the articleName >attribute!! It's bad enough that we already have two different uses for >that attribute... I'm reluctant to add one more to the fray! :-) Let's >create a new attribute instead of adding a new meaning to an existing >one. > > > We understand that the articleName attribute in Simple / Collection tags is the "anchor point" we have to use to refer to that Simple / Collection. Referring to Simples / Collections / Simples into collection using articleNames give us more granularity than referring to mobyDatas using queryIDs. There is no need to create another additional "identifying" attribute if we can identify the entity we are reporting an error for. Probably we have to rewrite that part to clarify several points: - The error tag has to use an attribute to refer to the corresponding failing simple / collection. We can call this attribute exceptionRef, articleNameRef or something similar, to avoid using articleName again in a different context, but - We are referring to the erroneus entity using its articleName, and that's why the articleName has to be mandatory (note that this is a significant change in the bioMOBY specification, but we can't figure out any other way to report errors at this level) David >I hope others will participate in this discussion - it's been pretty >quiet out there! I have not thought deeply about error reporting, and I >would prefer to leave the final decision to people who *have* thought >deeply about it. I am perfectly happy to simply sign-off on whatever >the expert group decides - I really do not want to be the arbiter of the >final decision in this matter because I just don't have the full scope >of the problem in my head! I am happy, however, to participate in the >overall debate leading up to that decision. > >M > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available URL: From markw at illuminae.com Wed Aug 17 16:17:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 17 Aug 2005 09:17:57 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <43031B90.4020802@cnb.uam.es> References: <00 1901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> <43031B90.4020802@cnb.uam.es> Message-ID: <1124295477.21293.18.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-17 at 13:12 +0200, David Gonz?lez Pisano wrote: > We understand that the articleName attribute in Simple / Collection tags > is the "anchor point" we have to use to refer to that Simple / > Collection. Referring to Simples / Collections / Simples into collection > using articleNames give us more granularity than referring to mobyDatas > using queryIDs. There is no need to create another additional > "identifying" attribute if we can identify the entity we are reporting > an error for. This is the only problematic part of the solution, since it requires a potentially troublesome change to the API. For this solution, you require all of the Simples in a Collection to have a unique articleName tag. At present, they likely have no tag at all (since this is not mandated by the API), and at best will all have the *same* tag even if we mandate that all output parameters must have an article name. If we make the value of this tag auto-generated (like an auto-increment field in a database), then it adds a new meaning to articleName, so let's just not pursue this possibility any further :-) Whatever solution we come up with, it cannot use articleName as its primary means of identifying the failed entity. > - The error tag has to use an attribute to refer to the corresponding > failing simple / collection. We can call this attribute exceptionRef, > articleNameRef or something similar, to avoid using articleName again in > a different context, but Super! > - We are referring to the erroneus entity using its articleName, and > that's why the articleName has to be mandatory (note that this is a > significant change in the bioMOBY specification, but we can't figure out > any other way to report errors at this level) I'm not sure why we need two ways of referring to the same entity? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Aug 18 21:27:16 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 18 Aug 2005 14:27:16 -0700 Subject: [MOBY-dev] CORE DEVELOPERS please create a bugzilla account... Message-ID: <1124400436.25003.2.camel@bioinfo.icapture.ubc.ca> Hi all core developers, We had our first Bugzilla bug report today, but nobody has signed-up to be a debugger :-) Can I request that all core developers (anyone who has committed significant code to the repository, or anyone who wants to be a MOBY debugger) please sign-up so that bugs can be assigned to you with email notification. It would be a good idea if we started using this bug tracking system rather than relying on the mailing list. http://bugzilla.open-bio.org/createaccount.cgi Thanks! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 07:43:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 08:43:55 +0100 (BST) Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Dear all, I am late with handling this email but it does not mean that I under-estimate the importance of th topic. It's actually crucial for claiming that we have a robust and interoperable technology. But we need it fast. I mean A decision should be made soon. i completely agree with Oswaldo that waiting for such important topic for several years now is a bit unfortunate. So let's face the problem... I read Oswaldo's proposal and I had opportunity to discuss it personaly. But actually I do not have a strong opinion HOW to handle errors if we handle them SOON. One missing piece (IMHO) there is not using the standard way for error handling in web services. I suspect that i know why it is not there - because there is not clear solution that would guarantee to work everywhere (now I am quoting the documenattion for the latest Apache Axis). However, I have tried it, and it works fine between perl and java (from both sides). So I think it is worth to use it. So now is my summary (and perhaps suggestion): 1) Critical errors. A service should raise an exception. So this level does not return any Moby specific data - everything is handled on SOAP level (sending back faultCode, faultString and such usuaal tags). In Java it is easy, in Perl as well (use SOAP::Fault). This does not bring any additional complexity to the client code - unless a client is badly written. What I want to say is that a good client even now should be prepared for transport exception (when a service is down completely, for example). So catching also a SOAP error produced by a service is trivial addition. To improve interoperability here, we should discuss the error strings etc. But there were suggestion in Osvaldo's proposal we can follow. The critical is a decision that we allow services to raise an exception in a critical situation. 2) "Your data are wrong" is the next level of errors. For this, both Oswaldo's sollution would work. As I said, I can go both ways IF we define what is an empty response. Does it mean an empty tag mobyData or an empty Object, or Simple... If we come to the end, what does an empty Integer mean? Does it mean always an error? Because an empry String can be a valid answer but empty Integer probably not. So the problems here are not that much where to put error strings (service notes or inside simples) but what "empty" means. 3) And we can talk about the third level - if we distinguish that sometimes simply your data are wrong and I cannot return you anything (above), or your data are partially wrong and I can retunr you at least something. but again, Oswaldo explained it already. So what should I put into my services? Please, Mark, tell us... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 07:43:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 08:43:55 +0100 (BST) Subject: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> Message-ID: Dear all, I am late with handling this email but it does not mean that I under-estimate the importance of th topic. It's actually crucial for claiming that we have a robust and interoperable technology. But we need it fast. I mean A decision should be made soon. i completely agree with Oswaldo that waiting for such important topic for several years now is a bit unfortunate. So let's face the problem... I read Oswaldo's proposal and I had opportunity to discuss it personaly. But actually I do not have a strong opinion HOW to handle errors if we handle them SOON. One missing piece (IMHO) there is not using the standard way for error handling in web services. I suspect that i know why it is not there - because there is not clear solution that would guarantee to work everywhere (now I am quoting the documenattion for the latest Apache Axis). However, I have tried it, and it works fine between perl and java (from both sides). So I think it is worth to use it. So now is my summary (and perhaps suggestion): 1) Critical errors. A service should raise an exception. So this level does not return any Moby specific data - everything is handled on SOAP level (sending back faultCode, faultString and such usuaal tags). In Java it is easy, in Perl as well (use SOAP::Fault). This does not bring any additional complexity to the client code - unless a client is badly written. What I want to say is that a good client even now should be prepared for transport exception (when a service is down completely, for example). So catching also a SOAP error produced by a service is trivial addition. To improve interoperability here, we should discuss the error strings etc. But there were suggestion in Osvaldo's proposal we can follow. The critical is a decision that we allow services to raise an exception in a critical situation. 2) "Your data are wrong" is the next level of errors. For this, both Oswaldo's sollution would work. As I said, I can go both ways IF we define what is an empty response. Does it mean an empty tag mobyData or an empty Object, or Simple... If we come to the end, what does an empty Integer mean? Does it mean always an error? Because an empry String can be a valid answer but empty Integer probably not. So the problems here are not that much where to put error strings (service notes or inside simples) but what "empty" means. 3) And we can talk about the third level - if we distinguish that sometimes simply your data are wrong and I cannot return you anything (above), or your data are partially wrong and I can retunr you at least something. but again, Oswaldo explained it already. So what should I put into my services? Please, Mark, tell us... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 15:26:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 08:26:04 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> > So what should I put into my services? Please, Mark, tell us... If you read my earlier comments I have already refused to make these decisions - the are better left to people who have thought extensively about them. Once you have come to an agreement, YOU tell ME what to do, and I (or the new curator, Frank) will add it to the API. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 15:26:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 08:26:04 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> > So what should I put into my services? Please, Mark, tell us... If you read my earlier comments I have already refused to make these decisions - the are better left to people who have thought extensively about them. Once you have come to an agreement, YOU tell ME what to do, and I (or the new curator, Frank) will add it to the API. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 15:44:33 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 16:44:33 +0100 (BST) Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> Message-ID: > If you read my earlier comments > I always read your comments... > I have already refused to make these decisions - the are better left > to people who have thought extensively about them. > That's nonsense. Sorry, Mark, but you put us into this mess because you had no time, mood or funding to make the error handling properly in the first place. Also, the current API - that does not define fully what "an empty result" means - is surely something you could /should think about it, and not let it completely on decision on other people. I am happy to discuss it, but at the end it will surely require changes in your code (perhaps not so much in registry, but surely in the library for service providers). So without your commitment to this topic it seems a bit of waste of time... The problem is not that you *have* to participate on every decision - but the problem is that we do not have (still) a procedure how to make changes in the API. Just "I or Frank will add it to the API" is not a proper process. And this process, in order to be successful, must be discussed with you as a PI and project manager. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 15:44:33 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 16:44:33 +0100 (BST) Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124897164.8181.26.camel@bioinfo.icapture.ubc.ca> Message-ID: > If you read my earlier comments > I always read your comments... > I have already refused to make these decisions - the are better left > to people who have thought extensively about them. > That's nonsense. Sorry, Mark, but you put us into this mess because you had no time, mood or funding to make the error handling properly in the first place. Also, the current API - that does not define fully what "an empty result" means - is surely something you could /should think about it, and not let it completely on decision on other people. I am happy to discuss it, but at the end it will surely require changes in your code (perhaps not so much in registry, but surely in the library for service providers). So without your commitment to this topic it seems a bit of waste of time... The problem is not that you *have* to participate on every decision - but the problem is that we do not have (still) a procedure how to make changes in the API. Just "I or Frank will add it to the API" is not a proper process. And this process, in order to be successful, must be discussed with you as a PI and project manager. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 15:47:03 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 08:47:03 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 16:44 +0100, Martin Senger wrote: > is surely something you could /should think about > it, and not let it completely on decision on other people. I have offered to participate in the discussion, and am doing so. > I am happy to discuss it, but at the end it will surely require changes > in your code (perhaps not so much in registry, but surely in the library > for service providers). So without your commitment to this topic it seems > a bit of waste of time... And will make the necessary changes in the code once a decision has been reached. > The problem is not that you *have* to participate on every decision - > but the problem is that we do not have (still) a procedure how to make > changes in the API. Correct. > discussed with you as a PI and project manager. It is as we speak. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 15:47:03 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 08:47:03 -0700 Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 16:44 +0100, Martin Senger wrote: > is surely something you could /should think about > it, and not let it completely on decision on other people. I have offered to participate in the discussion, and am doing so. > I am happy to discuss it, but at the end it will surely require changes > in your code (perhaps not so much in registry, but surely in the library > for service providers). So without your commitment to this topic it seems > a bit of waste of time... And will make the necessary changes in the code once a decision has been reached. > The problem is not that you *have* to participate on every decision - > but the problem is that we do not have (still) a procedure how to make > changes in the API. Correct. > discussed with you as a PI and project manager. It is as we speak. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Aug 24 16:07:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 17:07:11 +0100 (BST) Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > > but the problem is that we do not have (still) a procedure how to make > > changes in the API. > > Correct. > So how are we going to solve this? This is *a* solution (based on my experiences from the OMG process): 1) Anybody can make a suggestion to make a change in API (we can call it RFP - request for proposal, or RFC - request for comments, or whatever). An example of such thing are the proposals from Oswaldo and his collegues (eventhough I would not expect to have it always so perfectly written :-)). Important is that it must *say* this is a RFP/RFC, not just a wish in email. We will keep a place for it (bugzilla has wishlists?). 2) Then a calendar (deadline) must be attached to it. It can be suggested already by the author of the RFP/RFC, or a default value is attached. We need to say what is a default value. 3) The RFP can be considered only if the change is back-uped by two (three?) other developers. They do not need to fully agree with all details, their role is just to prevent overhelming number of small changes coming fast. 4) It is also considered only if somebody has resources to really implement the change. This should be also a part of the clendar ("when it can be done"). 5) Discussion on RFC, changes re-distributed, etc. In charge is the author of the original RFC. Deadline can be extended - don't be too formal here. 6) Now the tricky part: I think taht there should be only few people (major developers) who can vote on it. This is called an "Architecture Board" at OMG and guarantees that the changes are hopefully not breaking other things. 7) Then comes implementation, documenttaion etc. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 24 16:07:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 24 Aug 2005 17:07:11 +0100 (BST) Subject: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124898423.8181.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > > but the problem is that we do not have (still) a procedure how to make > > changes in the API. > > Correct. > So how are we going to solve this? This is *a* solution (based on my experiences from the OMG process): 1) Anybody can make a suggestion to make a change in API (we can call it RFP - request for proposal, or RFC - request for comments, or whatever). An example of such thing are the proposals from Oswaldo and his collegues (eventhough I would not expect to have it always so perfectly written :-)). Important is that it must *say* this is a RFP/RFC, not just a wish in email. We will keep a place for it (bugzilla has wishlists?). 2) Then a calendar (deadline) must be attached to it. It can be suggested already by the author of the RFP/RFC, or a default value is attached. We need to say what is a default value. 3) The RFP can be considered only if the change is back-uped by two (three?) other developers. They do not need to fully agree with all details, their role is just to prevent overhelming number of small changes coming fast. 4) It is also considered only if somebody has resources to really implement the change. This should be also a part of the clendar ("when it can be done"). 5) Discussion on RFC, changes re-distributed, etc. In charge is the author of the original RFC. Deadline can be extended - don't be too formal here. 6) Now the tricky part: I think taht there should be only few people (major developers) who can vote on it. This is called an "Architecture Board" at OMG and guarantees that the changes are hopefully not breaking other things. 7) Then comes implementation, documenttaion etc. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 24 16:24:10 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 09:24:10 -0700 Subject: [personal] Re: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: References: Message-ID: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-24 at 17:07 +0100, Martin Senger wrote: > An example of such thing are the proposals from Oswaldo and his > collegues (eventhough I would not expect to have it always so perfectly > written :-)). Indeed! It was more of a work of art than an RFC :-) They have really set the bar for the rest of us... > Important is that it must *say* this is a RFP/RFC, not just > a wish in email. We will keep a place for it (bugzilla has wishlists?). Unfortunately not :-( I'm looking for something to use as an alternative, but coming up empty. I wonder if Simon's Wordpress could do something in this regard? TWiki has templates, and I suspect Wordpress has something similar... > 6) Now the tricky part: I think taht there should be only few people > (major developers) who can vote on it. This is called an "Architecture > Board" at OMG and guarantees that the changes are hopefully not breaking > other things. I think we know who those people are, for the most part, but I think it would be good to open up the floor for volunteers with the caveat that there *will be an expectation* of a ~significant time commitment from those who volunteer, and with a one-year tenure (so that people don't join just to get their favorite feature through the process and then disappear again). This should sufficiently self-regulate the membership that it wont get unwieldy, and selects those who are both committed, and knowledgeable. > 7) Then comes implementation, documenttaion etc. Is that the fun part? ;-) M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 24 16:29:55 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 09:29:55 -0700 Subject: [personal] Re: [moby] Re: [MOBY-dev] how to handle errors in a biomoby service? In-Reply-To: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> References: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <1124900995.8181.57.camel@bioinfo.icapture.ubc.ca> This would also give us a clear basis for splitting-up the semi-annual developers meeting into the "core" developers and the "adherents". This is something I had hoped to do in the coming year anyway (assuming that we get funded at all... which is what I am currently working on! Fingers crossed!) M > > 6) Now the tricky part: I think taht there should be only few people > > (major developers) who can vote on it. This is called an "Architecture > > Board" at OMG and guarantees that the changes are hopefully not breaking > > other things. > > I think we know who those people are, for the most part, but I think it > would be good to open up the floor for volunteers with the caveat that > there *will be an expectation* of a ~significant time commitment from > those who volunteer, and with a one-year tenure (so that people don't > join just to get their favorite feature through the process and then > disappear again). This should sufficiently self-regulate the membership > that it wont get unwieldy, and selects those who are both committed, and > knowledgeable. -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From fgibbons at hms.harvard.edu Wed Aug 24 18:08:10 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 24 Aug 2005 14:08:10 -0400 Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <200508241557.j7OFv1Tu013092@portal.open-bio.org> Message-ID: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Martin, At 11:57 AM 8/24/2005, moby-dev-request at portal.open-bio.org wrote: >This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). Thanks for that suggestion - that sounds very sensible to me. As to whether Bugzilla has wishlists, I can't find them. (I hold the distinction of being the first - and to my knowledge, only - user of MOBY's Bugzilla set up.) Still, I guess we could overload the definition of 'bug' as meaning anything that needs attention. SourceForge has trackers that can differentiate between at least these four categories: bugs, support-requests, patches, and features requests. I'm sure there are good reasons why it makes sense to put MOBY on open-bio, rather than SourceForge. Is there any way we (and by 'we' I mean whoever runs open-bio :) could 'upgrade' the features offered by bugzilla there, to distinguish between those different kinds of requests? It would also help if the link to bugzilla got moved to a more prominent position on the MOBY home page. I really agree with Martin, that we need to adopt a more formalized (but not necessarily formal) approach to developing MOBY, because it's becoming bigger, and more widely used. The unformalized communication based on email doesn't scale terribly well: * there's poor differentiation between feature requests and bugs; and no definitive process for making decisions on either one; * there's no permanent record of decisions taken (except by searching the mail archives - good luck with that!); * although it's possible to announce future directions for development, they soon get lost in the archives, since they're not tagged as such. There are already powerful tools to help manage distributed software development, and I'd like to see us use them more. Using them would not only be good for our internal development, it would be good for our image, because it would look like we know what we're doing, giving newbies more confidence to join. Just my opinion, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From gordonp at ucalgary.ca Wed Aug 24 18:28:18 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 24 Aug 2005 12:28:18 -0600 Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> References: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: <430CBC42.4040404@ucalgary.ca> At the very least, you can set the severity of a bug to "enhancement" in Bugzilla. It's a start... > * there's poor differentiation between feature requests and bugs; and > no definitive process for making decisions on either one; > * there's no permanent record of decisions taken (except by searching > the mail archives - good luck with that!); > * although it's possible to announce future directions for > development, they soon get lost in the archives, since they're not > tagged as such. From markw at illuminae.com Wed Aug 24 20:54:48 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 24 Aug 2005 13:54:48 -0700 Subject: [MOBY-dev] RFC management system? Message-ID: <1124916888.8181.115.camel@bioinfo.icapture.ubc.ca> Hi all, I'm looking into "RT" from http://www.bestpractical.com It is being used by the open-bio people for their request tracking, so if it serves our purposes we could easily piggy-back. if anyone knows about this, please send your opinion. I'm just starting to look at it now... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Thu Aug 25 22:04:34 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Thu, 25 Aug 2005 16:04:34 -0600 Subject: [MOBY-dev] question to ask References: <1124900650.8181.52.camel@bioinfo.icapture.ubc.ca> <1124900995.8181.57.camel@bioinfo.icapture.ubc.ca> Message-ID: <430E4072.6010801@cpsc.ucalgary.ca> Hi Mark, I have a question to ask you: I made my service can take a large input sequences (1000 to 5000 DNA) in XML format. I use "./build/run/run-cmdline-client -scall search_Pfam ../../../JMOBY2/DNASEQ/input_1000" to test this service. The input_1000 contains 1000 DNA sequences in XML format. This service takes 3 mins and 34 seconds to parse the input file, and terminated after 3 mins and 41 seconds, then I got the error message as the following: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [string: null] Fault string: (0)null Fault code: {http://xml.apache.org/axis/}HTTP Fault actor: null When calling: http://moby.ucalgary.ca/cgi-bin/MobyEd_dispatcher.cgi =========== at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:196) at org.biomoby.client.CentralImpl.call(CentralImpl.java:1422) at MobyCmdLineClient.main(MobyCmdLineClient.java:641) =========== I thought the service got time out, so I changed "call.setTimeout(new Integer (0)" to "call.setTimeout(new Integer (600000)" in the "CentralImpl.java", then recompiled and I tested the service again, but still got same message. However, the big problem which I have right now is the service will be terminated after around 4 mins. I want to delay the timeout time. If you can, could you let me know is there anyway which I can solve this problem. Now I just tested on 800 and 1000 sequences. The 800 sequences worked fine, but not 1000 sequences. please help me if you can. I know you are very busy. Thanks so much! Joyce From markw at illuminae.com Thu Aug 25 22:04:55 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 25 Aug 2005 22:04:55 +0000 GMT Subject: [MOBY-dev] question to ask Message-ID: <1142838580-1125007531-cardhu_blackberry.rim.net-21511-@engine09-cell01> This is for the Java guru's to answer... M -----Original Message----- From: Chunyan Wang Date: Thu, 25 Aug 2005 16:04:34 To:markw at illuminae.com, Core developer announcements Subject: [MOBY-dev] question to ask Hi Mark, I have a question to ask you: I made my service can take a large input sequences (1000 to 5000 DNA) in XML format. I use "./build/run/run-cmdline-client -scall search_Pfam ../../../JMOBY2/DNASEQ/input_1000" to test this service. The input_1000 contains 1000 DNA sequences in XML format. This service takes 3 mins and 34 seconds to parse the input file, and terminated after 3 mins and 41 seconds, then I got the error message as the following: ===ERROR=== org.biomoby.shared.MobyException: ===ERROR=== Fault details: [string: null] Fault string: (0)null Fault code: {http://xml.apache.org/axis/}HTTP Fault actor: null When calling: http://moby.ucalgary.ca/cgi-bin/MobyEd_dispatcher.cgi =========== at org.biomoby.client.CentralImpl.doCall(CentralImpl.java:196) at org.biomoby.client.CentralImpl.call(CentralImpl.java:1422) at MobyCmdLineClient.main(MobyCmdLineClient.java:641) =========== I thought the service got time out, so I changed "call.setTimeout(new Integer (0)" to "call.setTimeout(new Integer (600000)" in the "CentralImpl.java", then recompiled and I tested the service again, but still got same message. However, the big problem which I have right now is the service will be terminated after around 4 mins. I want to delay the timeout time. If you can, could you let me know is there anyway which I can solve this problem. Now I just tested on 800 and 1000 sequences. The 800 sequences worked fine, but not 1000 sequences. please help me if you can. I know you are very busy. Thanks so much! Joyce _______________________________________________ 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 Fri Aug 26 00:03:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 26 Aug 2005 01:03:44 +0100 (BST) Subject: [MOBY-dev] question to ask In-Reply-To: <430E4072.6010801@cpsc.ucalgary.ca> Message-ID: Hi, I am afraid I do not have any good answer for you. When I tried the same service today (with a very short sequence) I have got timeout after several seconds. It said "(504)Proxy Timeout ( This operation returned because the timeout period expired.)", which seems exactly what you witnessed. My feeling is that the proxy mentioned in the message is on the service provider side. I think that the best would be to contact and ask the service provider. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Aug 26 07:52:34 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 26 Aug 2005 08:52:34 +0100 (BST) Subject: [MOBY-dev] changes in jMoby Message-ID: Dear all, I have made few (hopefully not breaking anything) in jMoby (the reason why will come apparent when I finish documenting my efforts over this weekend and send another email here). The most important is that you should call ./build.sh in order to get a newly added jar (alltools2.jar). This will probably download all libraries again - thats' because an updated time-stamp in the jar registry - but it wil happen just once (but do not do it on a slow modem :-)). Also I updated version of jdom.jar from beta to the 1.0. Everything compiled fine, but please check your code that nothing broke (it's really time to think seriously on jUnits - and I do think about it...). The directory src/Services was almost empty - and I moved the rest what was there into the more appropriate place src/main (the package name remained the same). Instead there is now src/samples where we can put examples, tutorial as etc. It does not compile by default - so it does not break the normal/main code. There is a bunch of new targets in Ant, such as samples-compile, samples-docs, samples-jar, samples-clean. There is also a directory src/samples-resources where you can put testing or demo files. All files here are utomatically loaded to the CLASSPATH so you can use getResource() to get them without troubles with their physical location (and there is a new method in Utils.java doing so in one line - readResource(). Please read docs/ChangeLog for few details what I did. Thank you, Paul, that you are contributing there. Have ever headrd about this file, Eddie? Eddie, could you reconsider directory 'org' that suddenl;y appeared in the main directory? It should be somewhere else... (let's discuss it offline). Please let me know if I broke anything. I apologize if I did (but I have checked many times before commiting my huge changes, so I hope everything is fine...). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From wangch at cpsc.ucalgary.ca Fri Aug 26 15:55:03 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Fri, 26 Aug 2005 09:55:03 -0600 Subject: [MOBY-dev] question to ask References: Message-ID: <430F3B57.2040602@cpsc.ucalgary.ca> Thanks, Martin. You said you tried the same service, which service? Is that search_Pfam? This service is tested with up to 800 sequences; it worked fine by using command line, but not from the MOBY Browser (works fine with one sequence). Actually, this is another big problem I have right now. The another problem is : When a user submits a request to one of our services from the MOBY Browser, if our server is busy and the request needs to take more than a few minutes to finish, then the service gets timeout. For our services, we need them to be able to take mutiple input sequences (maybe up to 5000 sequences) and input with seconary input. I am not sure what these problems are. But I will look into them. If anyone can give me suggestions, please let me know. Thanks. Joyce Martin Senger wrote: >Hi, > I am afraid I do not have any good answer for you. When I tried the >same service today (with a very short sequence) I have got timeout after >several seconds. It said "(504)Proxy Timeout ( This operation returned >because the timeout period expired.)", which seems exactly what you >witnessed. My feeling is that the proxy mentioned in the message is on the >service provider side. I think that the best would be to contact and ask >the service provider. > > With regards, > Martin > > > From senger at ebi.ac.uk Fri Aug 26 16:40:54 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 26 Aug 2005 17:40:54 +0100 (BST) Subject: [MOBY-dev] question to ask In-Reply-To: <430F3B57.2040602@cpsc.ucalgary.ca> Message-ID: > You said you tried the same service, which service? Is that search_Pfam? > Yes, the search_Pfam. > needs to take more than a few minutes to finish, then the service gets > timeout. > We had the same (or similar) problem at EBI. The timeout can happen at several places. And one good candidate is a proxy server (I am saying good, because the error I got mentioned proxy). The proxy can be configured how long it waits before timeout. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 26 22:20:31 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 26 Aug 2005 15:20:31 -0700 Subject: [MOBY-dev] Migration of database to new API Message-ID: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Hi all, As we move toward deploying the new API, there are some serious consequences on the underlying databases. Let me first re-cap the new API features that I am discussing and what effects they have on the databases: 1) Inheritence from primitives through ISA relationships is no longer allowed. e.g. plain-text ISA String is no longer allowed. To achieve the same result, you now create an object that inherits from Object and contains the primitive. e.g. plain-text ISA Object; plain-text HASA String. 2) All service inputs and outputs must now be named (articleName) ------ For case 1, I have written a migration script that does the following: a) identifies every object that inherits directly from a primitive b) creates a new object called OldObjectName_v2 that inherits from Object and contains that primitive type through a HASA relationship, with the contained articleName being the same as the original object name. e.g. plain-text ISA String results in a new object plain_text_v2 ISA Object; plain_text_v2 HASA String(plain_text) c) updates the description of the original object such that the description now reads "DEPRECATED - use plain_text_v2 instead" This is in the Database folder of the CVS. At present, this script only goes down one level of the object hierarchy, and does not explicitly deprecate, nor create new object types for, any children of now deprecated objects, nor for any objects that contain a deprecated object Q1: Should it do so ...or is this going to create mass confusion for people? Q2: How long should the deprecation period be before we refuse to support the old objects any longer? My feeling is that it should be quite limited... e.g. 2 months. If you can't update your service to use a new object type within two months, then it gets removed from the registry. I updated all ~20 of my services in about 5 minutes, so that gives you a sense of how much effort it is... -------- For case 2, I have not yet written a script. I am loathe to change people's service registrations at all! I would prefer that people update their RDF signatures and let the agent update their service registration (once we get the agent running - this has been postponed *yet again* in order to bring our service signature model in sync with the one that we just jointly developed with myGrid last month). What concerns me is that this might require a lot of hand-editing from those who have hundreds of services registered (e.g. soaplab), so...?? Would it be preferable for me to script this and just attach arbitrary names to your inputs/outputs in the database? This is going to be a painful API change no matter how we play it, but I want to be sure that we all know what the changes are going to be and have agreed on the path of least pain before we begin the process. It's all for the best! Honestly! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Sat Aug 27 00:53:22 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 01:53:22 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Aug 27 00:53:22 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 01:53:22 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 00:58:33 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 27 Aug 2005 00:58:33 +0000 GMT Subject: [MOBY-dev] Migration of database to new API Message-ID: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> There is no need for a name change again. The object will forever be called -v2 It's just an identifier... M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 01:53:22 To:markw at illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Sat Aug 27 00:58:33 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 27 Aug 2005 00:58:33 +0000 GMT Subject: [MOBY-dev] Migration of database to new API Message-ID: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> There is no need for a name change again. The object will forever be called -v2 It's just an identifier... M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 01:53:22 To:markw at illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > b) creates a new object called OldObjectName_v2 > But then there will be a need in the future for yet another change from OldObjectName_v2 back to OldObjectName_v2. So I do not understand fully why not to change it (a) either under the OldObjectName directly, or (b) keep it as it is and let people change it in two months and after that simply remove them. > At present, this script only goes down one level of the object > hierarchy, and does not explicitly deprecate, nor create new object > types for, any children of now deprecated objects, nor for any objects > that contain a deprecated object Q1: Should it do so > I think that any change that goes only half-ways will confuse people and programs as well. Make it all, or make it none, would be my suggestion. > going to create mass confusion for people? Q2: How long should the > deprecation period be before we refuse to support the old objects any > longer? > Two months seem okay (but I do not have any services so my voice is not important here). > For case 2, I have not yet written a script. I am loathe to change > people's service registrations at all! > As I said above: don't do it. Just let them know if they do not do it in a given period, you will remove their registration. The same I would prefer with objects (but as I sais it is not really my cup of tee). > who have hundreds of services registered (e.g. soaplab) > Don't worry about soaplab. None such service was/is and will be (afaik) running. It was registered by a student who is not anymore working on the soaplab2moby project. > This is going to be a painful API change no matter how we play it > So why not to make the changes regarding the error-handling in the same time? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Sat Aug 27 01:06:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 02:06:55 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> Message-ID: > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Aug 27 01:06:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 02:06:55 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <17973474-1125104353-cardhu_blackberry.rim.net-937-@engine08-cell01> Message-ID: > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 01:12:53 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 27 Aug 2005 01:12:53 +0000 GMT Subject: [MOBY-dev] Migration of database to new API Message-ID: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> I strongly disagree in return :-) If I have an object called "sequence" there is no indication in the name that it is a fasta sequence or an embl sequence or a genbank sequence or whatever. The fact that it is called sequence-v2 is no more nor less confusing! (Ben is sitting here beside me in the pub chuckling about the dangers of mixing semantics meaning into names :-) ) M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 02:06:55 To:markw at illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Migration of database to new API > There is no need for a name change again. The object will forever be called -v2 > > It's just an identifier... > Strongly disagree. The names are visible to people in many clients that list them. They should be named sensibly. Adding an artificial suffix v2 just without any compelling reasons is a bad design (and there is no compelling reason for that). I will better stop now (you got me agian!?)... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Sat Aug 27 01:22:42 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 02:22:42 +0100 (BST) Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> Message-ID: > The fact that it is called sequence-v2 is no more nor less confusing! > Nonsense. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Aug 27 11:11:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 12:11:09 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? Message-ID: Having an LSID of a service instance (as returned by 'findService' from a registry) I can do two things: ask for data and ask for metadata (connected to this LSID). The metadata is not the topic here (now). What if I ask for data? I can get nothing back, indicating that there is no data associated with this service instance. And I think that I would get nothing because looking at the LSID now it does not seem to indicate any data (it does not have any version etc., for example). I may be wrong, but let's assume, only hypotetically, that I am not wrong and that really I do not get back any data. That's a pity because I want to improve my cache-aware clients by storing LSID in my cache, then asking for a list of services, and by comparing what I have and what I get, I can update in my cache only services that changed. Two problems with that: 1) The list of services (method retrieveServices) does not return LSIDs. Bad luck. Mark, you sent an email saying that lsid attribute is now everywhere. Well, it is not... 2) LSID resolver does return nothing when asking for data (if my hophoteziz above is rigth). Can this be fixed please? Thanks you, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 11:15:15 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 27 Aug 2005 11:15:15 +0000 GMT Subject: [MOBY-dev] what are services LSIDs good for? Message-ID: <1178247580-1125141356-cardhu_blackberry.rim.net-18035-@engine10-cell01> I think I said it was returned on the new codebase, which is only running on the test server - is that the one you are hitting? We thought about keeping trtack of versions and sending the WSDL of the service as the data, but the discussion bogged down on whether that was really what service data *should* be, so it never got resolved (excuse the pun!) M -----Original Message----- From: Martin Senger Date: Sat, 27 Aug 2005 12:11:09 To:Moby Developers Subject: [MOBY-dev] what are services LSIDs good for? Having an LSID of a service instance (as returned by 'findService' from a registry) I can do two things: ask for data and ask for metadata (connected to this LSID). The metadata is not the topic here (now). What if I ask for data? I can get nothing back, indicating that there is no data associated with this service instance. And I think that I would get nothing because looking at the LSID now it does not seem to indicate any data (it does not have any version etc., for example). I may be wrong, but let's assume, only hypotetically, that I am not wrong and that really I do not get back any data. That's a pity because I want to improve my cache-aware clients by storing LSID in my cache, then asking for a list of services, and by comparing what I have and what I get, I can update in my cache only services that changed. Two problems with that: 1) The list of services (method retrieveServices) does not return LSIDs. Bad luck. Mark, you sent an email saying that lsid attribute is now everywhere. Well, it is not... 2) LSID resolver does return nothing when asking for data (if my hophoteziz above is rigth). Can this be fixed please? Thanks you, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Sat Aug 27 11:25:43 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 12:25:43 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <1178247580-1125141356-cardhu_blackberry.rim.net-18035-@engine10-cell01> Message-ID: > I think I said it was returned on the new codebase, which is only > running on the test server - is that the one you are hitting? > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > We thought about keeping trtack of versions and sending the WSDL of > the service as the data, but the discussion bogged down on whether > that was really what service data *should* be, so it never got > resolved (excuse the pun!) > I know about this discussion. I actually do not care what will be returned back (at least not now), but I do care that the LSID of a registered service will chnage if I re-register the same service and I change something in it. That's what LSIDs are for, not? Can that be done? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Aug 27 16:21:27 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 27 Aug 2005 09:21:27 -0700 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <43109307.70402@illuminae.com> Hit the test server: http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl We are planning to keep version numbers of services, but this is waiting on the agent, and the agent is waiting on the final decision on an RDF document format describing a service. Eddie is back from holiday on Monday and this is the first thing on his list, so it should all come together quickly from here on! M Martin Senger wrote: >>I think I said it was returned on the new codebase, which is only >>running on the test server - is that the one you are hitting? >> >> >> > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > > > >>We thought about keeping trtack of versions and sending the WSDL of >>the service as the data, but the discussion bogged down on whether >>that was really what service data *should* be, so it never got >>resolved (excuse the pun!) >> >> >> > I know about this discussion. I actually do not care what will be >returned back (at least not now), but I do care that the LSID of a >registered service will chnage if I re-register the same service and I >change something in it. That's what LSIDs are for, not? > Can that be done? > > Martin > > > From senger at ebi.ac.uk Sat Aug 27 16:30:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 17:30:31 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <43109307.70402@illuminae.com> Message-ID: > Hit the test server: > > http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl > This has only two services and neither of them has an LSID as an attribute. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Aug 27 16:33:25 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 17:33:25 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <43109307.70402@illuminae.com> Message-ID: > We are planning to keep version numbers of services > Good. Please keep in mind my suggestion *not* to return WSDL as service data (I told it to Eddie already in Malaga; there is no sense to duplicate this feature if we have it already in registry API) but returns instead a fingerprint of data that are registered. So if a provider re-register the LSID changes and people can se that a new version of a service is there. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From tmo at ebi.ac.uk Sat Aug 27 16:49:43 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Sat, 27 Aug 2005 17:49:43 +0100 Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <431099A7.7000902@ebi.ac.uk> Martin Senger wrote: >>We are planning to keep version numbers of services >> > > Good. Please keep in mind my suggestion *not* to return WSDL as service > data (I told it to Eddie already in Malaga; there is no sense to duplicate > this feature if we have it already in registry API) but returns instead a > fingerprint of data that are registered. So if a provider re-register the > LSID changes and people can se that a new version of a service is there. Should there be anything returned as LSID data for a service? A service is an abstract entity, it doesn't have a physical existance so it's meaningless (according to the LSID specification) to return data for it. Something like a protein sequence has a real world entity which can have various literal representations (hence having an abstract root sequence object which referes in the metadata to various concrete LSIDs for each format) but in this case there is no real world object. LSIDs for services should only return metadata, they shouldn't return data in any form whatsoever. If you want to return metadata pointing to a servicedescription LSID (or whatever) and have the data for the servicedescription be a WSDL that would sound reasonable but the service itself is an abstract entity. It would be exactly as reasonable to return a bitmap image of the server hardware... Tom From senger at ebi.ac.uk Sat Aug 27 17:03:00 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 18:03:00 +0100 (BST) Subject: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <431099A7.7000902@ebi.ac.uk> Message-ID: Tom, No, Tom, I disagree. There is no reason why abstract term/entities could not have a real data associated. And I gave a good reason how I would use such data. A "service instance" (an unfortunate name of a service fingerprint in a registry invented by a bilogist) is a real object in a registry, and I am asking to give LSID data to reflect the fact that it is important and useful to know whether such object in registry changed or not. Of course, and you are right, that the same can be achieved from metadata. But it would mean that if I need information about all services, I would need to go to all service providers (because they act as LSID metadata resolvers) - and not just to one place where this information is already stored. And, to be fair, where the API for such simple task is easy enough. As long as we have a central registry (and everytime I listen to Mark I have feeling that he is going as much as possible not to have it :-)) why not to use it efficiently for what it was designed (this time the same biologist had luckier hand). Nice to hear again from you, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sun Aug 28 02:50:37 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun, 28 Aug 2005 02:50:37 +0000 GMT Subject: [MOBY-dev] Migration of database to new API Message-ID: <17778361-1125197479-cardhu_blackberry.rim.net-5182-@engine08-cell01> I don't see how flipping names back and forth over different underlying structures is a "meaningful and consistent" strategy... ?!?!?!!!???! M -----Original Message----- From: Benjamin Good Date: Sat, 27 Aug 2005 15:37:26 To:markw at illuminae.com, Core developer announcements Subject: Re: [MOBY-dev] Migration of database to new API Jumping in since I was mentioned ... In the current version of moby, as I understand it at least, I have to side with Martin on this (sorry Mark, don't fire me!). Ahab, as well as other generic clients, benefits substantially from meaningful object and service names. Taking your (Mark's) argument further, we might as well eliminate human-readable names altogether and simply assign a unique number to each one - which is fine for the use as a machine name, but totally useless to an anonymous human user of the data-type. To be precise, in the current formulation of BioMoby, the ONLY semantics associated with the data-types are encoded in the names of the objects. Thus, until we have a consistent framework for encoding semantics in another more robust fashion, like a separate ontology that has nothing to do with syntax, we should at least attempt to encourage meaningful and consistent naming strategies. -Ben On Aug 26, 2005, at 6:12 PM, mark wilkinson wrote: > I strongly disagree in return :-) > > If I have an object called "sequence" there is no indication in the > name that it is a fasta sequence or an embl sequence or a genbank > sequence or whatever. The fact that it is called sequence-v2 is no > more nor less confusing! > > (Ben is sitting here beside me in the pub chuckling about the > dangers of mixing semantics meaning into names :-) ) > > M > > > -----Original Message----- > From: Martin Senger > Date: Sat, 27 Aug 2005 02:06:55 > To:markw at illuminae.com, Core developer announcements dev at portal.open-bio.org> > Cc:mobydev > Subject: Re: [MOBY-dev] Migration of database to new API > > >> There is no need for a name change again. The object will forever >> be called -v2 >> >> It's just an identifier... >> >> > Strongly disagree. The names are visible to people in many > clients that > list them. They should be named sensibly. Adding an artificial > suffix v2 > just without any compelling reasons is a bad design (and there is no > compelling reason for that). > I will better stop now (you got me agian!?)... > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > >_______________________________________________ > 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 > > -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Mon Aug 29 14:32:30 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 29 Aug 2005 15:32:30 +0100 (BST) Subject: [MOBY-dev] Moses - Moby Services Support In-Reply-To: <1476.82.66.216.27.1118945157.squirrel@82.66.216.27> Message-ID: Hi all, My first month at Philippines, at IRRI, is almost finished. So it's time to announce some progress :-) I have commited code and a lot of documentation helping to write Biomoby services in Java. The idea is to generate classes for all registered data types and then generate skeleton for a new service. Its developer can extend such skeleton , put there the business logic without worries about the Biomoby XML and about the SOAP itself. These things should be hidden. It is similar what Paul Gordon provides for the clients, but here you can use strongly-type approach (having all data types generated). Or, you can say, that we can have more ways to do the same, like in Perl :-) As (almost) a side-effect, the generated code, because it has rich API/javadoc comments, can be used as a primitive browser of the biomoby registry. Here you can see the API for all data types and for all services as they are today (when I find a place where I can run a cronjob, we can have this API up-to-date anytime you look): http://www.ebi.ac.uk/~senger/jMoby/APIservices/index.html The documentation is in jMoby and can be viewed at: http://biomoby.org/moby-live/Java/docs/Moses.html. I hope you'll enjoy it and I am happy to hear your suggestions, bug reports (remember there is also a bugzilla open now, but feel free to send emails direcly to me) and anything bout Moses. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From wangch at cpsc.ucalgary.ca Mon Aug 29 17:44:34 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Mon, 29 Aug 2005 11:44:34 -0600 Subject: [MOBY-dev] Question on parser References: <001901c59e5c$30eebfa0$346dd696@ac.uma.es> <1124209283.18621.85.camel@bioinfo.icapture.ubc.ca> Message-ID: <43134982.4020503@cpsc.ucalgary.ca> Hi all, I have a question about the parser. I am working on making my service to take mutiple sequences (up to 5000 and more) input. When I tested on 800 sequences, the time to take the parser to parse a 800 sequences is about 3 mins and 32 seconds. It took 14 mins to parse a 2000 sequences. It seems to take longer time when the input sequence size increases. Is this normal? I think the time should not be too much difference for parsing different size sequence input. Could anybody explain this "problem" to me? Thanks. Joyce From markw at illuminae.com Mon Aug 29 17:45:55 2005 From: markw at illuminae.com (mark wilkinson) Date: Mon, 29 Aug 2005 17:45:55 +0000 GMT Subject: [MOBY-dev] Re: Question on parser Message-ID: <1690593290-1125337603-cardhu_blackberry.rim.net-28949-@engine13-cell01> Define "parser"... What parser are you talking about? M -----Original Message----- From: Chunyan Wang Date: Mon, 29 Aug 2005 11:44:34 To:markw at illuminae.com, Core developer announcements Subject: Question on parser Hi all, I have a question about the parser. I am working on making my service to take mutiple sequences (up to 5000 and more) input. When I tested on 800 sequences, the time to take the parser to parse a 800 sequences is about 3 mins and 32 seconds. It took 14 mins to parse a 2000 sequences. It seems to take longer time when the input sequence size increases. Is this normal? I think the time should not be too much difference for parsing different size sequence input. Could anybody explain this "problem" to me? Thanks. Joyce -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Mon Aug 29 17:49:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 29 Aug 2005 18:49:59 +0100 (BST) Subject: [MOBY-dev] Question on parser In-Reply-To: <43134982.4020503@cpsc.ucalgary.ca> Message-ID: > Could anybody explain this "problem" to me? Thanks. > What language are you using, what XML library in that language? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Aug 29 19:45:07 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 29 Aug 2005 12:45:07 -0700 Subject: [moby] Re: [MOBY-dev] what are services LSIDs good for? In-Reply-To: References: Message-ID: <1125344707.16473.17.camel@bioinfo.icapture.ubc.ca> On Sat, 2005-08-27 at 17:30 +0100, Martin Senger wrote: > This has only two services and neither of them has an LSID as an > attribute. I think they have an LSID attribute (or at least, they do when I make the call), but that attribute has no value. I have just added an LSID value into the database manually so that you have something to retrieve, but don't try to resolve it, because it isn't "real" M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Mon Aug 29 19:45:37 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Mon, 29 Aug 2005 13:45:37 -0600 Subject: [MOBY-dev] Question on parser References: Message-ID: <431365E1.7080800@cpsc.ucalgary.ca> Martin Senger wrote: >>Could anybody explain this "problem" to me? Thanks. >> >> >> > What language are you using, what XML library in that language? > I am using Perl and XML::DOM. I am using "genericServiceInputParser($data)" to parse the input sequence in my service. By the way, I want to let you know I fixed timeout problem. Thanks for your suggestion. Joyce > Martin > > > From senger at ebi.ac.uk Tue Aug 30 00:06:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 30 Aug 2005 01:06:09 +0100 (BST) Subject: [moby] Re: [MOBY-dev] what are services LSIDs good for? In-Reply-To: <1125344707.16473.17.camel@bioinfo.icapture.ubc.ca> Message-ID: > I think they have an LSID attribute (or at least, they do when I make > the call), but that attribute has no value. > Yes, that was also my observation. Hard to test if it is empty :-) > but don't try to resolve it, because it isn't "real" > Let us know please where things are real :-) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Aug 29 23:36:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 29 Aug 2005 16:36:34 -0700 Subject: [MOBY-dev] Production registry now running on new codebase Message-ID: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Tue Aug 30 02:08:44 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue, 30 Aug 2005 02:08:44 +0000 GMT Subject: [MOBY-dev] Moby central "Relationships" function is buggy Message-ID: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Hi all, Don't trust the output from "Relationships" in moby central. It seems to return only the immediate parent and root. I'm working on it. M -----Original Message----- From: Mark Wilkinson Date: Mon, 29 Aug 2005 16:36:34 To:mobydev Subject: [MOBY-dev] Production registry now running on new codebase Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 _______________________________________________ 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 Tue Aug 30 02:08:44 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue, 30 Aug 2005 02:08:44 +0000 GMT Subject: [MOBY-dev] Moby central "Relationships" function is buggy Message-ID: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Hi all, Don't trust the output from "Relationships" in moby central. It seems to return only the immediate parent and root. I'm working on it. M -----Original Message----- From: Mark Wilkinson Date: Mon, 29 Aug 2005 16:36:34 To:mobydev Subject: [MOBY-dev] Production registry now running on new codebase Hi all, The production registry at mobycentral.icapture.ubc.ca is now running the codebase that is in the current CVS. I did this as a "finger in the dike" measure to prevent new objects from being registered that don't follow the correct inheritance patterns, and to prevent new services from being registered that do not have named inputs and outputs. This also gives you a chance to see what the new messages look like, including their use of LSID's throughout. The v0.87 API explains what the messages should look like. I haven't updated the client code on the Perl side to extract the lsid's from these messages yet, but that is coming. The gbrowse_moby code still seems to work with this new codebase so we appear to still be relatively backwards-compatible :-) Cheers everyone! Mark -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From carrere at toulouse.inra.fr Tue Aug 30 06:36:32 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Tue, 30 Aug 2005 08:36:32 +0200 Subject: [MOBY-dev] Question on parser In-Reply-To: <431365E1.7080800@cpsc.ucalgary.ca> References: <431365E1.7080800@cpsc.ucalgary.ca> Message-ID: <4313FE70.80308@toulouse.inra.fr> Hi all, I got the same problem when I wanted to parse huge XML files. That's why I have written a clone of CommonSub.pm using "xsltproc" to parse MOBY message. Then the parsing time problem was removed. However, how do you fixed timeout problem ? Sebastien Chunyan Wang wrote: > > > Martin Senger wrote: > >>> Could anybody explain this "problem" to me? Thanks. >>> >>> >> >> What language are you using, what XML library in that language? >> > I am using Perl and XML::DOM. I am using > "genericServiceInputParser($data)" to parse the input sequence in my > service. > By the way, I want to let you know I fixed timeout problem. Thanks for > your suggestion. > > Joyce > >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Tue Aug 30 15:01:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 30 Aug 2005 08:01:00 -0700 Subject: [moby] Re: [MOBY-dev] Question on parser In-Reply-To: <4313FE70.80308@toulouse.inra.fr> References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> Message-ID: <1125414060.19194.26.camel@bioinfo.icapture.ubc.ca> On Tue, 2005-08-30 at 08:36 +0200, Sebastien Carrere wrote: > That's why I have written a clone of CommonSub.pm using "xsltproc" to > parse MOBY message. Would you be willing to add this to the CVS? > However, how do you fixed timeout problem ? In the 1.0 release we should have a spec for asynchronous services, so this problem will hopefully not be as severe... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From wangch at cpsc.ucalgary.ca Tue Aug 30 16:17:56 2005 From: wangch at cpsc.ucalgary.ca (Chunyan Wang) Date: Tue, 30 Aug 2005 10:17:56 -0600 Subject: [MOBY-dev] Question on parser References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> Message-ID: <431486B4.6060700@cpsc.ucalgary.ca> Hi, I changed TimeOut from default to 50000 in the Apache config to fix timeout problem. How big was your XML file when you had problem? Cheers, Joyce Sebastien Carrere wrote: > Hi all, > > I got the same problem when I wanted to parse huge XML files. > That's why I have written a clone of CommonSub.pm using "xsltproc" to > parse MOBY message. > Then the parsing time problem was removed. > > However, how do you fixed timeout problem ? > > Sebastien > > Chunyan Wang wrote: > >> >> >> Martin Senger wrote: >> >>>> Could anybody explain this "problem" to me? Thanks. >>>> >>>> >>> >>> >>> What language are you using, what XML library in that language? >>> >> I am using Perl and XML::DOM. I am using >> "genericServiceInputParser($data)" to parse the input sequence in my >> service. >> By the way, I want to let you know I fixed timeout problem. Thanks >> for your suggestion. >> >> Joyce >> >>> Martin >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > From leolxshen at gmail.com Tue Aug 30 21:03:43 2005 From: leolxshen at gmail.com (leo shen) Date: Tue, 30 Aug 2005 14:03:43 -0700 Subject: [MOBY-dev] xml schema generator for Moby object committed Message-ID: Hi all, The java codes of XML schema generator has been commited in org/biomoby/shared/schema Cheers From dgpisano at cnb.uam.es Thu Aug 25 12:36:01 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu, 25 Aug 2005 14:36:01 +0200 Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <430DBB31.8070009@cnb.uam.es> Dear all, Here you have the Exception (Errors) reporting Request for Comments document. We have included some interesting comments taken from discussions / lists and rewritten it to make it more clear. It presents only one proposal to deal with error information, although it has also presents an extension option to report errors related to Simples into Collections. That extension can be considerered optional (we in the INB will be using it anyways). Please feel free to comment / discuss about it. Also, please feel free to use the document as guinea pig if we set up a procedure to deal with RFPs/RFCs in the MOBY community ;-) Regards, David Martin Senger escribi?: >>>but the problem is that we do not have (still) a procedure how to make >>>changes in the API. >>> >>> >>Correct. >> >> >> > So how are we going to solve this? > This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). > > 2) Then a calendar (deadline) must be attached to it. It can be >suggested already by the author of the RFP/RFC, or a default value is >attached. We need to say what is a default value. > > 3) The RFP can be considered only if the change is back-uped by two >(three?) other developers. They do not need to fully agree with all >details, their role is just to prevent overhelming number of small >changes coming fast. > > 4) It is also considered only if somebody has resources to really >implement the change. This should be also a part of the clendar ("when it >can be done"). > > 5) Discussion on RFC, changes re-distributed, etc. In charge is the >author of the original RFC. Deadline can be extended - don't be too formal >here. > > 6) Now the tricky part: I think taht there should be only few people >(major developers) who can vote on it. This is called an "Architecture >Board" at OMG and guarantees that the changes are hopefully not breaking >other things. > > 7) Then comes implementation, documenttaion etc. > > Cheers, > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v1.5.doc Type: application/msword Size: 139776 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available URL: From goodb at interchange.ubc.ca Sat Aug 27 22:37:26 2005 From: goodb at interchange.ubc.ca (Benjamin Good) Date: Sat, 27 Aug 2005 15:37:26 -0700 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> References: <1068324378-1125105213-cardhu_blackberry.rim.net-31192-@engine13-cell01> Message-ID: Jumping in since I was mentioned ... In the current version of moby, as I understand it at least, I have to side with Martin on this (sorry Mark, don't fire me!). Ahab, as well as other generic clients, benefits substantially from meaningful object and service names. Taking your (Mark's) argument further, we might as well eliminate human-readable names altogether and simply assign a unique number to each one - which is fine for the use as a machine name, but totally useless to an anonymous human user of the data-type. To be precise, in the current formulation of BioMoby, the ONLY semantics associated with the data-types are encoded in the names of the objects. Thus, until we have a consistent framework for encoding semantics in another more robust fashion, like a separate ontology that has nothing to do with syntax, we should at least attempt to encourage meaningful and consistent naming strategies. -Ben On Aug 26, 2005, at 6:12 PM, mark wilkinson wrote: > I strongly disagree in return :-) > > If I have an object called "sequence" there is no indication in the > name that it is a fasta sequence or an embl sequence or a genbank > sequence or whatever. The fact that it is called sequence-v2 is no > more nor less confusing! > > (Ben is sitting here beside me in the pub chuckling about the > dangers of mixing semantics meaning into names :-) ) > > M > > > -----Original Message----- > From: Martin Senger > Date: Sat, 27 Aug 2005 02:06:55 > To:markw at illuminae.com, Core developer announcements dev at portal.open-bio.org> > Cc:mobydev > Subject: Re: [MOBY-dev] Migration of database to new API > > >> There is no need for a name change again. The object will forever >> be called -v2 >> >> It's just an identifier... >> >> > Strongly disagree. The names are visible to people in many > clients that > list them. They should be named sensibly. Adding an artificial > suffix v2 > just without any compelling reasons is a bad design (and there is no > compelling reason for that). > I will better stop now (you got me agian!?)... > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > > _______________________________________________ > 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 > > From dgpisano at cnb.uam.es Thu Aug 25 12:36:01 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu, 25 Aug 2005 14:36:01 +0200 Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <430DBB31.8070009@cnb.uam.es> Dear all, Here you have the Exception (Errors) reporting Request for Comments document. We have included some interesting comments taken from discussions / lists and rewritten it to make it more clear. It presents only one proposal to deal with error information, although it has also presents an extension option to report errors related to Simples into Collections. That extension can be considerered optional (we in the INB will be using it anyways). Please feel free to comment / discuss about it. Also, please feel free to use the document as guinea pig if we set up a procedure to deal with RFPs/RFCs in the MOBY community ;-) Regards, David Martin Senger escribi?: >>>but the problem is that we do not have (still) a procedure how to make >>>changes in the API. >>> >>> >>Correct. >> >> >> > So how are we going to solve this? > This is *a* solution (based on my experiences from the OMG process): > > 1) Anybody can make a suggestion to make a change in API (we can call >it RFP - request for proposal, or RFC - request for comments, or >whatever). An example of such thing are the proposals from Oswaldo and his >collegues (eventhough I would not expect to have it always so perfectly >written :-)). Important is that it must *say* this is a RFP/RFC, not just >a wish in email. We will keep a place for it (bugzilla has wishlists?). > > 2) Then a calendar (deadline) must be attached to it. It can be >suggested already by the author of the RFP/RFC, or a default value is >attached. We need to say what is a default value. > > 3) The RFP can be considered only if the change is back-uped by two >(three?) other developers. They do not need to fully agree with all >details, their role is just to prevent overhelming number of small >changes coming fast. > > 4) It is also considered only if somebody has resources to really >implement the change. This should be also a part of the clendar ("when it >can be done"). > > 5) Discussion on RFC, changes re-distributed, etc. In charge is the >author of the original RFC. Deadline can be extended - don't be too formal >here. > > 6) Now the tricky part: I think taht there should be only few people >(major developers) who can vote on it. This is called an "Architecture >Board" at OMG and guarantees that the changes are hopefully not breaking >other things. > > 7) Then comes implementation, documenttaion etc. > > Cheers, > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v1.5.doc Type: application/msword Size: 139776 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available URL: From senger at ebi.ac.uk Wed Aug 31 01:38:51 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:38:51 +0100 (BST) Subject: [MOBY-dev] Production registry now running on new codebase In-Reply-To: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Message-ID: I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger at gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 01:38:51 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:38:51 +0100 (BST) Subject: [MOBY-dev] Production registry now running on new codebase In-Reply-To: <1125358594.17622.4.camel@bioinfo.icapture.ubc.ca> Message-ID: I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger at gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 01:23:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:23:31 +0100 (BST) Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <430DBB31.8070009@cnb.uam.es> Message-ID: Thanks for the updated document. Before I express my comments to it here is a few bits regarding RFC procedure for this proposal (assuming that we agreed on an RFC procedure as, or close to, suggested in previous emails: 1) I second the proposal (so it can become an RFC) 2) I suggest to resolve it (accept or refuse) before September 15 (so this is an RFC calendar). Concretely, I propose that Mark will ask selected voters after this date to vote on it. (BTW, I like and support his idea to have a year-long tenure on the voting list (that's actually very close why OMG has its Architecture Board also with rotating, and *dedicated*, people). Now back to the proposal, here are my comments (I suggest that those comments that are acceptable by the INB authors, and that are not in contradiction with the email discussion, will be incorporate and a new draft will be circulated - perhaps already without reasoning). Generally, I like the proposal, my comments are only about details. 1) The attribute names 'Value' and 'Description' are not intuitive. They should express more what they are about. What about "errorCode" (or only "code") and "errorMessage" (or only "message")? 2) I know that the article name in Simples in Collection is an optional part of the proposal - but I agree with Mark that using there again the term "articleName" is bad (too overloaded). What about to use there a completely different tag, like "elementId"? >From this change (if accepted) follows at once that the attribute name in mobyException should not be "refArticleName" (because sometimes it refers to a non-article name) - so why not to call it just a "ref", or "refElement"? 3) I would like to have (in the exception API handling) a remark that the clients are obliged to be aware that a service can also raise an exception that will be delivered in the SOAP envelope (that is a standard way). As I said, good clients have to do it anyway (because your service does not have always full control what to return back) - so I would keep this option there. 4) Just to keep in synch with other software projects, I would add one more severity level - a simple "message" (so we would have, errors, warnings, messages). 5) The list of codes is not always clear: - should the sub-phrases in 201 be distinguish by a separate code? - 621 (service not available) means actually that the resources the service wishes to use are not available (because if it was a service itself, it would not have any chance to report it, that would be a soap exception mentioned above), - 622 (malformed Moby response) - what is a response here? - and anyway, this may be difficult to catch (I know in SOAP::Lite you do not get control only when the whole XML is parsed) - why do you call some codes "client-side detected errors"? - generally, I would put less codes and rather to define how service providers can expressed their own service-specific codes (by saying in which range they should put such specific codes) 6) Some typos: - articlename attribute should be articleName - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is something else in Biomoby API) 7) Attributes in mobyException (refArticleName, or whatever name we will agree on, and reqQuery) should be made optional - so an exception can refer to the whole response (or to a whole query if only reqQuery is present). With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 01:23:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:23:31 +0100 (BST) Subject: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: <430DBB31.8070009@cnb.uam.es> Message-ID: Thanks for the updated document. Before I express my comments to it here is a few bits regarding RFC procedure for this proposal (assuming that we agreed on an RFC procedure as, or close to, suggested in previous emails: 1) I second the proposal (so it can become an RFC) 2) I suggest to resolve it (accept or refuse) before September 15 (so this is an RFC calendar). Concretely, I propose that Mark will ask selected voters after this date to vote on it. (BTW, I like and support his idea to have a year-long tenure on the voting list (that's actually very close why OMG has its Architecture Board also with rotating, and *dedicated*, people). Now back to the proposal, here are my comments (I suggest that those comments that are acceptable by the INB authors, and that are not in contradiction with the email discussion, will be incorporate and a new draft will be circulated - perhaps already without reasoning). Generally, I like the proposal, my comments are only about details. 1) The attribute names 'Value' and 'Description' are not intuitive. They should express more what they are about. What about "errorCode" (or only "code") and "errorMessage" (or only "message")? 2) I know that the article name in Simples in Collection is an optional part of the proposal - but I agree with Mark that using there again the term "articleName" is bad (too overloaded). What about to use there a completely different tag, like "elementId"? >From this change (if accepted) follows at once that the attribute name in mobyException should not be "refArticleName" (because sometimes it refers to a non-article name) - so why not to call it just a "ref", or "refElement"? 3) I would like to have (in the exception API handling) a remark that the clients are obliged to be aware that a service can also raise an exception that will be delivered in the SOAP envelope (that is a standard way). As I said, good clients have to do it anyway (because your service does not have always full control what to return back) - so I would keep this option there. 4) Just to keep in synch with other software projects, I would add one more severity level - a simple "message" (so we would have, errors, warnings, messages). 5) The list of codes is not always clear: - should the sub-phrases in 201 be distinguish by a separate code? - 621 (service not available) means actually that the resources the service wishes to use are not available (because if it was a service itself, it would not have any chance to report it, that would be a soap exception mentioned above), - 622 (malformed Moby response) - what is a response here? - and anyway, this may be difficult to catch (I know in SOAP::Lite you do not get control only when the whole XML is parsed) - why do you call some codes "client-side detected errors"? - generally, I would put less codes and rather to define how service providers can expressed their own service-specific codes (by saying in which range they should put such specific codes) 6) Some typos: - articlename attribute should be articleName - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is something else in Biomoby API) 7) Attributes in mobyException (refArticleName, or whatever name we will agree on, and reqQuery) should be made optional - so an exception can refer to the whole response (or to a whole query if only reqQuery is present). With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Aug 31 01:40:20 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed, 31 Aug 2005 01:40:20 +0000 GMT Subject: [MOBY-dev] Production registry now running on new codebase Message-ID: <1929607892-1125452470-cardhu_blackberry.rim.net-30717-@engine12-cell01> Let's use bugzilla rather than the list, though... M -----Original Message----- From: Martin Senger Date: Wed, 31 Aug 2005 02:38:51 To:markw at illuminae.com, Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Production registry now running on new codebase I cannot register a service with name MyTestingService_112233445566. I am sending the following: mobyMyTestingService_112233445566Retrievaltest.test.sengerhttp://localhost:8080/axis/srevicesmartin.senger at gmail.com1 String ... and getting back en error: "malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_]" Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ 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 Aug 31 01:49:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:49:01 +0100 (BST) Subject: [MOBY-dev] Moby central "Relationships" function is buggy In-Reply-To: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Message-ID: > Don't trust the output from "Relationships" in moby central. It seems > to return only the immediate parent and root. I'm working on it. > Actually, for me, it does not return anything, at all: METHOD CALL: Relationships ------------ GenericSequenceISAHASAHAS1 ------------ METHOD RETURN: ------------ Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 01:49:01 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 02:49:01 +0100 (BST) Subject: [MOBY-dev] Moby central "Relationships" function is buggy In-Reply-To: <1455548939-1125367772-cardhu_blackberry.rim.net-21509-@engine13-cell01> Message-ID: > Don't trust the output from "Relationships" in moby central. It seems > to return only the immediate parent and root. I'm working on it. > Actually, for me, it does not return anything, at all: METHOD CALL: Relationships ------------ GenericSequenceISAHASAHAS1 ------------ METHOD RETURN: ------------ Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 03:30:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 04:30:12 +0100 (BST) Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: Frank, I am slowly starting to read your version of API. I am sorry that I have not read it whole, and that I am giving the comments step by step. The first few comments about the registry API: * I think that the first page (with a list of methods) should also have (even start with) a list of links to objects used by these methods, such as a query object. * I disagree with labelling the deregisteService as depracated. As far as I understood, it will be still around for quick resgiter/unregister cycle where I am not conceedrn about security (that somebody can deregister my service). So from the API point of view it is a normal method, not a deprecated one. Mark? * service protocol "moby" is actually a service category, not a protocol I think * I would move definition of a "A MOBY compliant service" to the section about services API (here may be just a link to it). As I said I am really concern that these two APIs are (or were before you enter the scene) confusing, so make them as separate as possible. * retrieveResourceURLs has a wrong description (something about providers) * some details have also categories cgi.soap, some not... I suggest to remove all cgi and sopa for now (we will have in in the CVS if we need it to re-introsduce it later; surely the 'soap' category bring nothing than a confusion (isn't it current moby based on soap? - I know how it is, but newbies perhaps not) * the notes starting the section " MOBY Central Procedure Call XML" shoulod be on the first page, or linked in the first page". And the last (but not an unimportant) general comment: the XML-based API should be expressed as DTD (which is more preferable in this context, XSD is not so human readable). Also the details about individual tags and attributes are quitel imited now. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Aug 31 03:30:12 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 31 Aug 2005 04:30:12 +0100 (BST) Subject: [MOBY-dev] RFC's in MOBY In-Reply-To: <5.2.1.1.2.20050824135125.011f2ea0@email.med.harvard.edu> Message-ID: Frank, I am slowly starting to read your version of API. I am sorry that I have not read it whole, and that I am giving the comments step by step. The first few comments about the registry API: * I think that the first page (with a list of methods) should also have (even start with) a list of links to objects used by these methods, such as a query object. * I disagree with labelling the deregisteService as depracated. As far as I understood, it will be still around for quick resgiter/unregister cycle where I am not conceedrn about security (that somebody can deregister my service). So from the API point of view it is a normal method, not a deprecated one. Mark? * service protocol "moby" is actually a service category, not a protocol I think * I would move definition of a "A MOBY compliant service" to the section about services API (here may be just a link to it). As I said I am really concern that these two APIs are (or were before you enter the scene) confusing, so make them as separate as possible. * retrieveResourceURLs has a wrong description (something about providers) * some details have also categories cgi.soap, some not... I suggest to remove all cgi and sopa for now (we will have in in the CVS if we need it to re-introsduce it later; surely the 'soap' category bring nothing than a confusion (isn't it current moby based on soap? - I know how it is, but newbies perhaps not) * the notes starting the section " MOBY Central Procedure Call XML" shoulod be on the first page, or linked in the first page". And the last (but not an unimportant) general comment: the XML-based API should be expressed as DTD (which is more preferable in this context, XSD is not so human readable). Also the details about individual tags and attributes are quitel imited now. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From carrere at toulouse.inra.fr Wed Aug 31 06:46:36 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Wed, 31 Aug 2005 08:46:36 +0200 Subject: [MOBY-dev] Question on parser In-Reply-To: <431486B4.6060700@cpsc.ucalgary.ca> References: <431365E1.7080800@cpsc.ucalgary.ca> <4313FE70.80308@toulouse.inra.fr> <431486B4.6060700@cpsc.ucalgary.ca> Message-ID: <4315524C.6040307@toulouse.inra.fr> The MOBY message that I wanted to parse was a 12 Megabyte one. The web-service concerned is: name: ImgaGetTigrXMLEntriesFromKeyword uri: bioinfo.genopole-toulouse.prd.fr input: String Output(s): /Collection of /text-xml, as TIGRXML and /Collection of /IMGA_Accession, as IMGA_Accession I think this is a little bit extreme, but it works fine now. Sebastien Chunyan Wang wrote: > Hi, > I changed TimeOut from default to 50000 in the Apache config to fix > timeout problem. > How big was your XML file when you had problem? > Cheers, > > Joyce > > Sebastien Carrere wrote: > >> Hi all, >> >> I got the same problem when I wanted to parse huge XML files. >> That's why I have written a clone of CommonSub.pm using "xsltproc" to >> parse MOBY message. >> Then the parsing time problem was removed. >> >> However, how do you fixed timeout problem ? >> >> Sebastien >> >> Chunyan Wang wrote: >> >>> >>> >>> Martin Senger wrote: >>> >>>>> Could anybody explain this "problem" to me? Thanks. >>>>> >>>>> >>>> >>>> >>>> >>>> What language are you using, what XML library in that language? >>>> >>> I am using Perl and XML::DOM. I am using >>> "genericServiceInputParser($data)" to parse the input sequence in my >>> service. >>> By the way, I want to let you know I fixed timeout problem. Thanks >>> for your suggestion. >>> >>> Joyce >>> >>>> Martin >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Wed Aug 31 19:39:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 31 Aug 2005 12:39:44 -0700 Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-31 at 02:23 +0100, Martin Senger wrote: > 2) I suggest to resolve it (accept or refuse) before September 15 (so > this is an RFC calendar). Concretely, I propose that Mark will ask > selected voters after this date to vote on it. OK. I will be on holiday that day in the mountains (likely with no net access even from my cell phone) so perhaps David or Martin can call the vote in my absence? > (BTW, I like and > support his idea to have a year-long tenure on the voting list (that's > actually very close why OMG has its Architecture Board also with > rotating, and *dedicated*, people). Super! I'll try to write-up a formal "constitution" document in the next few days... > 1) The attribute names 'Value' and 'Description' are not > intuitive. They should express more what they are about. What about > "errorCode" (or only "code") and "errorMessage" (or only "message")? I agree. > 2) I know that the article name in Simples in Collection is an > optional part of the proposal - but I agree with Mark that using there > again the term "articleName" is bad (too overloaded). What about to > use there a completely different tag, like "elementId"? I think I proposed this alternative as well. I do have a deeper concern, however, and I want to discuss this thoroughly before we make any decisions here. It isn't entirely clear to me that there is a need to throw errors on a specific Simple within a Collection. This is very complicated for me to explain clearly, but I will try... A collection is a "semantic unit" - it is the response to a ***single*** input. As such, it cannot be partially erroneous! It is either entirely erroneous, or entirely correct. To throw an error on a single sub-unit of a collection casts doubt on the validity of the entire collection (since you cannot interpret what the collection would have "looked like" had that error not been thrown) and thus the entire collection must be considered flawed. Imagine it this way: What would it mean to have a Blast report where certain HSP's within the Blast report contained error messages? Does it mean that there was a sequence in the underlying database that was somehow incorrectly formatted If so, then the blast provider should have caught that error and not reported that match at all rather than telling the client that there is a flakey sequence in their database. Does it mean that the software is buggy? If so, then the entire report is potentially flawed, and should not have been produced. Does it mean that (in some way) the input sequence was peculiar? If so, then again the entire output is suspect and not just a single HSP within that output. Do you see what I am getting at? The scenario we are trying to accommodate, in my opinion, is impossible if people are using Collections in the way they are intended to be used. > 3) I would like to have (in the exception API handling) a remark that > the clients are obliged to be aware that a service can also raise an > exception that will be delivered in the SOAP envelope (that is a > standard way). As I said, good clients have to do it anyway (because > your service does not have always full control what to return back) - > so I would keep this option there. Absolutely! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Aug 31 19:39:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 31 Aug 2005 12:39:44 -0700 Subject: [personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal In-Reply-To: References: Message-ID: <1125517184.21799.71.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-31 at 02:23 +0100, Martin Senger wrote: > 2) I suggest to resolve it (accept or refuse) before September 15 (so > this is an RFC calendar). Concretely, I propose that Mark will ask > selected voters after this date to vote on it. OK. I will be on holiday that day in the mountains (likely with no net access even from my cell phone) so perhaps David or Martin can call the vote in my absence? > (BTW, I like and > support his idea to have a year-long tenure on the voting list (that's > actually very close why OMG has its Architecture Board also with > rotating, and *dedicated*, people). Super! I'll try to write-up a formal "constitution" document in the next few days... > 1) The attribute names 'Value' and 'Description' are not > intuitive. They should express more what they are about. What about > "errorCode" (or only "code") and "errorMessage" (or only "message")? I agree. > 2) I know that the article name in Simples in Collection is an > optional part of the proposal - but I agree with Mark that using there > again the term "articleName" is bad (too overloaded). What about to > use there a completely different tag, like "elementId"? I think I proposed this alternative as well. I do have a deeper concern, however, and I want to discuss this thoroughly before we make any decisions here. It isn't entirely clear to me that there is a need to throw errors on a specific Simple within a Collection. This is very complicated for me to explain clearly, but I will try... A collection is a "semantic unit" - it is the response to a ***single*** input. As such, it cannot be partially erroneous! It is either entirely erroneous, or entirely correct. To throw an error on a single sub-unit of a collection casts doubt on the validity of the entire collection (since you cannot interpret what the collection would have "looked like" had that error not been thrown) and thus the entire collection must be considered flawed. Imagine it this way: What would it mean to have a Blast report where certain HSP's within the Blast report contained error messages? Does it mean that there was a sequence in the underlying database that was somehow incorrectly formatted If so, then the blast provider should have caught that error and not reported that match at all rather than telling the client that there is a flakey sequence in their database. Does it mean that the software is buggy? If so, then the entire report is potentially flawed, and should not have been produced. Does it mean that (in some way) the input sequence was peculiar? If so, then again the entire output is suspect and not just a single HSP within that output. Do you see what I am getting at? The scenario we are trying to accommodate, in my opinion, is impossible if people are using Collections in the way they are intended to be used. > 3) I would like to have (in the exception API handling) a remark that > the clients are obliged to be aware that a service can also raise an > exception that will be delivered in the SOAP envelope (that is a > standard way). As I said, good clients have to do it anyway (because > your service does not have always full control what to return back) - > so I would keep this option there. Absolutely! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274